Add support for bootc

[cgwalters]

So a while ago, we added the ostreecontainer kickstart verb. The advantage of this is that it works in exactly the same way/shape as the ostreesetup did.

However, the bigger picture direction I'd like to go is actually towards bootc install - where a container image can install itself.

The relevance to Anaconda here is that we'd support something like this:

# Basic partitioning
clearpart --all --initlabel --disklabel=gpt
reqpart
part / --grow # --fstype xfs (or could come from container)

bootc quay.io/fedora/fedora-bootc:40

Goals:

• Be able to define the filesystem type in the container with the bootc install config
• Potentially: Embed full or partial kickstart in container image (some users may want to even do machine-specific derived containers); in this path we could theoretically just have inst.bootc=quay.io/exampleos/blah
• More important: Things around tracker: logically bound app images containers/bootc#128 - also relates to anaconda flatpak bits

And here, this uses bootc install-to-filesystem; Anaconda takes care of initializing the filesystem tree, but otherwise just executes the container to do the install.

Crucially in the bootc install flow, it's actually the container that installs the bootloader to the target disk, not Anaconda.

Other higher level goals

Implementation goals

Implementing this is mostly:

• Add podman to the ISO
• Kickstart verb glue
• bootc expands to podman run --privileged --pid=host --net=none --security-opt label=type:unconfined_t <image> per the doc

Of course, one thing we could do is add generalized support for pulling and executing a container...basically do an install like this:

%post --no-chroot
podman run ...

But, that has a few downsides around ergonomics, fragility, etc.

[cgwalters]

xref https://gitlab.com/CentOS/cloud/sagano which would use this

[akdev1l]

Hi everyone,

I work on the installer ISOs for theUniversal Blue project and we’ve had issues on creating offline installer images for ostree container native systems due to limitations in the ostreecontainer verb. I would like to make sure we can get support for offline installation with the new bootc capabilities.

The current implementation of the ostreecontainer verb does not allow us to set the —target-imgref correctly so we’ve had to resort to hacks (rebasing on first boot) to work around this limitation (ref: ostreedev/ostree-rs-ext#512).

I’m not sure what this would mean for the bootc implementation. I imagine we would put the container archive in the ISO and pull from there similar to how the ostree repo is embedded in existing Silverblue images.

As a side note I was going to try to craft a patch to add this support to the ostreecontainer verb but it’s clear bootc switch the way of the future so not sure if such patch would be accepted - if so I will create a separate issue for that.

[cgwalters]

I'm sure we could get a patch merged that added better support for --target-imgref to the ostreecontainer verb!

But yes, would like to move in the bootc direction overall.

[jkonecny12]

I was already asked for support of --target-imgref, however, we are right now blocked by Anaconda doesn't support --imgref but only the split version (which I think is correct), however, that the split version doesn't exists for --target-imgref so without ostree-rs-ext support this doesn't fit well.
@achilleas-k

However, I see focus on the bootc would change this.

[cgwalters]

BTW an important detail in this is that bootc will own installing the bootloader (via bootupd by default) which also means that using bootc should automatically turn off anaconda's bootloader installation.

[fabiendupont]

Would there be other options than --to-filesystem or could it be an implicit destination?

[cgwalters]

Sorry yes this needs to be fleshed out more. Here's my thoughts: We want to support two modes:

• Anaconda defines the partitioning setup: If the kickstart has any partitioning at all this automatically switches the bootc install invocation to use install-to-filesystem
• The container defines the partitioning: This is IMO a cool part of this; say I want to install a RHEL system but I want to use fscrypt/fsverity which is only supported by ext4 today in RHEL9. In my container build, I just add a drop-in /usr/lib/bootc/install/50-mycustom.conf that sets root-fs-type = "ext4". A big point of this is that the "source of truth" becomes the container image, not the kickstart.

And what may be even cooler I think is a third model:

• Anaconda knows to look for /usr/lib/bootc/install-anaconda/inst.ks which contains arbitrary kickstart setup

[jkonecny12]

Hi @cgwalters thanks for all the information. I just want to clarify I understand it correctly.

So it means that we need to support 3 modes?

• with --to-filesystem where we do the partitioning and run bootc to install the bootloader stuff
• without --to-filesystem where we can't do partitioning and bootc call will handle everything
• where we would look for the kickstart inside the container which would be basically merging of the kickstart files

All these will skip the bootloader installation by Anaconda.

Am I correct @cgwalters ?

[cgwalters]

That's what I'm thinking, but of course this is a collaborative thing. I'd say probably the most important short term is supporting the first one because it will fix bootloader updates in general and help align things.

[cgwalters]

One thing I hope we can fix as we do this is e.g. ostreedev/ostree#3193 - the bootc install flow just uses kernel arguments for the rootfs and I think this is ultimately the right thing.

[cgwalters]

So recently we've done quite a lot in bootc (layered on top of ostree) and in the current situation none of those features will apply.

For example the kernel argument support.

But even more recently we're switching bootc to support logically bound containers

[cgwalters]

To xref I am working on containers/bootc#915 which will end up working around this.

[cgwalters]

Thinking about this more. First let's assume we have podman in the Anaconda ISO.

A core problem to solve is pulling the container image.

Let's assume that this phase happens after the target filesystem is created. One option I think would be viable is to always create a temporary swap file on that filesystem. Alternatively, pull that image to a temporary place on the target FS (e.g. podman run --root=/mnt/sysimage/var/tmp/anaconda-podman <image>).

The basic idea either way is to avoid the "running from RAM" penalty - and also in the bootc case, we could in theory optimize this to avoid writing the OS files twice by using reflinks (also xref containers/storage#1849 ).

This would greatly help in the implementation of a bootc install to-filesystem backend for Anaconda.

However one thing that would be significantly cleaned up here is if bootc itself offered a way to spawn code running against the target root after bootc install to-filesystem is complete. Right now Anaconda has a bunch of hand-crafted container stuff and ideally the %post verb when executing against a bootc target had a proper setup (w/composefs in particular).