Creating an install ISO with Anaconda

Using bootc-image-builder is great for creating virtual and cloud images, but for bare metal installs we need a different approach. In those environments, the Anaconda installer is still widely used, automated by kickstart files.

Anaconda is typically used via the boot ISO shipped by Red Hat. There are several ways to get a host to boot from this ISO image including PXE or HTTP Boot over the network, as an image via IMPI, or a physical disk inserted into a drive. The kickstart file for an install can also be provided in several ways, including over a network or as part of the ISO.

For this section of the lab, we’ll focus on creating a boot ISO that includes the kickstart. The configuration of Anaconda via kickstart will be the same, regardless of how it is presented to the host being installed. This means you can incorporate bootc hosts into an existing kickstart infrastructure fairly seamlessly.

To create the ISO with an embedded kickstart, we will use bootc-image-builder. Make sure you have the bootc image to be installed available in system storage.

All of the kickstart is standard fare. Anaconda will create the partitions and filesystems on disk, enable services, and create users just like it would in any other install. You even have access to the %pre and %post blocks too, the only missing section from any kickstart you have today is the %packages list. The full details of kickstart is beyond the scope of this lab, but the example will create a single partition, create a user, start ssh, disable the firewall, and reboot once finished. Oh, and of course deploy our image.

The kickstart file is added to the ISO via a customization block of the bootc-image-builder config file. Add the following to config-iso.toml and save the file. Be sure to add the ssh public key for your system.

You can now create a file called config-iso.toml with the following contents, replacing "SSHKEY" in the key field with the contents of public key from your system.

The new ostreecontainer command replaces the standard %packages block of the kickstart file that defines what RPMs would be installed by Anaconda. This replaces that set of RPM transactions with the bootc image to be unpacked and installed to disk.

When creating an ISO with an embedded kickstart however, bootc-image-builder will automatically inject the correct ostreecontainer directive for the image we pass. This image is embedded in the ISO with the kickstart, which makes this ISO a completely self-contained installer for a single image.

The command looks nearly identical to the one used to create the virtual machine QCOW2 disk in the earlier exercise, using a new output type.

For this output type there are two stages, bootc-image-builder will first create the ISO image from the same source repos as the container it’s passed. This ensures we get matching versions on the installer and the image to be installed regardless of the host’s OS version, eg a RHEL 10 ISO for a RHEL 10 image.

While the ISO builds, let’s talk about the change needed to use bootc with a kickstart file in a network based install. If you wanted to deploy from a container registry, just add the new ostreecontainer command. In that kickstart, ostreecontainer takes the url argument with the full location and name of the image:

This will download the image during the install process and use bootc to deploy the contents to the disk set up by Anaconda according to the kickstart file. You can boot from the standard boot ISO downloaded from the Customer Portal and pass the kickstart via HTTP, or from a Satellite server. The only change is how software is processed during the install.

Having created a custom installation ISO, we can boot a virtual machine and automatically install our image. We are once again using virt-install to create a local VM, the main difference is that here we are using the options to pass the local path of the ISO file. We’ll attach virsh to the console created via the --extra-args options so we can see what happens.

Locate the installer ISO in the bootiso directory.

Copy the ISO to a location that virsh can find it, like with the QCOW2 disk image. This is mainly about permissions and access.

Now we’re ready to start the install from our ISO image.

Once the initial boot is complete, you’ll get to see anaconda at work. At various points you’ll see output like below, showing anaconda reading the kickstart, and calling bootc to deploy the image to the disk layout it created.

When prompted, hit Enter to finish the installation and shut down the VM

We can now start our new bootc virtual machine.

Check to make sure the virtual machine running:

Like with the previous virtual machine created, you can directly see if the http application is already running on the host:

The output should be "Hello Red Hat Summit 2025!!"

You can now login to the virtual machine.

Once you have logged in, you can inspect the bootc status.

One thing that immediately is different in the bootc status output is that the deployed image image is a local path, not the registry naming convention we’ve been using. Let’s dig a little deeper by pulling the spec block from the full YAML output.

The transport line refers to how containers are pulled and are defined as part of the OCI standards. The oci transport type means this is a single image located at a specific local path. This path existed in the install environment, but isn’t a container storage location we’d use on a live system. In fact, this image may not exist on the system at all since /run is a tmpfs location.

It’s important to note that not having the container image on the system doesn’t affect bootc operations at runtime. Once installed or an update is pulled and deployed, the container image is no longer needed. Rollbacks are to the deployment on disk, not to an image.

So far in this lab, we have been using the registry transport, which requires network access. To manage updates in an offline manner, say for disconnected environments or those with intermittent connectivity, we could replicate the OCI transport and present an image at the same location. But we can also use the standard system storage locations with the containers-storage transport. A full discussion of transports and their associated uses and configuration is outside the scope of this lab.

For this lab, let’s provide an update via standard system storage. We can use skopeo to copy images from one location to another. Here, we will use it to copy from the lab registry to the host, but it can also be used to copy to and from a USB drive or other media.

We need to be sure to use sudo to copy into the system storage location and not the user’s.

Switch our installation to use the new container image, using the --transport flag to let bootc know we want to use local container storage for update tracking.

At this point, the "new" installation has been prepared and will be started at next boot of the virtual machine.

The last step for the change to take effect is to reboot the virtual machine. Before doing so, please make sure you are logged in to the virtual machine and not the hypervisor (the prompt should look like `[core@localhost ~]$ `):

In a short time after that command, you should be able to ssh back to the virtual machine:

And check the bootc status:

In the status you can see bootc is now tracking local container storage for updates, not the filesystem path. Further updates just need to be copied there for bootc to recognize and apply. You could use skopeo sync a registry repository to media, like a USB drive, as well as copy it from the media to the local storage on the host.

This opens a range of possibilities to deliver installations and updates for edge devices, disconnected networks, and any other arenas where direct connectivity to a registry over a network isn’t possible or desired.

Before proceeding, make sure you have logged out of the virtual machine:

The prompt should look like `[lab-user@bastion ~]$ ` before continuing.