Hacking Confused about update order - Atmosphere CFW emunand or first the clean OFW

[Sala]

Hi
I use the same FW version on sysnand OFW and emunand CFW
I don't know where to start updating my switch

for what I understood from what I've read I have to start to remove incognito in exosphere
and atmosphere should handle host file
I did this offline and I've use 90dns checker to check if everything was ok (everything was green)

Then, I should update atmosphere to the latest version
(I actually don't understand why the AIO Switch updater doesn't have atmosphere anymore among the downloadable CFW)
Update fusee
Download the FW from AIO Switch updater
install the firmware using Daybreak
Reboot to CFW emunand

then
If I reboot to OFC sysnand everything should be ok and I can update the switch firmware normally

is this correct?
Thank you in advance

 

[petspeed]

Yes the order of the tasks are correct but before you update the firmware also update sigpatches and sysmodules (if you use any)

However I would update everything manually instead of using AIO. That gives more control and more knowledge about what is going on. Info here: https://nh-server.github.io/switch-guide/extras/updating/

Regarding incognito and DNS blocking you can still use exosphere to blank prodinfo (incognito) in FW 17.x as long as you also block Nintendo servers. That is easily done with Atmosphere\s DNSmitm feature with a hosts file. Se more info here: https://rentry.org/ExosphereDNSMITM

 

[Sala]

Yes the order of the tasks are correct but before you update the firmware also update sigpatches and sysmodules (if you use any)

However I would update everything manually instead of using AIO. That gives more control and more knowledge about what is going on. Info here: https://nh-server.github.io/switch-guide/extras/updating/

Regarding incognito and DNS blocking you can still use exosphere to blank prodinfo (incognito) in FW 17.x as long as you also block Nintendo servers. That is easily done with Atmosphere\s DNSmitm feature with a hosts file. Se more info here: https://rentry.org/ExosphereDNSMITM

right, also sigpatches and sysmodules

but about incognito in exosphere I've read that 17.0.0 have issues with that, that's why I've turned it off in exosphere
are you sure that may work? (I've already set up the host file)
Because I prefere the exosphere method over other methods

One more question
What about burnt fuses?
will my switch sysnand ofw turn on after I already updated the emunand cfw?

And also: can I use 17.0.0 on emunand cfw and 17.0.1 on sysnand ofw?

Thank you in advance

 

[petspeed]

Yes incognito via exosphere still works in fw 17.x IF you also block Nintendo servers either with DNSmitm or 90DNS.

Yes ofw will still work because cfw doesn't burn fuses. But I don't see any reason not to update sysmmc as well. Being on different fw may make the cart slot unusable in either sysmmc or emummc depending on your config

Yes you can use 17.0.0 on emu and 17.0.1 on sys if you like. But why not just use 17.0.1 on both?

 

[urherenow]

Dunno why, but it's weird seeing someone talk about updating with no mention of hekate. But step 1 is ALWAYS to extract the latest Atmosphere and hekate (if you're using it). Then update sysmodules as required, and sigpatches if you need them. When all of that is updated, it's safe to update either sys or emu in whichever order you feel like. But I personally like to update sys normally first, so that I can just dump the firmware myself for updating emu, without having to download the fw separately.

However, it may be less stressful for some people with modchips to download the fw first, and use sys cfw to update with daybreak. In the case an official fw update touches boot0, some mod chips will need to be reset and retrained.

 

[Sala]

Yes incognito via exosphere still works in fw 17.x IF you also block Nintendo servers either with DNSmitm or 90DNS.

Yes ofw will still work because cfw doesn't burn fuses. But I don't see any reason not to update sysmmc as well. Being on different fw may make the cart slot unusable in either sysmmc or emummc depending on your config

Yes you can use 17.0.0 on emu and 17.0.1 on sys if you like. But why not just use 17.0.1 on both?

Isn't the latest atmosphere for 17.0.0 only?
I should get some sleep

 

[petspeed]

Latest firmware is 17.0.1 and Atmosphere 1.6.2 supports it

 

[Sala]

Ok

Result: No one warned me that I was on the verge of bricking my Switch.
It seems that it’s somewhat common for the Switch V1 that used EmuMMC and updated to 17.0.x. The solution is relatively simple, but I still encountered a significant problem. That’s why I’m here writing about what happened, so if anyone needs it, they can find the solution here.

