-
Notifications
You must be signed in to change notification settings - Fork 14
Description
When we build the container image for the UKI case, we measure the content of the container to get the composefs hash, and then we add this hash to the UKI kernel command line. Then we need to place the resulting UKI somewhere in the container image. The build flow looks like below:
FROM bootc:latest as base
# Your changes here
FROM base as uki-build
RUN --mount=type=bind,from=base,target=/mnt/base <<EOF
dnf install <tools to build the uki>
# Measure the content of the base container, doing SELinux labeling
COMPOSEFS_FSVERITY="$(cfsctl --repo /tmp/sysroot compute-id --bootable /mnt/base)"
build-uki-command --command-line="... $COMPOSEFS_VERITY ..." --output=/uki
EOF
FROM base as final
COPY --from=uki-build /uki <DESTDIR>
Then, when the container image gets pulled into a system, cfsctl/bootc will generate the composefs image but this time from the container final image. Thus anything that changed in the last step of the build will change the hash of the image, unless we explicitly ignore it when building the composefs image.
This means that if we are putting the UKI in /usr/lib/modules/$UNAME/uki.efi
(following the recommendations from https://uapi-group.org/specifications/specs/unified_kernel_image/#locations-for-distribution-built-ukis-installed-by-package-managers) then it will change the mtime of the /usr/lib/modules/
directory, which will change the hash of the composefs image. And there is no easy way to know after the fact what the "correct" mtime should be.
One way this is worked around right now is that we ignore the content of /boot
and reset its timestamp to 0. This means that we should be able to put anything in /boot
and have it ignored. This is however not ideal as this is "implicit".
Maybe we should make an implicit /.composefs-ignored
directory instead that would hold content that is not taken into account when generating the image.