Image mode for RHEL 10: Updates in seconds with soft reboot

The promise of image mode is to align OS management with the agility of modern application development. Forcing a long reboot for a minor library update runs counter to that goal. The new soft reboot is a critical feature designed to make image mode viable for many more users by directly addressing this primary operational issue. It reconciles the atomic safety of image-based management with the operational speed demanded by its target audience. What if it were possible to gain all the benefits of atomic, image-based updates without a full reboot of the systems every time?

An alternative to full reboot

For any system administrator managing critical infrastructure, the full system reboot is a source of anxiety and delay. After applying a routine update, the process begins: the system shuts down, the screen goes dark, and a long, tense wait for the hardware to complete its Power-On Self-Test (POST), initialize firmware, load the bootloader, and finally, start the kernel. This entire sequence can take several minutes or even 20-30 minutes for large bare-metal nodes with extensive BIOS initialization times, during which a critical service is entirely offline. 

Image mode (powered by bootc) offers a modern approach to operating system management. It allows administrators to build, deploy, and manage the entire OS using the same container-native tools and workflows used for applications, enabling atomic updates, reliable rollbacks, and a consistent, verifiable OS state across a fleet. This model brings the principles of DevOps and GitOps to the OS layer.

However, this power has historically come with a perceived trade-off, an immutability tax. Because the OS is managed as a single, immutable unit, every update (no matter how small) required a full, time-consuming image update and reboot. This created a significant operational challenge. This represents a key barrier to adoption for teams that require maximum uptime.

Understanding the systemd soft reboot

The solution lies in a capability native to systemd: the soft reboot. A soft reboot is a userspace-only restart. When initiated, the systemd-soft-reboot.service terminates all running userspace processes, first with a SIGTERM signal and then with SIGKILL for any that remain before re-executing the systemd service manager (PID 1) to bring the system's services back online.

The key to its speed is the long list of time-consuming steps it completely bypasses. A soft reboot avoids the entire hardware and kernel initialization sequence, which is often the longest part of a traditional reboot cycle. Specifically, a soft reboot skips:

• The hardware reboot operation (POST)
• Firmware initialization (BIOS/UEFI)
• Boot loader initialization (for example, GRUB)
• Kernel initialization
• Initial Ramdisk (initrd) execution

While the kernel remains running, its settings (such as sysctl values) are preserved, as is the state of the /run filesystem. This makes it an ideal mechanism for applying updates to userspace components like shared libraries (glibc, openssl) or system services, which you can reload with their new versions in a fraction of the time.

The following describes the difference between the traditional reboot versus the systemd soft reboot.

Image mode (bootc): A new OS in seconds

While systemctl soft-reboot is a powerful primitive on its own, its true potential is unlocked when combined with an image-based system like bootc. A simple soft reboot just restarts the current userspace. The transformative capability of the bootc integration is using this mechanism to pivot to an entirely new and updated userspace atomically.

This integration is orchestrated through a special mechanism provided by systemd: the /run/nextroot/ directory. When an administrator triggers an update, the process unfolds as follows:

1. The user requests an update or a switch to a new image via a command like bootc upgrade, bootc update, or bootc switch.
2. Leveraging its underlying ostree technology, bootc transactionally fetches and stages the new OS deployment. This new filesystem tree is prepared but not yet active.
3. When requesting a soft reboot as part of the update, bootc invokes logic (powered by the ostree-admin-prepare-soft-reboot command) to mount the new, staged OS filesystem at the special location /run/nextroot/.
4. This triggers the systemd-soft-reboot.service. As part of its execution, it explicitly checks for the existence of /run/nextroot/.
5. Finding the new root filesystem mounted there, systemd performs a switch_root operation into it before it re-executes itself to bring up the new userspace.

The result is the system re-emerging in seconds, running the completely new OS image. This entire transition happens without ever touching the running kernel or waiting for hardware initialization. This feature represents a significant evolution of the ostree-based atomic update model. The update was traditionally guaranteed by the hard reboot. The soft-reboot feature with bootc provides the same guarantee of a complete and consistent filesystem swap within a much faster, userspace-only transition. This enhancement fundamentally changes the operational calculus of managing atomic systems, making updates that once required minutes of downtime achievable in mere seconds.

The sub-minute RHEL update

This new capability is available starting with Red Hat Enterprise Linux (RHEL 10) in image mode. The following steps demonstrate how to apply a userspace update to a RHEL bootc system with minimal downtime.

