Eliminate livecd-tools from RHEL/fedora images

[jmpolom]

Kairos version:
Affects any image built from the Dockerfile at images/Dockerfile.kairos-rhel (see line 50)

CPU architecture, OS, and Version:
I tested on x86_64 with the quay.io/kairos/fedora:40-core-amd64-generic-master image

Describe the bug
The inclusion of the livecd-tools package pulls in a bunch of python dependencies and other utilities such as xorriso and lorax. The necessity of these in a minimal base image designed for downstream re-use is entirely unclear to me. The image variants based on other variants such as Tumbleweed and Debian do not include similar distro specific live image tooling.

I'm unable to trace the dependency of this package to a kairos component, but if that is the case it needs to be documented somewhere but currently doesn't appear to be (assume it isn't required). Extraneous software should be considered a bug in base images.

To Reproduce
Examine the image

Expected behavior
A truly lean and minimal base image

Logs

Additional context

[jmpolom]

Yes, the more I've looked at this I believe there is a fundamental problem with the package selection in the fedora image. Weak deps are turned off but things like systemd-udev (critical dependency for a booting system) aren't specified. There are also some issues with the image build process in the Dockerfile as well since dracut is included for the grub image but nothing is specified for systemd-boot (dracut would be needed regardless). Happy to send a PR with some corrections if it would be welcomed?

[jimmykarily]

Sure @jmpolom , if there is a cleanup needed, feel free to open a PR. Maybe there are packages that are no longer needed in there. Thanks!

[Itxaka]

umm under systemd-boot the dracut package should not be needed as that its the path for UKI in which we construct the initrd ourselves, so dracut is not used.

systemd-udev is a hard dep of systemd no? If so it will be brought automatically, even if weak deps are turned off

lievecd-tools may indeed not be needed.

[jmpolom]

umm under systemd-boot the dracut package should not be needed as that its the path for UKI in which we construct the initrd ourselves, so dracut is not used.

Can you point me to where UKI generation happens? I didn't obviously see it in any of the Dockerfiles I've looked at.

systemd-udev is a hard dep of systemd no? If so it will be brought automatically, even if weak deps are turned off

This is what you might imagine however systemd-udev is not a required dep for systemd itself. It looks like dracut or systemd-oomd-defaults would be the most likely candidates to bring it in. It should instead be specified directly especially if dracut won't always be in the package selection.

Does anyone know why livecd-tools was added to the image? I really cannot fathom a purpose to have it in a minimal base image but I also don't know the origins of this fedora based kairos image.

[Itxaka]

umm under systemd-boot the dracut package should not be needed as that its the path for UKI in which we construct the initrd ourselves, so dracut is not used.

Can you point me to where UKI generation happens? I didn't obviously see it in any of the Dockerfiles I've looked at.

in the Dockerfiles, its the systemd-boot targets. So for example here: https://github.com/Itxaka/kairos/blob/master/images/Dockerfile.rhel#L82

Its a bit of a maze, maybe @mauromorales can shed some ligth on it as our local docker expert :D

systemd-udev is a hard dep of systemd no? If so it will be brought automatically, even if weak deps are turned off

This is what you might imagine however systemd-udev is not a required dep for systemd itself. It looks like dracut or systemd-oomd-defaults would be the most likely candidates to bring it in. It should instead be specified directly especially if dracut won't always be in the package selection.

oh wow.

Does anyone know why livecd-tools was added to the image? I really cannot fathom a purpose to have it in a minimal base image but I also don't know the origins of this fedora based kairos image.

no idea no, might be because we needed some stuff that came with it or we used to build isos differently at the start? IMHO we can try to drop it doesnt look like we ever used to me.

[jmpolom]

in the Dockerfiles, its the systemd-boot targets. So for example here: https://github.com/Itxaka/kairos/blob/master/images/Dockerfile.rhel#L82

I saw that when going through the Dockerfile and it looks like a no-op build stage essentially as nothing special is done to that image besides not including the grub portions installed in the grub section above.

The ubuntu image has a bit more but still doesn't really look like a complete and functioning solution? I looked through the Earthfile and only saw hints at a "start" for building UKI:

kairos/Earthfile

Line 343 in 0f349d7

## UKI Stuff Start

Are UKI artifacts currently being built anywhere and available for testing? I assume the ISOs available on the release page are not UKI based?

[Itxaka]

in the Dockerfiles, its the systemd-boot targets. So for example here: https://github.com/Itxaka/kairos/blob/master/images/Dockerfile.rhel#L82

I saw that when going through the Dockerfile and it looks like a no-op build stage essentially as nothing special is done to that image besides not including the grub portions installed in the grub section above.

The ubuntu image has a bit more but still doesn't really look like a complete and functioning solution? I looked through the Earthfile and only saw hints at a "start" for building UKI:

kairos/Earthfile

Line 343 in 0f349d7

## UKI Stuff Start

Are UKI artifacts currently being built anywhere and available for testing? I assume the ISOs available on the release page are not UKI based?

yeah basically uki artifacts are base artifacts minus grub packages to keep them ligth. In some cases a few small; tools are added for management, like bootctl and such.

We mainly test ubuntu as it was the only one that covered what we needed and was going to be tested and used as a demo, so mostly our support was on there.

Artifacts are published along our normal containers with the -uki suffix, so for example quay.io/kairos/ubuntu:24.04-core-amd64-generic-v3.2.3-uki

there is also Fedora uki artifacts but those are less tested as we dont have anyone testing real deployments on them :D

Isos are useless if published under UKI as the point of UKI is trusted boot, which measn signing the artifacts with your own keys and enrolling those in the EFI firmware on the first boot to lock down the system, so we dont publish other than the base artifacts. So you need to build your your own uki artifacts always to make sense 👍 You can have a look at the Trusted boot pages for mor info

https://kairos.io/docs/architecture/trustedboot/
https://kairos.io/docs/installation/trustedboot/

[jmpolom]

That is helpful information. Is auroraboot then building the initrd when it composes the UKI? I was mainly interested in seeing where the initrd gets built for the UKI path if it is not using the distro provided initrd build tooling (dracut/mkinitramfs/etc, as mentioned above).

[Itxaka]

That is helpful information. Is auroraboot then building the initrd when it composes the UKI? I was mainly interested in seeing where the initrd gets built for the UKI path if it is not using the distro provided initrd build tooling (dracut/mkinitramfs/etc, as mentioned above).

yes, its aurora: https://github.com/kairos-io/AuroraBoot/blob/main/internal/cmd/build-uki.go#L508

What we basically do is, because we want a single UKI image with no separated initramfs and rootfs, we bundle the whole system into a "initramfs" with immucore as the init process. This allows us to setup the system as dracut would do but remount the current initramfs root as rootfs and exec systemd. So we do the initramfs -> rootfs inplace. That way, the whole system is measured for trusted boot, and data partitions (RW ones, so oem and persistent) are encrypted and only unlocked if the measurements of the system match.