Skip to content

Where to place the UKI in the container or ignoring specific path when building the composefs image #131

@travier

Description

@travier

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions