Hacking RELEASE Sigpatches for Atmosphere (fusee-primary only!)

[Danethos86]

Your choice, i know some people are still using 9.2 because none of the games they are currently playing requires 10.x.x

You can stay on that version until a game asks to update your firmware if you wish.

updated to 10.0 and now few games when play have a black screen and need force shutdown system and reboot.
i have sigpatched yet those games still mess up was there something i am missing?

 

[Draxzelex]

Well you (finally) cut the fat so I concede what I said about arguing for the sake of arguing.

To be fair, you haven't responded to the part where I mentioned that fss0 to sysMMC = 32 second boot and fusee-primary to emuMMC = 37 second boot. The fact that you are suggesting a bootloader for booting a whole 5 seconds faster (let alone 20 seconds) is a huge advantage for something a standard user might notice a few times a month is very ridiculous.

Also, no, I'm not arguing for the sake of arguing. Just showing your hypocrisy since you said that people were being misleading about fss0. With you being misleading on trying to promote hekate features as features solely for fss0, you try to say things such as:

"For example, you cannot tell if you booted emuMMC or not with Fusee unless you use different themes"

Which is laughable since, assuming that people installed games on the emuMMC, they will be able to tell the difference in the list of games that appear, and

"even then, fusee will not hesitate to kick you into sysMMC."

Which is even more misleading, because as long as emummc.ini's value doesn't change (and maybe the raw partition doesn't get corrupted), this will never happen

You never answered my original question of whether you would choose the faster or slower driving route. Unless you were implying that the faster route was better since you suggested getting patches that are updated faster. I and some people also don't really believe time is trivial especially when, in another thread, people were debating the installation speed of .NSP versus .XCI files (which I'm not in the interest of discussing). And for both of those points you cannot seem to wrap your head around, I am referring to users who are setting up emuMMC for the first time hence why I brought up people launching sysMMC by accident. Lastly, you still have not provided any reasons why someone should use fusee over fss0.

 

[Tokiwa]

updated to 10.0 and now few games when play have a black screen and need force shutdown system and reboot.
i have sigpatched yet those games still mess up was there something i am missing?

Try starting fresh with atmosphere. Delete both atmosphere and sept folders, download again fresh from github and apply the sigpatches from this thread and nothing else (also make sure you're using latest fusee-primary.bin, it gets updated as well).

If this doesn't fix the issue, try re-installing/updating your non-working games.

 

[pofehof]

. I and some people also don't really believe time is trivial especially when, in another thread,

So, you were arguing for the sake of arguing on this point?

And for both of those points you cannot seem to wrap your head around, I am referring to users who are setting up emuMMC for the first time hence why I brought up people launching sysMMC by accident.

You never implied this until now, and that is a ridiculously niche point. Still doesn't change you being very misleading on things such as fusee somehow kicking you to sysMMC which makes no sense (when hekate creates an emuMMC, the ini file's default is to have it enabled if you use fusee), and you still haven't provided why you said this.

Lastly, you still have not provided any reasons why someone should use fusee over fss0.

I have provided my reason. Patches for fusee usually, if not, always, come out faster than for hekate (in terms of days). Also, another thing is I don't care about boot time at all, (especially when the difference between both for me is negligible). Finally, doesn't hurt to use the method that atmosphere devs recommend. If atmosphere has an update, and hekate doesn't update right away, I can still used the new atmosphere if I use fusee-primary through chainloading.

 

[hippy dave]

There's a pinned thread about which patching/booting method to use. Take it there already and stfu.

 

[Danethos86]

Thanks i figured out that i needed sig patches for hakate and worked.
Apparently os still had partial hakate even though deleted sept and atmosphere folder. So when used hakate patches and not atmosphere ones worked perfectly.

 

[Asia81]

These are atmosphere sigpatches, not fss0, so they require using fusee primary (directly or through hekate) to work. At this time I dont think there are any fss0 patches for the latest atmosphere.

How would I do that tho?
This is my ini file.

Spoiler: Ini file

