How to rebase to Fedora Silverblue 34 Beta

News & Announcements Community Blog
1

Originally published at: How to rebase to Fedora Silverblue 34 Beta – Fedora Community Blog

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 to F34 Beta on your Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert back if anything unforeseen happens.

Prior to the update to Fedora 34 Beta, apply any pending upgrades.

Updating using terminal

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

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

$ ostree remote refs fedora

You should see the following line in the output:

fedora:fedora/34/x86_64/silverblue

Next, rebase your system to the Fedora 34 branch.

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

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

How to revert

If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 34 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu, 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 34 Beta and back. So why not do it today?

3 Likes
2

I would love to update, but I cannot get it working:

rpm-ostree rebase fedora:fedora/34/x86_64/silverblue
2 metadata, 0 content objects fetched; 788 B transferred in 2 seconds; 0 bytes content written
Checking out tree da03457... done
Enabled rpm-md repositories: updates fedora-cisco-openh264 rpmfusion-nonfree-updates rpmfusion-free-updates fedora rpmfusion-nonfree rpmfusion-free updates-archive
Updating metadata for 'updates'... done
rpm-md repo 'updates'; generated: 2018-02-20T19:18:14Z
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2021-02-23T00:49:00Z
rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2021-02-11T12:32:01Z
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2021-02-11T12:29:15Z
rpm-md repo 'fedora' (cached); generated: 2021-03-21T10:21:45Z
rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2021-03-22T05:12:42Z
rpm-md repo 'rpmfusion-free' (cached); generated: 2021-03-22T04:57:16Z
Updating metadata for 'updates-archive'... done
rpm-md repo 'updates-archive'; generated: 2020-12-17T22:13:22Z
Importing rpm-md... done
Resolving dependencies... done
error: Could not depsolve transaction; 2 problems detected:
 Problem 1: package libvirt-daemon-driver-qemu-7.0.0-4.fc34.x86_64 requires systemd-container, but none of the providers can be installed
  - package systemd-container-248~rc2-8.fc34.i686 requires libcurl.so.4, but none of the providers can be installed
  - package systemd-container-248~rc2-8.fc34.x86_64 requires systemd(x86-64) = 248~rc2-8.fc34, but none of the providers can be installed
  - libcurl-7.75.0-1.fc34.i686 has inferior architecture
  - libcurl-minimal-7.75.0-1.fc34.i686 has inferior architecture
  - cannot install both systemd-248~rc2-8.fc34.x86_64 and systemd-248~rc4-2.fc34.x86_64
  - cannot install both libcurl-7.75.0-1.fc34.x86_64 and libcurl-7.75.0-2.fc34.x86_64
  - package libcurl-minimal-7.75.0-1.fc34.x86_64 conflicts with libcurl(x86-64) provided by libcurl-7.75.0-2.fc34.x86_64
  - package libvirt-7.0.0-4.fc34.x86_64 requires libvirt-daemon-driver-qemu = 7.0.0-4.fc34, but none of the providers can be installed
  - conflicting requests
 Problem 2: package dnf-4.6.0-1.fc34.noarch requires python3-dnf = 4.6.0-1.fc34, but none of the providers can be installed
  - package python3-dnf-4.6.0-1.fc34.noarch requires python3-libdnf, but none of the providers can be installed
  - package python3-dnf-4.6.0-1.fc34.noarch requires python3-libdnf >= 0.57.0, but none of the providers can be installed
  - package supermin-5.2.1-1.fc34.x86_64 requires dnf, but none of the providers can be installed
  - package python3-libdnf-0.58.0-1.fc34.x86_64 requires libdnf(x86-64) = 0.58.0-1.fc34, but none of the providers can be installed
  - package libguestfs-1:1.44.0-5.fc34.x86_64 requires supermin >= 5.1.18, but none of the providers can be installed
  - cannot install both libdnf-0.58.0-1.fc34.x86_64 and libdnf-0.60.0-1.fc34.x86_64
  - package libguestfs-tools-1:1.44.0-5.fc34.noarch requires libguestfs = 1:1.44.0-5.fc34, but none of the providers can be installed
  - conflicting requests

