So what was the rundown of the problem, fedora updated shim and it broked everything downstream that
So what was the rundown of the problem, fedora updated shim and it broked everything downstream that had that as a dependency?
KThat also means this whole time you haven't had any kmods
KDon't know the root cause yet, but having our own key solves the problem
RView shim-x64 in the Fedora package repositories. shim-x64: First-stage UEFI bootloader
KAs evidenced by bazzite never breaking
KWhat we do know is it breaks secure boot and upstream is affected
KAnd we're just trying to put the fire out
Aok can anybody explain to me how i unpin a version? i just follow did this"❯ sudo ostree admin pin 0"
ZIt boots now on my laptop with secureboot enabled
KAwesome
KAppreciate you testing this with us
K@EyeCantCU congrats on saving the day
Hsudo ostree admin pin --unpin $indexget the index through
rpm-ostree status -v
KOnly a fucking Linux nerd would do
pin --upinunpin
Htake it up with the rpm-ostree devs 
KNo I'm just going to laugh at it in private and enjoy the software
ELol, you all had it just about figured out :). I'll get the signer in main after dinner
K@j0rge
Aspell ostree unverified registry first try
Athats abuse
Aor the fact that its docker://
Rthanks all for the efforts here. let me know when a decision has been made on whether to put this in the "other main" as well, whatever the decision may be
Abut oci: without //
KIt's going to hit main
EWhat's abuse is remembering the order of those words
RAi know
Ai had to do it 5 times today
Aand then bootc of course changes all of that
R
Aman when i see this i am happy that i am using ublue, i don't even understand what was the problem but it hit me and like hours it was gone, without i even taking a look at a github issue, Thanks for the effort guys.
JUgh I'm so mad right now lol
Rwho should we be mad at, it's still not clear
Rsomewhat embarrassing for fedora in general though tbh
JI blame the CEO of SecureBoot
JSounds like something difficult to unit test for
KBill Gates!!!
Jok so I have sd on, but still have the issue
Jdo I need to turn off sd and reenroll a bunch of stuff?
Rthis basically means that people using ublue, even the main images, will have a better base experience for upgrades than people using the official silverblue. yikes
JRemember when upstream images broke for like 10 days and no one noticed?
Jthat was last cycle though
Athats the point though
Jwe were all working though since we use the unofficial builds anyway
Ryeah im not sure what word to use
Rcause yeah the experience should be better
Rbut fedora is still supposed to get like "the basics" right
Ai feel like something this "core" should be stable and not something that downstream "distro" on "experience" should focus. but i don't understand the problem tough
Rthat's what im getting at yeah
Rtime for ublue to move to an openSUSE base :clueless:
KIf you've updated and your (Bluefin/Aurora) system is no longer booting, please do the following:
1. Disable secure boot in your BIOS
2. Boot into bluefin, and run
ujust enroll-secure-boot-keyujust update3. Reboot and follow the prompts.
4. Reboot again into your bios and enable secure boot once more.
You are only affected by this if you did not enroll our key during the initial install, which also means that you have not had any of our kmods enabled all this time. The root cause of the bug is still under investigation, but we can confirm it affects upstream Fedora. Thank you for your understanding.
Existing users with working systems can start from step 2 to ensure their system will remain functional during this time.
