Why Fedora Atomic Desktops Treat Updates Like Rebootable Images

A power loss mid-upgrade on a traditional distro can leave /usr half-written and the system unbootable. Fedora Silverblue and Kinoite avoid that class of failure by not mutating the running system at all. The base OS is an immutable OSTree image, and rpm-ostree stages a complete new deployment for the next boot. If the new image fails, you boot the previous one.

That is the practical engineering decision behind Fedora Atomic Desktops: reproducibility and safe rollback over in-place mutability.

From packages to versioned images

OSTree is a content-addressed filesystem tool. Fedora Atomic Desktops build the OS as a versioned tree of files, identified by a commit checksum. rpm-ostree is the Fedora tool that composes RPMs into those commits and manages deployments.

A deployment is a bootable snapshot of the OS: kernel, /usr, and the rpm-ostree metadata that describes it. The running system is read-only under /usr. User data lives on /home and /var, which are writable. Applications are expected to come from Flatpak or from user containers like Toolbox/Distrobox, keeping the base image small and reproducible. Layering RPMs onto the base with rpm-ostree override or install is possible, but it increases composition time and reintroduces dependency complexity.

How an update stays atomic

When you run an update, rpm-ostree does not touch the running tree. It downloads the new commit and its changed objects, composes a new deployment that is a child of the current one, and writes it to /ostree/deploy. The current deployment keeps running. Only a reboot switches the default boot entry to the new deployment.

Because the switch happens at boot via GRUB, an interrupted download or power loss cannot corrupt the running system. The new deployment is either fully present and bootable, or it never becomes the default. Every deployment remains bootable, so rollback is a boot menu choice or rpm-ostree rollback.

OSTree deduplicates content by file hash, so keeping two or three deployments costs far less than full copies.

Verify the model without risking a host

You can observe the image model in a VM. Install Fedora Silverblue or Kinoite for the release you intend to evaluate, and open a terminal as a regular user with sudo privileges.

Check the current state:

rpm-ostree status

Expected check: the output lists one or more deployments with a commit identifier and a boolean indicating which is booted and which is pending.

Stage an update:

rpm-ostree upgrade

This downloads the new base commit and stages it. The running system is unchanged. Reboot the VM.

After reboot, run rpm-ostree status again. Expected check: a second deployment appears and is now the booted one. In the boot menu you should see entries for both deployments.

To test rollback, either select the previous deployment from GRUB at boot, or from a working boot run:

sudo rpm-ostree rollback

Reboot and confirm the previous deployment becomes booted again. Risk: rollback changes the default boot target; ensure you have backups of any data written outside /home before experimenting.

Trade-offs to plan for

The gain is reproducibility, safe upgrades, and fast rollback. The cost is loss of familiar dnf mutability. Workflows that assume a writable /usr, kernel modules installed via DKMS, or installers that write to system paths will need adjustment. Layering many RPMs with rpm-ostree slows updates and can reintroduce conflicts similar to traditional package management. Some third-party drivers or VPN clients that install kernel modules may require a Toolbox container or a layered package.

The same rpm-ostree model underpins Fedora IoT and CoreOS, so skills transfer across Fedora’s image-based variants.

If you value a system that can be updated and reverted as a whole, try an Atomic Desktop in a VM, inspect deployments with rpm-ostree status, and confirm that a staged update only takes effect after reboot. That verification shows the engineering decision in practice: reliability through immutable, bootable images rather than in-place mutation.