Recent searches
Search options
Two Silverblue systems here got hit by the secure boot signature bootloader bug on the upgrade that brought in a new kernel. Good thing there are rollbacks (to boot an older version) and a workaround.
Issue: https://github.com/fedora-silverblue/issue-tracker/issues/543
Workaround to keep using secure boot (run these commands on a working boot): https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-2048350047
Hopefully there's an automatic fix soon? ('bootupd' should be the long term fix for this.)
@garrett I’m stuck to F39 because of that. Or did it get fixed and I missed the window?
@hub As long as you can boot, you should be able to run that workaround.
(I would've expected an automated fix not long after it was filed on 28 March, but here we are in mid-June, with just the workaround.
There is another workaround of not using secure boot, but I don't consider that a valid workaround. The copy files from one place to another is the correct workaround fix.
It just should've been automated at this point, really. 
)
@garrett both are super shit. and yes it should have been a P1 blocker,.
But it's SilverBlue. Has been a let down from day one.
@hub I mean, all OSes have their issues (a recent Windows release accidentally made the start menu not available, for example).
But yeah, I agree. This should be a P1.
Bugs in Fedora's Atomic builds should be high-priority blockers with quick fixes, especially when they're as serious as not being able to update and/or boot a new version. (Both, even, in this case.)