Manual action required to update Fedora Silverblue, Kinoite and IoT (version 36)

Pocket watch photo by Ivan Diaz on Unsplash, Cracked glass photo by Thomas Dumortier on Unsplash

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

Fedora Project community

19 Comments

  1. Jonas Gierer

    You can also run

    sudo grub2-mkconfig

    after

    rpm-ostree upgrade

    , feels a bit safer imo. But if your solution works without the risk of breaking anything, that’s fine too.

    • 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.

  2. 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.

  3. 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?

  4. 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.

  5. 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.

  6. 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.

  7. Karzika siham

    😍👌😍

  8. Mihai

    rpm-ostree cancel && rpm-ostree update && sudo grub2-mkconfig

    run it once in terminal and you’re set

  9. 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

    sudo ostree admin finalize-staged

    and

    grub2-mkconfig

    after the command

    rpm-ostree update

    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

    rpm-ostree status

    .

  10. 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

  11. Hannes

    I think this workaround broke my install.

  12. 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

      cat /etc/os-release

      .

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions