How to build ISOs from bootable OCI containers?

Project Discussion
, ,
1

I have a custom OCI bootable container based on the quay.io/fedora/fedora-silverblue image. Currently, I have to manually switch to my image with rpm-ostree rebase after installing from the Silverblue ISO. This works fine for me, but I want to distribute my ISO to other people who expect a normal installation experience without running shell commands.

How can I build a live ISO which installs my container to disk? I would prefer if my container is also used in the live environment since it has some modifications that are necessary for hardware support. I know how to build ISOs for regular (non-atomic) Fedora from kickstart files, but I can not find any docs on how to build ISOs for atomic desktops.

1 Like
2

Really cool! I want to do the same for CentOS Stream 10 + EPEL + KDE, will be quite some effort!

I found these docs to be helpful

I already successfully created a barebones CS10 qcow virtual machine image. You would want an “anaconda ISO”.

I am not sure how ready this all is.

Apart from that, uBlue also uses the OCI images and has their own (?) ISO builder. For that I am sure it works.

This is the currently maintained Github action

Well that is a rabbit hole. CoreOS has a different OS builder probably also for ISOs, Colin Walter used parts of that to create a builder that works without root.

In short, ext4 and xfs filesystems can only be created by a root user with the kernel, using an unprivileged container doesnt work.

You can use virtualization though, with KVM.

1 Like
3

As far as I know, there is no Live ISO for Atomic Desktops yet, but since I am currently working on a guide for the bootc docs on how to create an interactive installer, I can post the draft here.

4

As far as I know, there is no Live ISO for Atomic Desktops yet

I think calling it a live ISO was confusing, I am trying to make something like the silverblue ISO which boots into GUI anaconda.

5

I got an ISO to build with bootc-image-builder, but it automatically starts the anaconda installation without asking the user anything. This automatically picks the first disk it finds so it is not safe to ship to users. Is there a way to make anaconda ask for installations settings?

6

This is what I meant by “Interactive installer”.

You can provide a custom kickstart config file in bootc-image-builder.
If you provide an empty custom kickstart file you will end up with an incomplete kickstart config containing only the ostreecontainer directive:

[customizations.installer.kickstart]
contents = ""

However, this is not the best UX in my opinion, because the “Kickstart insufficient” error appears in the “Installation Destination” item. So my suggestion for the kickstart config is to automatically select and partition the first disk found, which is probably what most users will do anyway.

[customizations.installer.kickstart]
contents = """
# Disk information is created using the %pre section
%pre

    #! /usr/bin/env bash

    # Get only disk names and sort by sequence number
    disks=($(lsblk --noheadings --output NAME --sort DISK-SEQ --nodeps --include 3,8,112,202,259))

    # Select the first disk and use it for installation
    disk0=${disks[0]}
    echo "ignoredisk --only-use=$disk0" > /tmp/disk-install

%end

# Use graphical install
graphical

# Leverage the preinstallation script
%include /tmp/disk-install

# Erase all partitions and initialize the disk label
clearpart --all --initlabel

# Automatically create partitions
autopart
"""

Of course, the user has the option to select another device or make a custom storage configuration in the “Installation Destination” item.

Please test this configuration and give feedback from the people you distribute the ISO to so I can have more data before opening a PR in the docs repo.

Thank you!

7

I’m using the kickstart below:

[customizations.installer.kickstart]
contents = "graphical"

It allows anaconda to be interactive. I always choose the automatic partition anyway and it works fine.

However, the repo listed with rpm-ostree status (or bootc status) is pointing to the local storage created by anaconda, so I had to rebase to my remote package repository,

8

This should help:

1 Like
9

I got a working ISO with this config:

[customizations.installer.kickstart]
contents = """
graphical
%post
bootc switch --mutate-in-place --transport registry ghcr.io/username/image:41
%end
"""

My image is meant to be used in dual boot situations with wierd partition layouts, so I dont want to automatically partition the first disk. If a user accidentally clicks through the installer, it can cause data loss for other OSs.

Also, the installer wants to create users instead of this being handled by g-i-s like on silverblue. This is weird but its not really a problem other than just being different from usual.

2 Likes