How to rebase to Fedora Silverblue 38 Beta

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. Let’s see the steps to upgrade to the newly released Fedora 38 Beta, and how to revert if anything unforeseen happens.

Before attempting an upgrade to the Fedora 38 Beta, apply any pending upgrades.

Updating using terminal

Because the Fedora 38 Beta is not available in GNOME Software, the whole upgrade must be done through a terminal.

First, check if the 38 branch is available, which should be true now:

$ ostree remote refs fedora

You should see the following line in the output:

fedora:fedora/38/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:

# 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 rpm-ostree status):

$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora 38 branch.

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

Finally, the last thing to do is restart your computer and boot to Fedora Silverblue 38 Beta.

How to revert

If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 38 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 38 Beta and back. So why not do it today?

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? For example from Fedora 36 Silverblue to Fedora 38 Silverblue?

Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (37->38 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 blog post.

$ rpm-ostree status State: idle Deployments: ● fedora:fedora/38/x86_64/silverblue Version: 38.20230331.n.0 (2023-03-31T15:53:16Z) Commit: 303d395deb1ed814549d7c930215080bb454a68b8eba5b531bf5f91d93b62bdf GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464 fedora:fedora/37/x86_64/silverblue Version: 37.1.7 (2022-11-05T06:01:00Z) Commit: bfe9de223c9a4ba4a793d3e01f6b09024c919685ee73c896af767958725cac79 GPGSignature: Valid signature by ACB5EE4E831C74BB7C168D27F55AD3FB5323552A

Comments

sampsonf says:

Please read the below thread before rebase from ostree variants 37 to 38 - it is about sshd might failed to start after the rebase.

Fedora CoreOS next stream rebasing to Fedora Linux 38 Project Discussion

Update: see Fedora CoreOS next stream rebasing to Fedora Linux 38 - #16 by bgilbert Cross-posting from this coreos-status email. Fedora Linux 38 Beta will be released next week [1]. Starting March 14, newly provisioned Fedora CoreOS nodes on the next stream will be based on Fedora Linux 38. On March 16, existing Fedora CoreOS nodes on the next stream will begin to update. For more information about Fedora 38, see the Fedora Project’s list of official Changes [2] and the Fedora CoreOS analysis…
dustymabe says:

Thank you Sampson for posting this. Indeed, we have a fix in flight, but if you require connecting into your Silverblue machine via ssh then you may consider waiting to switch until we have the fix rolled out.

It is worth noting that once the fix rolls out affected machines will be back to a good state.
piotr says:

I pin and unpin deployments with silverpin. Yeah, I’ve been told it looks complex to install but pre-assembled binaries are also available and I find it extremely handy once installed on the system.

This is the first direct rebase test from SB37 to latest SB38 without the sshd error:

avongauss says:

Assembly is definitely an interesting choice for such a utility.