Luma3ds: ARM9 exception if L is held on boot without an emuNAND present.

[ksanislo]

The system will throw an exception if L is held down on boot, even when there is no emunand/rednand on the SD card.

There should be a check to see if there's a NAND image/partition to be booted before just trying to go for it.

[TuxSH]

Can't reproduce. Also, that check is done.

[ksanislo]

Here are the crash dumps... Anything else I can provide that will help?

dumps.zip

[TuxSH]

Are you sure there's no emuNAND?

Someone had a similar bug (@liomajor)

[ksanislo]

I reformatted the SD card on-console with the latest version of Emunand9, using the no emunand option. Perhaps it doesn't clean everything up?

[TuxSH]

Try to uncheck "autoboot sysnand" to see...

[ksanislo]

Same crash by default, and holding L boots properly.

[AuroraWright]

Something tells me you had a GW emuNAND once on that SD card, and the NCSD header still wasn't deleted by files. You should make a FULL format of the card (not a "quick format"), let it overwrite EVERYTHING, and try again.

[ksanislo]

Yeah, I definitely had a redNAND, which I deleted with EmuNAND9's format option. I take it that isn't enough to avoid how luma checks for if one exists.

Can you tell me how much of the SD needs to be wiped to avoid the check? I'd rather zero just the blocks that are being looked at than write the full size of the card.

[TuxSH]

Yep, and that was the point of my question (to check if luma detected the "deleted" emunand).

[Margen67]

If you look at the SD card in Disk Management do you see any "Unallocated" partitions?

[ksanislo]

The FAT partition is full size of the sd. The problem is that the check here in https://github.com/AuroraWright/Luma3DS/blob/master/source/emunand.c#L28 is bugged to fuck. It should be looking at the partition table to determine if there's even possible space set aside for an emunand/rednand before trying to check for magic. The magic check alone is insufficient and doesn't really follow any kind of standard.

I just manually wiped the magic string's sector from my SD and it stopped misdetecting for me at least.

[Mrrraou]

@ksanislo Don't blame Luma for this. There is no proper way of checking if the user uses EmuNAND or RedNAND. But indeed, the partition table _could_ be checked, even though that would be very complex to handle all the cases.

[ksanislo]

@Mrrraou but it's definitely a luma bug that causes this, and it's /not/ hard to check. Pull the partition table from the MBR, find the first FAT partition (which the 3DS is going to use) and make sure there's enough space between 0 and the start of that partition to hold an emunand. If not, then obviously there's no emunand and the magic check shouldn't be performed.

How MBR partitioning works hasn't changed in decades, even if the emunand doesn't have it's own partition. That it's not being checked to ensure that there's something reserved somewhere is just lazy coding.

[Mrrraou]

Checking if a partition is big enough to hold an EmuNAND/RedNAND but not too big is definitely possible; but can still cause bugs: people with multiple RedNANDs/EmuNANDs and unallocated space can cause trouble. Newer EmuNAND/RedNANDs are writing to the MBR to add the partition for EmuNAND/RedNAND. However, knowing the difference between an EmuNAND and a RedNAND is hard.

[ksanislo]

You don't need to know the difference to be able to say there's no emunand or rednand, so trying to boot will cause an exception and fail. And luma is 100% free to enforce proper MBR partitioning in their support of emunand/rednand if they so choose. Hell, once you've identified a *nand image in unpartitioned space, it could even be converted to a partition directly without modifying the data. Just prompt to press A for it on boot the first time.

However actually fixing this bug doesn't require any changes of the sort, it just needs to do a proper job of verifying things look correct before trying to boot.

[Mrrraou]

I never said that knowing the difference was needed to know if there was one. But there are a lot of kinds of redNAND/emuNAND: there are already multiple NAND sizes, and there are even "minimal" sizes, without the padding at the end of the NAND. And there are people with multiple emuNANDs/redNANDs. This is more complicated than you may think.

[pbanj]

This has nothing to really do with luma. This is an issue with using emunand9 to remove an Emunand/rednand. It doesn't remove it properly so luma thinks there is one. If emunand9 removed it properly this wouldn't be an issue

[ksanislo]

Emunand9 /does/ clear the magic manually now, I asked d0k3 to add that to
work around this design flaw. However, this _IS A LUMA BUG_. Luma should
use the partition table to verify that the possible emunand isn't inside
the FAT partition before trying to boot it. Format by anything doesn't wipe
data, it only resets the allocation table. This is a seriously amateur
design oversight that should be fixed on Luma's side, not patched out by
every possible format tool under the sun.

[pbanj]

Considering you have to rebuild the MBR to get rid of it no its not a luma issue. How do I know what has to be done? Because I have helped fix this issue for many people. A simple reformat is not enough, the fact is emunand9 left the MBR fucked up.

[TuxSH]

This is not a luma issue, but we provided a workaround nevertheless.

[ksanislo]

@pbanj Emunand didn't leave "the MBR fucked up", Luma wasn't checking the MBR at all.. it was only checking a predefined offset directly on the SD card for a string... this /was/ a luma bug, not an emunand9 bug, nor any other program's bug. Luma was failing to follow the MBR or partition layout, and was just blinding trying to find a magic string on the SD card.

[AuroraWright]

@ksanislo I solved this, but govern improve your attitude accordingly towards strangers on the internet, please. I'm sure many people in my place would have just closed this issue after those arrogant remarks. Alternatively, push a fix yourself.

[ksanislo]

And it only took your team 28 days to acknowledge that what I reported was an actual bug. Thanks so much.

[fox8091]

Heh. Try a big company that get PAID to make software. Still takes a lot of time. These guys do it free. Don't like it, don't use it. (shrug)

[AuroraWright]

@ksanislo first I'm not obligated to do anything for you or anyone else for that matter (as this is an entirely free and non-profit project), second "my team" (it's just me and @TuxSH btw) was busy actually implementing needed things and refactoring the code, which I think was more important than avoiding a few people from full formatting the SD.
As I said, next time solve it yourself instead of whining for others to do it when you want them to.