Atomic System Updates on Fedora Silverblue: Using rpm-ostree for Safe Upgrades and Rollbacks

Problem: Wanting a reliable way to update a Fedora workstation without risking an unbootable system

Many desktop users hesitate to apply system updates because a failed upgrade can leave the machine unable to boot, requiring a rescue image or reinstall. Fedora Silverblue addresses this by treating the operating system as an immutable, versioned tree, similar to a Git repository. Each upgrade creates a new deployment that shares unchanged files with the previous one via hard links, allowing instant rollback if something goes wrong.

Thesis: The rpm-ostree tool provides atomic upgrades, easy rollbacks, and a clean separation between the base image and user‑installed software, making system maintenance predictable and safe.

How OSTree enables atomic upgrades

OSTree stores the root filesystem as a series of commits. When you run rpm-ostree upgrade, the tool downloads the newest commit, applies it atomically, and marks it as the default boot entry. A reboot switches to the new deployment; the old deployment remains unchanged on disk, ready to be selected again.

Layered packages keep the base pristine

Because the base image is read‑only, traditional dnf cannot modify system packages directly. Instead, you add software with rpm-ostree install package. These layered packages are stored in an overlay that persists across rebases and upgrades, while the underlying OSTree commit stays untouched.

Worked example: Upgrading to the next Fedora release and verifying the result

1. Check the current deployment (run in a terminal with standard user privileges):

   rpm-ostree status

   Look for the line State: deployed and note the Commit identifier.
2. Apply the upgrade (requires sudo):

   sudo rpm-ostree upgrade

   The command downloads the new commit, stages it, and reports a success message. No reboot occurs yet.
3. Reboot to activate the new deployment:

   sudo systemctl reboot

   After the boot loader menu appears, the default entry will be the newly deployed commit.
4. Verify the upgrade (standard user):

   grep VERSION_ID /etc/os-release

   Expected output shows the newer Fedora version, e.g., VERSION_ID="40". You can also run rpm-ostree status again to see the new commit marked as Deployed and the previous one as Available.
5. Optional: Test a rollback (if the new deployment behaves unexpectedly):
   • Reboot and hold Shift (or Esc) to access the GRUB menu.
   • Select “Fedora Silverblue” → “Previous boot entry” (or the entry with the older timestamp).
   • After boot, run rpm-ostree status to confirm you are back on the earlier commit.

Trade‑off and limitation: Read‑only base image and kernel modules

The immutable base protects the system but means that any software that expects to write into /usr (such as certain proprietary drivers or kernel modules that install files directly) cannot be installed via dnf. You must either:

• Package the driver as a layered RPM with rpm-ostree install, ensuring it only places files in /var or /usr/local, or
• Use an Akmods‑style build that compiles the module against the running kernel and stores the result in the overlay.

This adds a step compared to traditional Fedora Workstation, but it keeps the base image clean and guarantees that rollbacks will not leave stray kernel modules behind.

Actionable closing: Checklist for safe system maintenance on Silverblue

• Run rpm-ostree status before any upgrade to know your starting commit.
• Use sudo rpm-ostree upgrade to stage the new deployment.
• Reboot and verify the new version with grep VERSION_ID /etc/os-release.
• If needed, roll back via GRUB or sudo rpm-ostree rollback and confirm the earlier commit.
• Add only essential software through rpm-ostree install; prefer Flatpak or containerized apps for GUI programs.
• Periodically clean old deployments with sudo rpm-ostree cleanup --reboot to free space.