erm... have i done a stupid mistake?GARBL
erm... have i done a stupid mistake?
ah ok, nothing wild - but maybe you could add that line of enabling the patches? of course that disabled emunand boot and signature checks...."Starting config from scratch" literally means all the options are cleared. Select your patches again. (And that previous post was a stupid post I wanted to delete)
Should work fine as long as you do it from emuNANDah ok, nothing wild - but maybe you could add that line of enabling the patches? of course that disabled emunand boot and signature checks....
But on the other hand - it didn't helped :/ Tried to boot for 5 Times now.
But just in case - the online update should worke right? because then i just gonna reinject my 9.5 emunand back and try to update it with the online update again.
Alright buuuutShould work fine as long as you do it from emuNAND
well i didn't changed the firmkey.bin...@mid-kid might the firmkey.bin be different for newer firmwares? Meaning a different cetk will be needed, and since the old firmkey.bin is still there it won't boot?
Well that was my point, maybe you needed a different firmkey.bin for 9.5+ firmware.bin files... But since you seem to have gotten it working, that theory is out the door and I updated my postwell i didn't changed the firmkey.bin...
@mid-kid might the firmkey.bin be different for newer firmwares? Meaning a different cetk will be needed, and since the old firmkey.bin is still there it won't boot?
EDIT: never mind, looks like the issue was solved
That's what I thought, but figured it was worth a shot. It was worth it since I learned somethingfirmkey doesn't change.
You don't really need the cetk anymore (it's needed to generate firmkey.bin and is uneeded afterwards) and yes the 9.5 firmware.bin won't boot the 9.6+ emuNAND this is a known thingOk, so the online update worked but i had to boot 4 times untill it finally loaded
I will now copy the "old" firmware.bin and cetk from before the cake-update back and try to do it again.
But so far i think the problem lies in the old firmware.bin and cetk which i had.
This seems to be happening a lot to n3ds users lately. I have no idea what is causing it.
If anyone who had this problem has been able to solve it, could you please state how? (I'll add it to the FAQ)
Think of it like this, the system applications (home menu, etc.) and services check which firmware version (which is what firmware.bin is ) and if it's not the right version it simply refuses to start. So, using a 9.5 firmware.bin means that 9.6+ applications say "firmware version doesn't match the version I want, so I will refuse to launch" all that is needed is the proper firmware and both the firmware and applications and services all are happy and the system boots... Could we remove these checks? Absolutely. Would it be practical to do so? Probably not... Spoofing the firmware version in the firmware.bin might be though but why do that when you can get the right firmware anyways?Yeah - the wrong firmware.bin and the fact that the patches have been disabled (which didn't let emunand boot) are 2 errors which i encountered, so i think those 2 options should be mentioned when such update-questions are happening.
And sorry for taking both of your times @dark_samus3 and @mid-kid.
After installing cake-cfw somewhere near december 2015 i haven't been loking around for the emunand stuff, just saw it today and tried it :/ Therefore the common knowledge about the 9.5 firmware.bin and the 9.6+ firmware.bin was missing (and i don't even know why we do need those files).
And thanks at this point for your cake-cfw! It is really easy to use - in my case much easier than rxtools.
May be a good thing because of 10.4's ASLR like thing.Think of it like this, the system applications (home menu, etc.) and services check which firmware version (which is what firmware.bin is ) and if it's not the right version it simply refuses to start. So, using a 9.5 firmware.bin means that 9.6+ applications say "firmware version doesn't match the version I want, so I will refuse to launch" all that is needed is the proper firmware and both the firmware and applications and services all are happy and the system boots... Could we remove these checks? Absolutely. Would it be practical to do so? Probably not... Spoofing the firmware version in the firmware.bin might be though but why do that when you can get the right firmware anyways?
That's a very good point, but is the "ASLR" built into the kernel (where it should be) or is it built into the applications, since I think Smea mentioned that it was only in certain applications...May be a good thing because of 10.4's ASLR like thing.
I retried with CakesFW 108.
My settings:
n3DS sysnand 9.2E
Emunand 10.5E
Linked nands
Patches:
Enable Emunand
Disable signature checks
Configuration:
Enable autoboot
It does not work... Just a black screen, I never reached the system menu. No problem with ReiNand... I don't understand what's happening.
I have the same issue after updating to 10.5. Can boot into Sysnand fine but if I try to boot to Cakes just black screen.
He already got his problem fixed, the emuNAND patch got disabled so it was just looping sysNAND menuhaxI'm surprised that this works with ReiNand, but what is likely happening is a result of your NANDs being linked.
Because your NANDs are linked, they share theme data. Since the theme data is where menuhax lives, both NANDs will attempt to autoboot menuhax when they start up. This causes a loop where it tries to load CFW, then load menuhax, then crash.
Possible solutions:
1) Unlink your NANDs via tinyFormat. Arguably the best solution, and the one that everyone and their mother will tell you to do.
2) Manually boot cakes every time from the Homebrew Menu. Yuck.
3) Use this modified version of CHMM2 and follow the steps to dissociate the themes (and thus avoid menuhax loops) between emuNAND and sysNAND. The idea is that since sysNAND doesn't have theme shuffle, it will ignore loaded theme shuffles. However, emuNAND will not ignore it, thus causing it to load the shuffled theme instead of the menuhax theme.
You might be able to use this to set up themehax in your emuNAND separate and distinct from menuhax in sysNAND, but I only recently set this up, so I haven't tried this.
I hope this helps!