Accidentally installed an NSP to nand using DBI

[mikefor20]

Do you mean the "internal storage" from the emummc? Because you can avoid installing updates and DLCs there, i install everything (including dlc and updates) in the microsd and keep the internal storage from emummc just for saves. DBI gives you the option to choose where to install.

DBI can but the native updater won't. It won't matter much for you but I ran a CLEAN EmuMMC online for 2 years. The native stuff and some older hombrew won't install updates on the SD either. There is no advantage to shrinking the primary EmuMMC. Shrinking causes broken links on your previously installed NSP too. No advantage, possible problems. Skip it.

I'd like to add, I frequently help people here. I will not recommend something that will cause more confusion or issues that I, or the other helpful Tempers,have to fix. Things that have no use except complicating things will be met with the same response.. skip it. You can do a lot of things differently than the norm but there is no point. So skip it.

If you have a good reason,present it. Convince me. I have an open mind and I love to learn. Otherwise I'll stick to my guns. Aside from auxiliary EmuMMC for niche purposes there is no reason to shrink your EmuMMC.

 

[Hassal]

Part of the confusion is using the NAND synonymously with emuNAND and sysNAND. Both should be used explicitly to refer to the system in use.

 

[MightySashiman]

mikefor20​

I don't understand why this is incorrect. For the games I own and want to play online, I play them (installed for eshop games, or gamecard) on OFW so the whole topic is irrelevant. For my hacked setup where I play dumps, I exclusively use CFW@EmuMMC, and of course will not be using any official updater (for the simple reason that all nintendo related domains are blocked anyway), and update manually by installing the update NSPs as they become available online (even for the game I own). In that last case (that targets the majority of people here let's be real), then just install everything to SDcard (volume 5 in MTP responder) in DBI, reduce EmuMMC USER partition to a safe minimum, forget about it and call it a day. Why on earth would you want to have to juggle with 2 storage spaces when 1 big one, more easily accessible, does the trick ?

Imho the advantage is quite obvious, the problem you mention ("Shrinking causes broken links on your previously installed NSP too") is solved by planning properly from the beginning: reduced EmuMMC size at creating stage, not afterwards.

 

[mikefor20]

mikefor20​

I don't understand why this is incorrect. For the games I own and want to play online, I play them (installed for eshop games, or gamecard) on OFW so the whole topic is irrelevant. For my hacked setup where I play dumps, I exclusively use CFW@EmuMMC, and of course will not be using any official updater (for the simple reason that all nintendo related domains are blocked anyway), and update manually by installing the update NSPs as they become available online (even for the game I own). In that last case (that targets the majority of people here let's be real), then just install everything to SDcard (volume 5 in MTP responder) in DBI, reduce EmuMMC USER partition to a safe minimum, forget about it and call it a day. Why on earth would you want to have to juggle with 2 storage spaces when 1 big one, more easily accessible, does the trick ?

You can shrink it. I didn't say you can't. There is no reason. When you first shrink it installed NSP break. And a few things need SysNAND.

Once again, you do you,but I will stress that it causes more complications for the noob reading this and has no real advantage. As someone who supports people here i say skip it. It's useless and has potential for issues.

"I shrunk my existing EmuMMC and my games won't load" isn't something I want to deal with repeatedly. If you can't manage the 2 buckets if installable space then you probably shouldn't be modding anything. Every post here gets noobs going. 2 years from now someone reads this and all hell breaks loose. At least for them. And the guy helping. You do you but I say skip it. If it's done it's fine. Leave it.

 

[Tokiwa]

DBI can but the native updater won't. It won't matter much for you but I ran a CLEAN EmuMMC online for 2 years. The native stuff and some older hombrew won't install updates on the SD either. There is no advantage to shrinking the primary EmuMMC. Shrinking causes broken links on your previously installed NSP too. No advantage, possible problems. Skip it.

