Hi @HastD!

You may be interested in https://github.com/jlebon/chunkah. It's a successor to build-chunked-oci to which bootable containers will likely eventually migrate.

I'm having a similar discussion with myself in https://github.com/jlebon/chunkah/issues/16. But basically, two things I'll note:

1. In the general case, it's not always the optimal move to have the initramfs be in its own layer.
2. In the specific case you're concerned about (user-owned/unpackaged config files getting lumped together), the optimal option is likely to do this separately from chunking.
3. The initramfs is special in that it's one large unpackaged file, but one may have multiple large unpackaged files, so we likely want something smarter than just special-casing the initramfs. The opposite approach, which I mentioned in that comment, is to special-case unpackaged /etc files instead.

Regardless, I also think we definitely should allow users to force any arbitrary files to be separate if they'd like/know better (filed https://github.com/jlebon/chunkah/issues/36 for that).

Anyway, happy to start collaborating/chatting there if you're interested. The code is certainly not as baked/battle-tested as build-chunked-oci, and it still does dumb things, but it should improve quickly.

Hi @jlebon, thanks for your work on Chunkah—it's a very cool project that I've been keeping an eye on. I anticipate that once it reaches a certain level of stability, BlueBuild will also add an option to use Chunkah in place of build-chunked-oci for rechunking images.

In any case, while I do agree that it's not always optimal to put the initramfs in its own layer, I do think it's often still a good choice: the initramfs is large enough that it would significantly reduce average update sizes even if we can only avoid having to download its layer, say, every other update.

I also agree that in some cases it might make more sense to instead special-case unpackaged /etc files, but that's beyond the scope of this PR and would be a more substantial change to build-chunked-oci.

As for this PR specifically, I think it's worth keeping in mind that this is simply a bug-fix: the intent of the existing code is to put the initramfs in its own layer as an exclusive component, but this doesn't happen because it's erroneously given package metadata instead of component metadata. This also has consequences that are clearly a bug: because the initramfs is incorrectly marked with package metadata, it can't be manually assigned to a layer using the user.component xattr either.

I am not opposed to this, and most failures seem unrelated. However https://github.com/coreos/rpm-ostree/actions/runs/22593223740/job/66384557537?pr=5535 that concerns me. I am not sure if that is because the algorithm we had in place needs modification now that the initramfs is not counted as a package. I need to dig deeper on this I have not looked at how we do the chunking before.

@jmarrero I'm pretty sure I understand the reason for this test failure now. Unfortunately, fixing the handling of the initramfs here seems to have uncovered a bug in how ostree-ext handles exclusive components: in particular, if I'm understanding the code correctly, it looks like ostree-ext will always fail to use a prior build's layer plan if the image has exclusive components. (I did some local testing that seems to back this up.)

The problem is that, in ostree_ext::chunking::basic_packing_with_prior_build, to use the prior build's layer plan, we require bin_size to be >= the number of layers of the prior build (excluding the ostree commit layer): https://github.com/bootc-dev/bootc/blob/015903b95d28a786ae7c21ef057dfb42716d5e32/crates/ostree-ext/src/chunking.rs#L640-L643

But on the other hand, the bin_size input comes from here: https://github.com/bootc-dev/bootc/blob/015903b95d28a786ae7c21ef057dfb42716d5e32/crates/ostree-ext/src/chunking.rs#L381-L384
And this is essentially computed as the maximum layer count minus the number of layers that have already been reserved at that point in the function... but this takes place after we've already made a layer for each exclusive component earlier in the same function, so I think this will always fail if there are exclusive components.

I haven't wrapped my head around the full packing algorithm well enough yet to understand exactly which part of this needs to be fixed and how best to fix it, but it seems like the problem is that it doesn't take into account the likely presence of the same exclusive components in the prior build. (I should probably write this up as an issue for ostree-ext; I'll do that later.)

In any case, I think we have to hold off on merging this PR, because even though this PR does fix a bug, the other bug uncovered by doing so is worse, since (if I've understand the code correctly) the only reason chunking based on a prior build's layer plan has been working at all is the absence of exclusive components in the builds.

Okay, I wrote up the issue in bootc-dev/bootc#2057.