Skip to content

many: bootc sealed images (composefs, and bootloader) (HMS-10628)#2326

Open
supakeen wants to merge 11 commits into
osbuild:mainfrom
supakeen:bootc-sealed
Open

many: bootc sealed images (composefs, and bootloader) (HMS-10628)#2326
supakeen wants to merge 11 commits into
osbuild:mainfrom
supakeen:bootc-sealed

Conversation

@supakeen
Copy link
Copy Markdown
Member

@supakeen supakeen commented May 9, 2026

This PR introduces support for bootc 'sealed' images. Sealed images use the composefs backend, together with a UKI, signed systemd-boot, and chain it all together to ensure only a trusted composefs is booted.

This has implications for how we deal with the disk images produced.

For starters; currently for bootc we can assume an image is sealed based on bootc container inspect returning if the kernel is unified. This then implies that the composefs backend must be used. It also implies that systemd must be used as the bootloader.

For the latter we expect the container to configure this and don't assume it based on the presence of a unified kernel.

For now I've called the boolean for this 'unified'. If in the future there comes a possibility where we want composefs to be standalone from sealed then we can split the boolean out.

This is only implemented for disk images, it is currently out of scope for ISO's and PXE images; for the latter we might want to error out when a unified kernel is detected in the container?

We skip all customizations in the pipeline if they touch the filesystem. We cannot adjust the filesystem that was created during the container build as its verity hashes are recorded in the UKI, the system will not boot if we modify the filesystem in any way.

Similarly we cannot accept any kernel argument customizations, including those in our own definitions, as they are encoded in the UKI at container build time.

For now these are silently ignored; we have no precedent for being able to deny customizations only after we've resolved content and I could only come up with bad ways to error out later.


Related: osbuild/image-builder-cli#506

@supakeen supakeen requested a review from a team as a code owner May 9, 2026 07:41
@supakeen supakeen requested review from avitova, croissanne and thozza May 9, 2026 07:42
@supakeen supakeen marked this pull request as draft May 9, 2026 07:42
@supakeen supakeen changed the title many: bootc sealed images (composefs, and bootloader) many: bootc sealed images (composefs, and bootloader) (HMS-10628) May 9, 2026
@supakeen supakeen force-pushed the bootc-sealed branch 2 times, most recently from a4d30e9 to 75682dd Compare May 12, 2026 05:57
@schutzbot
Copy link
Copy Markdown
Contributor

schutzbot commented May 12, 2026

A previous version of this PR changed the images API or behaviour causing integration issues with osbuild-composer.
This is now fixed.

@supakeen supakeen force-pushed the bootc-sealed branch 3 times, most recently from d21d693 to e3f7250 Compare May 13, 2026 11:49
supakeen added 11 commits May 15, 2026 07:21
New options were introduced to the `osbuild` stage in `osbuild` 180.
Let's make them available on the stage options so we can start making
use of them in `images`.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Run `bootc inspect` during the resolving of a container to assert if we
will need to set the `composefs-backend`. Currently this is implied when
the `unified` field is set to true on the kernel.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Generalize the `DefaultRootfs` function to return the entire install
configuration; we'll need more fields from it later.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
If the bootloader is available in the install configuration then we fill
it in on the bootc info struct so we can use it later to pass on the
appropriate value to the bootc install stage.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Store the newly resolved fields on the bootc distro so they can be used
by image types.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Propagate the new values from the bootc distro onto the bootc disk image
type.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Propagate the unified kernel and bootloader values all the way into the
pipeline generator. At this point they may be set on the options.
Unified Kernel Images cannot have custom kernel arguments in the current
setup. Let's not set them; no matter where they come from.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
When a sealed bootc container is being deployed to a disk image we
cannot touch any files on disk. Doing so would break the fs-verity hash
for the filesystem, which is embedded in the UKI's kernel command line.

Thus we skip all potential customizations that would touch the
filesystem.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
When a bootc container is unified there's no need to create a partition
table. It can be actively harmful if it is created with the wrong
filesystem type.

Disable the automatic creation of /boot, this only affects those
containers that have their rootfs set to btrfs (such as the Fedora
Atomic Desktops) where we normally automatically create a /boot.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Sealed images don't use bootupd; thus we don't need to inject a BIOS
partition on these. Let's not.

Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
@supakeen supakeen marked this pull request as ready for review May 15, 2026 06:05
@supakeen
Copy link
Copy Markdown
Member Author

I've opted to move the rest of the work here to follow-ups as they can be worked around in the container:

  1. Assign DPS UUIDs based on architecture #2337
  2. NewPartitionTable default filesystems #2336

This was discussed in: osbuild/image-builder-cli#506 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants