bib: add support for `--type bootc-installer` #1094

mvo5 · 2025-10-29T15:22:26Z

This commit adds support for the new bootc-installer image
type that will take a bootc container and create an ISO out
of it. It also adds a new --installer-payload-ref option
so that the user can specify a different payload container
to install.

See osbuild/images#1906 for details.

This is the equivalent of
osbuild/image-builder-cli#341
for bootc-image-builder and allows us to build these kinds
of images with bib now too.

/jira-epic HMS-8839

mvo5 · 2025-10-29T17:00:29Z

test/test_build_iso.py

        assert "usr/bin/bootc" in output
+
+
+@pytest.mark.skipif(platform.system() != "Linux", reason="boot test only runs on linux right now")


Note that this build/boot test would ideally live in "images" but we don't have the infra there yet for this kind of local qemu tests.

supakeen · 2025-10-30T05:45:44Z

README.md

 | `vmdk`                | [VMDK](https://en.wikipedia.org/wiki/VMDK) usable in vSphere, among others            |
-| `anaconda-iso`        | An unattended Anaconda installer that installs to the first disk found.               |
+| `bootc-installer`     | An installer ISO image based on the specified bootc container image.                  |
+| `anaconda-iso`        | (legacy) an unattended Anaconda installer that installs to the first disk found build from RPMs. |


I don't think this is legacy yet? Does any project currently publish installer containers?

Thanks, I'm happy to revert this again. In my head it is already legacy but maybe I'm a bit (too) quick with jumping to this. I will let @ondrejbudai chime in here :)

Yeah it probably can't be legacy yet.

It also adds a new --installer-payload-ref option
so that the user can specify a different payload container
to install.

As far as the mechanics...I think it (almost) never makes sense for one to install this installer container (today). Feels like the target image should be a required positional argument (do we have the ability to do that?)

I tend to agree that if I were using this I'd expect to have to pass two containers always with a stretch goal of passing only the payload (to-be-installed) container which then automatically gets derviced.

Embedding of the payload container would become optional once anaconda gains its bootc verb, the remote would still need to be passed but we can put embedding behind a flag (smaller ISO for deployment environments with network).

@cgwalters since you're here now; are there already issues tracking the building of a 'base installer' container for Fedora and/or CentOS?

@cgwalters since you're here now; are there already issues tracking the building of a 'base installer' container for Fedora and/or CentOS?

Not that I know of, we could definitely add something like this in fedora-bootc.

But it's a bit complex because that'd add another variable in all of this. The way I was thinking of this is we just document how to add Anaconda as a layer on top of one's image - this means it naturally carries all configuration from the base (including critical stuff like kernel + kargs + injected 3rd party drivers in /usr/lib/modules etc.)

If we shipped a pre-built installer container...hmm, well I guess it would work equally well really (maybe sometimes better even?) to have users do a matrix build where they do two builds, one FROM <golden installer image> and one that generates their target.

Hmm. I guess an intermediate thing we could do here is add bootc-base-imagectl --anaconda, before shipping it as a prebuilt image.

Sure thing, I can look into this tomorrow.

@cgwalters since you're here now; are there already issues tracking the building of a 'base installer' container for Fedora and/or CentOS?

Not that I know of, we could definitely add something like this in fedora-bootc.

But it's a bit complex because that'd add another variable in all of this. The way I was thinking of this is we just document how to add Anaconda as a layer on top of one's image - this means it naturally carries all configuration from the base (including critical stuff like kernel + kargs + injected 3rd party drivers in /usr/lib/modules etc.)

If we shipped a pre-built installer container...hmm, well I guess it would work equally well really (maybe sometimes better even?) to have users do a matrix build where they do two builds, one FROM <golden installer image> and one that generates their target.

Mmm, sure that's right; the question is if any of that configuration is going to interfere with Anaconda's operation, it can be picky about its environment. Only one way to find out :)

We'll definitely need to document and standarize on the bootc documentation pages how these types of containers should be built and that it should be the default way of building installers in bootc-land?

I removed the part about the deprecation.

lzap

There is the workaround that can be removed.

lzap · 2025-11-03T08:09:44Z

test/test_build_iso.py

+    # can update images/ to set the correct efi_src_dir and this can
+    # be removed
+    # see also https://bugzilla.redhat.com/show_bug.cgi?id=1750708
+    RUN dnf reinstall -y shim-x64


Since osbuild/osbuild#2202 is merged, this can be removed now.

Let me update the comment, sadly its more complicated, see osbuild/osbuild#2205

The NewAnacondaContainerInstaller got renamed to NewAnacondaContainerInstallerLegacy.

This commit adds support for the new `bootc-installer` image type that will take a bootc container and create an ISO out of it. It also adds a new `--installer-payload-ref` option so that the user can specify a different payload container to install. See osbuild/images#1906 for details. This is the equivalent of osbuild/image-builder-cli#341 for bootc-image-builder and allows us to build these kinds of images with bib now too.

Add an integration test that uses the new `bootc-installer` image type to perform a full install and validate that booting into the resulting image works.

mvo5 requested a review from a team as a code owner October 29, 2025 15:22

mvo5 requested review from achilleas-k, croissanne and supakeen and removed request for a team October 29, 2025 15:22

mvo5 force-pushed the bootc-installer-image-type branch 2 times, most recently from 3bcac31 to 4359aea Compare October 29, 2025 16:54

mvo5 commented Oct 29, 2025

View reviewed changes

supakeen previously approved these changes Oct 30, 2025

View reviewed changes

supakeen reviewed Oct 30, 2025

View reviewed changes

mvo5 dismissed supakeen’s stale review via 2f6ea26 October 30, 2025 12:02

mvo5 force-pushed the bootc-installer-image-type branch from 4359aea to 2f6ea26 Compare October 30, 2025 12:02

mvo5 changed the title ~~bib: add support for `--type bootc-installer~~ bib: add support for --type bootc-installer Oct 30, 2025

supakeen previously approved these changes Oct 31, 2025

View reviewed changes

lzap requested changes Nov 3, 2025

View reviewed changes

mvo5 added 5 commits November 4, 2025 12:34

go.mod: move to images v0.211.0

514844c

bib: update for v0.211 api change

0352132

The NewAnacondaContainerInstaller got renamed to NewAnacondaContainerInstallerLegacy.

test: fix missing wait() when killing qemu

4989e0f

test: add bootc-installer image type test

f8b67b4

Add an integration test that uses the new `bootc-installer` image type to perform a full install and validate that booting into the resulting image works.

mvo5 dismissed supakeen’s stale review via f8b67b4 November 4, 2025 11:35

mvo5 force-pushed the bootc-installer-image-type branch from 2f6ea26 to f8b67b4 Compare November 4, 2025 11:35

supakeen mentioned this pull request Nov 5, 2025

Add support for iso #433

Open

		assert "usr/bin/bootc" in output


		@pytest.mark.skipif(platform.system() != "Linux", reason="boot test only runs on linux right now")

bib: add support for --type bootc-installer #1094

Are you sure you want to change the base?

bib: add support for --type bootc-installer #1094

Uh oh!

Conversation

mvo5 commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

supakeen Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

supakeen Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lzap left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bib: add support for `--type bootc-installer` #1094

bib: add support for `--type bootc-installer` #1094

mvo5 commented Oct 29, 2025 •

edited

Loading

supakeen Oct 30, 2025 •

edited

Loading

supakeen Oct 30, 2025 •

edited

Loading