Homebrew Plailect guide problem - system fails to boot, failed A9LH installation?

[SG6000]

Hello,

I'm a bit concerned about an issue I have with the process I'm following (Plailect's A9LH guide).

- I have a Euro N3DS (priginally on FW 9.6) which I downgraded today to 9.2 (as per the guide) using a Freakyforms cart.
- I had to rerun the downgrade (as it had stalled with an error message part way through) but all seemed fine upon a 2nd attempt.
- I launched Decrypt 3dsx and created a NANDmin.bin backup
- Did all the Part 3 A9HL prep work - double and triple checking that all the correct files were in the right place in the sd card folders and launched SafeA9LHInstaller which booted into black screens.
- After waiting, I checked the guide again:

"Section II - Installing arm9loaderhax

New 3DS

• Get into the homebrew launcher through the entrypoint of your choice
• Launch SafeA9LHInstaller
  • If you get a glitched screen, follow this troubleshooting guide"

Although I wouldn't have classed the the black screens as glitched - but clearly there was a problem, so I waited a while and rebooted to try again. However, I have failed to reboot the console at all and have tried to do so:

- with the card inserted
- without the card
- with all the files re-copied onto the card
- using the test payload
- after deleting the specific folder in Nintendo 3ds///extdata (as suggested as part of the 'Black screen on sysnand boot' section further down in the troubleshooting section

If anyone has any suggestions on anything else I can try (or any other thoughts) I'd appreciate it, because although the blue power light comes on I'm starting to think that this machine might be bricked.

 

[antiNT]

can you boot into recovery mode?
"The recovery mode (also known as Safe Mode Boot) can be accessed when turning on the Nintendo 3DS while holding A+R+L+Up(DPad). This menu is made to update your Nintendo 3DS through internet, if an update previously failed." You will be on the latest firmware but it's better than a bricked console.

 

[SG6000]

No, I forgot to mention that. Recovery mode does not work. Booting into hourglass doesn't work either.

I have an A9LH'd O3DS so being on latest FW and starting again wouldn't have been a big deal.

 

[osaka35]

- I had to rerun the downgrade (as it had stalled with an error message part way through) but all seemed fine upon a 2nd attempt.

Quick question, did you restart after downgrading or did you go straight to Decrypt9 after downgrading? Just trying to troubleshoot where exactly the problem potentially occurred.

 

[SG6000]

Quick question, did you restart after downgrading or did you go straight to Decrypt9 after downgrading? Just trying to troubleshoot where exactly the problem potentially occurred.

I rebooted after downgrading (having replaced the otherapp.bin for Freakyforms with one that for 9.2).

There's no apparent mention of issues with SafeA9LHinstaller other than the glitched screen -and if my black screens count as being glitched I would have thought that rebooting to load up SafeA9LHinstaller again would have been the safest course or action.

Thanks for checking.

 

[dudemo]

I just had the same problem. Literally. Launched SafeA9LHInstaller and got a black screen, but I followed the instructions exactly anyway. When the console failed to reboot automatically, I held the power button to force a shutdown.

It rebooted to a black screen. So I held the power button again and tried again while holding select to bring up Luma's config. It booted to the home menu. So I tried reinstalling A9LH and this time I could see the Installer screens. Ran the process again and now I'm on 11.1 A9LH'd.

Did you have a failed downgrade?

 

[SG6000]

I did yes - the first attempt to downgrade to 9.2 shut down partway through, but it worked fine the second time.

I was satisfied that the second attempt was successful as Decrypt had launched and I was able to create a NAND back up.

Launching Luma or hourglass isn't happening unfortunately.

 

[SG6000]

This isn't a bump as such - just wanted to point out that I popped into the 3DSHacks IRC to see if anyone there had any ideas, and after answering several questions about how my unit behaves and what exactly had happened the helpful people over there seemed satisfied that this was worth noting officially on the github.

I know the general consensus is that 99% of issues and bricks are the result of user error but in this case SafeA9LHinstaller booted to a brick without me being able to have prevented it - and once something like this happens you really do wish it was user error that caused it because at least it's a logical explanation.

 

[Inochi.no.Zenmai]

Well, if you're 100% certain this wasn't user error, sorry then. If the console booted to a black screen (not even backlight init) then it's a brick. I had one doing the A9LH install but I knew what I did, messing with a system file and forgetting to restore the original. The console bricked when downgraded to 2.1. Thankfully someone did a hardmod and now it's working fine.

Hardmod it's what you'll have to do now.

 

[SG6000]

Thanks, and yes, I know it's a hardmod or nothing at this point.

I've actually done a decent of number stock 3DS-to-A9LH mods - for friends and a few friends of friends - and they've all gone more or less smoothly except for the one time that I was complacent (with my own unit). I knew exactly how I'd messed up simply by retracing my steps.

I know that the otpless method is technically the quickest and safest one yet but I don't think I'll be be touching it again until SafeA9LHinstaller gets a legit stability update of its own.

 

[Quantumcat]

Good thinking making a NAND backup - now you have a way to recover. Sorry that happened to you though!!

I'm sure the people on the IRC asked already - but did you reuse the SD card that you installed a9lh with on the other console? Maybe the OTP.bin was still on the card? Although I thought SafeArm9Installer had a way of verifying the correct OTP.

 

[SG6000]

No, it was a fresh card and formatted before use. Also the new method for N3DS-to-A9LH doesn't involve retrieving the otp. And yes, there was indeed someone who asked about the otp.

Actually, before I logged off from it there was someone else reporting a similar issue - black screens and some kind of bricking following launching SafeA9LHinstaller - but as he/she was able to boot into Luma config and therefore also boot into hourglass in order to reflash a backup their situation seemed to point in the right direction.

 

[el_gonz87]

Strange, I did this yesterday and I got 2 black screens, but on 3rd attempt it worked fine.

I forgot to rename hourglass9 to start_hourglass9, can you confirm this? (I know you said you double check, but sometimes it doesn't hurt to triple )

Would also help if you post a directory tree of Sd card just in case to have an extra pair of eyes look.

Did you also make sure you got the SafeA9LHInstaller for the model i.e. new 3ds?

 

[XxShalevElimelechxX]

Good thinking making a NAND backup - now you have a way to recover. Sorry that happened to you though!!

I'm sure the people on the IRC asked already - but did you reuse the SD card that you installed a9lh with on the other console? Maybe the OTP.bin was still on the card? Although I thought SafeArm9Installer had a way of verifying the correct OTP.

Well, he can recover without a backup too, he can flash a CTRNAND partition through a hardmod.
He will lose everything, but its better than a bricked console though...

 

[annson24]

Well, he can recover without a backup too, he can flash a CTRNAND partition through a hardmod.
He will lose everything, but its better than a bricked console though...

Really? Was this ever done before?

Sent from my SM-N930F using Tapatalk

 

[cravas]

Well, he can recover without a backup too, he can flash a CTRNAND partition through a hardmod.
He will lose everything, but its better than a bricked console though...

Where did you see or heard about this???
If it were possible, then who would care for NAND backups from the console???

You should try to know better before stating this.
Or, post the source so to have a confirmation of it.

--------------------- MERGED ---------------------------

Did you also make sure you got the SafeA9LHInstaller for the model i.e. new 3ds?

I'm also thinking the same: is it possible that you used the v2.0.3 instead of the v2.5?

Other then this, it looks OP is "that one guy that bricked while installing A9LH".

@OP Good luck reviving it.

 

[XxShalevElimelechxX]

Really? Was this ever done before?

Sent from my SM-N930F using Tapatalk

It WAS done and tested by myself too.
CTRNAND Transfer...: This menu contains various options to enable transfer of CTRNAND partitions between consoles.

From d0k3 release notes of d9wip- * "Auto CTRNAND Transfer: Automatically transfer a transferable CTRNAND image to this consoles NAND. Without A9LH installed, this will overwrite the FIRM0, FIRM1, CTRNAND. With A9LH installed, this will only overwrite CTRNAND. O3DS images can be transferred into N3DS consoles, but the NCSD header of the NAND may be overwritten. * Dump transferable CTRNAND: Dump a CTRNAND image for later use in the feature above. Transferables images can be shared between consoles. * Autofix CTRNAND: Use this to automatically fixes the CMACs for movable.sed, *.db and system saves inside the CTRNAND. It will also fix the inside the data folder. This is useful f.e. when a CTRNAND from another console was previously injected the regular way.SO

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds). I wonder if this might bypass the N's 11.0 hardcoded min system title version list as I don't think the transfer is using the direct installing/removal of titles into the system. Then again, running d9 requires arm9 and I highly doubt the CTRNAND transfer functionality uses arm11k services only so I think it doesn't make any changes to the 11.0 people."
It overwrites FIRM 0/1, where a9lh is actually installed, and ALL the system titles, and again, Ive already tested it with my n3ds (bricked it on purpose cuz i did to myself a hardmod just in case lol) and it worked like a charm.

 

[Quantumcat]

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds)

