install/flat: Use composefs pipeline for rootfs

[ericcurtin]

--flat install implementation will go through the composefs
repository. This gives several advantages:

• SELinux labeling is handled by composefs-rs (selabel), which applies
  labels from the image's file_contexts rather than inheriting the
  running container's labels.
• The kernel installation flow is reused from composefs-rs
  (get_boot_resources / UsrLibModulesVmlinuz).
• The composefs repo is preserved at /sysroot/composefs, making it
  easy to convert to immutable/bootc mode later. Users who don't want
  the metadata overhead can rm -rf /sysroot/composefs.
• write_to_path supports reflink copies on btrfs/XFS, sharing blocks
  with the composefs object store.
• --source-imgref now works with --flat (the in_host_mountns guard is
  removed since we pull via the image reference, not via cp /).

[ericcurtin]

Not complete, wanted to see what shape the builds are in

[gemini-code-assist]

Code Review

This pull request introduces an experimental --flat mode for bootc install to-filesystem, which performs a traditional-style OS installation from a container image. The implementation is well-structured, adding new functions for each step of the flat installation process and integrating it into the existing installation flow. The changes also include a new unit test for BLS entry creation.

My review focuses on potential improvements in memory efficiency and code maintainability. I've suggested using streaming copies for kernel and initramfs files to reduce memory usage and pointed out an opportunity to refactor duplicated bootloader installation logic into a shared function.

[ericcurtin]

This is admittedly quite basic, it's just copy stuff in the right place, but it's a start

[ericcurtin]

What I am thinking the next step here is:

For /usr, /bin, /lib, etc.: do a Rust-written equivalent of rsync -aHAX --delete --one-file-system instead of cp, so extraneous files are removed
For /etc: apply the same 3-way merge logic from finalize.rs
For /var, /home, /root: do nothing

[cgwalters]

regular (non-bootc) Linux system

Request: Please don't use "regular" (or worse "normal") in that way, it implies other things are "irregular" (or worse "abnormal"). In this case I'd say "mutable" (or just non-bootc) as you did.

---

Anyways on the implementation side, I think it'd be really nice if we actually did create a composefs repo but then from there we did a reflink based copy out.

There are several huge advantages to that, among them we'd be reusing the selinux labeling support in composefs(-rs) for example, and the kernel installation flow.

Further it makes it way easier to then convert the image to immutable/bootc style later on. And anyone who doesn't want the extra metadata overhead can just rm -rf /sysroot/composefs or so.

I think we should not regenerate the initramfs client side by default.

[ericcurtin]

regular (non-bootc) Linux system

Apologies, you've mentioned this before and I completely understand the logic.

Request: Please don't use "regular" (or worse "normal") in that way, it implies other things are "irregular" (or worse "abnormal"). In this case I'd say "mutable" (or just non-bootc) as you did.

Anyways on the implementation side, I think it'd be really nice if we actually did create a composefs repo but then from there we did a reflink based copy out.

There are several huge advantages to that, among them we'd be reusing the selinux labeling support in composefs(-rs) for example, and the kernel installation flow.

Further it makes it way easier to then convert the image to immutable/bootc style later on. And anyone who doesn't want the extra metadata overhead can just rm -rf /sysroot/composefs or so.

I think we should not regenerate the initramfs client side by default.

All fair points.

[cgwalters]

I haven't even looked at install.rs changes yet and no promises on this one in the review queue in general, but I also don't want to block experimentation on it.

Speaking of even if we were to land this for sure it'd need to be an experimental feature (much like its close cousin in #1969 )