Closed 1337weegee closed 3 years ago
Thats not how this works lol
Once Fusee-primary is used you are NOT using hekate, so nothing in your hekate config matters in the slightest, other than the fact that you told it to boot fusee-primary.
If anything changed at all, it's in atmosphere, and your configuration of it (or lack thereof).
I'm well aware of this. This answer does not explain why the version string used to end in S when I used to select the "Not Working" config in older hekate/nyx builds and now there's always an E. I used this setup for testing things and many others can attest to this being the past behavior, whether intentional or otherwise.
I understand well that pointing to fusee-primary with the config means hekate's settings are ignored as I used to configure atmosphere's BCT.ini before it was moved in the recent update. I'm just confused as to why the emummc_force_disable=1 line behaved in this manner before.
Edit: Please excuse me if I came off as rude here. I'm slightly irritated and am looking for a proper explanation.
Did you move the config to the new location? Maybe have copies in both locations just in case the move isn't taking place for some reason? If you are launching using fusee-primary, anything you config in hekate does not apply. So it has to be a recent config change that caused it. Try copying and setting up a new atmosphere folder?
That actually didn't matter to me because I always delete the atmosphere folder before updating or downgrading and use fresh files. The BCT.ini goes in SD:/atmosphere/config. The recent update just moved it to config_template instead so those who overwrite the atmosphere folder do not lose their existing config.
In any case, downgrading to 0.16.2 should have had my expected outcome if this were an atmosphere issue.
Because you have a emummc.ini that fusee uses
fusee prim can't use hekate's config.
All this time you were booting emummc with AMS Sys Test
that uses payload=
.
Payload= bypasses everything. The hekate boot entry keys are for hekate only.
If you want to learn more because that was asked many times, check the closed issues tracker.
Lastly, you are not supposed to delete the bootloader folder. You are supposed to drag n drop and merge it, in order to maintain all configs. hekate release is made to never need a bootloader folder delete.
Title says it all really. For months now, I've been using the emummc_force_disable=1 line alongside payload=bootloader/payloads/fusee-primary.bin in order to boot into SysMMC by having a config point to fusee-primary. Since 5.5.2/Nyx 0.9.8, this no longer works and the emuMMC will still force boot. Here's the config I've been testing with:
[config] autoboot=0 autoboot_list=0 bootwait=3 backlight=100 autohosoff=0 autonogc=1 updater2p=0 bootprotect=0
{--- Stock ---} [Stock (SYSNAND)] emummc_force_disable=1 fss0=atmosphere/fusee-secondary.bin stock=1 icon=bootloader/res/stock_boot.bmp {}
{------ Atmosphere ------} [AMS EMU (Working)] payload=bootloader/payloads/fusee-primary.bin emummcforce=1 icon=bootloader/res/bootlogo.bmp {}
[AMS Sys Test (Working)] fss0=atmosphere/fusee-secondary.bin emummc_force_disable=1 icon=bootloader/res/bootlogo.bmp {}
[AMS Sys Test (Not Working)] payload=bootloader/payloads/fusee-primary.bin emummc_force_disable=1 icon=bootloader/res/bootlogo.bmp {}
I did manage to boot SysMMC with the fss0 line, but I'm perplexed as to why I cannot do it using the last config (the Not Working one). This persists across V1 and V2 Erista units as well as Mariko units, to my knowledge (if that matters). I didn't see anything in the changelog that would cause this, but I may have missed something.
On a slightly unrelated note: During my testing, I stumbled upon an issue where I'd get the "Old nyx GUI found" error when downgrading to hekate 5.5.1/nyx 0.9.7 with the GUI displaying 5.5.2. I ALWAYS delete my bootloader folder before extracting a different one and I even downloaded the older one again to make sure I didn't miss anything. Still couldn't boot to SysMMC using last config which I found really strange.
Lastly, the hotfix pushed yesterday did not affect this either, but I'm not surprised as that was supposedly only for that partition manager error.