Accidentally installed an NSP to nand using DBI

[tabzer]

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.


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, not 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.

People would have to read into the conversation in order to be "confused", but information has been progressive to satiate those as far as they want to go. I don't get the gatekeeping, as it was a personal interest of mine to understand the recent developments of the scene. I don't use DBI and am curious about the appeal. If it is still under development, then I don't understand why it would be largely ignorant of the fact that emuMMC is a thing, or specifically, THE thing.

 

[urherenow]

I don't understand

you should leave it at that, and stop posting. And you have proven nothing, except your own ignorance.

 

[mikefor20]

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.

Not AFAIK. I just swap SDs. I actually use a SD extension with a 2 to 1 adapter. Works great. SX has a seperate folder as does rei lol. I still use SX for USB archives of old games and I can see if the kids swapped the sd. I have custom boot logos for
them too.

you should leave it at that, and stop posting. And you have proven nothing, except your own ignorance.

He is troll but he thinks he's helping. Welcome to the internet.

 

[RednaxelaNnamtra]

People would have to read into the conversation in order to be "confused", but information has been progressive to satiate those as far as they want to go. I don't get the gatekeeping, as it was a personal interest of mine to understand the recent developments of the scene. I don't use DBI and am curious about the appeal. If it is still under development, then I don't understand why it would be largely ignorant of the fact that emuMMC is a thing, or specifically, THE thing.

As mentioned, hos Software doesn't know if it runs on emunand or sysnand, so it can't output any info about it.
Exosphere seems to haven an api to get that info, but I dont know if it's freely exposed for applications to access, and at least on a quick glance on github I didn't find anything using it at all, besides atmosphere itself.
And people interested in the topic but without a lot of knowledge in the topic might read more, and I think the way some things where presented would really confuse newcomers.
We also answered you many times why a HOS application, like in this case dbi, would not know about being on sys or emunand, because it uses fs to access files and the nand, and that's all redirected behind the scenes to the emunand instead.

 

[tabzer]

you should leave it at that, and stop posting. And you have proven nothing, except your own ignorance.

Sour grapes. I was pretty clear about my ignorance as well as yours. If you don't like it, talk to my mother.

he thinks he's helping

Helping myself.

We also answered you many times why a HOS application, like in this case dbi, would not know about being on sys or emunand, because it uses fs to access files and the nand, and that's all redirected behind the scenes to the emunand instead.

I’m talking about devs making applications in the current year. They are capable of expressing relativity.

 

[urherenow]

Nevermind. Added to the ignore list.

 

[RednaxelaNnamtra]

I’m talking about devs making applications in the current year. They are capable of expressing relativity.

They can't express info that they don't know/don't have access to, even if they want to, so that response doesn't make any sense.
Also keep in mind, some of those tools might still support sxos, limiting what they have access to even more.

 

[urherenow]

They can't express info that they don't know/don't have access to, even if they want to, so that response doesn't make any sense.
Also keep in mind, some of those tools might still support sxos, limiting what they have access to even more.

Don't bother. This dude is dense, and convinced of his intellect. I have a very short block list, and he's now on it. It'll make your quality of life better.

 

[MightySashiman]

I really don’t understand the agressivity of some senior members here, and really don’t get why it seems so complicated to understand and seemingly ill-advised to have ONE single big storage to store all game assets (base, updates, dlcs) : THE SDCARD, which contents are easily accessible, and reduce to as little as reasonably possible the EmuMMC size on creation.

It would seem the answer to this idea is just “noobs will fuck it up”. If you don’t want a noob to fuck up, start by actually using clear language about the various logical volumes rather than a jumbled up mix of terms referring to the underlying physical storage device (NAND, SDCARD), using the name of the fucking OS (HOS) to refer to the SDCARDs EXTENDED LOGICAL VOLUME.

There is no way a newbie will learn and grow if met with contempt and confusing instructions but never actual EXPLANATIONS.

edit: is there a way to redirect Saves creation/reading from internal storage (aka: (Sys/Emu)NAND/USER volume) to extended storage (aka: stupid ass-named “HOS” aka the SDCARD)

 

[tabzer]

They can't express info that they don't know/don't have access to, even if they want to, so that response doesn't make any sense.
Also keep in mind, some of those tools might still support sxos, limiting what they have access to even more.

Devs who are aware of the scene certainly have access to this information, regardless of limitations of the software that they make. It is my understanding that general consensus to “NAND” is reference to that on the eMMC, so a better term, or subtext clarifying the limitations of the software would help rectify the type of ignorance that @urherenow is ashamed of.

I really don’t understand the agressivity of some senior members here, and really don’t get why it seems so complicated to understand and seemingly ill-advised to have ONE single big storage to store all game assets (base, updates, dlcs) : THE SDCARD, which contents are easily accessible, and reduce to as little as reasonably possible the EmuMMC size on creation.

It would seem the answer to this idea is just “noobs will fuck it up”. If you don’t want a noob to fuck up, start by actually using clear language about the various logical volumes rather than a jumbled up mix of terms referring to the underlying physical storage device (NAND, SDCARD), using the name of the fucking OS (HOS) to refer to the SDCARDs EXTENDED LOGICAL VOLUME.

There is no way a newbie will learn and grow if met with contempt and confusing instructions but never actual EXPLANATIONS.

edit: is there a way to redirect Saves creation/reading from internal storage (aka: (Sys/Emu)NAND/USER volume) to extended storage (aka: stupid ass-named “HOS” aka the SDCARD)

I’m sharing part of your corner. @mrdude referenced the capability of creating a smaller emmumc, although @mikefor20 would prefer to shut discussion about it down. It might be possible to reserve the entire data on your SD card for the emuMMC, but it would restrict your use for other kinds of data with other apps. I personally don’t mess with it, because it is somewhat easy enough to manage data between the emummc storage and “sd” storage by moving games back and forth within the system settings. Maybe @mrdude can provide a reference to a resource or explain how easy it is to customize your own emuMMC size. Resizing after the fact, though, may cause you some issues that @mikefor20 referred to, though it’s unsubstantiated in the context of this thread. AFAIK, Hekate can create a custom-sized emuMMC pretty easily.

As for save data, as far as I know, both CFW and OFW create and utilize save data from their respective system partitions. You can use apps to back them up to SD and restore them from SD, but there isn’t a way I know to do what you are suggesting.

 

[urherenow]

(aka: stupid ass-named “HOS” aka the SDCARD)

NO. Not AKA the SDCARD. Where did you ever get that from? HOS= Horizon Operating System. Apps that load and do their thing directly from RCM or launching the payload from nyx, do so on their own. When you fully boot the Switch, whether OFW or CFW, you are looking at HOS, and everything you run, has to go through HOS. Atmosphere/CFW just happens to patch and inject system calls, overriding and adding to the official behavior.

Save redirection... there are threads about that here, if you'd just use the search function: https://gbatemp.net/threads/how-does-save-redirection-work.554106/

But better than that, read the directions: https://github.com/Atmosphere-NX/Atmosphere/tree/master/docs
Or even just the configuration template:

; Controls whether fs.mitm should redirect save files
; to directories on the sd card.
; 0 = Do not redirect, 1 = Redirect.
; NOTE: EXPERIMENTAL
; If you do not know what you are doing, do not touch this yet.
; fsmitm_redirect_saves_to_sd = u8!0x0

https://github.com/Atmosphere-NX/At...b/master/config_templates/system_settings.ini

As for the emummc... that's personal preference, and not at all ill advised. At one point, it was, because there was a terrible performance hit. That has supposedly been corrected a long time ago now. I only say supposedly because I Can't testify to that first-hand. If you don't install to nand while using emummc, and you are using a full-sized nand, then you are indeed wasting sdcard space. But you can fill up the emummc as well with installed things and use the space anyway. Not really much different from using a vanilla Switch (except that you CAN resize the emummc, if you choose to). And this doesn't make those files any more or less "Accessible". You still need to use hacdiskmount or the like to do anything with them, because HOS encrypts the contents, and emummc files are just containers for the nand partitions. Using a file-based emummc instead of a raw partition-based, does make backing up and migrating to a new/bigger card much more easy, however.

 

