Boots to black screen on Wii when a hard drive is plugged in

[Catmansys]

On Wii when a USB hard drive is plugged in it boots to black screen then crash. Removing USB hard drive from USB port fixes issue. Clearly the coding is set to read from hard drive and SD card and issue is somewhere there on latest build. .10.04

[endrift]

Likely a duplicate of #3354. How big is the drive and how is it partitioned?

[Catmansys]

Likely a duplicate of #3354. How big is the drive and how is it partitioned?

No. More like #3106 I too had to use the custom boot dol you gave them for 10.03 because with hard drive it would cause black screen then crash. Upon updating to 10.04 and bug is back. Hardrive is WD black 3tb fat32 32k cluster. No partitions MBR

[endrift]

32K sectors is the problem here, not the partitioning. See my reply to #3354

[Catmansys]

32K sectors is the problem here, not the partitioning. See my reply to #3354

Hold on how does that make sense? The app and the roms are all on SD card not external hard drive. When external hard drive is plugged in app has black screen issue. Again the custom dol you made for problem #3354 fixes this issue. Currently reverted back to that custom dol 10.03 to get it working again. Alternatively I have to unplug hard drive from Wii in order for current 10.04 to launch correctly even though again everything is on my SD card not hard drive. The bug is due to when launching mGBA it scans hard drive even though I did not launch it from there or have any roms there. Maybe code it to not scan external hard drive when launch from SD card.

[Catmansys]

I mean custom dol 10.03 for issue #3106 fixes issue

[endrift]

The reason the build of 0.10.3 still works is that the code I use for interfacing with FAT32 filesystems got updated in 0.10.4. This new version contains a new bug that's causing this. Said bug was not present in 0.10.3 and the issue there was a different bug, also caused by third party code changing out underneath mGBA. This time I'm not sure if there's a quick way to fix it.

[Catmansys]

The reason the build of 0.10.3 still works is that the code I use for interfacing with FAT32 filesystems got updated in 0.10.4. This new version contains a new bug that's causing this. Said bug was not present in 0.10.3 and the issue there was a different bug, also caused by third party code changing out underneath mGBA. This time I'm not sure if there's a quick way to fix it.

My SD card is fat32 also 32k cluster unplugging hard drive from Wii fixes issue in 10.04. Can’t you simply tell the app to NOT scan external USB drive when launching from SD card? That would fix it. I think.

[endrift]

Huh. Perhaps the bug isn't what I thought it was then. I'd like to hear back from the dkP people about this before I dig too much on it.

Regarding not scanning the external USB drive...I'm not specifically telling to to scan the USB drive. I'm telling it to mount FAT32 volumes, and that third-party code I mentioned then scans for all available volumes it can find. That just happens to include you USB hard drive. I would have to tell it to specifically skip the hard drive, and I don't want to do that for the convenience of one user when booting off of SD and having ROMs on an external hard drive is a thing other users may well want.

[Catmansys]

Huh. Perhaps the bug isn't what I thought it was then. I'd like to hear back from the dkP people about this before I dig too much on it.

Regarding not scanning the external USB drive...I'm not specifically telling to to scan the USB drive. I'm telling it to mount FAT32 volumes, and that third-party code I mentioned then scans for all available volumes it can find. That just happens to include you USB hard drive. I would have to tell it to specifically skip the hard drive, and I don't want to do that for the convenience of one user when booting off of SD and having ROMs on an external hard drive is a thing other users may well want.

Hmm. Yes I understand that. But I'm not the only one with a Nintendo Wii and a USB hard drive plugged in you see. So many others will also have this issue. For the record even the Atari 2600 emulator has exactly same issue and requires unplugging of USB hard drive. So whatever issue is, is shared in that app code too. I’m not a coder but am sure it’s a simple setting or line of code in app. Because it’s totally possible to have it working. Im trying to help you come up with a band aid fix for now and hopefully this will be properly fixed in future. But what if you put a setting in INI file like scan USB device to =true and for us that don’t store roms on it can modify the ini and force it to =false or =off? Like I see settings in it. See attached image.

[Catmansys]

I hope something like that would be a temporary fix. Anyway thank you for replying to me and especially thank you for still being part of the Wii hacking scene. I really appreciate it. I’ll leave a summary of issue incase you want to note it down

