Add shared initrd handling for blsforme schemes

[tarkah]

Shared (version independent) initrd files can be deduplicated across multiple kernels. This adds support to identify when initrds are shared vs versioned and for the newer blsforme schemes, it places those assets beneath a "shared" directory that allows deduplication.

This adds logic to detect shared initrd files in two different ways:

• kernel/{version}/foo-shared.initrd / -shared.initrd suffixed files in the versioned kernel directory.
• kernel/initrd.d/foo.initrd / All .initrd extension files in the initrd.d directory.

Any filenames that get matched from initrd.d will take priority over filenames from a versioned kernel directory to handle migration from the older scheme to the newer initrd.d scheme.

Testing

I've installed the two packages that have shared initrd files:

And also tested our collision logic applies to these assets as well:

Boom!

[ermo]

Is it random which gets the .0 and which gets the .1 suffix, in the sense that "the contents of the files are hashed, and then the files are sorted according to their hash values"?

I guess I'm a little confused by .0+.1 combination in one boot entry, and the .1+.0 combination in the other? Is that just an implementation detail on its own, where it doesn't matter what the mapping suffix is, just that it represents "the correct file version for any bootable fstx"?

[tarkah]

Is it random which gets the .0 and which gets the .1 suffix, in the sense that "the contents of the files are hashed, and then the files are sorted according to their hash values"?

I guess I'm a little confused by .0+.1 combination in one boot entry, and the .1+.0 combination in the other? Is that just an implementation detail on its own, where it doesn't matter what the mapping suffix is, just that it represents "the correct file version for any bootable fstx"?

Correct. Things can only be grouped by / deduplicated by hash, so hash is the only thing we can deterministically sort by to provide a stable determinstic suffix. Or at least it's the easiest way without a lot more complexity.

It has nothing to do with the order of entries or anything like that. It's entirely opaque & irrelevant when looking at it from how entries link to each asset, outside of it will point to the correct one for that entry.

[tarkah]

I guess we can use an indexset instead of a btreeset and then they'll retain an index relative to the order they were added, which might make more sense.

[bhh32]

@tarkah Looks really good! Nice job!