[RednaxelaNnamtra]

I really don’t understand the agressivity of some senior members here, and really don’t get why it seems so complicated to understand and seemingly ill-advised to have ONE single big storage to store all game assets (base, updates, dlcs) : THE SDCARD, which contents are easily accessible, and reduce to as little as reasonably possible the EmuMMC size on creation.

It would seem the answer to this idea is just “noobs will fuck it up”. If you don’t want a noob to fuck up, start by actually using clear language about the various logical volumes rather than a jumbled up mix of terms referring to the underlying physical storage device (NAND, SDCARD), using the name of the fucking OS (HOS) to refer to the SDCARDs EXTENDED LOGICAL VOLUME.

There is no way a newbie will learn and grow if met with contempt and confusing instructions but never actual EXPLANATIONS.

edit: is there a way to redirect Saves creation/reading from internal storage (aka: (Sys/Emu)NAND/USER volume) to extended storage (aka: stupid ass-named “HOS” aka the SDCARD)

Yep, newbies need explanations, that why I'm trying to explain why something is the case, and others did too.
Still it's good to not throw everything together, for example in this case arguing about what apps can access, by using payloads as example for stuff that can access more, when the topic is about hos apps which both are completely different environments.
It's kinda like talking about android apps accessing files, and then talking about the recovery image having access to files. It's true, but it's not relevant to the topic and just adds confusion, which need to be cleared up directly.

Devs who are aware of the scene certainly have access to this information, regardless of limitations of the software that they make. It is my understanding that general consensus to “NAND” is reference to that on the eMMC, so a better term, or subtext clarifying the limitations of the software would help rectify the type of ignorance that @urherenow is ashamed of.

That nand is used it pretty much a leftover from the big overlap between the 3ds and switch scene, so it sticked, because people where already used to those names, making it easier to explain some stuff.

It's also pretty clear in a good guide, that nand/mmc/internal storage while in the os/HOS always refers to whatever the user booted into, unless specificly specified differently. Also important is, that those are fully seperated, and the other one is not accessible under normal circumstances for the apps in the os.
And this is important, since while homebrew can be more specific about it in theory (if the api is actually exposed and available to normal applications), everything from the switch os/HOS will not be able to, so the user needs to know about this.

 

[mikefor20]

I really don’t understand the agressivity of some senior members here, and really don’t get why it seems so complicated to understand and seemingly ill-advised to have ONE single big storage to store all game assets (base, updates, dlcs) : THE SDCARD, which contents are easily accessible, and reduce to as little as reasonably possible the EmuMMC size on creation.

It would seem the answer to this idea is just “noobs will fuck it up”. If you don’t want a noob to fuck up, start by actually using clear language about the various logical volumes rather than a jumbled up mix of terms referring to the underlying physical storage device (NAND, SDCARD), using the name of the fucking OS (HOS) to refer to the SDCARDs EXTENDED LOGICAL VOLUME.

There is no way a newbie will learn and grow if met with contempt and confusing instructions but never actual EXPLANATIONS.

edit: is there a way to redirect Saves creation/reading from internal storage (aka: (Sys/Emu)NAND/USER volume) to extended storage (aka: stupid ass-named “HOS” aka the SDCARD)

No agression. Just no coddling or hand holding. You need to read. Do your due diligence. I don't need to explain things for the thousandth time. A quick simple search will turn up the answer. I don't need to argue with anyone. Shrinking the EmuMMC is pointless in most cases. We already explained why. The problem isn't that the senior members are agressive,it's the fact that.people like that troll spread false information to confuse the issue and noobs start hijacking and making threads instead of searching themselves. If you want to know why, please use the search bar. There are many threads on this stuff. Otherwise,take my word for it.

