Due to an unfortunate combination of issues, the Fedora Silverblue, Kinoite and IoT variants that are running a version from 36.20220810.0 and later are no longer able to update to the latest version.
You can use these two commands to work around the bugs:
$ sudo find /boot/efi -exec touch '{}' ';'
$ sudo touch /etc/kernel/cmdline
Afterwards, you can update your system as usual with GNOME Software (on Silverblue) or via:
$ sudo rpm-ostree upgrade
These two issues are rooted in GRUB2 bugs that have only landed in Fedora and do not affect CentOS Stream 9 or RHEL. This also does not affect Fedora CoreOS for different reasons.
You can get more details about those issues in the tracker for Fedora Silverblue: https://github.com/fedora-silverblue/issue-tracker/issues/322
Jonas Gierer
You can also run
after
, feels a bit safer imo. But if your solution works without the risk of breaking anything, that’s fine too.
Timothée Ravier
We’ve spent time to write this article, to test those commands and to make sure that they are the strict necessary and safest workaround. Other workarounds might be incomplete or only partially fixing the issue.
heliosstyx
It’s only valid for UEFI capable machines. On my BIOS-legacy only machines (older HP-notebooks) the updates are working very well. No issues under Silverblue.
Piotr
I’m on Silverblue 37 pre-release, beginning from 37.20220822.n.0 when I installed it from nightly composes, today on 37.20220909.n.0. Should I run these commands (to prevent this issue or for any reason)? Am I safe?
Timothée Ravier
If you can update your system as usual then no need to run those commands and you can ignore this issue.
Gt
Because I’ve been having error messages while updating, I thought this applied to me. Upon executing the commands for version 7 of the kernel, my unit failed to boot. Luckily, I was able to boot to a previous version of the os (version 6). I removed the version 7 kernel, tried to update to it again and got the same failure. “Failed to start initrd-switch-root.service” The unit then dumped me back to Emergency mode. How do I fix this?
GT
After further investigation, I noticed in my GRUB menu screen that the latest kernel was missing several parameters. After editing the menu (using grubby command “sudo grubby –args” and putting the root and rootvol definitions, I was able to boot.
J3RN
I noticed that I was unable to update around a couple of weeks ago and assumed it was just me. Glad I saw this article! I was about to do a full re-install.
collura
modified your ‘/boot/efi’ command to ‘/boot/grub2’
for a silverblue bios system and then updates finally worked:
$ sudo find /boot/grub2 -exec touch ‘{}’ ‘;’
$ sudo touch /etc/kernel/cmdline
$ rpm-ostree update
Thank you very much for the effort.
Was stuck on that nasty bug for a while lol.
Karzika siham
😍👌😍
Mihai
rpm-ostree cancel && rpm-ostree update && sudo grub2-mkconfig
run it once in terminal and you’re set
James
I have the same problem on a raspberry pi running coreos, and on silverblue VMs that have been installed into kvm virt-manager using bios rather than efi.
I haven’t been able to fix the coreos machine yet, and will probably reinstall, but more recently, on the silverblue bios vm’s, I have run
and
after the command
and the updates have installed ok, and recently the updates have installed without the needs for the further commands.
The problem you have written about also affected the installation of programs. After updating to the most recent updates, using the method I mentioned above, I have succesfully installed a gnome program and it has been installed and added to the layered package list in the output from the command
.
Tiago
Ii made a fresh install of silverblue 36 and updated to latest version i still need to run thoso commands ?
nikita
Check if you can overlay any packages, and if $rpm-ostree status displays any errors
Hannes
I think this workaround broke my install.
Timothée Ravier
It’s unlikely that those specific commands broke your system so please file an issue in the tracker for Fedora Silverblue: https://github.com/fedora-silverblue/issue-tracker/issues
GT
I had a similar situation. The article seemed to apply to my install since I was getting an error but I really don’t now if I’m running SilverBlue or not. How does one check for that? It would be a real help to us “newbies” if instructions included HOW to check for specific version since a “uname -a” didn’t match what was explained in the article.
I fixed my issue by using grubby to re-add the arguments that seemed to be deleted when running those commands but I still get messages occasionally about software not being installed.
Jens Petersen
If you are not sure – then you probably aren’t running SB.
If you are running Silverblue your system should have fedora-release-identity-silverblue and rpm-ostree packages installed say, but you can also
.
GT
Thank you for the command!