Skip to content

Composefs backend #1314

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Johan-Liebert1
Copy link

A rough draft for installing and booting using composefs-rs. Current only works for install to-disk via bootc install to-disk --composefs [options]

Issues:

  1. Issue with transport type continers-storage, viz, #117. Needs some ironing out.
  2. Bootc images need rebuilding with composfs-rs components, namely composfs-setup-root

I have a few logs being logged as warning, just for visibility. Will remove them when it's ready.
Same with composefs-rs patch in cargo.toml

Done to facilitate the installation of a composefs repository to
disk

Signed-off-by: Pragyan Poudyal <[email protected]>
@github-actions github-actions bot added the area/install Issues related to `bootc install` label May 13, 2025
Copy link
Collaborator

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this!!

.create_dir_all("composefs")
.context("Creating dir 'composefs'")?;

tracing::warn!("STATE: {state:#?}");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend dbg! for this type of stuff; it will build locally but not pass CI so it can't be accidentally merged.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intend to remove all these logs. They were only for debugging purposes

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep that makes sense, what I meant is that use dbg! locally. (Or use tracing::debug! and keep the tracing in there and just use the tracing selector to ensure you see what you want...we are really chatty with a big env RUST_LOG=debug unfortunately today, mostly in container fetches)

@@ -1199,7 +1199,7 @@ async fn run_from_opt(opt: Opt) -> Result<()> {
let fd =
std::fs::File::open(&path).with_context(|| format!("Reading {path}"))?;
let digest: fsverity::Sha256HashValue = fsverity::measure_verity(&fd)?;
let digest = hex::encode(digest);
let digest = digest.to_hex();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be squashed with the previous commit, and it may make sense to have a "bump composefs-rs" prep PR split out right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that makes sense. I'll put this in a separate PR

async fn install_to_filesystem_impl(
state: &State,
rootfs: &mut RootSetup,
cleanup: Cleanup,
composefs: bool,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would make sense as part of state

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was conflicted on where to put this. Thanks for the review. I'll add this to State

&imgstore,
)
.await?;
tracing::warn!(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment re dbg! or this one could also make sense as a tracing::debug! that gets left in right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes. We can keep this one as debug

@cgwalters
Copy link
Collaborator

bootc install to-disk --composefs

The branding here is a bit confusing because of course, bootc already uses composefs. Just the https://github.com/composefs/composefs/ version, and that is "indirectly" via ostree.

Bigger picture I think what we're trying to aim for here primarily is "sealed" images right? In that case then, one thing I think would make sense is that we don't even have an option to install - we determine what to do by inspecting the container.

It does of course make sense to eventually support unsealed images this way too...which will be extremely important for eventually migrating existing ostree systems. There's an enormous set of details there though.

So my proposal in a nutshell:

  • Let's call it "composefs native" storage or so (the branding here is again hard, open to other ideas)
  • Default to (i.e. require) composefs-native storage if we detect the image is a sealed UKI.
  • Make the opt-in flag called like --composefs-native or so for unsealed cases. That said, it could also make sense to add some sort of flag to the container image to do this instead; because I think most people who want to do this will always want to do it. It's basically similar to what we have with kernel arguments; they can be either baked into the container or applied out of band, and in the general case we need both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/install Issues related to `bootc install`
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants