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.
Ris there a reason secureboot needs to be disabled? cant you enroll a new key with it enabled?
Ai did with it enabled but on version 17 instead of 18
Kcan't boot the system to run the ujust
Rbut if they're already booted into a pre-problem image, they can literally just
ujust enroll-secure-boot-keyand problem is gone
Jyeah ok so here's what I did
Rmight be good to specify
JI was booted into my working image
Jand reenrolled my key
Kyes that's true, but also everyone should already have this key
Jthen I was good to go
Kbecause if they didn't, no akmods
JORGE
Jyeah what RO describes is how I did it
Jright
JI know man
Jlook, I didn't invent secureboot lol
Jnot my fault
Rright so ensuring the existing key is enrolled should be the only step for users who aren't seeing the issue yet
