You might know the UKI concept we introduced a some years ago, UKI = unified kernel image. You glue kernel, initrd and some other stuff into one UEFI PE binary, so that it can be secureboot authenticated as one, be measured as one, and updated as one.

It has many benefits to do things that way, but it also comes with one drawback: you bake in a single kernel cmdline, and in sb mode there's no way to use any other (well unless you use uefi addon files, but that involves signing stuff…

…separately and dealing with side-cars. And there's no nice way to choosing one of multiple cmdline choices in the boot menu.)

I decided to do something about this now. here's a WIP PR: https://github.com/systemd/systemd/pull/33512 – it allows baking multiple alternative kernel command lines into a UKI, and the idea is that the boot menu then offers all of them to the user, synthesizing multiple boot menu entries from a single UKI.

It's a reasonable simple approach I'd claim.

Intended usecase for this: one UKI synthesizing three menu items: one for regular boots, one to activate storagetm mode, and one to trigger a factor reset. (or any other combo a distro desires)

Some things we still need to hash out – but I am quite confident that this design is quite close to what we'll merge into systemd-stub in the end.

@pid_eins Last week I ramped up my home office kernel QA to use UKI so I guess it was great timing then :-)

Is there LXR for systemd?

@jarkko i am not aware of any, but i never used lxr myself, hence i might not be up-to-date on that.

@pid_eins not a big deal, just checking

@pid_eins does systemd have built-in mok signer?

@pid_eins I'd love to learn more about if:

1) Is UEFI net booting this kind of thing possible? Normally you template a kernel cmdline at runtime from a provisioning server, but with this it's baked inside the UKI?

2) Can I create two /boot partitions (on different physical drives) with the same UKI on each, and that way if one drive dies, the other one will still let the machine boot?

@jarkko no.

@pid_eins OK, fair enough, thanks for the responses! I asked the last question mainly because I was not entirely sure how far is the reach of bootctl. Now I know.

@purpleidea uefi http boot allows you to boot efi binaries, so you can boot a uki/sd-stub with this. That said sd-boot doesnt support http boots however, it doesn't know how to retrieve additional resources via http. It only knows how to do this via uefi fs apis. But without sd-boot you wouldnt have a boot menu you can pick one profile from those an uki offers.

@purpleidea and sure, you can put an ESP on each disk you have and put a copy of the same UKI on, so that any of the ESPs is fine to boot.

There has been some RFE for things like "bootctl" to manage that for you automatically, but noone did anything about it so far.

@pid_eins I think sd-boot is great for its simplicity, and I think it should be kept as simple as possible. Having the option for multiple cmdlines is great, but there should be sensible defaults in sd-boot for auto-selection of some, if not explicitly asked to do something else. Why not have something like UKI overlays, which overlay a single section of a given UKI. The "upperdir" UKI would need to contain the signature for the combination of it with its "lowerdir". Of course, it would still need to be signed, but so does a UKI with multiple command-line entries

@pid_eins hmm your secure boot might want to then add some more security to let you start up storagetm.