Managing System State with rpm-ostree in Fedora Silverblue

Solving the Partial Upgrade Problem

Traditional Linux distributions use a mutable root filesystem where packages are installed and updated individually. If a power failure occurs or a dependency conflict arises during a dnf update, the system can enter a "broken" state where some binaries are updated but others are not, often requiring manual rescue via a live USB.

Fedora Silverblue solves this using an atomic update model. Instead of modifying the running system, rpm-ostree creates a new, read-only system image (a deployment) in the background. The update only takes effect when you reboot into this new image. If the new version fails to boot or crashes, you can instantly revert to the previous known-working state from the boot menu.

How the Atomic Mechanism Works

The root filesystem (/) is immutable, meaning it cannot be written to during normal operation. This ensures that the system remains exactly as the developers intended. To add software or update the OS, rpm-ostree performs a rebase: it takes the base image commit and layers your requested changes on top to create a new deployment.

Practical Example: Layering and Updating

To add a system-level tool (like vim or wget) that cannot be provided by a Flatpak, you must "layer" it into the image. This requires root permissions and a reboot to activate.

# Run on a Fedora Silverblue terminal
# Install a package into the next deployment
sudo rpm-ostree install vim

# Stage the latest system updates
sudo rpm-ostree upgrade

# Verify the pending changes
rpm-ostree status

Expected Result: The rpm-ostree status command will show two entries. One is marked as booted (your current state), and the other is marked as pending. The pending deployment contains both the OS updates and the vim package.

To activate these changes, reboot the system. Upon restart, the pending deployment becomes the booted one.

Comparison: Mutable vs. Atomic Workflows

Action	Fedora Workstation (dnf)	Fedora Silverblue (rpm-ostree)
Install App	Immediate write to /usr	Staged in new image; requires reboot
System Update	Packages replaced one-by-one	Whole image replaced atomically
Failure Recovery	Manual package rollback/reinstall	Select previous deployment at boot
Root Access	Read-Write	Read-Only (except /etc and /var)

Limitations and Common Mistakes

The immutable design requires a shift in how you manage software. Attempting to use traditional dnf commands will fail because the filesystem is read-only.

The "Layering Trap"

A common mistake is using rpm-ostree install for every application. Because every layered package triggers the creation of a new system commit, layering too many packages leads to:

• Slower Updates: The system must re-calculate the image commit every time you update.
• Increased Disk Usage: Each deployment consumes significant space.
• Dependency Bloat: You lose the benefit of the clean, base image.

The Solution: Use Flatpaks for desktop applications. Flatpaks run in isolated containers and do not require system re-imaging or reboots to install.

Configuration Overrides

Since /usr is read-only, you cannot modify system binaries. However, /etc remains writable. If a system update overwrites a configuration file you modified, rpm-ostree manages these as overrides, preserving your changes in /etc while updating the underlying base image.

Verification and Rollback

To verify your current system state and see which commit is active, run:

rpm-ostree status

If you encounter a kernel panic or a driver issue after an update, you can roll back the state. Since the previous deployment is preserved on disk, you do not need to "uninstall" the update. Simply restart the machine and select the previous version from the GRUB boot menu.

To make a rollback permanent (so the system doesn't try to boot the broken version again), run the following command from the reverted session:

# Permanently remove the failed deployment
sudo rpm-ostree rollback

Risk: Running rollback removes the most recent deployment. Ensure you have identified the cause of the failure before purging the image to allow for forensic debugging if necessary.