Solution:
Simply remove your SD card and use a new clean SD card with Hekate and Atmosphere (Atmosphere alone will also work). Turn on the Switch’s SysNAND with CFW. This means no EmuMMC, but Atmosphere over the SysNAND (that’s why you need a clean SD card).
When you turn on the Switch with Atmosphere, Atmosphere will fix things for you. You just have to boot the SysNAND with Atmosphere CFW once, and then you can turn the Switch off, remove the SD card, and replace it with your SD card with EmuNAND and play normally (remember to deactivate syspatches and update sigpatches).

My Problem:
My Switch didn’t want to boot in CFW. It seems like my jig isn’t working as it used to, and the Switch wasn’t actually turned off. So the first step is to turn off the Switch by pressing the power button for 15 seconds (even if the screen is black, it may not be turned off). Then use the jig and RCM you prefer.

Note: The Switch can boot in RCM even with a damaged NAND, so if it’s not working, just double-check everything, the jig, the cable, etc.

P.S.: I panicked a little and, of course, made things worse.
P.P.S.: Everything works fine now.
Thank you.

 

[ASCiiDiTY]

However, it may be less stressful for some people with modchips to download the fw first, and use sys cfw to update with daybreak. In the case an official fw update touches boot0, some mod chips will need to be reset and retrained.

When you do it this way will it not cause a problem with the fuse count? I've been thinking about getting a v2 or oled chipped, but the chip needing retraining worries me because I am not good with electricals, and I don't understand the fuse count.

 

[petspeed]

Ok

Result: No one warned me that I was on the verge of bricking my Switch.
It seems that it’s somewhat common for the Switch V1 that used EmuMMC and updated to 17.0.x. The solution is relatively simple, but I still encountered a significant problem. That’s why I’m here writing about what happened, so if anyone needs it, they can find the solution here.

Solution:
Simply remove your SD card and use a new clean SD card with Hekate and Atmosphere (Atmosphere alone will also work). Turn on the Switch’s SysNAND with CFW. This means no EmuMMC, but Atmosphere over the SysNAND (that’s why you need a clean SD card).
When you turn on the Switch with Atmosphere, Atmosphere will fix things for you. You just have to boot the SysNAND with Atmosphere CFW once, and then you can turn the Switch off, remove the SD card, and replace it with your SD card with EmuNAND and play normally (remember to deactivate syspatches and update sigpatches).

My Problem:
My Switch didn’t want to boot in CFW. It seems like my jig isn’t working as it used to, and the Switch wasn’t actually turned off. So the first step is to turn off the Switch by pressing the power button for 15 seconds (even if the screen is black, it may not be turned off). Then use the jig and RCM you prefer.

Note: The Switch can boot in RCM even with a damaged NAND, so if it’s not working, just double-check everything, the jig, the cable, etc.

P.S.: I panicked a little and, of course, made things worse.
P.P.S.: Everything works fine now.
Thank you.

This only happens if you used homebrew to reset SysMMC. You never mentioned that you have used cfw on SysMMC. Normally if you do that you will run Atmosphere on SysMMC after the upgrade anyway and then there is no issue because you have updated to Atmosphere 1.6.2

Anyway since it is fixed by Atmosphere 1.6.2 it is really not a big issue anymore.

Good you got it fixed

 

[Sala]

This only happens if you used homebrew to reset SysMMC. You never mentioned that you have used cfw on SysMMC. Normally if you do that you will run Atmosphere on SysMMC after the upgrade anyway and then there is no issue because you have updated to Atmosphere 1.6.2

Anyway since it is fixed by Atmosphere 1.6.2 it is really not a big issue anymore.

Good you got it fixed

well I own a v1 bought at the beginning of the switch era
I think I've tried every cfw that was created lol
So before I was using cfw on sysnand and then when became possible I switched to cfw on emunand

good that everything works
I just wanted to complete the thread with my experience

 

[urherenow]

When you do it this way will it not cause a problem with the fuse count? I've been thinking about getting a v2 or oled chipped, but the chip needing retraining worries me because I am not good with electricals, and I don't understand the fuse count.

You shouldn't need to worry about the fuse count. People on like 4.1 and below are the only ones that do. While using CFW, fuse count will be ignored entirely. Using OFW will simply burn the appropriate fuse(s). Using OFW with TOO MANY burnt fuses, because you decided to try to downgrade your sysmmc, will not work. That's pretty much it.