Hacking Installed a9lh in o3ds, sysnand doesn't boot up even after re-flashing it

[Rak]

I was installing a9lh on a friends o3ds and found a series of problem throughout the process:

First the emunand didn't want to boot up, I ended up changing the sd card and the CFW I was using and eventually it started to boot up. But the CFW would stop working after each entry into emunand (regardless of if I used rxtools or reinand, luma wasn't working for me) and would start working again randomly after a number of tries (entering sysnand once seemed to fix it, but correlation doesn't equal causation).

After that I managed to downgrade the emunand, but I needed to defrag the ctr partition because a previous gateway downgrade had left the system in a fragmented state. I also needed to stop using reinand because it was preventing native firm from being downgraded. This should be included in the guide instead of that "use whatever CFW you want" crap. Specially the part about the gateway downgraded fucking up the system like that.

After all that trouble I managed to flash my downgraded nand to the sysnand, got the otp, re-flashed the original nand and was back safe and sound on the menuhax booted homebrew launcher. Everything was awesome! I finished setting a9lh and luma to auto boot emunand and everything was working fine!...... Except the sysnand, it refuses to boot no matter how many time I re-flash it. I even tried flashing my emunand into it, but nothing seems to work.

Right now I am suspecting that it has something to do with a9lh, but I have no way of confirming that. I don't want to give the system to my friend in that state, any ideas what could have gone wrong? If it is important, I have been re-flashing it using decrypt9 loaded through the luma payloads and with the keep a9lh option.

 

[Halvorsen]

Simply put, the NAND chip in your system is probably dead. It was never meant to be used so extensively in a short amount of time and as such likely fried itself.
This isn't the first case; I've seen four others before.
You always run risks with hax.

 

[Rak]

Simply put, the NAND chip in your system is probably dead. It was never meant to be used so extensively in a short amount of time and as such likely fried itself.
This isn't the first case; I've seen four others before.
You always run risks with hax.

Really!? Damn. I mean, I flashed the sysnand twice and it broke the chip? That doesn't seem to be normal behavior considering the nand chip should be able to receive any number of upgrades from nintendo. If the problem really is hardware related there isn't much to do about it. :/

Is there no other possibility? Can it be confirmed somehow or there is no way of knowing besides the fact it doesn't work?

 

[Halvorsen]

Really!? Damn. I mean, I flashed the sysnand twice and it broke the chip? That doesn't seem to be normal behavior considering the nand chip should be able to receive any number of upgrades from nintendo. If the problem really is hardware related there isn't much to do about it. :/

Is there no other possibility? Can it be confirmed somehow or there is no way of knowing besides the fact it doesn't work?

Updating through Nintendo is nowhere near intensive as a NAND backup and restore. And btw, how'd you get a9lh with two nand restores?
Even if, that mean you dumped the NAND twice, in addition to flashing it, meaning around an hour of intensive data transfers.

 

[Rak]

Updating through Nintendo is nowhere near intensive as a NAND backup and restore. And btw, how'd you get a9lh with two nand restores?
Even if, that mean you dumped the NAND twice, in addition to flashing it, meaning around an hour of intensive data transfers.

One backup to get an original nand, one restore to get to 2.1 and one final restore to get back to the original nand. But, if the proximity of the actions is important, I guess you are right.

In any case, this too should be explained on the guide. Not only is it a risk that is not mentioned even once, it also could help users by telling them to go slowly and let the chip cool off (assuming the heat generated was the cause of the failure).

Anyway thanks for your time in explaining this to me, and please, do tell the guide maker about including the troubleshoot for the people who had previously used gateway downgrade and about reinand blocking 2.1 nfirm downgrade.

 

[funnystory]

One backup to get an original nand, one restore to get to 2.1 and one final restore to get back to the original nand. But, if the proximity of the actions is important, I guess you are right.

In any case, this too should be explained on the guide. Not only is it a risk that is not mentioned even once, it also could help users by telling them to go slowly and let the chip cool off (assuming the heat generated was the cause of the failure).

Anyway thanks for your time in explaining this to me, and please, do tell the guide maker about including the troubleshoot for the people who had previously used gateway downgrade and about reinand blocking 2.1 nfirm downgrade.

Ask for other opinions first though,I find it hard to believe your nand chip would be fried.

 

[Rak]

Ask for other opinions first though,I find it hard to believe your nand chip would be fried.

Well, if anyone else has any other ideas, I will be watching this thread. At least the 3ds is still usable thanks to the emunand and a9lh still working.