I'd like to add, I frequently help people here. I will not recommend something that will cause more confusion or issues that I, or the other helpful Tempers,have to fix. Things that have no use except complicating things will be met with the same response.. skip it. You can do a lot of things differently than the norm but there is no point. So skip it.

If you have a good reason,present it. Convince me. I have an open mind and I love to learn. Otherwise I'll stick to my guns. Aside from auxiliary EmuMMC for niche purposes there is no reason to shrink your EmuMMC.

Ok you mean updating from the eshop, i was confused because this is a topic about DBI so clearly anyone installing nsp/nsz/xci isn't worried about clean emummc (they are either offline or using exosphere/incognito, which is basically a self ban).

Never said i supported or was against shrinking, so i see no need to "present" anything or convince anyone. Personally i don't see any reason to shrink since i can just choose to install in the internal storage when/if i run out of space of my microsd card.

 

[mikefor20]

Ok you mean updating from the eshop, i was confused because this is a topic about DBI so clearly anyone installing nsp/nsz/xci isn't worried about clean emummc (they are either offline or using exosphere/incognito, which is basically a self ban).

Never said i supported or was against shrinking, so i see no need to "present" anything or convince anyone. Personally i don't see any reason to shrink since i can just choose to install in the internal storage when/if i run out of space of my microsd card.

Lots of people have clean online unbanned EmuMMC. And shrinking your primary EmuMMC is pointless.

If you have a good reason,tell me , otherwise i stick to my story. Skip it.

 

[The Real Jdbye]

• that's why the whole semantics in he NS scene is mighty confusing for newcomers...
• and that's also why Sthetix suggests to reduce the size of EmuMMC at partition time mine's only a few GBs

No point, there is no benefit to reducing the emuNAND size.

I don't see how this is relevant. When installing games using DBI, install to SD card (5). I don't see the point of installing games to the emuMMC's USER partition (which is also on the the SD card).

You waste SD card space if you don't. If you have plenty of space, that's not an issue though.

DBI can but the native updater won't. It won't matter much for you but I ran a CLEAN EmuMMC online for 2 years. The native stuff and some older hombrew won't install updates on the SD either. There is no advantage to shrinking the primary EmuMMC. Shrinking causes broken links on your previously installed NSP too. No advantage, possible problems. Skip it.

I'd like to add, I frequently help people here. I will not recommend something that will cause more confusion or issues that I, or the other helpful Tempers,have to fix. Things that have no use except complicating things will be met with the same response.. skip it. You can do a lot of things differently than the norm but there is no point. So skip it.

If you have a good reason,present it. Convince me. I have an open mind and I love to learn. Otherwise I'll stick to my guns. Aside from auxiliary EmuMMC for niche purposes there is no reason to shrink your EmuMMC.

The native updater will install wherever your game files are stored. Not sure what it does for cartridge games though. But you can always move the data afterwards.

 

[mikefor20]

No point, there is no benefit to reducing the emuNAND size.

You waste SD card space if you don't. If you have plenty of space, that's not an issue though.

The native updater will install wherever your game files are stored. Not sure what it does for cartridge games though. But you can always move the data afterwards.

Exactly. I saw some updates going to SD with the native installer.. some not. Carts were updating to SysMMC I'm 99% sure. Idk what happens when it's full.. maybe default to SD. I have had to deal with a few tempers telling me it ran out. The whole breaking of the installed links is the real reason I don't want people seeing this thread and shrinking the emunand willy nilly. I had to deal with that too.

Like I said,the only use for shrinking is to have a tiny additional EmuMMC for a.special use. Like one on 11.x for SXOS to have USB loading. And that's for people who have it already and a big SXOS compatible XCI collection already. Works great. I had an additional shrunken one as a guest nand for my kids friend. Little shit is a save file deleter so I made na tiny one just for him. Lol. If you have specific special cases, maybe....
As a daily driver not ideal.

Noobs, dont do it.

 

[urherenow]

