Replies: 1 comment 1 reply
-
|
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? |
Beta Was this translation helpful? Give feedback.
1 reply
-
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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:
FROM <mycustom image> RUN dnf -y install anacondaor 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.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 justdnf -y install anaconda, I haven't tried, but running from a container is nicer I think for this)Beta Was this translation helpful? Give feedback.
All reactions