Step 1: Establish a baseline

First, check the current state of the system to have a baseline for comparison. This command shows the digest of the currently booted container image.

Bash

sudo bootc status 

Next, confirm that a sample package cowsay is not currently installed.

Bash

rpm -q cowsay

package cowsay is not installed 

Step 2: Build and push an updated image

To perform an update, we need a new version of the OS image. Create a Containerfile that adds the cowsay package to the base RHEL bootc image.

Dockerfile

FROM registry.redhat.io/rhel10/rhel-bootc:10
RUN dnf install -y cowsay && dnf clean all

Now, build this image and push it to a container registry that the target system can access.

Bash

podman build -t quay.io/my-repo/rhel-bootc-cowsay:latest
podman push quay.io/my-repo/rhel-bootc-cowsay:latest

Step 3: Apply the update with soft reboot

This is the main event. Use the bootc switch command to target the new image and instruct it to use a soft reboot. The --apply flag tells bootc to immediately trigger the reboot after successfully staging the update.

Bash

sudo bootc switch --soft-reboot=required --apply quay.io/my-repo/rhel-bootc-cowsay:latest

The --soft-reboot=required flag is critical. It instructs bootc to prepare the system for a soft reboot and exit with an error if one is not possible (e.g., if the update contains a new kernel or different kernel arguments). This is ideal for automated workflows where predictable, minimal downtime is essential. An alternative, --soft-reboot=auto, will gracefully fall back to a traditional hard reboot if you can't perform a soft reboot.

Step 4: Verification

The system will soft reboot and should be accessible again within seconds. Once it is back, verify that the update was successful.

First, check the bootc status again. The output will show the new image digest and, with the --verbose flag, will include a new flag confirming the last transition was a soft reboot.

Bash

sudo bootc status --verbose

State: idle
Booted:
  - ostree-image-signed:docker://quay.io/my-repo/rhel-bootc-cowsay:latest
    Version: 10
    Digest: sha256:a1b2c3d4...
    soft reboot: yes

To provide definitive proof that a soft reboot occurred, check the systemd property that counts them.

Bash

systemctl show --value --property SoftRebootsCount

Finally, confirm that the new package is present and functional.

Bash

cowsay "Soft reboots are fast!"

 ________________________
< Soft reboots are fast! >
 ------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     || 

Knowing the limits

While powerful, soft reboots are not a "silver bullet" for all update scenarios. Understanding the limitations is key to using this tool effectively and safely.

The big one: Kernel updates

The most significant limitation is that a soft reboot cannot apply a new kernel. The Linux kernel is loaded by the bootloader early in the boot process and cannot be swapped out while the system is running. If an image update includes a new kernel version or a new initrd, a traditional, a full reboot is required to activate it.

Fortunately, bootc is designed to handle this intelligently. When using --soft-reboot=auto, bootc will detect the presence of a new kernel and automatically perform a full reboot. If you use --soft-reboot=required, the command will fail with an informative error, preventing an unexpectedly long downtime in an automated script that requires a fast update.

The kernel module caveat

A more nuanced consideration involves kernel modules (kmods). It is possible to build and deploy a userspace update containing a new version of a driver or other kernel module that is incompatible with the currently running kernel. A soft reboot would activate this new userspace, potentially leading to system instability or hardware issues. This is primarily a concern for advanced use cases. The best practice is to thoroughly test image builds and ensure that userspace components maintain compatibility with the kernel versions they will run.

Looking ahead

What does this mean for image-based systems? The integration of soft reboots into bootc dramatically reduces downtime for the majority of OS updates, increases operational efficiency, and enables broader adoption of Image Mode for RHEL. For Red Hat OpenShift Container Platform users, this means less pod disruption and a bare-metal update experience that feels as fast as a cloud instance. This feature is a key step in a broader strategy to make the operating system behave more like a cloud-native application: agile, declarative, and managed with minimal disruption. It further aligns the lifecycle management of the OS with the CI/CD principles used for the applications running on it.

Looking ahead, this technology opens the door to even more advanced capabilities. You can configure the underlying systemd mechanisms to allow specific, long-running services or containers to survive a soft reboot, continuing to run uninterrupted while resetting the rest of the userspace around them. This could be a game-changer for GPU-intensive AI workloads.

This feature represents a fundamental improvement in how we manage and update modern Linux systems. We encourage you to explore image mode and the new soft-reboot capability in RHEL 10. For more details, consult the official documentation and share your feedback through Red Hat's standard channels.