The question isn't about emummc, but the scope of DBI's access. I also don't know that OP saw the game after it was installed, only that they realized they did something using a certain method that would raise their concern.

There are many apps, and some do allow access to both physical NAND as well as emulated versions. This thread piqued some curiosity about DBI and I am not anymore enlightened to as why a modern Switch app would erroneously refer to something as NAND when it is not.

I’ll try this one more time.

NO app accesses sysnand and emunand simultaneously. None. Period. If YOU are using emummc, any calls to nand are directed to the emummc. CFW settings controls this, and apps do not know the difference. If YOU load sysnand, the app uses sysnand.

NAND, whether physical eMMC, raw partition, or file-based, is something that won’t let you see individual files without your encryption keys and other software. SD, is always in your Nintendo folder on your fat32/exfat partition (different locations for each emummc/eMMC, unless for some weird reason, you redirected your emummc’s Nintendo folder to point to the regular one). This is why it makes sense for DBI to give you the choice of NAND, or SD. For the last time, the physical/emulated aspect is a function of the firmware. DBI has zero to do with that.

 

[mikefor20]

I’ll try this one more time.

NO app accesses sysnand and emunand simultaneously. None. Period. If YOU are using emummc, any calls to nand are directed to the emummc. CFW settings controls this, and apps do not know the difference. If YOU load sysnand, the app uses sysnand.

Thank you. I just said that above. There is an exception,payloads.. lockpick for example. Technically i can manipulate an emunand from sysnand run app. Tegra explorer.. ftp. Even mtp if I delete or move files so I included that too.

 

[tabzer]

I’ll try this one more time.

NO app accesses sysnand and emunand simultaneously. None. Period. If YOU are using emummc, any calls to nand are directed to the emummc. CFW settings controls this, and apps do not know the difference. If YOU load sysnand, the app uses sysnand.

NAND, whether physical eMMC, raw partition, or file-based, is something that won’t let you see individual files without your encryption keys and other software. SD, is always in your Nintendo folder on your fat32/exfat partition (different locations for each emummc/eMMC, unless for some weird reason, you redirected your emummc’s Nintendo folder to point to the regular one). This is why it makes sense for DBI to give you the choice of NAND, or SD. For the last time, the physical/emulated aspect is a function of the firmware. DBI has zero to do with that.

Apps operated via RCM can do have the wider scope of access. Even Mike has a good point about "sysnand" having greater access. Hacdiskmount is what originally came to mind when reading this thread. The term NAND is throwing, hence the OP.

 

[mikefor20]

What happens in EmuNAND stays in EmuNAND

Another reason hidden partition EmuNAND is superior. Hard for a moron and Tegraexplorer to mess up the EmuNAND. File based is good for Emunand 3 or 4 but I much prefer the noob resistant hidden partition.

 

[urherenow]

Apps operated via RCM can do have the wider scope of access. Even Mike has a good point about "sysnand" having greater access. Hacdiskmount is what originally came to mind when reading this thread. The term NAND is throwing, hence the OP.

I'm filing you into the hopeless category. RCM apps do not run under HOS (If you even have a clue what that means). They run on bare metal. DBI is not an "RCM app".

 

[tabzer]

DBI is not an "RCM app".

Okay, but HacDIskMount kind of is. Like I said, I didn't know the scope of DBI's access or its limitations. Saying that it is impossible for apps to do so is just wrong.

 

[urherenow]

Okay, but HacDIskMount kind of is. Like I said, I didn't know the scope of DBI's access or its limitations. Saying that it is impossible for apps to do so is just wrong.

No, hacdiskmount is ABSOLUTELY running on bare metal (RCM). DBI runs under HOS. To say is doesn't know where the NAND lives is 100% correct. I already told you, the firmware controls that. Please just stop talking out of your ass. You have no idea what you're talking about. DBI will NEVER touch emmc while you're using emummc, and vice versa.

 

[RednaxelaNnamtra]

