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.
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.
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:
fedora:fedora/35/x86_64/silverblue
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?
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.
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.
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
XXX?
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:
https://discussion.fedoraproject.org/t/simplifying-updates-for-rpm-fusion-packages-and-other-packages-shipping-their-own-rpm-repos/30364
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.
rugk
So correctly using two hypens (it is incorrectly converted here), I still get an error:
error: usage error: Too many arguments
rugk
Ah, it was indeed a copy error. The
at
was a wrong char.
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
Silverblues
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
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.
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
(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):
runtime/org.fedoraproject.Platform/x86_64/f34
Nothing unused to uninstall