And there are tons of things we steer people away from because noobs will screw it up. If it's not necessary, no .dvantage, and is risky to people with no knowledge or even the ability to search or comprehend then we will steer you away. Time and time again bad advice leads to problems in modding communities. A sea of people who need explanations Telling me I am wrong when they can't tell a SD from an OS. I am not explaining EVERTHING every time a lazy noob asks about something that is already explained to death. Google it before you ask. Read.

Yep, newbies need explanations, that why I'm trying to explain why something is the case, and others did too.
Still it's good to not throw everything together, for example in this case arguing about what apps can access, by using payloads as example for stuff that can access more, when the topic is about hos apps which both are completely different environments.
It's kinda like talking about android apps accessing files, and then talking about the recovery image having access to files. It's true, but it's not relevant to the topic and just adds confusion, which need to be cleared up directly.



That nand is used it pretty much a leftover from the big overlap between the 3ds and switch scene, so it sticked, because people where already used to those names, making it easier to explain some stuff.

It's also pretty clear in a good guide, that nand/mmc/internal storage while in the os/HOS always refers to whatever the user booted into, unless specificly specified differently. Also important is, that those are fully seperated, and the other one is not accessible under normal circumstances for the apps in the os.
And this is important, since while homebrew can be more specific about it in theory (if the api is actually exposed and available to normal applications), everything from the switch os/HOS will not be able to, so the user needs to know about this.

Noobs need to read. A NAND and a MMC are,for all intents and purposes, the same and are the consoles internal storage.. There is no difference to the user and is something said out of habit from consoles past. Wii had EmuNAND. True. HOS on the other hand, is a specific OS. Horizon is the official name for the Switch's operating system. It means the stock environment. Not just a blanket term for whatever is running. This is the type information that is easily searched and annoying as hell to keep explaining, correcting and arguing with know it all trolls who know nothing and don't read. Countless noob threads with basic terminology defined. The guides used to hack the system in the first place usually explain these concepts,if you read completely and comprehend.

If you were back in kindergarten and you couldn't understand the concept of a vowel,why would I start teaching you full words and sentence structure? You need develop an understanding with a good foundation not just find an answer. Some things in the scene have the potential for data loss or bricking of the system. The "senior members" have helped many foolish noobs who come crying for help because they don't listen, search or read. The idea of not telling someone to do something unnecessary and potentially dangerous because they are a noob is sound and smart. If you want to know why you'll have to read up.

The fact that the thread (de)evolved in to this is because the troll tried to flex. It was ill informed, arrogant and incorrect And has history of this behavior.

Don't shrink your EmuMMC/EmuNAND. It is pointless. Except in the special use case above. I don't want you losing data and I don't want to have to help you fix it.

 

[cnzqy1]

I'm glad that I looked at this thread, didn't think hard enough to realize that NAND in emuMMC is actually on the SD card and now I have more free space to install games after moving stuff to NAND.

 

[tabzer]

The fact that the thread (de)evolved in to this is because the troll tried to flex. It was ill informed, arrogant and incorrect And has history of this behavior.

You want to point out where I was “incorrect”? I don’t have the same directive of begrudgingly “helping ‘newbs’” and “protecting them from too much information”. I saw that the information being presented was more or less “trust me bro” and said that it was wanting. That triggered some people. Empathizing with the perspective of someone using DBI for the first time, I find it completely reasonable to be alarmed by the unintentional mistake of installing a game to “NAND”. Some people like to make broad claims and avoid nuance. That’s fine. What’s not fine is calling people trolls because they don’t do things or think in your way; it is just a reflection of your incompetence in recognizing their concern.

I attest that while certain members have “devolved” in their capacity in being more specific, the general course of the thread has been slowly approaching it. If you aren’t interested, we don’t really need an announcement saying so. Your lack of response would be enough.

