Distribution for the installer

[ondrejbudai]

We build the installer from scratch, and thus we need to know which distribution and repositories (there are distribution-specific quirks for installer) to build from. In the more distant future, I would like bootc-image-builder to use an installer from a container image, but is a completely new territory, and we simply don't have the time now to pursue this option short-term.

The current situation is: bootc-image-builder is based on Fedora 39, but the repositories used to build the installer are from Fedora ELN. People will certainly want to build Fedora 40 and Centos Stream 9 based installers.

I think we have the following options for fixing the situation:

1) Take the distribution from the bootable container

Currently, the containers are not labeled with a distribution ID at all. Thus, we probably need to crack-open the bootable container, and read this from /etc/os-release, that's fine. We have two options regarding repositories: Either, we can hard-code them in bootc-image-builder (that's how osbuild-composer does it), or we can read /etc/yum.repos.d from the bootable container.

This will get quite ugly with RHEL, because AFAIK /etc/yum.repos.d will be simply empty.

2) Take the distribution from the bootc-image-builder

The bootc-image-builder has /etc/os-release and matching /etc/yum.repos.d. The bib binary can just read these and assemble the installer based on its own distributions and repositories. It's probably quite simple to get RHEL working, because the RHEL bootc-image-builder will be RHEL-based.

However, this means that we have to start building bootc-image-builder based on each supported distribution, so people can build all installer versions. So at least fedora-38, fedora-39, fedora-40, fedora-eln and centos-stream-9. This explodes our testing matrix, while providing zero value for disk images. :/

3) Take the distribution as an argument

When building an installer, a user would have to specify from which OS they want the installer. Basically sudo podman [...] bootc-image-builder --type iso --distro fedora-40. In this case, bib would have to have all repositories hardcoded inside. This sucks, but at least we have just one container image (well... actually an upstream one, and a RHEL-based one, so two...)

---

I hate the option 3. I'm torn between 1 and 2. I think I slightly prefer number 2, but building multiple versions of bib gives me headaches...

Note that we need to resolve the discussion in order to fix #157

[achilleas-k]

How about a combination of 1 and 2? Read /etc/os-release from the container but keep repository configs for each supported distro in the bib container? Or read /etc/yum.repos.d from the container if available and fall back to built-ins?

[ondrejbudai]

I like this idea including the fallback. :)

[M4rtinK]

Just a note about the Anaconda installer - historically the installer team considered that installer from a given development branch (Rawhide, branched Fedora, RHEL 8, RHEL 9, etc.) will be built from content corresponding to the given branch (Rawhide, branched Fedora, RHEL 8, RHEL 9, etc.) and install content corresponding to the given branch.

This has been done to keep a sane support matrix during installer development and testing. Otherwise various issues could happen:

• RHEL N installer being required to install RHEL N+1 or modern Fedora content, potentially requiring costly extensive backports

• modern Fedora installer being able to install supported but old RHEL content, preventing features long unused in upstream from being removed from the upstream codebase (authconfig support for example)

• any new upstream feature would have to be extensively tested against all the existing RHEL content it would be expected to install

• the installation media content depends on whats in the repos for the given distro - RHEL 8 media use a metacity as X WM, while RHEL 9 & Fedora use gnome-kiosk + RHEL 10 a future Fedora will mostly likely use Wayland; if an Anaconda codebase would have to support all possible installation image configuration, it could also result in substantial code bloat as various WMs & both X and Wayland would have to be supported for ever

So if changing this status quo would appear necessary, it would be certainly something to be discussed with the installer team & installer QA. 🙂

[M4rtinK]

@jstodola @KKoukiou @jkonecny12

[ondrejbudai]

This implies that the first option is the only acceptable one from your point of view, right? I think that the solution proposed by Achilleas is well-aligned with this.

[cgwalters]

Right we're clearly going to follow the status quo of sticking with distro $major bound anaconda.

[jikortus]

I'd also think that the first option only makes sense (as explained by Martin), at least for now.

[cgwalters]

This will get quite ugly with RHEL, because AFAIK /etc/yum.repos.d will be simply empty.

Since we're building this in a containerized environment if the host is using entitled repositories we'll get those injected into the container.

[cgwalters]

I'd add an option 4: Take a buildroot container as input

IOW bootc-image-builder --format=iso --buildroot=quay.io/centos/centos:stream9 quay.io/examplecorp/my-custom-bootc-os - and we verify that the distribution major is the same for both.

[jkonecny12]

I wonder what is the benefit of this? Seems to me more prone to mistakes and harder to use.

[cgwalters]

To be clear I also think we should do 1&2 by default.

[cgwalters]

The centos-bootc originated images gained a redhat.id label recently (xref CentOS/centos-bootc#110 ) but...I think it's probably best to still look at /usr/lib/os-release in the image anyways, because in the end we know we need that input container image already pulled anyways.