Containers have been around for more than a decade. Today, containers are the most preferred way to deploy Linux user space applications. Supported by a solid set of tooling infrastructure and practices, containers allow a standard, secure, and lightweight approach to build, share, and run applications.
Bootable containers extend these benefits and approaches to configure, deploy, and manage Linux-based bootable images. bootc (bootable container) provides transactional, in-place updates for operating systems using standard container images. These bootc-based Linux images are immutable.
Basic building blocks
The following figure captures a simplistic flow of a bootable container image.

Figure 1. Bootable containers
The following components represent the basic building blocks to generate a bootable container image.
- bootc: A utility to create, deploy, and manage bootable containers.
- bootc-image-builder (bib) : An image builder project that supports various formats of bootc images (for example, raw, qcow2, anaconda-iso)
- base container image : A base container image (for example, Fedora) used to generate a bootable container image.
- An Open Container Initiative (OCI) compliant container management tool (for example, podman, Docker)
GitHub-hosted bootc-related upstream projects now support IBM Power architecture (ppc64le).
Support for the following listed formats is available in ppc64le architecture:
- bootc install to-disk
- qcow2 (with bib)
- raw (with bib)
This blog outlines the steps to create a bootable container image (in disk format) that can run on an IBM Power (ppc64le) logical partition (LPAR).
The required environment includes:
- An IBM Power10 processor-based server
- An LPAR booted with Fedora41 ( installed on disk /dev/sda)
- A spare disk (/dev/sdb) to hold the bootable container images
- An exiting bootc-enabled container image (for example, fedora-bootc) hosted in a container registry like quay.io
Step 1 : prepare and setup
- Install the bootc utility.
$ yum install bootc
- Install the container management tool.
$ yum install podman
Step 2: Use bootc install to-disk command to generate a bootable container image
Run the following command to generate a bootable container image. Note that bootc install command requires a container environment to run and as shown is invoked with podman command.
For details about various supported bootc options, refer to the bootc install documentation.
$ podman run --pull=newer --rm \ ## Use a standard container tooling (podman)
--privileged --pid=host --network=host \
--security-opt label=type:unconfined_t \ ## security options for the container
-v $(pwd)/output:/output -v /dev/:/dev \ ## mount sub volumes
-v /var/lib/containers/storage:/var/lib/containers/storage \
quay.io/fedora/fedora-bootc:latest \. ## bootc enabled image
bootc install to-disk \ ## bootc install command with target as disk
--target-no-signature-verification \ ## Options to control the bootc install cmd
--wipe --block-setup direct \ ## behaviour. Eg —wipe to wipe target disk
--filesystem xfs \ ## filesystem to be used on target disk
/dev/sdb ## target disk device

The --wipe option specified in the command wipes the existing data on the device.

The bootc command reformats the disk and then creates a disk label, a PReP boot (on ppc64le architecture) partition, and a root partition on the disk.

The tool then proceeds to create a file system on the device. In this example xfs was used.
Other supported file system types are ext4 and btrfs.

After the container image is written to the disk, the bootc tool then proceeds with the boot loader configuration so that the device can be detected during boot.
bootc relies on bootupd (which in turn uses grub2 on ppc64le architecture) to handle the boot loader configuration and setup.

After successful completion of the above command, the disk now contains a bootable container image and this can be used as a bootable device. Proceed to reboot the LPAR.
Step 3. Validate the bootable container image
This section describes the required steps to boot the LPAR using the disk containing bootable container image.
- In the SMS menu type 5 and press Enter to select the Select Boot options option and to specify the disk containing the container image as the boot device.

- In the Boot Options screen, type 1 and press Enter to select the install/boot device.

- In the Select Device Type screen, type 3 and press Enter to select hard drive.

- In the Select Media Type screen, type 7 and press Enter to list all the devices.

- In the Select Device screen, type 1 and press Enter, as in this case, option 1 is the disk that contains the container image.

- In the Select Task screen, type 2 and press Enter to select the normal boot mode.

- In the exit screen, type 1 and press Enter to exit the SMS menu and proceed with the Linux boot process.

- Notice that you proceed with Linux boot process automatically.

- Notice that the login prompt is displayed after a successful Linux boot.

Container update and rollback using bootc
In addition to deployment of the container image, the bootc tool also provides capabilities to manage OS updates and rollback. The system supports in-place transactional updates with rollback after deployment. These kind of management operations , also known as Day 2 management baseline, consists of transactionally fetching new operating system updates from a container registry and booting the system into them, while supporting manual, or automated rollbacks in case of failures.
Let us look at each of the command operations in detail.
bootc upgrade: Update an operating system
The bootc upgrade command can be used to manually fetch the transactional updates from a container registry and boots the system into the new updates. This command queries the container registry and queues an updated container image for the next boot.
The following screenshot shows different command line options supported with bootc upgrade.

The bootc status command can be used to check if a container is booted using a bootc-based image. The output captured in the following screenshot shows details of the current running bootc image along with its sha256 digest value.

You can use the bootc upgrade --check command to check if an update is available. In case an update is available, the system displays an output like the one in the following screenshot.

To perform an update, run the bootc upgrade command. Note that the downloaded changes are staged and are not applied to the running system.
The --apply option, if specified, will automatically act and reboot the system into the new update. The following screenshot captures the output of the bootc upgrade –apply command

Note that the version to be booted (version 42.20250202.0) is different from the original version (version 41.20250202.0).
After a reboot is issued, an additional entry (as captured in the following screenshot) specific to this upgraded image is seen in the GRUB menu.

The following screenshot captured after the system boot shows the new kernel and the image.

bootc rollback: Rollback from an updated operating system
An OS upgrade performed using the bootc upgrade command can be reverted using the bootc rollback command. This command changes the bootloader entry ordering to queue up the deployment under rollback for the next boot. In case there is an unapplied or staged upgrade, the rollback command will discard it.
As shown in the previous screenshot the system is booted in Version: 42.20250202.0. This was the version installed after an upgrade using the bootc command.
To perform a rollback operation, run the bootc rollback command as shown in the following screenshot.

After a reboot, the system will boot back to the previous version as captured in the following screenshot.

Note that the booted version is 41.20250202.0
bootc switch – switching the container image reference
You can change the container image reference used for upgrades by using the bootc switch
command. For example switch from test to production tag.
The following screenshot shows the status of the current image.

To manually switch an existing container image reference, use the bootc switch command.
In this example the container image reference is switched from tag 41 to 42.

bootc status output confirms the switch and displays the queued version to be booted on next boot.

On next boot, the system will boot to the container image with tag 42. Optionally, you can use the –apply option to automatically reboot if the system (after the switch) has changed.
The bootc switch command performs the same operations as the bootc upgrade command and additionally changes the container image reference.
Summary
Bootable container (or bootc) extends the benefits and approaches of Linux user space applications containers to configure, deploy, and manage Linux-based bootable images.
bootc extends all the capabilities of container lifecycle management to include OS kernel (and initrd), bootloader, and related components along with the applications. This capability helps enterprises achieve end-to-end development, deployment, security, and management of OS and applications together using the standard container tooling.
References