yes my cfw is on a emunand i made sure i set one up both times I installed the software
Pretty sure you need to dump the game or find nsp copy to be install on your emunand.
yes my cfw is on a emunand i made sure i set one up both times I installed the software

How is the SD card formatted? And have you checked to see if the SD card is fake or not?I have ipatched N Switch on firmware 4.1.0. I tried to install HBmenu for few years now with same result. The exploit works every time and I see HBmenu and Caffeine Icons. I select HBmenu it does it's thing. 30 sec+ I get SUCCESS and it asks me to press home and the Album and then IT ALWAYS freezes!
I tried restoring the Switch to original settings, re-formatted the SD card in PC and in another Switch, Tried all sort of hbmenu.nros and same thing. It simply refuses to load that HBmenu. Freezes partially. It will even go back to the Pegascape screen, but other than giving me shut down options, nothing works.
Anyone came across such stubborn Switch and got it to work? Any suggestions?
Screen looks like in this thread gbatemp.net/threads/hbmenu-not-working-album-icon-results-in-blank-screen-softlock.511525/. OP claims he fixed it with newer files, but I think I have the newest (downloaded off switch.homebrew.guide) [the forum won't let me post links, so add the usual hxxps://]
Have you tried using other USB ports and/or cables?When i select "install all" within tinfoil usb install it will just download the first file in the list, not the rest. Why is that?
I tried Tinwoo before, but Tinwoo gives me an error after it finished (usbthreadfunc73: usb transfer timed out or failed), but with tinfoil it installs no problem.
Based on what your goal is, you should create an emuMMC now then restore the clean eMMC backup you made way back when. If you create an emuMMC now, it will be a copy of everything that you have done so far on your sysMMC. Restoring a clean backup before making emuMMC will result in you making a clean emuMMC which doesn't line up with your goal unless you wish to go online with emuMMC (which is more safe than you might think).Something tells me that I've done a lot wrong.
I've bought my switch back in 2019: In this order I can remember:
1. used hekate, nand backup, can't remember wich firmware back then.
2. used to turn it on sometimes on ofw because noobish
3. Turned on auto_rcm.
4. turned on incognito_rcm blank
5. I'm updating for a bout a year using ChoidujourNX/Daybreak
6. I've always used sysnandCFW
7. If i want to 'clean' my switch, without any traces, what I'm suposeed to do? I mean, I want to migrate to emunand(offline homebrews), and sysnand (official online nintendo games like metroid prime 5 and 6).
Do i need to know my fuses to know where to downgrade to? Or i'm lost?
Bonus question. Is cfw/emunand very slow? (its sd card after all)
thanks in advance
I've been putting off updating my Switch (it's on 10.2 with AMS 15 using emunand) but finally want to update. So I have a few questions:
1. From what I understand, I should update atmosphere, then hekate (in this order). The update process is essentially just merging new files/folder with the existing ones. Does it matter if I just back up my old files/folders, then delete them on my SD card, and extract fresh copies from the updates?
2. When updating the actual firmware itself, it is recommended that I make a BOOT0/1 eMMC backup. That part seems simple. After this, I should be updating my sysMMC first. So my question is: do I update sysMMC by booting the existing stock firmware (i.e. retail mode with no payloads) and then update the firmware? The reason I ask is that I vaguely remember hekate having non-EmuMMC boot options, making me wonder if these are the ones I should be booting instead.
- While the order of Atmosphere and Hekate does not largely matter, what does matter is how you update the files. It is incorrect to simply merge the existing files/folders because old files/folders will remain with the new ones. Better practice is to delete the old CFW files/folders before placing the new ones on the SD card. You can back them up though before you delete the old CFW files/folders
- You do not need to make an additional BOOT0/BOOT1 and eMMC backup if you already have those backed up. While these are updated when the firmware changes, you can still restore older versions of them. As for how to update the firmware, it depends if you want to burn fuses or not. Fuses only matter in case you ever wish to downgrade to a firmware that has a better exploit than the current one such as a hypothetical untethered coldboot. If you don't care about fuses or downgrading for the sake of a more convenient exploit, then you can just do what you suggested and boot Stock mode via Hekate to update your firmware online. If you do care about burning fuses, which I should mention has no downsides, then you can either update via a homebrew application such as Daybreak or install the firmware update while Atmosphere is running and AutoRCM is enabled. Normally AutoRCM is used to prevent fuses from being burnt but is disabled during firmware updates; Atmosphere circumvents this. Whichever method you choose is ultimately up to you

