Add mkosi-addon and kernel-install plugin #3263
Conversation
|
Tested on my laptop, seems to work nicely. To install the addon requires a change to 90-uki-copy.install that I'll send once this is sorted out. |
Change mkosi-initrd to avoid adding local customizations (crypttab, kmods, fw) to the UKI by default, with an --host-only override. Add new mkosi-addon and kernel-install plugin to build local customizations into an EFI addon instead. This allows us to move closer to the desired goal of having universal UKIs, built by vendors, used together with locally built enhancements.
|
I think this belongs in systemd, not in mkosi. Users should be able to use their vendor provided UKI with an addon without needing mkosi installed on their system. The UKI is supposed to come with a set of kernel modules to satisfy 99% common use cases, so shipping the entirety of host loaded kernel modules as an addon doesn't make sense to me. Also we created mkosi-initrd specifically to generate hostonly initrds. That's it's only reason to exist, so adding a --host-only switch to it seems counter intuitive. I know you're trying to use mkosi-initrd and mkosi-addon together, but that means you're using a locally built initrd and then pretending it's not locally built. To me this is just overcomplicating the setup for the sake of pretending we're doing vendor built UKIs because distributions don't actually have vendor built UKIs yet. So I agree that an addon generating ker el-install plugin makes sense, but it should live in systemd next to the ukify plugin, not in mkosi, and we shouldn't try to make mkosi-initrd generate vendor built initrds when it's specifically built to generate local initrds. |
|
cc @keszybz |
|
It needs the logic to copy the kernel modules and firmware from the host, which is in the mkosi library code, so while the script could be moved, it would still depend on mkosi anyway, so why not keep it here so both plugins can be kept in sync? |
|
I'm arguing it doesn't need that logic. The vendor uki should include a default set of modules and firmware that work for most use cases. And then in super special cases addons are used to include a few extras. So it can live in systemd without having to depend on mkosi. |
|
That's unlikely to work though, you'd need a UKI with hundreds of MBs of stuff - the NVIDIA firmware alone is like 200M. Plus there's a gazillion different bluetooth/wifi firmwares, each in the tens of MBs each. There will always be demand for a minimal generic UKI + local-specific modifications. Otherwise why have that logic in mkosi-initrd either? Just build UKIs with everything, no? |
We have that logic in mkosi-initrd precisely because the initrd is built locally. We're building locally anyway so we might as well make use of the advantages that brings us. With your approach, you're using a vendor signed UKI and then requiring every user to enroll their own key since they need to add their own addon with kernel modules and firmware. So the entire point of the vendor signed UKI becomes moot because every single user still has to enroll their own key. The entire goal of the vendor signed UKIs is that they work out of the box for most use cases or the vendor also provides signed addons that extend the UKI. As soon as you require every single user to enroll their own key, you might as well build and sign the entire UKI locally and not bother with vendor signing to begin with. And if you're building and signing the UKI locally there's no point in using addons since you can just add everything straight into the UKI. So a solution like this that implies every user enrolling their own key is not an option in my opinion. |
|
And if you want this just for the niche use case where a user wants a locally signed addon with kernel modules with a minimal signed vendor UKI, that's too niche to me to justify all this extra code in mkosi for that specific use case. I would much rather we focus on building the entire UKI ourselves and signing that locally then instead of focusing on building addons for vendor signed UKIs. |
|
What is attractive to add to mkosi is a way to build those signed vendor addons. So I am actually interested in the addon output format as a similar mechanism to sysexts you can use it together with Overlay=yes to package an overlay on top of the base initrd mage into an addon. |
|
Having the possibility of building local customizations will always be needed, it cannot possibly be preditected what all combinations one might need will be, especially including local configuration (eg: crypttab) and kernel command line. Yes that will require local keys, but that's always been the case, eg: out of tree kernel drivers or filesystems |
Yes it will be needed, it's just not something I want to maintain the code for in mkosi. If the kernel modules logic is dropped I think it's perfectly fine to propose this for inclusion in systemd. I think mkosi should focus on either building vendor signed UKIs + vendor signed addons or locally signed UKIs and not everything inbetween. |
So, the idea is having |
Change mkosi-initrd to avoid adding local customizations (crypttab, kmods, fw) to the UKI by default, with an --host-only override.
Add new mkosi-addon and kernel-install plugin to build local customizations into an EFI addon instead.
This allows us to move closer to the desired goal of having universal UKIs, built by vendors, used together with locally built enhancements.