Extend v1 EROFS to OCI and booting by cgwalters · Pull Request #297 · composefs/composefs-rs

cgwalters · 2026-05-22T20:17:35Z

Builds on #225

In a nutshell: I want to do a cutover to generating V1 EROFS (i.e. bit-for-bit compatible with the original https://github.com/composefs/composefs ). The rationale here is basically we want to be able to replace that project entirely in a compatible way and we need to support RHEL9 and our current EROFS ("v2") isn't compatible because we were implicitly relying on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ed50b8231e37b1ae863f5dec8153b98d9f389b4

Handling EROFS versions

In an OCI image splitstream, we can now generate and reference either or both versions. For new repositories, we default to v1. Apart from UKIs, we don't care about the binary checksum of the EROFS, so it's totally fine to just change what we do there. One can use composefs to fetch OCI images and mount them as before, and the fact the EROFS is different is largely invisible.

Sealed UKIs

However, we do care for sealed UKIs that have a checksum of the EROFS. A composefs= karg signals that V2 EROFS is used. A new composefs.digest= karg signals that V1 EROFS is used.

Conveniently, I'm also using this transition to get rid of the annoying kernel warning because presence of a . signals it's for userspace, as is the case here.

alexlarsson · 2026-05-28T11:41:52Z

I think it is important to get this in and I'll start reviewing more carefully it on monday. Which PR is the latest though? Should i just ignore #225?

Also, I'm not 100% sure about defaulting to v1, because the xattr think in v2 is likely to improve perfomance in significant ways.

cgwalters · 2026-05-28T12:11:57Z

Thanks Alex! This one is an extension of #225 - I think that one should go first.

The adapt-composefs-rs-api branch still has the old get_cmdline_composefs import which was renamed in PR composefs#297. Point CI at the updated bootc branch (pushed separately to avoid disturbing the existing branch's CI), which carries the necessary adaptations: - OCI image ref API changes (image_ref_v1/v2) - V1 karg format string updates - Dual V1+V2 EROFS image generation TODO: revert to main once bootc-dev/bootc merges these adaptations. Assisted-by: OpenCode (Claude Sonnet 4.6) Signed-off-by: Colin Walters <walters@verbum.org>

cgwalters · 2026-06-08T13:05:23Z

+    ///
+    /// Returns an error if a matching karg is found but the hex digest cannot be parsed
+    /// for the given `ObjectID` type.
+    pub fn from_cmdline(cmdline: &str) -> Result<Option<Self>> {


TODO: unify with bootc karg parsing

jeckersb

Didn't review thoroughly but an AI-assisted review was mostly pointing out issues in the kargs parsing which I had already raised in a live call yesterday and we have a plan to remedy over in #180 so I'm not too worried about that for now.

cgwalters · 2026-06-09T21:49:49Z

Investigating the bootc revdep CI failure here.

cgwalters · 2026-06-12T09:36:08Z

OK! This one is finally passing the bootc revdep, should be good to go

Migrate OCI crate callers to the new RepositoryConfig API and add dual-format (V1+V2) EROFS image generation during OCI pull. The V1 kernel cmdline karg uses a new self-describing format: composefs.digest=v1-sha256-12:<hex> composefs.digest=v1-sha512-12:<hex> The value encodes the EROFS format version, hash algorithm, and block size before the digest, mirroring how meta.json uses fsverity-sha256-12. The stable key name composefs.digest works naturally with ConditionKernelCommandLine= and allows multiple entries on the same cmdline for different algorithm/format combinations. The initramfs (composefs-setup-root) parses all composefs kargs from the kernel cmdline in order, then tries to mount each image in sequence — the first image that actually exists in the repository wins. mount_composefs_image_if_exists() maps ImageNotFound to Ok(None), letting the mount loop skip missing images without swallowing real errors (verity mismatch, permissions, etc.). The legacy composefs=<hex> karg continues to work for V2 EROFS. Assisted-by: OpenCode (Claude Opus 4) Signed-off-by: Colin Walters <walters@verbum.org>

giuseppe

LGTM

cgwalters · 2026-06-12T10:38:31Z

OK one more tweak...I noticed the composers-boot logic wasn't handling multiple composefs=/composefs.digest arguments the same way bootc was. Now there's a shared helper.

cgwalters · 2026-06-12T15:00:35Z

@giuseppe this repo is configured so that pushes to a PR invalidate previous approvals (we're conservative)

giuseppe

LGTM

alexlarsson · 2026-06-15T12:06:35Z

I worry about the kernel command line length with this. The docs say:

The number of kernel parameters is not limited, but the length of the complete command line (parameters including spaces etc.) is limited to a fixed number of characters. This limit depends on the architecture and is between 256 and 4096 characters. It is defined in the file ./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.

And, in the automotive space we've definitely had issues with such limits. For example, android boot is limited to 511 bytes of commandline. We do currently when producing such images use "bootconfig" to move options into the kernel binary itself, which would fix this. However, it may make sense, to ensure (while we have the chance) that the commandline is not unnecessary long, by e.g. using (or at least optionally supporting) a base64 encoded digest intead of a hex one.

cgwalters · 2026-06-22T18:57:45Z

I worry about the kernel command line length with this.

Yeah, good point. I think what we could do is add support for looking up the digest from e.g. /usr/lib/composefs/rootfs.[json|toml|bikeshed] or so.

It'd be relatively straightforward to change bootc container ukify to instead inject that file into the initramfs.

It'd be a good idea to land support for this soon, then we can more reasonably cut over late.

We do currently when producing such images use "bootconfig" to move options into the kernel binary itself, which would fix this.

Hmm...that's a thing we could also do when generating a UKI too right? Do options injected that way show up in /proc/cmdline?

alexlarsson · 2026-06-23T08:46:22Z

@cgwalters Yes, these options work like normal in e.g. /proc/cmdline. The only weakness is that some commandline options are read very early by the kernel before the boot config data has been read. What we do is extract a subset of options (https://gitlab.com/CentOS/automotive/src/aboot-deploy/-/blob/main/aboot-update.c?ref_type=heads#L126) and extract only these as the main commandline, and then we dump the rest in a file, and use bootconfig -a $the_file $the_initrd to append the remaining options to the initrd.

In the end, it uses this: https://docs.kernel.org/admin-guide/bootconfig.html

alexlarsson · 2026-06-23T08:48:44Z

Hmm, actually I'm not sure they will be in /proc/cmdline, there seems to be a /proc/bootconfig thing instead...

cgwalters marked this pull request as draft May 22, 2026 20:17

cgwalters force-pushed the composefs-c-compat-oci-and-booting branch 2 times, most recently from a1e48b7 to c87fe17 Compare June 5, 2026 22:22

cgwalters marked this pull request as ready for review June 5, 2026 22:23

cgwalters force-pushed the composefs-c-compat-oci-and-booting branch from c87fe17 to 7c55c75 Compare June 7, 2026 22:58

cgwalters commented Jun 8, 2026

View reviewed changes

cgwalters requested a review from jeckersb June 8, 2026 18:12

cgwalters mentioned this pull request Jun 8, 2026

Mitigate generics #159

Open

jeckersb previously approved these changes Jun 9, 2026

View reviewed changes

cgwalters marked this pull request as draft June 9, 2026 21:49

cgwalters dismissed jeckersb’s stale review via 6ab3518 June 12, 2026 01:28

cgwalters force-pushed the composefs-c-compat-oci-and-booting branch 3 times, most recently from 953ac7b to d5470ef Compare June 12, 2026 09:35

cgwalters requested review from alexlarsson and giuseppe June 12, 2026 09:35

giuseppe previously approved these changes Jun 12, 2026

View reviewed changes

cgwalters dismissed giuseppe’s stale review via 23ca9c0 June 12, 2026 10:33

cgwalters force-pushed the composefs-c-compat-oci-and-booting branch from d5470ef to 23ca9c0 Compare June 12, 2026 10:33

cgwalters marked this pull request as ready for review June 12, 2026 10:37

cgwalters mentioned this pull request Jun 12, 2026

Add support for multiple composefs= digests bootc-dev/bootc#2248

Open

giuseppe approved these changes Jun 15, 2026

View reviewed changes

giuseppe added this pull request to the merge queue Jun 15, 2026

Merged via the queue into composefs:main with commit 0ea5d52 Jun 15, 2026
18 checks passed

travier mentioned this pull request Jun 24, 2026

Support replacing composefs/composefs #323

Open

Uh oh!

Conversation

cgwalters commented May 22, 2026

Handling EROFS versions

Sealed UKIs

Uh oh!

alexlarsson commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgwalters commented May 28, 2026

Uh oh!

cgwalters Jun 8, 2026

Choose a reason for hiding this comment

Uh oh!

jeckersb left a comment

Choose a reason for hiding this comment

Uh oh!

cgwalters commented Jun 9, 2026

Uh oh!

cgwalters commented Jun 12, 2026

Uh oh!

giuseppe left a comment

Choose a reason for hiding this comment

Uh oh!

cgwalters commented Jun 12, 2026

Uh oh!

cgwalters commented Jun 12, 2026

Uh oh!

giuseppe left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexlarsson commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cgwalters commented Jun 22, 2026

Uh oh!

alexlarsson commented Jun 23, 2026

Uh oh!

alexlarsson commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

alexlarsson commented May 28, 2026 •

edited

Loading

alexlarsson commented Jun 15, 2026 •

edited

Loading