Fedora Silverblue rpm-ostree design: layering, trust, and rollback

Problem: a system upgrade should not leave your workstation unbootable with no way back. Useful takeaway: Fedora Silverblue treats the base operating system as an immutable, read-only OSTree deployment. Run desktop applications as Flatpaks, run development toolchains in Toolbox or Distrobox containers, and use rpm-ostree layering only for packages that must exist in the host image. Verify the active deployment with rpm-ostree status before you reboot into an updated tree. OSTree manages the operating system as a series of checksummed, immutable filesystem commits. Each upgrade creates a new deployment alongside the previous one, and the bootloader can start either tree.

Requirements

• Read-only root filesystem for the base OS.
• Atomic upgrades: a new deployment appears next to the current one.
• Bootable rollback to the previous deployment.
• Application isolation from the base image.
• Cryptographic trust anchored in OSTree checksums and GPG-signed metadata from Fedora mirrors.

Smallest suitable design

Start with the Silverblue base deployment. Install GUI applications through Flatpak. Use Toolbox or Distrobox for command-line development work; run DNF inside the container, not on the host. Add packages to the host only when they must be part of the base image, such as hardware drivers, virtualization tools, or system-wide services with no Flatpak equivalent.

Comparison: where to install software

Location	Best for	Update method	Persistence
Base OS deployment	Kernel, system runtime	rpm-ostree upgrade	Immutable deployment
Flatpak	Desktop applications	flatpak update	Sandboxed application
Toolbox / Distrobox	CLI development tools	DNF inside the container	Container image; shared home
rpm-ostree layer	Host drivers, system services	rpm-ostree install plus reboot	Persists across rebases

Example: layering a host package

Run this in a terminal on the Silverblue host. rpm-ostree install requires root privileges and a reboot. Replace <package-name> with the actual package.

# Run on the Silverblue host. Requires root privileges.
rpm-ostree install <package-name>
systemctl reboot

Expected check: after reboot, rpm-ostree status should list the new deployment as active and still show the previous deployment. Risk: the layer persists across future Fedora version rebases and can complicate or block those rebases. Do not use dnf install directly on the Silverblue host.

Trust and data boundaries

• OSTree commit checksums verify that the downloaded tree matches the intended commit.
• GPG-signed metadata from Fedora mirrors protects against tampered update data.
• Flatpak applications run in a sandbox; inspect permissions with flatpak info --show-permissions <application-id>.
• Toolbox and Distrobox containers share your home directory by default, so treat the home directory as a shared data boundary between host and containers.
• SELinux is enforcing by default and may restrict Flatpak or container access to host devices and filesystem paths.

Operational checks

• rpm-ostree status — run on the host as a regular user. Confirms the active deployment, read-only root, and available previous deployment.
• rpm-ostree upgrade — run on the host with root privileges. Downloads and stages a new deployment; a reboot is required to boot into it. This changes system state.
• rpm-ostree rollback — run on the host with root privileges only after a state-changing operation such as an upgrade or install. It marks the previous deployment as the default boot entry. This changes system state.
• Bootloader entries — inspect available deployment entries before rebooting into a newly staged tree.
• getenforce — confirms SELinux state; expect Enforcing.
• flatpak info --show-permissions <application-id> — validates sandbox boundaries for a specific Flatpak.

Failure modes

• Failed upgrade: the previous tree remains intact and bootable.
• Layered package conflicts during a Fedora version rebase: existing layers may conflict with the new base image. Remove or review layers before rebasing.
• Persistent layering increases update size and long-term maintenance complexity.
• Proprietary kernel modules may not build cleanly against the ostree kernel or may require additional layered tooling.
• DNF is restricted on the host; using it to install system packages directly is not the supported Silverblue model.

Conditions that change the design

Consider traditional Fedora Workstation instead of Silverblue if:

• The workload requires proprietary kernel modules that are difficult to layer or build against the ostree kernel.
• You need frequent base-package churn or many system packages that have no Flatpak equivalent.
• Required software is unavailable as a Flatpak and unsuitable for a container.
• You want DNF as the primary package manager on the host operating system.

Limitations and practical verification

This note describes well-established Silverblue behavior. Verify commands on your own system before relying on them. After any rpm-ostree change, run rpm-ostree status and confirm that two deployments exist, the active deployment matches your intent, and the previous deployment remains listed. Run getenforce to confirm SELinux is enforcing, and review Flatpak permissions for any application that needs host devices or filesystem access.

Rollback is only meaningful after an operation that changes state, such as rpm-ostree upgrade or rpm-ostree install. It toggles the default boot entry between deployments; it does not remove the other deployment automatically.