How to rebase to Fedora Linux 35 on Silverblue

Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to update or rebase to Fedora Linux 35 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.

Prior to actually doing the rebase to Fedora Linux 35, you should apply any pending updates. Enter the following in the terminal:

$ rpm-ostree update

or install updates through GNOME Software and reboot.

Rebasing using GNOME Software

GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.

Fedora Linux 35 is available

First thing you need to do is to download the new image, so click on the Download button. This will take some time. After it’s done you will see that the update is ready to install.

Fedora Linux 35 is ready for installation

Click on the Install button. This step will take only a few moments and the computer will be restarted at the end. After restart you will end up in new and shiny release of Fedora Linux 35. Easy, isn’t it?

Rebasing using terminal

If you prefer to do everything in a terminal, then this part of the guide is for you.

Rebasing to Fedora Linux 35 using terminal is easy. First, check if the 35 branch is available:

$ ostree remote refs fedora

You should see the following in the output:


If you want to pin the current deployment (this deployment will stay as option in GRUB until you remove it), you can do it by running:

$ sudo ostree admin pin 0

To remove the pinned deployment use following command:

$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora Linux 35 branch.

$ rpm-ostree rebase fedora:fedora/35/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Linux 35.

How to roll back

If anything bad happens—for instance, if you can’t boot to Fedora Linus 35 at all—it’s easy to go back. Pick the previous entry in the GRUB menu at boot (if you don’t see it, try to press ESC during boot), and your system will start in its previous state before switching to Fedora Linux 35. To make this change permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 35 and roll back. So why not do it today?

New in Fedora Using Software


  1. Heliosstyx, Europe

    Thank you for article. Is it possible that you write a article how to to get the reverse way: Fedora 35 –> Fedora Silverblue?

    • John Doe

      This article is only showing how to rename from fedora silverblue 34 to fedora silverblue 35. It is not possible to convert a fedora installation to a silverblue installation (as far as I know). You’d need to install silverblue fresh from the iso.

      • Stephen

        The article shows you how to take a Fedora Linux 34 Silverblue installation and rebase it to Fedora Linux 35 Silverblue, while maintaining your current installed SW. If you were to use these instructions on a workstation they would fail due to rpm-ostree not being installed on Fedora Linux 34 Workstation. You are correct that Silverblue would need to be installed fresh in order to replace Workstation.

      • Heliosstyx, Europe

        Thank you for your clear answer.

  2. Robert

    I can’t wait to be able to use Silverblue because of the peace of mind it brings knowing nothing can “taint” the core Fedora image. Only thing holding me back is:
    1) I tried for an hour to setup VSCode and couldn’t get extensions working
    2) Most software projects I use like Laravel do not work with podman and installing docker via an rpm package feels dirty

    • Henkspermatank

      Laravel works fine here with podman. Both with and without rootless.

    • Jens Petersen

      You could try running vscode from Toolbx (toolbox).

    • hammerhead corvette

      Robert: You can install your docker images using Podman. As a matter of fact you can replace the docker commands 1 to 1 with podman commands. Plenty of articles here for that. I did manage to get VSCode in a toolbox container along with a Debian and Arch install. Also some docker iamges or Quay images.

  3. John Williams

    Error: Could not depsolve transaction; 1 problem detected:
    Problem: conflicting requests
    – nothing provides system-release(34) needed by rpmfusion-free-release-34-1.noarch


  4. John Williams

    Silly me. Bad me. Overcome with unreasonable rage in the moment at the seemingly nonsense and totally uninformative error message. Then, Google to the rescue! Problem caused by RPM Fusion, Solution:

    sudo rpm-ostree rebase fedora:fedora/35/x86_64/silverblue –uninstall rpmfusion-free-release-34-1.noarch

    • Calvin Walton

      If you have packages installed from rpmfusion, you can actually preserve them through the rebase. Use the combination of uninstall and install options on rpm-ostree, like so:

      rpm-ostree rebase fedora:fedora/35/x86_64/silverblue –uninstall rpmfusion-free-release-34-1.noarch –install (url of rpmfusion-free-release-35.noarch.rpm)

      • kuvuwosarugi

        There is an even better option, just install the versionless releases:

        sudo rpm-ostree update \
        –uninstall rpmfusion-free-release-34-1.noarch \
        –uninstall rpmfusion-nonfree-release-34-1.noarch \
        –install rpmfusion-free-release \
        –install rpmfusion-nonfree-release

        (Or just replace it with “rpm-ostree rebase” to avoid an additional step)

        It seems this way the rebase will just work without any manual adjustments and you probably can even use the graphical update through GNOME Software.

        • Theo

          Thanks a lot, this has been really helpful.

          So much so, that I think this should be covered in the regular “How to rebase” articles.

      • So correctly using two hypens (it is incorrectly converted here), I still get an error:

        $ rpm-ostree rebase fedora:fedora/35/x86_64/silverblue –-uninstall rpmfusion-free-release-34-1.noarch –-install
        error: usage error: Too many arguments
      • Ah, it was indeed a copy error. The




        was a wrong char.

  5. CRCinAU

    How is this different than going:

    $ dnf system-upgrade download –releasever=35
    $ dnf system-upgrade reboot

    and rolling back with:
    $ dnf system-upgrade download –releasever=34
    $ dnf system-upgrade reboot


    • microvardoc

      Silverblue doesn’t have dnf.

      • CRCinAU

        Sounds like just making life more difficult :\

        • ArtūrasB.

          How is that more difficult? Silverblue is a variant of Fedora Linux and it requires different tools (rpm-ostree) to handle its specific approach to deliver immutable OS. Regular Fedora WS is still there if dnf is your preferred to manage SW and system updates. Both variants of Fedora WS has different purposes, target audiences and tools to achieve those different goals.

    • Theo



      does not download and change packages indvidually directly in your root filesystem.

      In case you run a dnf command in Fedora, this adds and changes files in your only copy of Fedora. rpm-ostree in contrast create a “new” root filesystem for you and does prepare it for your next boot. This way you can install siverblue without doing any modifications on your current system and you can boot right into a fully installed and setup fedora on your next boot. The long process of installing/upgrading the existing rpms after the

      system-upgrade reboot

      just never happens so the upgrade (or rebase) is done really quickly and if something goes wrong you can just jump back to the prior version without backup.

      Note: I did simplify the process behind


      – suffice it to say that there are plenty of optimisations in the background similar to using git for source code versioning.

      I do hope this was helpful for you.

  6. Olivier Raggi

    Thanks for this article!

    After the rebase and an upgrade of flatpak applications and runtimes, I thought it might be necessary to do some cleaning, with

    flatpak uninstall --unused

    (to remove unused refs on the system)… and I get the following message and I don’t know what to do, any ideas?

    These runtimes in installation ‘system’ are pinned and won’t be remove; see flatpak-pin(1):
    Nothing unused to uninstall

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