Not sure what to do though. Removing libvirt doesn’t really seem to help:

rpm-ostree rebase fedora:fedora/34/x86_64/silverblue --uninstall=libvirt
2 metadata, 0 content objects fetched; 788 B transferred in 2 seconds; 0 bytes content written
Checking out tree da03457... done
Enabled rpm-md repositories: updates fedora-cisco-openh264 rpmfusion-nonfree-updates rpmfusion-free-updates fedora rpmfusion-nonfree rpmfusion-free updates-archive
rpm-md repo 'updates' (cached); generated: 2018-02-20T19:18:14Z
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2021-02-23T00:49:00Z
rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2021-02-11T12:32:01Z
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2021-02-11T12:29:15Z
rpm-md repo 'fedora' (cached); generated: 2021-03-21T10:21:45Z
rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2021-03-22T05:12:42Z
rpm-md repo 'rpmfusion-free' (cached); generated: 2021-03-22T04:57:16Z
rpm-md repo 'updates-archive' (cached); generated: 2020-12-17T22:13:22Z
Importing rpm-md... done
Resolving dependencies... done
error: Could not depsolve transaction; 1 problem detected:
 Problem: package systemd-container-248~rc2-8.fc34.i686 requires libcurl.so.4, but none of the providers can be installed
  - package libvirt-daemon-driver-qemu-7.0.0-4.fc34.x86_64 requires systemd-container, but none of the providers can be installed
  - package systemd-container-248~rc2-8.fc34.x86_64 requires systemd(x86-64) = 248~rc2-8.fc34, but none of the providers can be installed
  - libcurl-7.75.0-1.fc34.i686 has inferior architecture
  - libcurl-minimal-7.75.0-1.fc34.i686 has inferior architecture
  - package libguestfs-1:1.44.0-5.fc34.x86_64 requires libvirt-daemon-driver-qemu, but none of the providers can be installed
  - cannot install both systemd-248~rc2-8.fc34.x86_64 and systemd-248~rc4-2.fc34.x86_64
  - cannot install both libcurl-7.75.0-1.fc34.x86_64 and libcurl-7.75.0-2.fc34.x86_64
  - package libcurl-minimal-7.75.0-1.fc34.x86_64 conflicts with libcurl(x86-64) provided by libcurl-7.75.0-2.fc34.x86_64
  - package libguestfs-tools-1:1.44.0-5.fc34.noarch requires libguestfs = 1:1.44.0-5.fc34, but none of the providers can be installed
  - conflicting requests
3

Wouldn’t it make more sense to rebase to fedora:fedora/34/x86_64/testing/silverblue since the testing repo is what workstation betas use by default?

4

That command won’t work for users who have rpmfusion. There will be conflicts requiring users to uninstall rpm-fusion (and all packages installed from it) before the rebase and then reinstalling them again

This command will work in one go:

rpm-ostree rebase fedora:fedora/34/x86_64/silverblue --uninstall rpmfusion-free-release-33-1.noarch --install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-branched.noarch.rpm --uninstall rpmfusion-nonfree-release-33-1.noarch --install https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-branched.noarch.rpm

1 Like
5

I’ve never had to remove the packages installed from RPM Fusion, just the packages that configure the repository.

6

I have libvirt layered on my installation of Silverblue and didn’t had any issue on rebase. I would try enabling updates-testing to see if this is solved.

7

I never used it and the beta this way works fine. Is there any benefit this change could bring?

8

I don’t have rpm-fusion on my system, so didn’t know there could be any issue with it. Thanks for sharing the command.

9

Thank you for the idea. I reinstalled the system to rawhide two days ago - something I wanted to do anyways. This fixed a lot of issues for me and my system is now running under btrfs. :slight_smile: