RH134 Chapter 18 — Working with Image-Based Red Hat Enterprise Linux

Chapter Objective: Describe image mode for RHEL, define a system's configuration in a Containerfile, and check status, upgrade, switch, and roll back a bootc-managed system.

Key commands: bootc status, bootc upgrade, bootc switch, bootc rollback

Package-Based vs. Image-Based RHEL

Every prior chapter assumed the traditional model: RHEL installed once, then updated incrementally, package by package, with dnf. Image mode for RHEL offers a different approach — the entire operating system, defined and built as a container image, deployed and updated as a whole, atomic unit.

	Package-Based (dnf)	Image-Based (bootc)
Defined by	Whatever packages happen to be installed over time	A Containerfile, version-controlled like application code
Updates	Individual package changes, incrementally	A whole new OS image, applied atomically
Rollback	Complex, often manual	A single command back to the prior known-good image
Consistency across a fleet	Can drift between systems over time	Every system tracks the exact same image

🔵 Why It Matters Image mode brings the same build-once, deploy-everywhere, easily-rolled-back discipline that Chapter 17's container workflows apply to applications — now applied to the base operating system itself.

bootc and Image Mode

bootc is the tool that manages an image-mode RHEL system, built on ostree technology underneath. A running bootc system stores its filesystem state as versioned, bootable deployments — upgrading fetches and stages a new deployment without touching the currently running one, and a reboot switches into it.

✅ Tip — Same Registries, Same Tooling as Application Containers A bootc-managed RHEL image is pulled from and pushed to a container registry exactly like any other container image from Chapter 17 — the same podman build/podman push workflow applies, just targeting the OS itself instead of an application.

Defining a System with a Containerfile

# A Containerfile starting from a RHEL bootc base image,
# adding one additional package
FROM registry.redhat.io/rhel10/rhel-bootc:latest

RUN dnf install -y cowsay && dnf clean all

# Build and push the new OS image to a registry
podman build -t quay.io/my-repo/rhel-bootc-cowsay:latest .
podman push quay.io/my-repo/rhel-bootc-cowsay:latest

🔵 Note — The OS Configuration Is Now Code Because the entire system definition lives in a Containerfile, it can be version-controlled, code-reviewed, and reproduced exactly — the same practices already applied to application source code, now applied to the base operating system.

Checking System Status

# Show the currently booted image, its digest, and any staged update
bootc status

# Example output
Staged image: containers-storage:example.io/library/rhel-update:latest
Digest: sha256: 05b1dfa791...
Version: 10.0 (2025-07-07 18:33:19 UTC)
Booted Image: localhost/rhel-intel:base
Digest: sha256: 7d6f312e09...

✅ Tip — Check Status Before AND After a Change Recording the digest of the currently booted image before making a change gives you a clear before/after baseline — useful both for confirming an upgrade actually applied, and for troubleshooting if it didn't.

Upgrading and Switching Images

# Fetch and stage the latest version of the CURRENTLY tracked image
# (does not affect the running system until a reboot)
bootc upgrade

# Stage AND automatically apply/reboot immediately
bootc upgrade --apply

# Switch to tracking a DIFFERENT image reference entirely
# (e.g. moving from a staging tag to production)
bootc switch quay.io/my-repo/rhel-bootc-cowsay:latest

# Switch using a soft reboot — applies the new OS in seconds,
# without a full hardware reboot cycle
bootc switch --apply quay.io/my-repo/rhel-bootc-cowsay:latest

🔵 Exam Note bootc upgrade and bootc update are aliases for the same operation. bootc switch does the same underlying work as bootc upgrade, but additionally changes which image reference the system tracks going forward.

✅ Tip — Data in /etc and /var Survives Upgrading and switching both preserve system state outside the base image — host SSH keys, home directories, and local configuration in /etc and /var carry forward rather than being wiped by the new image.

Rolling Back

# Roll back to the previous deployment
bootc rollback

# Reboot immediately to apply it
reboot NOW

✅ Tip — Rollback Is the Real Payoff of Image Mode Recovering from a bad update traditionally might mean restoring a snapshot or backup. With image mode, bootc rollback && reboot NOW reverts the entire system back to the previous known-good deployment in roughly the time it takes to reboot.

Logically Bound Images

Some workloads — a security agent, a log-forwarding container — need to be available very early in boot, before the full system (and typically before networking) is ready. A logically bound image ties an application container's lifecycle directly to the host OS image, so it upgrades right alongside the base system rather than independently.

# Bound images are stored in bootc's own image storage, accessible
# to podman as an additional store
podman --storage-opt=additionalimagestore=/usr/lib/bootc/storage run <image>

🔵 Note Ordinary application containers from Chapter 17 remain independent of host OS upgrades by default — logically bound images are specifically for the smaller set of workloads that genuinely need to track the host's own lifecycle.

Key Terms for Chapter 18

image mode: Managing RHEL itself as a versioned, container-image-based deployment rather than incremental packages
bootc: The tool that manages an image-mode RHEL system's deployments, upgrades, and rollbacks
ostree: The underlying technology providing versioned, bootable filesystem deployments beneath bootc
Containerfile: The declarative file defining a bootc system image's contents, built with podman like any container image
bootc switch: Changes the tracked image reference and applies it, preserving /etc and /var state
bootc rollback: Reverts to the previously booted deployment
logically bound image: An application container whose lifecycle is tied to the host OS image's own upgrades

Review Questions

What is the fundamental difference between how a package-based RHEL system and an image-mode RHEL system are updated?
What underlying technology does bootc build on to manage versioned, bootable deployments?
What command shows the currently booted image and any staged update, and why is checking it before a change useful?
What is the difference between bootc upgrade and bootc switch?
What system state is preserved across an upgrade or switch, rather than being wiped by the new image?
Write the two commands needed to roll back to the previous deployment and reboot into it immediately.
What is a logically bound image, and why might a security agent or log forwarder specifically need to be one?