Fedora Silverblue and Kinoite: Atomic Updates, Trust Boundaries, and Rollback Decisions

Problem and useful takeaway

You are deploying Fedora Silverblue or Kinoite and need the base operating system—kernel, systemd, core libraries, and desktop environment—to update as one bootable image. A failed update must not leave the system unbootable, and user-installed applications must not mutate that image. The useful takeaway is to treat the OSTree commit as the root of trust, keep /usr read-only, deliver user software through Flatpak or Toolbox, and verify deployments with rpm-ostree status and ostree admin verify before relying on rollback.

Requirements

• Base system updates atomically as a single bootable OSTree commit.
• Instant rollback to the previous commit if the new deployment fails to boot.
• /usr is read-only and mounted from a verified commit.
• /etc and /var remain writable for system and user data.
• User applications arrive through Flatpak or containerized tooling, not by mutating the base image.

Smallest suitable design

rpm-ostree composes a bootable OSTree commit from RPM content. The commit contains the kernel, init system, core libraries, and desktop packages. On disk, /usr is read-only and tied to that commit, while /etc and /var are writable overlays. Each deployment gets a bootloader entry, typically through the Boot Loader Specification files read by GRUB, so the previous commit remains selectable at boot.

Trust and data boundaries

The OSTree repository is the root of trust for the base OS. Its commits are signed and GPG-verified, so the system can cryptographically confirm that deployed files match the intended image. Flatpak runtimes and applications use separate signatures and sandbox permissions; a Flatpak update does not alter the OSTree commit. Layered packages installed with rpm-ostree install mutate the local commit only. They require a reboot and break the guarantee that every machine running the same commit is identical.

Operational checks

Run these commands in a terminal on the Silverblue or Kinoite host. Placeholders such as should be replaced with a real Flatpak ID, for example org.gnome.TextEditor.

Diagnostic sequence after a failed base update

1. Boot the machine and use the GRUB menu to select the previous OSTree deployment if the new one fails.
2. After logging in, run rpm-ostree status to confirm the system is running the previous commit.
3. Run ostree admin verify --repo=/ostree/repo to confirm the rolled-back deployment is internally consistent.
4. If the failure was caused by a layered package, consider removing it with rpm-ostree uninstall and rebooting, or replace it with a Flatpak equivalent.

Failure modes

• Failed staging: A network or storage error during an update leaves the previous commit intact; the system simply continues booting the old deployment.
• Layered package conflicts: An rpm-ostree install transaction can abort due to dependency conflicts, leaving no new deployment to boot.
• /var overlay corruption: Corruption in the writable overlay can break user data or system state and requires manual repair; it is not fixed by rolling back the OSTree commit.
• Kernel or driver regression: Selecting the previous commit in GRUB usually restores a working kernel and driver combination.
• Flatpak permission changes: An application can break after a Flatpak update without affecting the OS image, so OS rollback will not repair it.

Conditions that change the design

• Frequent out-of-tree kernel module builds (DKMS, NVIDIA, ZFS) favor a traditional dnf-based Workstation because akmods rebuilds add reboot latency and potential mismatch on an immutable image.
• A requirement for per-package rollback without rebooting favors dnf over rpm-ostree.
• Hardware requiring proprietary or out-of-tree drivers may be difficult to support on a read-only /usr image.
• Environments where reboot latency is unacceptable are poorly suited to an image-based desktop that requires rebooting to apply or roll back base changes.
• Organizations moving toward unified container-native server and desktop management may evaluate bootc-derived images instead of classic rpm-ostree deployments.

Limitations and pre-production verification

Each staged commit consumes roughly one to two gigabytes. Use rpm-ostree cleanup -p to remove old, unbooted commits; it does not remove the booted deployment. SELinux policy is part of the immutable image, so local policy changes require a custom image build or layered packages plus a reboot. Manual edits to GRUB configuration are overwritten by the next rpm-ostree transaction.

Command paths and flags assume current Fedora Silverblue/Kinoite releases; verify them against your installed version before production use. A practical check is to confirm that the booted commit hash from rpm-ostree status matches the verified OSTree deployment, then test rollback in a non-production virtual machine before applying it to physical hardware.