I have attempted many times to get SX OS emuNAND to function to no avail. Atmosphere has fully functional emuNAND but all attempts with SX OS, from hidden partition to files all failed or lead to boot.dat error. I looked over various forums and came across a solution post, the solution was long but it got me to thinking of the cause.
The solution was factory resetting the console, but why would this work? It reinstalls the OS via a recovery image, even the boot sectors. That is where the problem was.
Some poeple may have dabbled with hekate and enabled AutoRCM, however, since hekate is open source and SX OS is closed source, the implementation of AutoRCM may vary, such that SX OS can not "auto-correct" it during emuNAND creation. The emuNAND creation is in fact working like it should, nothing is wrong with it, it's copying the system files as they are on NAND and making an emulated environment out of them, even the intentionally corrupt bootloader.
So, if you have any trouble, you can try disabling AutoRCM (fixing the bootloader) instead of going full factory reset mode on the thing. However, if you updated the OFW and then try to do non-autoRCM, you may lock the console to that firmware, not that it matters too much for an RCM exploitable model, but some might want to preserve their switch's original state.
This is just my guess as I am only one person and have but one console to test this theory on... Could try a poll.
The solution was factory resetting the console, but why would this work? It reinstalls the OS via a recovery image, even the boot sectors. That is where the problem was.
Some poeple may have dabbled with hekate and enabled AutoRCM, however, since hekate is open source and SX OS is closed source, the implementation of AutoRCM may vary, such that SX OS can not "auto-correct" it during emuNAND creation. The emuNAND creation is in fact working like it should, nothing is wrong with it, it's copying the system files as they are on NAND and making an emulated environment out of them, even the intentionally corrupt bootloader.
So, if you have any trouble, you can try disabling AutoRCM (fixing the bootloader) instead of going full factory reset mode on the thing. However, if you updated the OFW and then try to do non-autoRCM, you may lock the console to that firmware, not that it matters too much for an RCM exploitable model, but some might want to preserve their switch's original state.
This is just my guess as I am only one person and have but one console to test this theory on... Could try a poll.