[WIP] many: switch to bootc based anaconda (away from rpm) (HMS-9392)

[mvo5]

[build on top of https://github.com//pull/1058, much improved version of https://github.com//pull/1053 with support for "legacy" rpm based image types]

This spike show how we could use bootc based containers with anaconda. So instead of building our iso from rpm packages and just putting the bootc container into the rpm generated ISO this spike builds the ISO from a bootc container.

This requires that the container has the right content of course (i.e. anaconda). We would move some of the responsibility to the user (or to a tool that helps the user and hides the complexity here like bootc-iso-imagectl or something) to ensure that.

The Containerfile to generate an installer looks something like:

FROM {container_ref}
RUN dnf install -y \
     anaconda \
     anaconda-install-env-deps \
     anaconda-dracut \
     dracut-config-generic \
     dracut-network \
     net-tools \
     squashfs-tools \
     grub2-efi-x64-cdboot \
     python3-mako \
     lorax-templates-* \
     biosdevname \
     prefixdevname \
     && dnf clean all
# shim-x64 is marked installed but the files are not in the expected
# place for https://github.com/osbuild/osbuild/blob/v160/stages/org.osbuild.grub2.iso#L91, see
# workaround via reinstall, we could add a config to the grub2.iso
# stage to allow a different prefix that then would be used by
# anaconda.
# once https://github.com/osbuild/osbuild/pull/2202 is merged we
# can update images/ to set the correct efi_src_dir and this can
# be removed
RUN dnf reinstall -y shim-x64
# lorax wants to create a symlink in /mnt which points to /var/mnt
# on bootc but /var/mnt does not exist on some images.
#
# If https://gitlab.com/fedora/bootc/base-images/-/merge_requests/294
# gets merged this will be no longer needed
RUN mkdir /var/mnt

this basic template works for cs9,cs10,f42 (Note that the goal here is to essentially remove all quirks
and hide them in images/, ideally the containerfile would be just a "FROM \ndnf install anaconda...").

This branch also has a "--installer-payload" switch so to use this one would essentially write: bib --type iso --installer-payload quay.io/centos-bootc/centos-bootc:stream9 quay.io/centos-bootc-anaconda:stream9 (as currently the containerfile changes things like /root which makes it no longer a proper bootc container). We could of course explore making this more user friendly, either by a convention like "suffix -installer" for type iso or by creating a derrived constainer locally ourselfs with the above containerfile or helper or by fixing the issues that require /root to be a real dir (but even with that it would probably be undesired to install a container that contains a full anaconda env so something like installer-payload is probably still be needed).

Note that this is big departure from our current approach and we would need to think about a transition strategy/communication if we go down this route.

Thanks to Ondrej, Colin for their help/inputs in this, I hope it captures what they suggested to explore.

/jira-epic HMS-8839

JIRA: HMS-9392

[supakeen]

The links in the beginning are broken/wrong :)

[mvo5]

Running this locally:

======================== 3 passed in 1340.54s (0:22:20) ========================

:)

[cgwalters]

RUN dnf install -y \
     anaconda \
     anaconda-install-env-deps \
     anaconda-dracut \
     dracut-config-generic \
     dracut-network \
     net-tools \
     squashfs-tools \
     grub2-efi-x64-cdboot \
     python3-mako \
     lorax-templates-* \
     biosdevname \
     prefixdevname \

I commented on something related to this before but can someone (an the anaconda developer?) explain why this is not just dnf -y install anaconda-install-env-deps?

[elkoniu]

I commented on something related to this before but can someone (an the anaconda developer?) explain why this is not just dnf -y install anaconda-install-env-deps?

I think that anaconda-install-env-deps contains a really minimal set of tools needed only in the installation environment (live/netinst/DVD) and was created for the housekeeping purposes only.

Quoting spec

  240 %description install-env-deps                                                   
  241 The anaconda-install-env-deps metapackage lists all installation environment                                                                                                                                        
  242 dependencies. This makes it possible for packages (such as Initial Setup) to    
  243 depend on the main Anaconda package without pulling in all the install time     
  244 dependencies as well.

Maybe anaconda-install-img-deps would be a better candidate.

[mvo5]

I think this spike is at a point where it would be good to brainstorm/discuss in what direction we should do with regards of the Containerfile. I created https://github.com/orgs/osbuild/discussions/45 so that we can talk about we we want to expose it to our users (assuming we want to do that :) - I would especially appreciated the feedback from @cgwalters here of course.