From: Vitaly Kuznetsov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805606318 @eesposit @berrange personally, I'd suggest we don't over-complicate stuff **now**. Namely, we have only one UKI and only one signing SB key for it (which, in case of Fedora, is the same key as for the standard kernel). We don't know yet whether we will be building more UKIs and if yes, whether these UKIs will use different SB keys. Hopefully not, as to get distinct PCR7 fingerprints we will have to list all of them in SecureBoot DB. We can, of course, start by creating "kernel-uki-virt-addons-common" but in the absence of "kernel-uki-virt-addons" the "common" suffix is going to be a bit weird. Note, creating "-common" sub-package still doesn't give us a way to create kernel-version-independent addons, we will have to introduce a new srpm for that. Addons are, however, tiny, this means that if we have 3 copies of them when we have three UKIs installed, it is not a big deal. What is more important, is if we get an automated way to update them on the ESP with kernel updates. I.e. if I have an active addon for my UKI and I'm installing new UKI version (both kernel-uki-virt and kernel-uki-virt-addons), will the addon get updated on the ESP. In case the addon is global, this means the the cmdline gets updated for the already present UKIs is this is likely desirable. At the end, it may make sense to make all addons tied to the specific UKI version and teach kernel-install how to update the ESP when a new UKI version is installed. -- _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue