Luma3DS does not chainload into SafeB9SInstaller if it doesn't exist in SD as `boot.firm`

[lifehackerhansol]

This issue was common enough that on 3ds.hacks.guide we had people launch SafeB9SInstaller as boot.firm.

When Luma3DS is launched from CTRNAND, it reads chainloaded payloads from nand:/rw/luma/payloads instead of sdmc:/luma/payloads. In the event that one may have not have ever used Luma3DS on SD (I mean the console works in that state so people kinda just live with it), EzB9SUpdater may not launch SafeB9SInstaller and load something else (or not load at all).

Given the minimum Luma3DS version is set to 8.0, this means boot9strap 1.1 or later is installed, as boot9strap 1.0 only supports Luma3DS 7.1.

With that, I propose two solutions:

• Also update Luma3DS while you're at it, to latest stock version, and install to SD so that it ensures booting from SD.
• Provide a config.bin file based on the latest Luma3DS version (currently 10.3) before rebooting into chainloader. This is important as otherwise it will launch the Luma3DS configuration menu, ignoring the START button.

Or:

• Do everything on NAND, and copy the luma folder and boot.firm to NAND. Then launch SafeB9SInstaller by having it chainload from the NAND instead. This solution I pulled out of my butt compared to the previous solution so I don't even know if it works. Maybe.

[PabloMK7]

Hello!
Thanks for the information, I didn't consider that launching Luma from NAND checks another folder.

In any case, from experience 99% of the cases when Luma boots from NAND instead of SD is because of a corrupted SD card. For some reason, the OS can read the files properly, but not boot9strap. The only solution for that is to either copy boot.firm to the SD card again (which may still not work) or to format the SD to FAT32 so it regenerates the corrupted filesystem. If the SD is corrupted, it won't be able to launch SafeB9SInstaller.firm anyways.

It's not a good idea to update Luma3DS, because a lot of people use different builds of Luma3DS, such as the plugin loader branch, which would be overwritten. Also I'd prefer not doing anything with NAND, as I would have to remove or rename the boot.firm file on the SD, and if the user powers off the console, the console won't reboot to EzB9SUpdater and the boot.firm file won't be restored.

There is no issue if SafeB9SInstaller doesn't launch or the config menu shows up. The console will just reboot into EzB9SUpdater, where the tool asks the user if the installation was successful. If it isn't, the user can hold start again to try to go into SafeB9SInstaller again. A link to the Nintendo Homebrew discord server is also displayed, so the user can go there and ask for help if something doesn't work properly.

The solution to this would be if Luma or B9S allowed launching a .firm from memory with some API call, but that isn't the case, so the current solution is the best I can do.