Updates, Upgrades & Rollbacks
Installing updates on Fedora Atomic Desktops is easy and fast. It also has a special rollback feature, in case anything goes wrong. Additionally, you can choose to have multiple versions of your operating system installed at all times, and you can choose which one to boot into whenever you start up your system.
Updating Fedora Atomic Desktops
OS updates are fully integrated into the desktop; you will be automatically notified when an update is available. On Silverblue and Kinoite, updates are automatically downloaded. This behavior can be changed in the settings. On Sway Atomic, Budgie Atomic and COSMIC Atomic, updates need to be manually applied.
Once an update is ready, it is just a matter of rebooting to start using the new version. There is no waiting for the update to be installed during this reboot.
If you’d prefer, it is also possible to update using the command line. To do this, run:
$ rpm-ostree upgrade
This will check for new updates and download and install them if they are available. Alternatively, to check for available updates without downloading them, run:
$ rpm-ostree upgrade --check
Upgrading between major versions
Upgrading between major versions (such as from Fedora 42 to Fedora 43) can be completed using GNOME Software on Silverblue, Plasma Discover on Kinoite and Budgie Atomic.
Alternatively, Fedora Atomic Desktops can be upgraded between major versions using the rpm-ostree command.
|
Skipping major releases is currently untested and is thus not supported. You should update only one major release at a time, i.e. from Fedora 42 to 43, etc. |
First, make sure that you are running the latest update for the current version:
$ rpm-ostree upgrade
Reboot your system if needed. Then, verify that the branch for the next major version is available. You can print all available branches for the Fedora Atomic Desktop variant that you are currently using with the following commands:
$ source /etc/os-release
$ ostree remote refs ${ID} | grep $(arch) | grep ${VARIANT_ID}
After you’ve verified the name of your branch, you are ready to proceed. For example, to upgrade to Fedora Silverblue 43, the command is:
$ rpm-ostree rebase fedora:fedora/43/x86_64/silverblue
The old variant name for Sway Atomic is sericea and for Budgie Atomic it is onyx.
The process is very similar to a system update: the new OS is downloaded and installed in the background, and you just boot into it when it is ready.
| If you are using the RPM Fusion repositories and are having issues during major updates, see the Enabling RPM Fusion repos section. |
Rebasing to another Atomic Desktop
Additionally, you can choose to rebase to a different variant of Fedora Atomic. For example, if you are currently using Silverblue, you can switch to Kinoite. Fedora Kinoite is similar to Fedora Silverblue, except for the fact that it uses the KDE Plasma desktop instead of the GNOME desktop.
What this means is, you can rebase to Fedora Kinoite to try it out, without ever touching your current system.
Because the two system images are isolated from eachother, the two desktop environments will never be installed at the same time.
All your flatpak apps and files in the /home directory will remain persistent between rebases.
Same applies for testing out the development version of Fedora Atomic Desktops, which is Rawhide.
|
By default, OSTree only keeps the two most recent deployments. If you decide to rebase, make sure to pin your current deployment, so you don’t accidentally lose it. |
Rolling back
Fedora Atomic Desktops keep a record of the previous OS version, which can be switched to instead of the latest version. While this shouldn’t usually be necessary, it can be helpful if there is a problem with an update or an upgrade (rollbacks work the same way for both), as well as for development purposes.
There are two ways to roll back to the previous version:
-
Temporary rollbacks: to temporarily roll back to a previous version, simply reboot and select the previous version from the boot menu (often known as the GRUB menu).
-
Permanent rollbacks: to permanently switch back to the previous deployment, use the
rpm-ostree rollbackcommand.
After rolling back, you will technically be on an old OS version, and may be prompted to update. Updating will undo the rollback, so should be avoided if you want the rollback to stay in effect.
rpm-ostree only keeps one rollback version available by default.
If you want to rollback to another version than the one currently available on your system, you can do so with the following commands:
-
Pull the ostree commit log from the remote repository:
$ source /etc/os-release $ sudo ostree pull --commit-metadata-only --depth=10 ${ID} ${ID}/43/$(arch)/${VARIANT_ID} -
Display the log:
$ ostree log ${ID}:${ID}/43/$(arch)/${VARIANT_ID} -
Deploy a specific commit:
$ rpm-ostree deploy 43.20251031.0
| This will deploy the exact version as requested and will not include overlayed packages and other changes. |
Pinning and cleaning deployments
By default, the rpm-ostree upgrade or pm-ostree rebase commands will keep at most two bootable deployments, though the underlying technology supports more.
In some cases, such as a major version upgrade or rebase, you may want to keep your current deployment as a guaranteed fallback.
OSTree allows you to pin deployments.
Pinning ensures that your deployment of choice is kept and not discarded.
To pin an deployment, you need to know its index number.
To print the index numbers of the deployments, run the following command:
$ rpm-ostree status --verbose
If you want to pin your currently booted deployment, run the following command:
$ sudo ostree admin pin 0
If you pin many deployments, the /boot partition may run out of space and as a consequence the system may not be able to be upgraded.
In such cases, it is necessary to unpin and clean up some deployments.
To unpin a deployment, run the following command:
$ sudo ostree admin pin INDEX --unpin
You can run the above command multiple times to free up more space. Then clean up unpinned deployments:
$ rpm-ostree cleanup --rollback
The rpm-ostree cleanup --rollback command will not remove pinned deployments.
|
Want to help? Learn how to contribute to Fedora Docs ›