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. This article provides the steps to upgrade to the newly released Fedora Linux 42 Beta, and how to revert if anything unforeseen happens.
Before attempting an upgrade to the Fedora Linux 42 Beta, apply any pending upgrades.
Updating using terminal
Because the Fedora LInux 42 Beta is not available in GNOME Software, the whole upgrade must be done through a terminal.
First, check if the 42 branch is available, which should be true now:
$ ostree remote refs fedora
You should see the following line in the output:
fedora:fedora/42/x86_64/silverblue
If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:
# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0
To remove the pinned deployment use following command (2 corresponds to the entry position in the output from rpm-ostree status ):
$ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora 42 branch.
$ rpm-ostree rebase fedora:fedora/42/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Silverblue 42 Beta.
How to revert
If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 42 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase to Fedora Silverblue 42 Beta and fall back. So why not do it today?
Known Issues
Incorrect check for static configs with bootupd leads to no /boot/loader/grub.cfg after reboot
We advise users to hold off on testing bootupd on their updated Fedora Atomic Desktops & IoT systems until this bug is resolved.- systemd-remount-fs.service fails to start (root mount options from /etc/fstab are not taken into account anymore with composefs): https://gitlab.com/fedora/ostree/sig/-/issues/72
FAQ
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during rebase of Fedora Linux? For example from Fedora Silverblue 40 to Fedora Silverblue 42?
Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (40->41 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
After doing this you can follow the guide in this article.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Rebasing using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/42/x86_64/kinoite
Steven McKelvey
The ostree argument below seems to require a repo argument. What repo should be used?
ostree remote refs fedora
Scott Trakker
The command is good! Try it again!
Zachary
I disagree the command does not seem to be valid. I am getting the same issue. I suspect a specific repo needs to be enabled. What do you have enabled?
dnf -v repolist –enabled | awk ‘/Repo-name/,/Repo-baseurl/ {print}’ | egrep ‘^(Repo-name|Repo-baseurl)’
Matt
The command is fine but may be confusing depending on how your installation is setup.
You are on Silverblue 41 yeah?
A “repo” in ostree doesn’t refer to your setup dnf repositories, it is more like a git repository. It is a collection of data, synced from remotes. It points to a local directory on your system.
What does ‘/sysroot/ostree/repo’ look like?
The relevant docs are here:
https://ostreedev.github.io/ostree/repo/
Matt
“repo” in ostree and repo in dnf are not the same thing. A repo in ostree is like a repo in git, it’s the local collection of objects that let you modify/revert data. It is synchronized with remotes.
This error should appear if you are running ostree in something other than silverblue, and do not have a valid repo under /sysroot/ostree/repo. It can also happen if you run ostree in a container, like in toolbox.
But the command is correct and should work fine if you’re on a vanilla Silverblue 41 install.
Gimenez Nino
Nope, there is an –repo argument asked:
root@fedora:~# ostree remote refs fedora
Utilisation :
ostree remote refs [OPTION…] NAME
List remote refs
Options de l’aide :
-h, –help Affiche les options de l’aide
Options de l’application :
–repo=PATH Path to OSTree repository (defaults to current directory or /sysroot/ostree/repo)
-r, –revision Show revisions in listing
–cache-dir Use custom cache dir
-v, –verbose Print debug information during command processing
–version Print version information and exit
error: Command requires a –repo argument
Matt
I suspect the problem is right there in the error message.
The default for that argument is either your current directory when you issue the command, or /sysroot/ostree/repo.
Normally, /sysroot/ostree/repo should be a valid ostree repo.
Are you on Silverblue 41? Are you running it in a toolbox container? I get that error if I accidentally run it in toolbox.
Moa
Did I need rebase again when Silverblue 42 comes out?
Scott Trakker
No, you only need to rebase between major versions (Fedora 41, 42, 43, etc).
logo
No, just update your system like normal
Sarangem
No, you just perform a system update from Gnome Software or from terminal using ‘rpm-ostree update’
david
I’m having the same issues with ostree as for repo is not found in fedora 42 Beta
Matt
Are you on Fedora Workstation, or on Silverblue?
I think I’m seeing the pattern: people are trying to run these commands on regular Fedora. You can’t rebase Workstation to Silverblue. This is essentially the process to upgrade Silverblue to Silverblue.
Stijn
Note that packages are getting downgraded when I do this:
container-selinux 4:2.236.0-1.fc41 -> 4:2.235.0-2.fc42
criu 4.0-4.fc41 -> 4.0-3.fc42
criu-libs 4.0-4.fc41 -> 4.0-3.fc42
expat 2.7.0-1.fc41 -> 2.6.4-2.fc42
gdm 1:47.0-9.fc41 -> 1:47.0-4.fc42
git-core 2.49.0-1.fc41 -> 2.48.1-3.fc42
git-core-doc 2.49.0-1.fc41 -> 2.48.1-3.fc42
gnome-remote-desktop 47.3-1.fc41 -> 47.2-1.fc42
gtk-vnc2 1.5.0-2.fc41 -> 1.5.0-1.fc42
gvnc 1.5.0-2.fc41 -> 1.5.0-1.fc42
httpd 2.4.63-1.fc41 -> 2.4.62-6.fc42
httpd-core 2.4.63-1.fc41 -> 2.4.62-6.fc42
httpd-filesystem 2.4.63-1.fc41 -> 2.4.62-6.fc42
httpd-tools 2.4.63-1.fc41 -> 2.4.62-6.fc42
mbedtls 2.28.9-1.fc41 -> 2.28.8-1.fc41
mod_lua 2.4.63-1.fc41 -> 2.4.62-6.fc42
orca 47.3-1.fc41 -> 47.2-2.fc42
python3-boto3 1.37.14-1.fc41 -> 1.37.12-1.fc42
python3-botocore 1.37.14-1.fc41 -> 1.37.12-1.fc42
rpm 4.20.1-1.fc41 -> 4.20.0-8.fc42
rpm-libs 4.20.1-1.fc41 -> 4.20.0-8.fc42
rpm-ostree 2025.5-2.fc41 -> 2025.5-1.fc42
rpm-ostree-libs 2025.5-2.fc41 -> 2025.5-1.fc42
rpm-plugin-audit 4.20.1-1.fc41 -> 4.20.0-8.fc42
rpm-plugin-selinux 4.20.1-1.fc41 -> 4.20.0-8.fc42
wireshark-cli 1:4.4.4-1.fc41 -> 1:4.4.3-1.fc42
Matt
Something I think this article is missing:
Normally when you upgrade to a Fedora beta, you get the “testing” repo enabled automatically, and that’s basically part of being on the beta. The base release repo can move pretty slowly while in beta.
This rebase, is like running the beta, without the testing repo on, and some packages can be behind.
The part of the article that points to:
fedora:fedora/42/x86_64/silverblue
Most users probably actually want:
fedora:fedora/42/x86_64/testing/silverblue
You then rebase again to:
fedora:fedora/42/x86_64/silverblue
When you want to do the equivalent of turning off the testing updates.
Billi
I can not wait to reboot into the final version. I feel like a little kid on the verge of a birthday present. Silverblue 41 is already pretty damn good, but with all the new stuff coming, 42 is going to be one of the best releases ever.
Thanks guys.
Will
Ok, This sounds great!!! However, how will this effect my KDE Plasma desktop?
Will I have to re-customise (please say no and mean it).
AsciiWolf
Why not just enabling pre-release upgrades in Software instead? The following gsetting value works fine on regular Fedora Workstation and should also work fine on Silverblue:
gsettings set org.gnome.software show-upgrade-prerelease true