mGBA ver 0.10.4 (current as of 15 December 2024)
Running on Wii micro SD card fat32 32k cluster no USB hard drive attached boots perfectly fine

Having a hard drive plugged into USB port fat32 32k cluster shows black screen and returns to homebrew channel. Reading from hard drive light is on even though no roms are on it. Exactly as previous 0.10.3 from homebrew browser app OSC ver store.

the custom DOL file created in in issue #3106 fixes USB hard drive being plugged in for .10.3

again thank you for all your work and support and good luck in further fixing/coding of app.

[Extrems]

32K sectors is the problem here, not the partitioning. See my reply to #3354

Nah, it's the 3 TB hard drive. Clusters aren't the same as sectors and aren't really relevant, but that size of hard drive would necessarily have to use 4Kn sectors to have been working with previous software.

[endrift]

But I'm not the only one with a Nintendo Wii and a USB hard drive plugged in you see.

Yes, that is what I said.

So many others will also have this issue.

Not necessarily. As explained, this won't always happen and it depends on the drive.

I’m not a coder but am sure it’s a simple setting or line of code in app.

I reviewed the relevant code for how to disable that, or if it was even possible, before posting that. It is technically possible, but it's very hacky to do so. I would much rather wait for dkP to fix the bug on their end and pull in an updated version to lay this to rest.

[Extrems]

The latest libdvm has a g_dvmOgcUsbMount weak global to disable it.

[Catmansys]

The latest libdvm has a g_dvmOgcUsbMount weak global to disable it.

Thanks Extrems you’re another legend in the Wii hacking scene.

[Extrems]

Ah, if only you knew how stupid this situation actually is and the politics behind it. 😅

[Catmansys]

Ah, if only you knew how stupid this situation actually is and the politics behind it. 😅

Yeah I got no idea lol. I know this is off topic but I couldn’t find a way to message you on not64. But when using a classic controller pro attached to Wii mote then exiting not64 to homebrew channel the whole channel spazzes out, sometimes even taking screenshots. It’s as if some memory leak or something is triggering it.

[endrift]

To be more clear: it seems the problem lies ultimately not with the formatting, but the sector size of the drive itself. Most drives either have or pretend to have 512 byte sectors. Most modern hard drives fall into either the 512e (512 byte emulated) camp, which exposes 512 byte sectors but are actually 4096 byte sectors under the hood, or the 4Kn (4K byte native) camp, which exposes its real 4096 byte sectors as such. 512e is very common, as a lot of software expects drives to have 512 byte sectors, even if there's no hard guarantee that this will be the case. This bug is a case of where that expectation falls apart.

It seems like you have a 4Kn drive, which is pretty rare except in obscenely large drives or enterprise drives. I checked and even though I do have drives that large, none of them are 4Kn, only 512e. The person on the dkP team confirmed that the old version of the code did support non-512 byte sectors and the new didn't, but lacked a 4Kn drive with which to test any fixes.

[Extrems]

Some 512e drives can be switched to 4Kn using HUGO (WD) or SeaChest (Seagate). Large external drives usually contain enterprise drives, and as such can be switched.

[endrift]

I should note that switching will corrupt the drive. If you do switch you should back up the data first and then restore it after switching.

[Extrems]

I found on mine that the data remained fully intact, but obviously couldn't be mounted as the sector numbers were incorrect.

[endrift]

From a usability perspective I would count that as corrupt, just reversibly so.

[Catmansys]

To be more clear: it seems the problem lies ultimately not with the formatting, but the sector size of the drive itself. Most drives either have or pretend to have 512 byte sectors. Most modern hard drives fall into either the 512e (512 byte emulated) camp, which exposes 512 byte sectors but are actually 4096 byte sectors under the hood, or the 4Kn (4K byte native) camp, which exposes its real 4096 byte sectors as such. 512e is very common, as a lot of software expects drives to have 512 byte sectors, even if there's no hard guarantee that this will be the case. This bug is a case of where that expectation falls apart.

It seems like you have a 4Kn drive, which is pretty rare except in obscenely large drives or enterprise drives. I checked and even though I do have drives that large, none of them are 4Kn, only 512e. The person on the dkP team confirmed that the old version of the code did support non-512 byte sectors and the new didn't, but lacked a 4Kn drive with which to test any fixes.

here is drive info it it helps.