Save /boot structure as an image

[Johan-Liebert1]

For UKI booted systems we have a lot of stuff in /boot viz, UKI, UKI
Addons, UKI dumpfile, various UKI profiles and we may add more things in
the future. Currently we mask off /boot from the EROFS which leaves us
with a very inefficient way of reconstructint the filesystem from
splitstreams to get back what was in /boot

Instead, save a <verity>.boot EROFS in composefs/images/refs which
contains only the /boot directory. This is useful for installing UKI
addons from other deployments into the current one and also for GC-ing
UKI and respective addons which we currently do not

---

Make use of the saved .boot EROFS to GC everything in the boot
directory of the deployment being GC'd

Closes: composefs/composefs-rs#373

[cgwalters]

Why can't we just read the non-bootable tree? That's already supported in composefs-rs directly - the same filesystem tree one would get to run as a container image. Yes, we won't have e.g. SELinux labeling, but that's not a problem.

[cgwalters]

See above

[Johan-Liebert1]

Why can't we just read the non-bootable tree?

I didn't even realise we saved this :|
We can totally just use this image

[Johan-Liebert1]

Okay, going through the code a bit more, we're doing things extremely inefficiently. We're recreating the filesystem multiple times, one for non-bootable fs and once for bootable. I had some optimizations here edb2ef0, but the current stuff requires some more refactoring

[cgwalters]

Okay, going through the code a bit more, we're doing things extremely inefficiently. We're recreating the filesystem multiple times, one for non-bootable fs and once for bootable.

What's inefficient about that? It's just O(metadata) so I'd be surprised if it was taking a noticeable amount of CPU etc.

[Johan-Liebert1]

image::create_filesystem does untar and parse for all layers. This is mostly on the bootc side since we're not returning the created fs from composefs APIs the same filesystem is being created twice for one install/upgrade, one for the bootable erofs and one for the non-bootable. Also, currently we're not even passing the verity digest of the image to create_filesystem which hashes all of the layers for verification

[cgwalters]

image::create_filesystem does untar and parse for all layers.

Hmm, but we only need to process the tar metadata not the data, that seems like a plain bug to fix in composefs-rs - like we want a tar reading path that only gives headers from split stream.

Also, currently we're not even passing the verity digest of the image to create_filesystem which hashes all of the layers for verification

I don't understand this one.

But at this point can you spawn an agent on this and let's move this to composefs-rs?

All that needs to be done on the bootc side I think is to read the non-bootable image to access /boot, and we fix any perf issues in composefs-rs.

[Johan-Liebert1]

I don't understand this one.

Here https://github.com/bootc-dev/bootc/blob/main/crates/lib/src/bootc_composefs/boot.rs#L1486, we pass config verity as None, which in turn invokes https://github.com/composefs/composefs-rs/blob/main/crates/composefs-oci/src/image.rs#L124

But at this point can you spawn an agent on this and let's move this to composefs-rs?

This would be a combined effort really. I think the easiest solution is to simply return the created fs from composefs APIs and have other functions take in an Option<Filesystem<..>> as a param. But yeah, that can be a followup

[Johan-Liebert1]

Also, regarding just this PR, I don't believe there's any way we link the bootable and non-bootable EROFS-es? I see we have them as GC links in the config splitstream, but that requires reading the splitstream metadata. Should we create a ref in bootc for easier accessibility, similar to a ref I'm creating here 6660f94?

[cgwalters]

Hmm...yes we may be missing APIs for this, will look