`--type bootc-installer` needs undocumented flags.

[korasino]

The public bootc-image-builder docs for bootc-installer are incomplete. bootc-image-builder build --help documents the flags, but README misses that bootc-installer needs both a build container and an installer payload ref.

For bootc-installer, bootc-image-builder build --help exposes::

--build-container
--installer-payload-ref

But the published docs still suggest the simpler single imgref flow, which leads to:

error: cannot build manifest: no installer payload bootc ref set

[AWildBeard]

Best I can tell (from the unit test] is that --installer-payload-ref is used to detail a bootc container that (?) installs the bootc container some how.

[korasino]

@AWildBeard yeah, thanks, it's actually explained in the image-builder CLI docs here.

[AWildBeard]

Ah! Thank you I was hunting for this. TBH I never would have thought to give that a second look (--bootc-installer-payload-ref and the image-builder docs) because I didn't relate that these things are the same/related!

[supakeen]

Sorry yes; I've been documenting this stuff on the image-builder side and not the bootc-image-builder side. There's another PR open with a bunch of things that will expand on this there: osbuild/image-builder-cli#462

I also wrote a blogpost about the bootc-installer image type: https://supakeen.com/weblog/installer-types-for-bootc/

Note that the bootc-installer image type was a bit of an in-between experiment and we're currently focused on the bootc-generic-iso image type which makes even less assumptions about what's in your container so it allows to build more than installers.

You can see some examples of that being used here: https://github.com/ondrejbudai/bootc-isos

Since we plan to eventually migrate bootc-image-builder into image-builder; I'll add a tiny blurb referring to the image-builder documentation once the above PR lands here.

[korasino]

Coolio thanks for those links, pretty useful. Cant't wait for the bootc-generic-iso image type then.

Such a great piece of software this is.

[jmpolom]

What is the point of this option if it is ultimately still going to be an anaconda installer? How is this not just duplication of the anaconda-iso option? How does this help with uptake of the native bootc install pathways?

[supakeen]

What is the point of this option if it is ultimately still going to be an anaconda installer? How is this not just duplication of the anaconda-iso option? How does this help with uptake of the native bootc install pathways?

This is true and is why I suggested to use bootc-generic-iso in my previous comment here. That type makes less assumptions about what's inside the installer-ref.

We need to do better with documentation here and steering people towards it but at the same time we're also trying to gather feedback from users on it before making it "the one way".

Historically we started out with anaconda-iso; which is built from RPMs fetched from the repositories inside the payload container as this is how things work(ed) in the ostree world. As things went on we wanted to ship the installation environment as a container as well, the initial version of this was bootc-installer which is badly named as it still assumes Anaconda to be present inside the container. We then made that more generic and landed on bootc-generic-iso which can be used to build most forms of ISOs (the earlier example links show Debian, Ubuntu, live images, etc).

What do you mean by your last question? Have bootc install support creating iso9660 directly?