Yep, starting to talk about rcm payloads just confuses people even more, just stay in the hos scope.
This way it's simple to explain for users that don't know a lot, without confusing them to much.

So as mentioned before:
Nand for an application is always whatever you booted into, so for syscfw the sysmmc/sysnand and for emunand its the emunand/emummc on the sd. And the application doesn't know if it's running on emunand or sysnand, so its not reporting something more specific.

For this the user needs to make sure he knows where he is, this can be simplified for example by using the light theme in sysnand and dark theme in emunand.

 

[mikefor20]

Yep, starting to talk about rcm payloads just confuses people even more, just stay in the hos scope.
This way it's simple to explain for users that don't know a lot, without confusing them to much.

So as mentioned before:
Nand for an application is always whatever you booted into, so for syscfw the sysmmc/sysnand and for emunand its the emunand/emummc on the sd. And the application doesn't know if it's running on emunand or sysnand, so its not reporting something more specific.

For this the user needs to make sure he knows where he is, this can be simplified for example by using the light theme in sysnand and dark theme in emunand.

I always put custom themes on my EmuNANDs. The stock themes are boring. I put a couple of mine on Themezer. The kids setup is Pokémon themed. Mine is skeletal to match my see through Switch housing.

Lol old pic. Tinfoil tried to flip the image in my mobile but gave up after 2 seconds of effort. Hard to miss what NAND you're in with a good theme.

 

[tabzer]

No, hacdiskmount is ABSOLUTELY running on bare metal (RCM). DBI runs under HOS. To say is doesn't know where the NAND lives is 100% correct. I already told you, the firmware controls that. Please just stop talking out of your ass. You have no idea what you're talking about. DBI will NEVER touch emmc while you're using emummc, and vice versa.

It requires a PC application to deliver calls where the payload primes the switch for execution. Firmware is continually being exploited, so broad and unsubstantiable claims about all apps being incapable is really not reliable, especially considering my proof of you being wrong. Speaking of a specific app's limitations is really all that is relevant. DBI isn't capable, and doesn't seem to acknowledge that emuMMC is a thing, so you have to understand why confusion even happens.

 

[mrdude]

No, you're emuMMC isn't only a few GBs. It is either 32GB or 64GB depending if you're using a OLED Switch or not. There's no way to make it smaller

Hmm really, I managed to make an emunand 3,892,334,592 bytes (yep around 3 GB) and it works great + takes firmware updates no bother. You can partion an emunand to any size you want - as long as all the system files work and then flash that to a real nand - that's why some people buy blank chips of a larger size and partition them so they can have more space without an sd card.

 

[RednaxelaNnamtra]

I always put custom themes on my EmuNANDs. The stock themes are boring. I put a couple of mine on Themezer. The kids setup is Pokémon themed. Mine is skeletal to match my see through Switch housing.

Is it possible to set different themes for light and dark mode? Otherwise it won't really help with identifying if you booted into syscfw instead of emucfw, since they share the same atmosphere folder.

It requires a PC application to deliver calls where the payload primes the switch for execution. Firmware is continually being exploited, so broad and unsubstantiable claims about all apps being incapable is really not reliable, especially considering my proof of you being wrong. Speaking of a specific app's limitations is really all that is relevant. DBI isn't capable, and doesn't seem to acknowledge that emuMMC is a thing, so you have to understand why confusion even happens.

HOS apps running on emunand/emummc not being able to access sysnand/sysmmc is true though, since the redirect is done on CFW level.
That HOS apps running in sysnand can in theory access the emunand, if they have access to the dumped keys and since they can in theory open the raw sd, is a different thing, but not really relevant for any app accessing the nand/mmc as nand/mmc via fs, since that will always depend on what you bootet into, and won't be detectable by any app, unless they communicate specifically with exosphere, which I don't even know, exosphere will allow.
Also as mentioned, talking about rcm payloads is not relevant when talking about apps in HOS and will just confuse everyone that doesn't know a lot about the topic and stumbles upon this topic.