[config]
autoboot=0
autoboot_list=0
bootwait=1
backlight=220
autohosoff=0
autonogc=1
updater2p=0
{------ Atmosphere ------}
[Atmosphere EmuNAND]
fss0=atmosphere/fusee-secondary.bin
kip1=atmosphere/kips/*
emummcforce=1
icon=bootloader/res/emu_boot.bmp
{}
[Atmosphere SysNAND]
fss0=atmosphere/fusee-secondary.bin
kip1=atmosphere/kips/*
emummc_force_disable=1
icon=bootloader/res/sys_cfw_boot.bmp
{}
{-------- Stock ---------}
[Atmosphere Stock]
fss0=atmosphere/fusee-secondary.bin
stock=1
emummc_force_disable=1
icon=bootloader/res/stock_boot.bmp

 

[Tokiwa]

Thanks i figured out that i needed sig patches for hakate and worked.
Apparently os still had partial hakate even though deleted sept and atmosphere folder. So when used hakate patches and not atmosphere ones worked perfectly.

Yeah, if you're booting with fss0 then you need the Hekate patches. The patches from this thread are intended for fusee-primary.bin

How would I do that tho?
This is my ini file.

Spoiler: Ini file

[config]
autoboot=0
autoboot_list=0
bootwait=1
backlight=220
autohosoff=0
autonogc=1
updater2p=0
{------ Atmosphere ------}
[Atmosphere EmuNAND]
fss0=atmosphere/fusee-secondary.bin
kip1=atmosphere/kips/*
emummcforce=1
icon=bootloader/res/emu_boot.bmp
{}
[Atmosphere SysNAND]
fss0=atmosphere/fusee-secondary.bin
kip1=atmosphere/kips/*
emummc_force_disable=1
icon=bootloader/res/sys_cfw_boot.bmp
{}
{-------- Stock ---------}
[Atmosphere Stock]
fss0=atmosphere/fusee-secondary.bin
stock=1
emummc_force_disable=1
icon=bootloader/res/stock_boot.bmp

You can just put the latest fusee-primary.bin inside bootloader/payloads and boot from the payload menu in Hekate, it works that way too.

 

[Draxzelex]

You never implied this until now, and that is a ridiculously niche point. Still doesn't change you being very misleading on things such as fusee somehow kicking you to sysMMC which makes no sense (when hekate creates an emuMMC, the ini file's default is to have it enabled if you use fusee), and you still haven't provided why you said this.

Just because you subjectively disagree does not make it objectively wrong. Fss0 is superior because there are situations where it is better to use than fusee regardless if you believe it or not. You are also implying everyone uses Hekate to setup emuMMC which, unfortunately, cannot really be said since majority of guides have users partition the SD card manually. Maybe in a few months once guides are updated to reflect the new features of Hekate, this can become a non-issue but without a clear standard, user error is more prone with fusee compared to fss0. And by the way, you still have not chosen the faster or slower route.

I have provided my reason. Patches for fusee usually, if not, always, come out faster than for hekate (in terms of days). Also, another thing is I don't care about boot time at all, (especially when the difference between both for me is negligible). Finally, doesn't hurt to use the method that atmosphere devs recommend. If atmosphere has an update, and hekate doesn't update right away, I can still used the new atmosphere if I use fusee-primary through chainloading.

I should have been more clear. What I meant to ask was objective reasons to use fusee over fss0. I also addressed these points earlier so I won't repeat myself on those.

 

[Danethos86]

Weird part is boot fusee directly via rekado android app.
yet sense hakate menu on sd card fo lakka apparently had to use hakate patches.
Good thing is tinfoil app dont complain about current hakate files I have on sd card.
However i did haha system originally hack system using atmosphere hakate using fusee exploit early 2019 so could explain alot.

Also whats fss0 stand for?

 

[Ibcap]

How would I do that tho?
This is my ini file.
[/SPOILER]

Change the fss0=fusee-secondary line to payload=atmosphere/fusee-primary.bin and put fusee primary in the atmosphere folder. Fusee primary will always use emunand if enabled (assuming you have one made).

 

[jester_]

fss0 vs fusee-primary: you cannot use Tinfoil with patches.ini present. You can use Tinfoil with fusee-primary + sigpatches in this thread.

Why do you think so many people want the sigpatches in this thread? You don't think the majority want to use Tinfoil for their backups?

 

[pofehof]

You are also implying everyone uses Hekate to setup emuMMC which, unfortunately, cannot really be said since majority of guides have users partition the SD card manually.

And by the way, you still have not chosen the faster or slower route.

...This is how it always worked. People used something like MiniTool (PC) or TegraExplorer to partition the microSD card. Hekate was still needed to actually create the emuMMC (which copied the sysMMC info to the partition).

I have already mentioned that, with my 400 GB microSD card, the difference in boot times between both is only five seconds, which is, once again, negligible in my view (and many, many others').

What I meant to ask was objective reasons to use fusee over fss0. I also addressed these points earlier so I won't repeat myself on those.

The objective reason was patches for fusee-primary are usually updated a few days before fss0 patches, which you seem to have ignored.

 

[Bullseye]

I have already mentioned that, with my 400 GB microSD card, the difference in boot times between both is only five seconds, which is, once again, negligible in my view (and many, many others').

Interesting to see that with a large micro SD card as yours 400 GB the boot times difference is only 5 seconds.

In my case I am using a 200 GB micro SD card and the boot time difference is 18+ seconds. Quite a bit larger than that

 

[spike63995]

Completely at a loss here and hoping someone can help me. I just upgraded to 10.0.4 using choidujournx as always. It wasn't loading the CFW but it did just fine after I updated the SD contents. However my games were corrupted so I tried to reinstall and it told me to update sigpatches. So I replaced the sigpatches folders with the ones provided here 2.0.0-10.0.4 and now it shows up to the atmosphere screen and then the screen goes blank and never goes anywhere from there. I am using tegra and fusee-primary. I have downloaded latest atmosphere 0.13 and using the new fusee-primary.bin file. Any help would be appreciated.

EDIT: I'm an idiot, don't delete your original sigpatches....

 

[Draxzelex]

...This is how it always worked. People used something like MiniTool (PC) or TegraExplorer to partition the microSD card. Hekate was still needed to actually create the emuMMC (which copied the sysMMC info to the partition).

Its not about needing Hekate or not. Without a dedicated tool for formatting and creating emuMMC, people messed up and either launched sysMMC without knowing it, ended up on a black screen, ran into an error code, etc. And I will mention for the last time you have not answered my question and faster or slower driving routes. If you do not answer from this point on, I will assume you concede that the faster route is always preferred making Hekate objectively superior regardless of your subjective opinion.

The objective reason was patches for fusee-primary are usually updated a few days before fss0 patches, which you seem to have ignored.

The difference here is there is no objective payoff as opposed to a shorter boot time. I also listed reasons that updating patches too quickly can be negative. In addition to what I stated earlier, not everyone will be aware of a new set of patches whenever they are released. By the time most people realize a new set of patches is required, both will readily be available.

 

[pofehof]

Its not about needing Hekate or not. Without a dedicated tool for formatting and creating emuMMC, people messed up and either launched sysMMC without knowing it, ended up on a black screen, ran into an error code, etc. And I will mention for the last time you have not answered my question and faster or slower driving routes. If you do not answer from this point on, I will assume you concede that the faster route is always preferred making Hekate objectively superior regardless of your subjective opinion.

For point 1, if people followed the guide properly, they wouldn't come to that issue. As I mentioned, they would use Minitool to partition it, then hekate to copy the emuMMC file. If they couldn't do that, that is clearly on them. My original point was, in the end, everyone used hekate to create the emuMMC OS (after the partition has already been created), which means everyone will have an emummc.ini file to work with.

For the faster or slower driving issue, there are issues that you do not take into account. For example, the highway is a couple minutes faster, but it is more mileage, and thus, a majority of people will stick to the local road. This is exactly the same as you are trying to make it seem that the boot difference is a huge deal. The difference is so minute that a majority of people won't care about it. And, here, once again, you are making it seem hekate and fss0 are one in the same though what we are discussing (bootloaders from hekate), they clearly aren't.

The difference here is there is no objective payoff as opposed to a shorter boot time.I also listed reasons that updating patches too quickly can be negative. In addition to what I stated earlier, not everyone will be aware of a new set of patches whenever they are released. By the time most people realize a new set of patches is required, both will readily be available.

A shorter boot time that is so minuscule (supposedly 30 seconds, though in my tests, has been 5 seconds) that a majority of people won't care about it. I defer to the faster or slower driving issue that I mentioned above since you wanted me to answer that question. Your reasoning for "updating patches too quickly being bad" is an issue with updating to the latest firmware/CFW, not to updating to the latest patches...

As for people who are not aware of a new set of patches being released, most will find out within a day or the firmware dropping, and sometimes, the other one might not be updated by then. It's as simple as that.

 

[Joshmas]

any new sigpatched for error on 010000000000000D?
I think it's Edizon?

Hey having this issue also occasionally when I never did before, did you manage to fix this at all?

 

[Draxzelex]

For point 1, if people followed the guide properly, they wouldn't come to that issue. As I mentioned, they would use Minitool to partition it, then hekate to copy the emuMMC file. If they couldn't do that, that is clearly on them. My original point was, in the end, everyone used hekate to create the emuMMC OS (after the partition has already been created), which means everyone will have an emummc.ini file to work with.

]You and I both know that if people followed guides, there would no point for this forum, Discord support servers, or even YouTube video guides.

For the faster or slower driving issue, there are issues that you do not take into account. For example, the highway is a couple minutes faster, but it is more mileage, and thus, a majority of people will stick to the local road. This is exactly the same as you are trying to make it seem that the boot difference is a huge deal. The difference is so minute that a majority of people won't care about it. And, here, once again, you are making it seem hekate and fss0 are one in the same though what we are discussing (bootloaders from hekate), they clearly aren't.

Are you really insinuating that people take the shorter but longer road just to save on gas?

A shorter boot time that is so minuscule (supposedly 30 seconds, though in my tests, has been 5 seconds) that a majority of people won't care about it.

So you admit that fss0 is objectively superior.

Your reasoning for "updating patches too quickly being bad" is an issue with updating to the latest firmware/CFW, not to updating to the latest patches...

As for people who are not aware of a new set of patches being released, most will find out within a day or the firmware dropping, and sometimes, the other one might not be updated by then. It's as simple as that.

The latest patches may not always be a complete set or working properly. It also encourages people updating to the latest firmware when they shouldn't for multiple reasons. And as for your second point, that is purely theoretical with no logical backing. The patches are updated within a short period of time of each other and not everyone visits the site frequently enough to be aware of a new set of patches. Without any hard numbers, a case can be made either way therefore this point is moot.

 

[pofehof]

]You and I both know that if people followed guides, there would no point for this forum, Discord support servers, or even YouTube video guides.

While I do agree that there are many people who don't clearly follow directions, there are other reasons for this forums, such as people wondering why they got banned.

Are you really insinuating that people take the shorter but longer road just to save on gas?

I like how you are trying to be vague on the wording, just like you have been since the beginning of this convo which led you to spreading misinformation. I said people would take the longer (time) but shorter route (mileage) to save on gas. If you find this hard to believe, then I don't know what else there is to say, especially when this actually happens in real life.

This is why it's comparable to the boot times point. For some people, they will be willing to sacrifice five seconds of their life if they have more of a peace of mind with fusee-primary.

So you admit that fss0 is objectively superior.

Please do not put words into my mouth. This is when it's clear that you can't really form an argument, especially when I have been constantly saying this point. Another reason that this can't be a point (let alone objective) is because boot times are different for everyone (difference in SD card). An actual objective point would be SSD vs. HDD (OS boot times) where there are tons of data showing that SSDs are faster than HDDs.

Without any hard numbers, a case can be made either way therefore this point is moot.

Seeing that this isn't the only site where sigpatches are shared, (Discord hacking servers), no, it isn't moot.