The primary purpose of emuMMC is to have separate firmware versions on both sysMMC and emuMMC. That was the way it was used when on the 3DS and Gateway was the only method of hacking it but Gateway required a specific firmware version so emuMMC was developed to allow users to be on later firmware versions without losing the exploit/Thank you for the reply. Just a few follow-ups if you don't mind. Since there are two nands (sys and emu), and fuses can be kept un-burned, is it possible to keep my sys firmware at the lower 10.2 revision, and have my emunand run the latest 12.0.3? Or does updating the firmware on the emu side require updating the sys side as a pre-requisite? I.e. must firmware versions match on both sys and emu sides once everything is said and done? (My reading so far leads me to think that firmware versions must match, and that one has to at least update the sys side before one can proceed to update the emu side.)
The primary purpose of emuMMC is to have separate firmware versions on both sysMMC and emuMMC. That was the way it was used when on the 3DS and Gateway was the only method of hacking it but Gateway required a specific firmware version so emuMMC was developed to allow users to be on later firmware versions without losing the exploit/

Hi All,
I was checking my available memory on my modded switch. I've installed all games and the emuNAND to my SD card but the system memory only shows 8 GB left. I think there may be a game or two that I had installed before modding. Is there any way to figure out where a game is actually installed? I went through the file explorer in Tinfoil but couldn't really figure out what folder would contain those games and they just appear to be a series of letters and numbers rather than folders with game names.
Also, the free 8 GB is around 1 GB less than what I had a week ago. Is there anything about installing new games to the SD card that would also cause me to use up space on the system memory?
Thanks for any help.

Check if you move games into your system internal memory, go to settings, data management then Move Data Between System / microSD Card.
I'm not sure I understand. I have 200+ GB of games on the SD card, the internal memory I believe is 32 GB. What will it show if I try to move games into the internal memory? There's no way even one of those games, which are all 10-15 GB, would fit. Do I just try to move one of the game and if so, how do I decide which one?
Based on what your goal is, you should create an emuMMC now then restore the clean eMMC backup you made way back when. If you create an emuMMC now, it will be a copy of everything that you have done so far on your sysMMC. Restoring a clean backup before making emuMMC will result in you making a clean emuMMC which doesn't line up with your goal unless you wish to go online with emuMMC (which is more safe than you might think).
Fuses are only relevant if your trying to boot the console without Fusee Gelee which you will need in your case. Since Fusee Gelee is triggered before the fuse check, it allows us to technically boot any firmware we want regardless of the fuse count. Do not mistake this for being able to freely downgrade because you would need the exploit Fusee Gelee to boot up the console if too many fuses are burnt when downgrading. Downgrading for the sake of another exploit such as untethered coldboot is pointless if fuses are burnt but downgrading for the sake of a clean eMMC is useful.
Lastly, emuMMC/CFW is realistically the same speed as OFW/sysMMC. Theoretically, it is slower but the different is hardly noticeable.
I can only downgrade to the earliest Firmware installed WHILE using auto rcm ? I mean. When i made my clean backup file back in 2019, i've updated my switch sometimes using the official method, only mid 2020 i've started using autoRCm (not entering official nand anymore, so no burnt fusees).
Being so, some fusees were burn AFTER my clean backup, so I must presume that the switch will expect firmware above the one I have backed up.
There's a way to know the relation between expected firmware X fuse count?Good chance it won't boot if there are too many fuse count different.

Effectively, the answer is yes. There is no reason not to be using AutoRCM nowadays. People haven't been banned for using it by itself and it saves wear & tear on your Joy-Con rails.I can only downgrade to the earliest Firmware installed WHILE using auto rcm ? I mean. When i made my clean backup file back in 2019, i've updated my switch sometimes using the official method, only mid 2020 i've started using autoRCm (not entering official nand anymore, so no burnt fusees).
Being so, some fusees were burn AFTER my clean backup, so I must presume that the switch will expect firmware above the one I have backed up.
There's a way to know the relation between expected firmware X fusee count?
Thanks. How to count how many fuses are burn? i triyng to see in hekate screen, but its confusing.https://switchbrew.org/wiki/Fuses#Anti-downgrade
you can check this table, there is the expected fuse count and firmware, sometime you might be able to get away with 1-2 firmware over the expected firmware and get it to boot with hekate, if you burn too many fusee and try to boot a lower firmware the system might panic.
Thanks. How to count how many fuses are burn? i triyng to see in hekate screen, but its confusing.
How is it supposed to be formatted??How is the SD card formatted? And have you checked to see if the SD card is fake or not?