It is understood that you want people to use their switch in a certain way, and that is more important to you than conveying actual understanding. You’d prefer curated information that leads people to act the way that you would have them. It’s manipulative. I don’t share that sentiment. I could easily call you a troll in the same vein, but I am capable of recognizing your interest. I’d like it if you could try to recognize mine, or simply refrain from the libel.

While you think that you and @urherenow are presenting factual information, the broad stroke claims are only topical in the context of the current time. Predicting the future of apps and CFW, blindly assessing elusive limitations, and calling it “fact” is closed minded and opts you out on the push for greater capabilities of the scene. It can become outdated with a new development, which is what of a lot of people are here for, even if you aren’t.

Also important is, that those are fully seperated, and the other one is not accessible under normal circumstances for the apps in the os.
And this is important, since while homebrew can be more specific about it in theory (if the api is actually exposed and available to normal applications), everything from the switch os/HOS will not be able to, so the user needs to know about this.

I didn’t think what I was saying was that complicated—just that the dev relabeled “NAND” to something like “NAND/emuNAND” to avoid the confusion brought up by the OP. As for a good guide, we all know that the only good guide is @mikefor20.

 

[mikefor20]

You need to read more . You've been here a while. We explained already why you are wrong. You say we don't know the future. You don't understand the console. I am not dictating what people do. I am also telling them to read bit. The idea that it's my responsibility to explain everything to you is ridiculous. Google it. Search the Temp. There is no reason to shrink a daily driver EmuMMC

You don't know what you're talking about.

And telling you not to do something potentially hazardous isn't gate keeping. It's responsible. Just stop it.

You're just trying to shut down the thread as usual. Go away troll

 

[RednaxelaNnamtra]

I didn’t think what I was saying was that complicated—just that the dev relabeled “NAND” to something like “NAND/emuNAND” to avoid the confusion brought up by the OP. As for a good guide, we all know that the only good guide is @mikefor20.

Using "nand/emunand" might be even more confusing, since it might make the user think it's the emunand, when it's either the sysnand/emunand.
Sysnand/emunand might work, but it's a lot more text, and depending on the text size and structure of the gui, that might be to long.
Sys-/emunand might also work, but still it's a lot longer then nand, so the ui need to a company it.
But the way you phrased it sounded more like they need to either das emunand or sysnand, depending on the nand the user selected, at least it did to me sound more like that, and that might or might not be possible, depending on exosphere api.

 

[MightySashiman]

Yeah until you realise hetake calls "HOS" the fucking SDcard...

 

[urherenow]

Yeah until you realise hetake calls "HOS" the fucking SDcard...

Ummm… what? Hekate does not, and never did. If there is a thing called hetake, it’s clearly a joke.

edit: wait… there is a game character called hetake. Is there a user here that you’re talking about?

 

[tabzer]

Yeah until you realise hetake calls "HOS" the fucking SDcard...

Where did you see that? The only reason I think it might say that is because of how the hekate_ipl.ini (or itemized ini files) are written and those can be configured/labelled by the user. If would make sense that you didn't hack the switch yourself, or you used something outside of the GitHub source.

But the way you phrased it sounded more like they need to either das emunand or sysnand, depending on the nand the user selected, at least it did to me sound more like that, and that might or might not be possible, depending on exosphere api.

DBI 616 added this:

"Display of Emunand (E) or Sysnand (S) at the top left."

Considering that this type of information can be shared via atmosphere, or the lack thereof, it isn't impossible to implement communication of the use of emummc.

The idea that it's my responsibility to explain everything to you is ridiculous. Google it. Search the Temp. There is no reason to shrink a daily driver EmuMMC

You are posting by your own volition. Of course there are reasons to shrink the emuMMC. It’s just not practical in your estimation. We have different goals and interests in the scene, which is clear. If you want to be a parental figure of a forum, prepare to be disappointed. “Hacks and mods can be dangerous.” Different methods have different risks. Shrinking your emuMMC runs the risk of having to redo the emuMMC setup from scratch, so the use of backups can be encouraged.