LinuxCommandLibrary

rpm-ostree

Manage operating system images with atomic upgrades

TLDR

Show rpm-ostree deployments in the order they will appear in the bootloader

$ rpm-ostree status
copy

Show packages which are outdated and can be updated
$ rpm-ostree upgrade --preview
copy

Prepare a new ostree deployment with upgraded packages and reboot into it
$ rpm-ostree upgrade [[-r|--reboot]]
copy

Reboot into the previous ostree deployment
$ rpm-ostree rollback [[-r|--reboot]]
copy

Install a package into a new ostree deployment and reboot into it
$ rpm-ostree install [package] [[-r|--reboot]]
copy

SYNOPSIS

rpm-ostree <command> [<options>]

PARAMETERS

install <pkg...>
    Layers new RPM packages on top of the base OS. Requires a reboot to apply.

upgrade
    Downloads and deploys the latest available atomic OS update. Requires a reboot.

rollback
    Reverts the system to the previously deployed operating system version. Requires a reboot.

status
    Displays information about the current and available OS deployments, including layered packages.

rebase <ref>
    Changes the base OSTree branch or remote, effectively switching the system to a different OS variant or version.

override <subcommand...>
    Manages package overrides for base OS content, allowing replacement or removal of default packages.

DESCRIPTION

rpm-ostree is a hybrid image/package system that bridges the gap between immutable OSTree deployments and traditional RPM package management. It is foundational for operating systems like Fedora Silverblue, Fedora CoreOS, and RHEL for Edge, enabling atomic and transactional updates.

The core principle is an immutable root filesystem, where the base operating system is read-only. This significantly enhances system stability and security by preventing accidental or malicious modifications to core system files. Updates are performed atomically: the entire operating system, along with any layered packages, is updated as a single unit. This ensures that a system is always in a consistent state, and in case of an update failure, a rollback to the previous known-good deployment is straightforward and reliable.

While the base OS is immutable, rpm-ostree allows users to layer additional RPM packages. These layered packages are integrated into the atomic update process, guaranteeing their presence and consistency across system reboots and updates. It also supports rebasing the system to a different base image (e.g., switching branches or major versions) and provides robust rollback capabilities, making it an ideal solution for environments requiring high reliability and predictable system states.

CAVEATS

rpm-ostree fundamentally alters how packages are managed compared to traditional distributions:
1. Not a traditional package manager: It's not a direct replacement for dnf or yum for general package management. Its primary role is to layer RPMs on an immutable base, not manage packages within that base.
2. Reboots required: Most significant changes (e.g., installing layered RPMs, upgrading, rebasing) necessitate a system reboot to apply the new deployment.
3. Disk space usage: Multiple deployments are maintained for rollback functionality, which can consume significant disk space over time.
4. Layering limitations: Excessive layering of RPMs can complicate management and increase deployment size. For development tools or frequently changing software, containers (e.g., toolbox, distrobox) are generally recommended.

DEPLOYMENT MODEL

rpm-ostree operates on the concept of 'deployments'. Each time you make a change (e.g., install a package, upgrade), a new deployment is created. The system keeps multiple deployments, allowing for easy rollback to a previous, known-good state. Only one deployment is active at a time, and a reboot is required to switch to a different deployment.

LAYERING VS. CONTAINERS

While rpm-ostree allows layering RPMs, it's generally advised to use containers (like toolbox or distrobox) for development tools, programming languages, or software not strictly necessary for the core OS function. Layering should be reserved for system-level utilities, drivers, or applications that deeply integrate with the host OS. This approach keeps the base system lean and stable, while providing flexibility for user-space applications.

HISTORY

rpm-ostree was developed to address the need for reliable, atomic system updates in environments like Fedora Atomic Host (now Fedora CoreOS) and Fedora Silverblue. It emerged from the foundational OSTree project, which provides the underlying immutable filesystem and content-addressable storage for operating system deployments. The command was created to seamlessly integrate the existing RPM package ecosystem with OSTree's image-based update model. This allows users to layer traditional RPMs on top of an immutable base, providing flexibility without compromising the atomic update guarantees. Its development has been central to the evolution of "Atomic Workstation" and "Atomic Host" distributions, providing a robust and predictable operating system experience.

SEE ALSO

ostree(1), podman(1), docker(1), toolbox(1), distrobox(1), dnf(8)

Copied to clipboard