-
Notifications
You must be signed in to change notification settings - Fork 154
Add a composefs backend #1444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a composefs backend #1444
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces composefs as a new backend, which is a significant and extensive change. The new code paths for installation, upgrades, switching, and rollbacks for composefs are well-structured.
My review has identified a few issues, including a potential bug with a hardcoded transport value and an assert! that could lead to a panic. I've also included some suggestions for improving code style and robustness. Given this is a work-in-progress, these findings are not unexpected. Overall, this is a solid foundation for the new composefs functionality.
|
I'm going to rebase this. In the interest of preserving history I've saved a copy of the branch as composefs-branch-20250804 |
33e4511 to
7d596fe
Compare
|
OK at least this passes the existing tests. |
7d596fe to
d9b384d
Compare
|
I rebased 🏄 this again (and in the process reworked the composefs karg stuff to use the new kernel_cmdline |
|
OK I'd like to land #1525 and then rebase again |
828d837 to
1a7ac13
Compare
|
Rebasing on main ends up with a bunch of conflicts again. I was thinking about moving all composefs related code to separate files/crate to minimize conflicts |
|
Notes from meeting
|
|
@jeckersb before rebasing this would you mind also saving the existing branch? We've done that for the last few rebases |
54e254c to
f10ec34
Compare
|
Worth noting that I didn't do any of the squashing during the rebase, but at least with it clean we can easily decide which ones to squash out. |
f10ec34 to
67c4e8d
Compare
|
I'll be going ahead and rebasing again in prep for #1560 |
67c4e8d to
b45ef30
Compare
fd703ec to
023be10
Compare
|
rebased this again (saved the old one at |
|
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces significant new functionality for composefs support, including installation, upgrades, switching, and rollbacks. The changes are extensive, touching many parts of the codebase to accommodate composefs as an alternative to the existing ostree backend. New modules, data structures, and logic have been added to handle composefs-native systems.
The review has identified a few important issues. There's a high-severity bug where a hardcoded "docker" transport is used, which will prevent switching to images from other transports. Another high-severity issue is that a crucial finalization step (install_finalize) is skipped for composefs installations, potentially leaving them in an inconsistent state. Additionally, there are some medium-severity concerns regarding robustness against non-UTF8 paths and inconsistent use of std::fs versus cap_std for filesystem operations.
Overall, this is a great step towards composefs integration, and addressing these points will improve the correctness and robustness of the new functionality.
bda61be to
389a922
Compare
|
Rebased again. Only one conflict found Accepted both, and saved previous branch to |
ab51fe7 to
a718597
Compare
|
OK I rebased this, the conflict was from #1603 mainly. The resolutions were pretty straightforward. |
|
Previous branch is backed up at https://github.com/bootc-dev/bootc/tree/composefs-backend-2025-09-12 |
This adds a new off-by default feature to enable a new composefs-native backend for bootc. This is all still a live work in progress, but we're landing this first tranche of work to help avoid continual issues with rebasing. Thanks to everyone who worked on it! xref #1190 Co-authored-by: John Eckersberg <[email protected]> Co-authored-by: Robert Sturla <[email protected]> Co-authored-by: Colin Walters <[email protected]> Signed-off-by: Pragyan Poudyal <[email protected]>
a718597 to
8ac9eae
Compare
|
Rebased again. Saved the previous branch to Conflict found <<<<<<< HEAD
=======
#[clap(hide(true))]
#[cfg(feature = "docgen")]
Man(ManOpts),
#[cfg(feature = "composefs-backend")]
ComposefsFinalizeStaged,
>>>>>>> a7185978 (Add a composefs backend)resolved to #[cfg(feature = "composefs-backend")]
ComposefsFinalizeStaged, |
|
Weird, the |
|
Hmm...ugh. Looking... |
I was hitting a compliation error which *looks* like it was actaully an incremental compilation bug? Or it might have been rust-analyzer and local builds fighting over enabled features. Anyways, this ensures that we're gating on the composefs backend compiling. Signed-off-by: Colin Walters <[email protected]>
If we find UKI addons in the boot entries list, write them to ESP along with the UKI Signed-off-by: Pragyan Poudyal <[email protected]>
We don't need to write Grub menuentries for systemd-boot. For now the operation is a no-op, but later we would want to have .conf files in `ESP/loader/entries` so we can control the order of entries. Regarding that, we would also need to place the UKIs in a separate directory and not inside `ESP/EFI/Linux`, if we don't want duplicate entries, as systemd-boot will simply list all .efi files placed in EFI/Linux unconditionally Signed-off-by: Pragyan Poudyal <[email protected]>
|
OK after some auditing I think what happened is pretty simple, I probably forgot to |
|
Since I created this PR, I can't approve it; @jeckersb can you do so? |
jeckersb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥳
Add a comprehensive planning document for composefs integration that summarizes the current state and remaining work. The document covers the completed backend implementation (PR bootc-dev#1444), recent enhancements that made composefs the default, and outlines remaining work including fsverity upgrade paths, integrity verification, and testing gaps. This provides a roadmap for future composefs development and helps contributors understand the architecture and priorities. Signed-off-by: Ona <[email protected]> Co-authored-by: Ona <[email protected]>
Add a comprehensive planning document for composefs integration that summarizes the current state and remaining work. The document covers the completed backend implementation (PR bootc-dev#1444), recent enhancements that made composefs the default, and outlines remaining work including fsverity upgrade paths, integrity verification, and testing gaps. This provides a roadmap for future composefs development and helps contributors understand the architecture and priorities. Signed-off-by: Ona <[email protected]> Co-authored-by: Ona <[email protected]>
This adds a new off-by default feature to enable
a new composefs-native backend for bootc. This
is all still a live work in progress, but
we're landing this first tranche of work to help
avoid continual issues with rebasing.
Thanks to everyone who worked on it!
xref #1190
Co-authored-by: John Eckersberg [email protected]
Co-authored-by: Robert Sturla [email protected]
Co-authored-by: Colin Walters [email protected]
Signed-off-by: Pragyan Poudyal [email protected]