…rigid in nature: only one allowed kernel command line. We eventually added the concept of "profiles" to UKIs, so tha a single UKI could synthesize multiple boot menu entries, which enables you to chose one of many pre-prepared kernel command lines.

Which is much more powerful, but still a bit rigid: we needed ways to securely insert local parameterization into such a system (i.e. some signature keys or so, machine identity, …) so we added the concept of "side cars" to the thing, that…

With v261 we are going full circle to some level: there's now a new command "bootctl link", which links together a UKI (aka a Type#2 entry) and a bunch of side-cars and generates a new Type #1 entry from it (or, possibly, multiple, if profiles are used).

"bootctl link" hence plays a role somehwat similar to the pre-existing "kernel-install" tool, but has a much stricter focus: it does not support any plugins, but it does support Varlink from day 1.

If you ask me when distros should…

…use "kernel-install" and when use "bootctl link", I'd suggest: use kernel-install on traditional package-based distros, since installing a kernel there means doing a tonload of auxiliary work on various subsystems. Use "bootctl link" on modern image-based distros, where all that work is already baked into the update images themselves.

"bootctl link" is symmetric to the pre-existing "bootctl unlink". The latter removes a Type #1 entry from the ESP, and understands a concept of GC: it…

…will iterate through al referenced resources of an entry, and remove them if they are no longer referenced by any other Type #1. The former installs a new entry into the ESP along with its resources, if they haven't been copied there yet.

"bootctl link" also has a lot of really nice robustness properties: it carefully makes sure to place all resources into the ESP fully, before actually linking them into place. Thus, behaviour is somewhat atomic: either the entry fits in fully and all is…

…good, or something fails (which typically means not enough disk space), and then nothing actually materializes in the ESP, and is removed already before it ever was linked in.

Given that the ESP is VFAT there are limits to how "atomic" we can make that, but I think we should be pretty good in effect, as every call first cleans up what might be left (even if very unlikely) from the previous one.

Moreover it comes with an unlink strategy built into the linking strategy: if disk space is not…

…available, instead of just giving up, it will automatically delete the oldest entry (using the aforementioned bootctl unlink GC logic), repeatedly until enough space is available. When doing this it will carefully protect the currently booted entry however. Each time it will then attempt a link operation again.

In essence: the logic should be really robust and make the best of what's available: keep as many menu entries as possible, but avoid failures as long as possible, protecting the…

@pid_eins Does the unlink logic only protect the current booted one or does is also protect the ones from other images?

Say I have 2 images with 2 versions each. Would it have up to 3 versions it can GC (1 from the current booted one and 2 from the other image) or only 1 (the one from the current booted image)?