Consider deriving from fedora-bootc

[cgwalters]

The Anaconda ISO has historically been built with lorax, and more recently osbuild.

One thing I'd love to see is support a spike on what it'd look like to build Anaconda as a bootc container image - and then the step of "create a live ISO" would be done via bootc-image-builder. I tried to create space for this in osbuild/bootc-image-builder#165

The "internal" benefit here is basically having the center of gravity shift more towards container images - the disk images are secondary. Superficially, Anaconda from a user PoV would remain the same to start.

But this technical change would start to make more obvious the road to a few valuable things:

• As a customer who wants to create a bootc image with a custom kernel (for hardware enablement etc.) today precisely because the Anaconda ISO isn't built as a container but in an "osbuild way" inside bootc-image-builder, I can't literally just do FROM <mycustom image> RUN dnf -y install anaconda or so, but I'd also need to ensure that my custom kernel is provided as an RPM input to the bootc-image-builder process. The deep division between the two build systems is obvious here.
• It'd suddenly make it more obvious that we should support podman run --privileged quay.io/fedora/anaconda ... - and especially if we made it support takeover installs it'd be a quite flexible new way to do "reimaging" of systems, using Anaconda without dropping to rebooting into an ISO, etc. (Some of this may be possible of course today by just dnf -y install anaconda, I haven't tried, but running from a container is nicer I think for this)
• It'd be a great forcing function for us to generalize the case of "build a generic Live ISO" that we definitely want for a ton of use cases (as exists today for Fedora CoreOS but also the desktop Live ISOs etc.)

[jkonecny12]

I wonder, how would this work with our Dracut modules we need to have to make boot working. I'm not aware of Dracut modifications support for bootc. Is this possible?

[cgwalters]

https://docs.fedoraproject.org/en-US/bootc/initramfs/

[bam80]

The Anaconda ISO has historically been built with lorax, and more recently osbuild.

Sorry could you give more info about the transition happened?
For what Lorax is still used, and for what (and since when) osbuild is?

I reported a bug for Lorax and now wondering what other projects are relevant, too?

[jkonecny12]

The whole situation is a chaotic, Lorax is still used, however it depends on the delivery target:

• Lorax is currently used for boot.iso (everywhere)
• Kiwi is newly used for some Live ISOs including spins on Fedora, however, the goal is to take over all boot.iso + Live ISO
• Image Builder is used mainly for bootc ISOs but also for on demand builds for RHEL

So as you can see, lorax is still used but a lot of tools are involved together which makes the situation quite chaotic and problematic. Also, we are not involved in any of the tools, so if you want a change, you need to contact them directly.

[cgwalters]

Did you see this bit in my initial comment?

One thing I'd love to see is support a spike on what it'd look like to build Anaconda as a bootc container image - and then the step of "create a live ISO" would be done via bootc-image-builder. I tried to create space for this in osbuild/bootc-image-builder#165

I have to emphasize the deep importance of the split between "container image" and "disk image". They are not the same thing. This proposal is about creating quay.io/fedora/anaconda:rawhide or so. The step of making an ISO from it should operate on that container image.

A different but important way to say this is that as someone who wants to e.g. test a patch to Anaconda, I can do so via podman build to make a derived container image FROM quay.io/fedora/anaconda:rawhide. Then I can pass it to a tool (such as bootc-image-builder) to materialize my custom container into an ISO.

In this process the tester/contributor can leverage their container (and bootc) knowledge and does not need to learn Kiwi XML or other things.

[cgwalters]

I filed https://issues.redhat.com/browse/RHEL-89177 as a downstream issue to try to better illustrate again what problem(s) I'm talking about.

[cgwalters]

@travier shared https://github.com/travier/fedora-kinoite/blob/main/fedora-kinoite-live/Containerfile

[p5]

To build on this, Universal Blue has started investing in Live ISOs built from our bootc images.
We are pushing test ISOs with an in-house installer, though from looking at Timothée's repo, it seems very easy to switch over to anaconda once bootc is better supported.

Right now, we aren't bundling the installer inside the OCI, but rather splatting the OCI contents into a squashfs and dnf installing the installer (along with the other live ISO requirements) on that image. We then push the OCI image into an overlay containers-storage inside that squashfs which bootc can install to-disk or to-filesystem from.

[jkonecny12]

Just for information, we are just now working on support for bootc kickstart command.