Immutable Linux: Fedora Silverblue, Vanilla, openSUSE Aeon

Immutable desktop Linux distributions flip the traditional model on its head: the root filesystem is read-only, updates are applied atomically as whole-image transactions, and bad updates can be rolled back in seconds. Fedora Silverblue, Vanilla OS, and openSUSE Aeon each take this idea seriously but implement it differently. This guide covers how they work under the hood, how to live productively inside them, and when to reach for each tool in your arsenal.

How Immutable Desktops Work

The key insight is that traditional package managers mutate a live system in place—if something goes wrong mid-upgrade, you can be left with a broken state. Immutable distros avoid this by treating the OS as an image you swap between, not a pile of files you edit.

OSTree / rpm-ostree (Silverblue and friends)

OSTree is a content-addressed, Git-like object store for filesystem trees. Fedora Silverblue, Kinoite, and the broader Fedora Atomic Desktops family use rpm-ostree on top of OSTree. Each update downloads a new commit, places it alongside the current deployment on disk, and updates the bootloader to point to it. Your running system is never touched until the next boot.

Deployments live under /ostree/deploy/. Only two are kept by default (current + previous), keeping disk use reasonable.

Transactional Updates (openSUSE Aeon / MicroOS)

openSUSE Aeon uses Btrfs snapshots combined with transactional-update. An update is applied to a new Btrfs snapshot of the root subvolume; if the snapshot boots successfully, it becomes the new default. The running system is never modified. GRUB is automatically updated to offer rollback at the boot menu.

Vanilla OS (ABRoot)

Vanilla OS 2.x uses ABRoot, an A/B partition scheme. Two root partitions exist (A and B); updates are applied to the inactive partition, then the bootloader is switched. You always boot from one complete, known-good root. Vanilla also layers OCI images, pushing the immutable concept even further toward containers-as-OS.

Fedora Silverblue: Day-to-Day Workflow

Checking status and current deployment

rpm-ostree status

Output shows the booted deployment (marked with a star), its commit hash, and any staged deployment waiting for reboot. It will vary based on your installed layered packages and current Fedora version.

Updating the system

rpm-ostree upgrade

This stages a new deployment. Nothing changes until you reboot. To stage and reboot in one step:

rpm-ostree upgrade --reboot

GNOME Software handles updates graphically and will prompt you to reboot to apply them—it uses the same rpm-ostree backend.

Rolling back a bad update

rpm-ostree rollback

This makes the previous deployment the default for next boot. You can also select it from the GRUB menu without running any command, which is useful when the system won't boot far enough for a shell.

Layering packages (use sparingly)

The base image is meant to be lean. You can layer RPM packages on top of the OSTree commit when Flatpak, Toolbox, or a container won't work—for example, a kernel module or a hardware driver:

rpm-ostree install fuse-sshfs broadcom-wl

Layered packages are baked into your local deployment and persist across base upgrades, but they do increase update time and complexity. Keep the list short.

To remove a layered package:

rpm-ostree uninstall fuse-sshfs

Pinning a known-good deployment

sudo ostree admin pin 0

Index 0 is the booted deployment. Pinned deployments are not garbage-collected, giving you a permanent fallback. Unpin with ostree admin pin --unpin 0.

openSUSE Aeon: Transactional Updates

Applying updates

sudo transactional-update

This creates a Btrfs snapshot, applies all pending zypper updates inside it, and exits. Reboot to activate. Aeon also ships a systemd timer (transactional-update.timer) that does this automatically overnight—check its status with:

systemctl status transactional-update.timer

Installing packages transactionally

sudo transactional-update pkg install v4l2loopback-kmp-default

The package lands in the next snapshot, not the running system. Running zypper install directly on Aeon will warn you and may be blocked, depending on the release—always go through transactional-update for anything touching the root filesystem.

Rolling back

Select an older snapshot from the GRUB menu at boot (openSUSE labels them by date and snapshot number), or use:

sudo snapper rollback

Then reboot. The chosen snapshot becomes the new read-write default for the next transactional update cycle.

Application Strategy: Flatpak, Toolbox, and Distrobox

All three distros are designed with the expectation that most user-facing software comes from Flatpak, and that developer toolchains live in containers. Embrace this; fighting it creates unnecessary layered-package debt.

Flatpak for desktop apps

# Silverblue / Aeon / Vanilla OS
flatpak install flathub org.gimp.GIMP
flatpak update

Flatpak apps are fully independent of the OS image. Updates happen separately and don't require a reboot. On Silverblue, Flathub is pre-configured; on Aeon, you may need to add it:

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Toolbox / Distrobox for development

toolbox (Fedora) and distrobox (cross-distro) create rootful or rootless containers that share your home directory and feel like a native shell. Install anything inside without touching the host:

# Fedora Silverblue — create a Fedora 40 toolbox
toolbox create --release 40
toolbox enter

# Any immutable distro — Distrobox with an Ubuntu 24.04 container
distrobox create --name dev-ubuntu --image ubuntu:24.04
distrobox enter dev-ubuntu

Inside a Distrobox container you can run apt, dnf, or pacman freely. GUI apps launched from inside the container appear on the host desktop via socket passthrough—including Wayland support.

Verification: Confirming Your Deployment State

After any update or rollback, confirm what you're actually running:

# Silverblue
rpm-ostree status
uname -r

# openSUSE Aeon
btrfs subvolume list / | head -20
snapper list

For Silverblue, rpm-ostree status should show the booted commit with a checksum matching what you just pulled. For Aeon, snapper list will list snapshots with their creation time and whether the current one is active.

Troubleshooting

rpm-ostree is stuck or shows a conflict

If a previous operation was interrupted, a staged deployment may be corrupt. Clean it with:

rpm-ostree cleanup -s

The -s flag removes only the staged deployment. Use -p to also remove pending, -r for rollback deployments, and -m for cached metadata.

A layered package blocks an upgrade

Sometimes a layered package has no equivalent in the new base commit (e.g., it was renamed or dropped from the repo). rpm-ostree will refuse to upgrade and tell you which package is the problem. Options: remove the layer (rpm-ostree uninstall <pkg>), override the upgrade to skip it, or find a Flatpak/container replacement before upgrading.

Aeon: transactional-update fails to apply

Check the journal for the zypper transaction inside the snapshot:

sudo journalctl -u transactional-update --since today

Most failures are network errors or GPG key issues. Running sudo transactional-update dup forces a full distribution upgrade, which can resolve dependency deadlocks.

Home directory data is always safe

On all three distros, /home is a separate subvolume or partition that is never part of the OS image. Rolling back the OS does not affect your files. That said, application config files in ~/.config may reference features or file formats from the newer version—test before you commit to staying on the rollback.