Generate the fs index save too (17.0.0 brick issue)

[dorkeline]

While atmosphere fixes the issue it's still good if we don't cause potential timebomb bricks for people who might use this to wipe a console before selling it off, likely to someone who is not aware of how to fix it.

I haven't tested it on console yet (the generated files look fine) because i'd need to compile atmosphere for that with the workaround commit reverted and at the time of me trying it didn't seem to compile.

Sending it in as a draft until someone (or I) tests it on console and so I don't forget about it again like the last couple of days

[ghost]

@dorkeline Have you tried using this tutorial to compile Atmosphere?

https://gbatemp.net/threads/building-atmosphere-on-windows-using-msys2.613446/

That helped me some months ago when I couldn't for the life of me get Atmosphere to compile. Following this tutorial to a T helped me successfully compile it. Tutorial is for Windows, btw. It's probably easier to do in Ubuntu, but I'm not that knowledgeable in Linux.

[suchmememanyskill]

The issue isn't that compiling atmosphere is particularly hard, it's just very annoying and error prone to do

[ghost]

The issue isn't that compiling atmosphere is particularly hard, it's just very annoying and error prone to do

Ah, I see. I haven't compiled it that much, or anything Switch-related for that matter, so my knowledge of any this is just surface level deep.

[dorkeline]

Nah, I know how to compile atmosphere, but when I tried I got a error that fsProgramId was undefined, im assuming this libnx commit wasn't pushed yet, but I don't know for sure. I might have done something wrong but also this by far wouldn't have been the first time ams and libnx master are desynced so I just gave up and figured I'll try another day

[ghost]

While atmosphere fixes the issue it's still good if we don't cause potential timebomb bricks for people who might use this to wipe a console before selling it off, likely to someone who is not aware of how to fix it.

I haven't tested it on console yet (the generated files look fine) because i'd need to compile atmosphere for that with the workaround commit reverted and at the time of me trying it didn't seem to compile.

Sending it in as a draft until someone (or I) tests it on console and so I don't forget about it again like the last couple of days

Do we really need to compile Atmosphere without the workaround commit in order to test it?

Since you wrote "people who might use this to wipe a console before selling it off, likely to someone who is not aware of how to fix it." I'm thinking people who will sell their console will just flash the newest firmware and then sell it straight away, without using Atmosphere to fix anything, and the next person might just boot straight into the system, without going through Hekate and/or Atmosphere.

Is it enough testing to make firmware 17.0.0 using your (@dorkeline ) fork and flash that and boot straight into Nintendo OS, or do we also need Atmosphere without that specific commit to test both use-cases?

[JeffVi]

You should indeed test if stock works Not only on 17.0.0, but also on firmwares below 17.0.0 If stock works, I don't see why atmosphere wouldn't The idea is to be able to boot normally, without the need of using atmosphere

[ghost]

I have just built @dorkeline fork and tested firmware building. I'm going to flash it this weekend and test it out (without Atmosphere, as I don't know exactly which commit(s) I should revert). Does this sound ok:

I only have prod.keys for 16.1.0 at the moment, but that is an AutoRCM build, so I will rebuild without AutoRCM this time, for 16.1.0, boot stock and update to 17.0.0 and grab the new prod.keys. Then I will build firmware 17.0.0 with the new prod.keys on my Switch and boot it up once more.

[lsp199308]

Does this require net 7.0 to be installed, I get an error that

This error appears on mariko

[suchmememanyskill]

That error appears when the prod.keys is missing required keys. I haven't had the time yet to investigate

[dorkeline]

Sorry this took so long i got distracted with other things. I finally went to test it on my Lite by rebooting to OFW in hekate (i didnt pick Stock because i wanted to be sure no AMS code is running). After fixing these 2 issues it seems to work now, i was able to successfully boot into initial setup after nuking SYSTEM and replacing it with the generated files. Another person testing and confirming would be awesome, especially non mariko.

@lsp199308 if you have all other keys then try renaming your save_mac_key to save_mac_key_00 to make libhac happy.

[lsp199308]

extremely grateful

[ghost]

Sorry this took so long i got distracted with other things. I finally went to test it on my Lite by rebooting to OFW in hekate (i didnt pick Stock because i wanted to be sure no AMS code is running). After fixing these 2 issues it seems to work now, i was able to successfully boot into initial setup after nuking SYSTEM and replacing it with the generated files. Another person testing and confirming would be awesome, especially non mariko.

I'll rebuild it using the latest commits you've added @dorkeline and test it this weekend, either Saturday or Sunday. Does the following test process look ok to you or should I change anything?

I only have prod.keys for 16.1.0 at the moment, but that is an AutoRCM build, so I will rebuild without AutoRCM this time, for 16.1.0, boot stock and update to 17.0.0 and grab the new prod.keys. Then I will build firmware 17.0.0 with the new prod.keys on my Switch and boot it up once more.

EDIT: (Sunday the 5th. November 2023): Did everything I mentioned above and the Switch booted up both times without any issues.

EDIT: (Thursday the 9th. November 2023): Forgot to say, but yes, my Switch is the V1, so can confirm it working on non-Mariko models as well.

[lsp199308]

@dorkeline Is it possible to change the code to realize that you don't have to change prod.keys (in mariko)

[suchmememanyskill]

@lsp199308 fixed in latest commit