FAQ for Image mode for Red Hat Enterprise Linux

Use container technologies to build, deploy and manage your operating system with the same tools and workflows as applications, promoting a common experience and language across teams.

Explore the interactive lab Learn more
Red Hat Enterprise Linux
Overview Getting started FAQ Documentation

Frequently Asked Questions (FAQ)

Got questions about Image mode for Red Hat Enterprise Linux (RHEL)? You've come to the right place! This page addresses frequently asked questions regarding image mode and will be updated periodically based on new information and feedback.

Red Hat Brand icon for install

Q: How do I get image mode for RHEL?

Image mode is included and supported with Red Hat Enterprise Linux (RHEL) 9.6 and later, including RHEL 10. Users will  start with a bootc base image, then customize it by adding their own applications, configurations, and packages using a Containerfile. If you don’t already have a subscription the no-cost Red Hat Developer subscription makes getting started easy. 

To get you started, we’ve created some resources for you to follow along with in your own environment. If you’d like to try image mode without the need for any additional setup, you can explore via the interactive lab.
Red Hat Brand icon for hybrid cloud

Q: Where can I use image mode for RHEL?

Image mode is integrated within Red Hat Enterprise Linux (RHEL), and you can run it everywhere you already run RHEL. Specifically, image mode is available for deployment on infrastructure options such as: 

  • Bare metal servers: This allows you to deploy RHEL directly onto physical hardware through standard installation mechanisms like anaconda and kickstart..
  • Cloud instances: RHEL can be run in image mode on major cloud providers like AWS, Microsoft Azure, and Google Cloud Platform, with the addition of the appropriate agents and tools.
  • Virtual Machines (VMs): You can deploy image mode within virtualized environments managed by hypervisors like OpenShift Virt, OpenStack, HyperV, VMware, KVM, and others, with the addition of the appropriate guest tools.
  • Edge devices: Image mode is also suitable for deployment on edge computing devices, enabling consistent and manageable operating system deployments in distributed environments.
Red Hat Brand icon for a venn diagram

Q: How does bootc relate to image mode?

The enabling component for image mode is bootc. This new tool manages the installation of a system from the contents of a container image, as well as managing the active state of the installation on disk. Bootc has not only the core of image mode operations on a host, but also integrated into standard Red Hat tooling like anaconda, image builder, Satellite and more.
Red Hat Brand icon for a container

Q: Do I need to build a new image each time I want to change anything in my Containerfile or install a package?

The design goal for image mode is to move as much into the image definition via the Containerfile as possible. This is key for providing a single, known image that can be reused across multiple systems and footprints.  This means that anything controlled via that Containerfile requires changes to be made there, and a new build to be promoted for packages, configuration files, etc. However, not all configurations can be shared, like networking configurations or users. These can be managed locally per host through typical means like Anaconda, Ansible or cloud-init. 

Additionally, there is a new option in dnf to install packages on a bootc host that only persist until the next reboot. This new ‘transient’ installation pattern makes troubleshooting much easier and also works for hotfixes. 
Red Hat Brand icon for an anchor

Q: What files within /etc persist across image updates in image mode? How are they preserved?

Changes to files in /etc are persistent across image updates on an image mode host. The management of files in /etc is shared between the image update and the local host via a process known as a 3-way merge. Any local changes to files from the container  image will no longer be updated from future images. This comparison is on a file by file basis, so it is entirely possible and safe to have some files in /etc managed via the image (like crypto policies) and others managed locally (like hostnames). If a file has been modified and you wish to “reset” it so it can be managed via the container image, simply copy the original file from the /usr/etc/ directory to /etc. This is a powerful feature not found on traditional Linux systems.
Red Hat Brand icon for NO

Q: Can I convert a system from package mode to image mode?

No, package mode systems can not be converted to image mode, or vice versa. These new operating modes of RHEL are mutually exclusive. The new system-reinstall-bootc tool provides a simplified wrapper around an install option that replaces an existing package mode host with a new image mode host. This can be very useful for deployments where a traditional installation method, like creating a hypervisor specific disk image, isn’t desirable.
Red Hat Brand icon for update

Q: Can you upgrade from a rhel-9-bootc image to a rhel-10-bootc image?

Yes. Upgrades across minor and major releases are supported with image mode. 
Red Hat Brand icon for secured

Q: Can I use FIPS with image mode?

Yes, FIPS mode is supported with image mode systems. Enabling FIPS, along with other advanced features, often requires adding kernel arguments during the boot process. bootc provides a simple way to define kernel arguments within the container image itself. For the precise steps and any release-specific information regarding FIPS configuration in RHEL, please refer to the official RHEL documentation.
Red Hat Brand icon for command line

Q: How does rhel-bootc differ from UBI images? Can I add a kernel to UBI and boot it?

While both rhel-bootc and Universal Base Images (UBI) share roots in Red Hat Enterprise Linux, they serve distinct purposes and have different content and licensing. rhel-bootc is specifically designed as a foundational image for installing a lightweight RHEL system, complete with the kernel, firmware, and bootloader, and is governed by the standard RHEL End User License Agreement (EULA). UBI, conversely, is a smaller set of RHEL packages under a more permissive EULA that allows for redistribution. Its primary use is as a base for building application containers, aligning with the RHEL lifecycle. Currently, making UBI images directly bootable by adding a kernel isn't supported, though it's a future goal.