How to rebase to Fedora 31 on Silverblue

Silverblue is an operating system for your desktop built on Fedora. 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 Fedora 31 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 the the update to Fedora 31 it is better to do any pending upgrades.

Updating using GNOME Software

Unfortunately the update can’t be done in GNOME Software right now, because of a bug in GNOME Software itself. For additional information please look at upstream issue.

Updating using terminal

If you do not like GNOME Software or like to do everything in terminal, than this next guide is for you.

Updating to Fedora 31 using terminal is easy. First, check if the 31 branch is available, which should be true now:

$ ostree remote refs fedora

You should see the following in the output:

fedora:fedora/31/x86_64/silverblue

Next, rebase your system to the Fedora 31 branch.

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

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

How to revert things back

If anything bad happens — for instance, if you can’t boot to Fedora 31 at all — it’s easy to go back. Just pick the previous entry in GRUB, and your system will start in its previous state before switching to Fedora 31. To make this change permanent, use the following command:

$ rpm-ostree rollback

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

Fedora Project community

18 Comments

  1. Boricua

    Hi, there appears to be something missing in the first command. I am getting this (edited for reason of space and privacy):

    [Boricua@main ~]$ ostree remote refs fedora
    Usage:
    ostree remote refs [OPTION…] NAME
    List remote refs
    Help Options:
    -h, –help Show help options
    Application Options:
    –repo=PATH Path to OSTree repository (defaults to current directory or /sysroot/ostree/repo)
    –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
    [Boricua@main ~]$

    Same thing happens if I use the sudo option.

  2. Lucas

    Wow… Just amazed about the easiness of upgrading to another version with those “immutable OS”…

    What about customizing your environment (gnome-tweak, icons, …) ? This question may seem dummy but I’m quite curious about Silverblue and feedback from other curious like me 🙂

    Who knows, I will switch from my classical Fedora 30 to Silverblue a day !

    • Unfortunately gnome-tweaks must be layered and the GNOME wants to use new application for Extensions and fonts management.

      Otherwise you can customize what you want as long as you don’t need to do any changes in immutable directories.

    • Xon

      You can download tweaks from the gnome software app, that’s what I did.

  3. Hi, could you try

    ostree remote list

    ?

    If you are using the Silverblue for some time, you probably have another remote. I had fedora-workstation instead of fedora, so I switched.

    • Boricua

      Same result:
      $ ostree remote list
      Usage:
      ostree remote list [OPTION…]
      List remote repository names
      Help Options:
      -h, –help Show help options
      Application Options:
      –repo=PATH Path to OSTree repository (defaults to current directory or /sysroot/ostree/repo)
      -u, –show-urls Show remote URLs in list
      -v, –verbose Print debug information during command processing
      –version Print version information and exit
      error: Command requires a –repo argument

      Just in case, I am running a regular Fedora 31 workstation, rpm based. Perhaps I misunderstood this article.

  4. JCjr

    The way that Silverblue is documented, it mentions that all updates need reboots because of the image rebase stuff. How is that any different from Fedora Workstation though? Any time GNOME Software shows updates for “regular” Fedora, it wants to reboot – even for silly little things like a Chromium update for a system that doesn’t even have Chromium installed (this happened recently on a clean network install). I can understand wanting to reboot for a kernel update so that you can use it right away, but not a day goes by where GNOME Software detects an update is available that after pressing the Download button, it’s succeeded by a “Restart and Install” button. Why is GNOME Software so aggressive for reboots when DNF can install practically anything without requiring a reboot?

    • @JCjr: I believe G-s takes a conservative approach because of the number of user reports that come in via help channels ultimately caused by libraries or apps that have been upgraded underneath an active session. I find the easiest approach is just wait until I’m done with a session to worry about updates.

    • AsciiWolf

      These are offline updates and they are not specific only to GNOME Software. Here is more information about them: https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

    • George.M

      I use Fedora 30 Workstation as my daily computer. I’ll upgrade to 31 when some of the little bothersome bugs get ironed out properly. Ever since F15, I’ve always done the updates via terminal:

      sudo dnf upgrade –refresh

      By using the terminal, no reboot is requested.

      Silverblue is fun to play with at the moment but still lacks many apps in the software repository to be productive. LibreOffice would be a great start.

  5. Otavio

    Got this, anyone can help?
    tks

    Could not depsolve transaction; 2 problems detected:
    Problem 1: conflicting requests
    – nothing provides libjpeg-turbo(x86-64) = 2.0.2-1.fc30 needed by libjpeg-turbo-devel-2.0.2-1.fc30.x86_64
    Problem 2: package scl-utils-build-1:2.0.2-8.fc30.x86_64 requires redhat-rpm-config, but none of the providers can be installed
    – package redhat-rpm-config-142-1.fc31.noarch requires python-srpm-macros >= 3-46, but none of the providers can be installed
    – package redhat-rpm-config-140-2.fc31.noarch requires python-srpm-macros >= 3-46, but none of the providers can be installed
    – cannot install both python-srpm-macros-3-42.fc30.noarch and python-srpm-macros-3-49.fc31.noarch
    – conflicting requests

  6. When well 31 workstation be ready for download? I already have 30 workstation and I have had it since it came out!

  7. Andrew Galford

    A bit off topic but close enough. I got inspired by Silverblue to do a read only filesystem for regular Fedora. So I fired up my VM made 3 drives for boot, root and var then made the boot and root read only. As you can imagine the regular workstation with GUI would lock up at the login screen after trying to log in I needed a separate drive for home duh. However thats not the end of the story I decided to go more robust for a minimal install and fixed the home dir/drive that is when started to find that services would not start like systemd hostname, chronyd, and nginx. Any thoughts suggestions or help would be appreciated.

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