Extend v1 EROFS to OCI and booting#297
Draft
cgwalters wants to merge 4 commits into
Draft
Conversation
Contributor
|
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. |
Collaborator
Author
|
Thanks Alex! This one is an extension of #225 - I think that one should go first. |
cgwalters
force-pushed
the
composefs-c-compat-oci-and-booting
branch
2 times, most recently
from
a1e48b7 to
c87fe17
Compare
Extract sub-second nanoseconds from PAX extension mtime headers. The tar-core crate only keeps the integer seconds; we now read the fractional part ourselves and populate st_mtim_nsec accordingly. Prep for V1 EROFS compatibility where nanosecond timestamps matter for bit-for-bit reproducibility with the C composefs implementation. Assisted-by: OpenCode (Claude Opus 4) Signed-off-by: Colin Walters <walters@verbum.org>
Add expected_v1_id and expected_v1_bootable_id fields to the ContainerImage test struct and pin values for all four fixture images. This extends the digest stability test to cover the V1 EROFS writer alongside the existing V2 coverage. Prep for the V1 EROFS OCI integration. Assisted-by: OpenCode (Claude Opus 4) Signed-off-by: Colin Walters <walters@verbum.org>
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>
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
force-pushed
the
composefs-c-compat-oci-and-booting
branch
from
c87fe17 to
7c55c75
Compare
cgwalters
commented
Jun 8, 2026
| /// | ||
| /// 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>> { |
Collaborator
Author
There was a problem hiding this comment.
TODO: unify with bootc karg parsing
jeckersb
approved these changes
Jun 9, 2026
jeckersb
left a comment
jeckersb
left a comment
Collaborator
There was a problem hiding this comment.
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.
Collaborator
Author
|
Investigating the bootc revdep CI failure here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 newcomposefs.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.