Decrypt9 does not work from homebrew over 9.2. Above 9.2 it has to be run from an a9lh payload.

Edit: or did you mean with hardmod? I didn't know you could do a CTR transfer by hardmod.

 

[SG6000]

Strange, I did this yesterday and I got 2 black screens, but on 3rd attempt it worked fine.

I forgot to rename hourglass9 to start_hourglass9, can you confirm this? (I know you said you double check, but sometimes it doesn't hurt to triple )

Would also help if you post a directory tree of Sd card just in case to have an extra pair of eyes look.

Did you also make sure you got the SafeA9LHInstaller for the model i.e. new 3ds?

Yestersday I spent more time checking everything over than I have ever done with the longer methods in the past - and that was prior to the brick.

Hourglass was renamed correctly (which wouldn't have helped anyway as Luma / A9LH wasn't installed to begin with), data input files were v3 with the new otpless-specific firm and SafeA9LHinstaller was 2.5 and 100% the correct N3DS compatible one. I confirmed all of this with guys on the IRC before they recommended that an issue was raised, and if there was any indication that I had used / placed the wrong files or made any other kind of common mistake I wouldn't think it would be worthwhile drawing attention to it.

Thanks in any case.

--------------------- MERGED ---------------------------

Other then this, it looks OP is "that one guy that bricked while installing A9LH".

@OP Good luck reviving it.

I don't want to sound overly dramatic but OP was that one guy who found that SafeA9LHinstaller v2.5 bricked his unit.

 

[HyperT]

It WAS done and tested by myself too.
CTRNAND Transfer...: This menu contains various options to enable transfer of CTRNAND partitions between consoles.

From d0k3 release notes of d9wip- * "Auto CTRNAND Transfer: Automatically transfer a transferable CTRNAND image to this consoles NAND. Without A9LH installed, this will overwrite the FIRM0, FIRM1, CTRNAND. With A9LH installed, this will only overwrite CTRNAND. O3DS images can be transferred into N3DS consoles, but the NCSD header of the NAND may be overwritten. * Dump transferable CTRNAND: Dump a CTRNAND image for later use in the feature above. Transferables images can be shared between consoles. * Autofix CTRNAND: Use this to automatically fixes the CMACs for movable.sed, *.db and system saves inside the CTRNAND. It will also fix the inside the data folder. This is useful f.e. when a CTRNAND from another console was previously injected the regular way.SO

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds). I wonder if this might bypass the N's 11.0 hardcoded min system title version list as I don't think the transfer is using the direct installing/removal of titles into the system. Then again, running d9 requires arm9 and I highly doubt the CTRNAND transfer functionality uses arm11k services only so I think it doesn't make any changes to the 11.0 people."
It overwrites FIRM 0/1, where a9lh is actually installed, and ALL the system titles, and again, Ive already tested it with my n3ds (bricked it on purpose cuz i did to myself a hardmod just in case lol) and it worked like a charm.

That's not a hardmod; a hardmod is a 1:1 writing to the NAND chip. decrypt9 isn't hardmod