I just want to warn people against what Djoen said: EMUNAND IS NOT A VALID SYSNAND IMAGE SINCE 7.0
If you restore emunand to sysnand, you will end up with a bricked system. BE SMART
OK. Wait a minute. If I format EmuNAND while on 9.2, then dump SysNAND on 9.2, copy both to my PC, and fc/b them, I get no differences encountered. So, at least in that case, it is a valid SysNAND dump. But what you're saying is, if the EmuNAND hadn't been formatted at that version, it would not have been a proper dump? Does it not perform the update properly or something? And would using UpdateCDN instead of doing an online update make a difference?
Needless to say your message is reaching me a bit late, because as a test, I did try restoring a 9.2 EmuNAND as NAND.BIN on a system that had never been beyond 4.5, and that did get me a brick. Well, that makes sense if it's not creating a proper NAND. Before that, I'd taken my Zelda unit that had actually been on 9.2 back and forth several times without issue (first time, I forgot to turn wifi off and got the update message, second time, I forgot to backup the 4.2 before using SMT4 to take it to 4.5). I've downgraded two other consoles without issue, so, the software seemed perfectly safe until this incident. Also, thanks to people who apparently weren't aware NANDs are system-locked, we know the restore feature won't restore a NAND from another system. Apparently there are some inconsistencies it can't check for though.
I've been wracking my brain trying to figure out what caused the brick. Since, I had crossed off the NAND dump being invalid, I was starting to think the brick had occurred because I unlinked. After all, once you've eliminated all other possibilities, whatever is left, however unlikely, is the solution. Looks like I crossed something off the list too quickly though. Well, it's been said that, in any equation, the statistic that is most obviously correct, beyond all need of checking, is the error. Apparently there's some truth to that.
This would also explain why people get bricks if they update in GW mode without EmuNAND present, if GW mode doesn't create a valid NAND. I would probably not have tried to update SysNAND with a ROM using a Gateway anyway, since I also own a Sky3DS. So, apparently Gateway mode assumes that it's working with EmuNAND when you update. Something tells me they're going to want to add a check for that. Still, I ran into no issues using ROM update to get the EmuNAND on a new system to 8.1, then using UpdateCDN to take it to 9.2. Not that it makes sense for me to keep 9.2 EmuNAND backups, being able to run Ninjhax from the Sky, but for the sake of completeness, before going to 9.4, I did. Anyway, I'm not seeing the problem the OP mentioned. Seems fine for updating EmuNAND.
Here's the thing, though. Someone with a hard mod that I asked to test using the restore feature with an EmuNAND dump was actually able to restore a 9.4 EmuNAND to SysNAND. So, with my 9.2 being from an update, and therefore created by 2.6, and a 9.4 EmuNAND obviously being created by 2.7 or later, is it possible they've fixed this issue in newer versions?
Looks like once I unbrick it this weekend, I'll have several tests to run. One thing's for sure, this restore option certainly takes the safety off the gun so to speak. Fortunately, soldering 4 wires isn't something I even break a sweat over.
