From: Philipp Rudo prudo@redhat.com
kernel.spec: Fix UKI naming to comply with BLS
The Boot Loader Specification (BLS) [1] suggests that type #2 entries (UKIs) shall have the same names like type #1 entries with the exception of the suffix being .efi instead of .conf. In particular this means that the name for installed UKIs should be <entry-token-or-machine-id>-<version>.efi. The same naming convention is used by kernel-installs 90-uki-copy.install [2] in systemd v253.
Adjust the workaround to install UKIs in the kernel.spec to follow the same naming convention in order to prevent breaking user space tools that rely on it.
[1] https://uapi-group.org/specifications/specs/boot_loader_specification/ [2] https://github.com/systemd/systemd/blob/v253/src/kernel-install/90-uki-copy....
Signed-off-by: Philipp Rudo prudo@redhat.com
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template index blahblah..blahblah 100644 --- a/redhat/kernel.spec.template +++ b/redhat/kernel.spec.template @@ -3033,10 +3033,12 @@ touch %{_localstatedir}/lib/rpm-state/%{name}/installing_core_%{KVERREL}%{?-v:+% %define kernel_uki_virt_scripts() \ %{expand:%%posttrans %{?1:%{1}-}uki-virt}\ mkdir -p /boot/efi/EFI/Linux\ -cp /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz-virt.efi /boot/efi/EFI/Linux/vmlinuz-%{KVERREL}%{?1:+%{1}}-virt.efi\ +entry_token=$(kernel-install inspect | grep KERNEL_INSTALL_ENTRY_TOKEN: | cut -d ' ' -f2)\ +cp /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz-virt.efi /boot/efi/EFI/Linux/${entry_token}-%{KVERREL}%{?1:+%{1}}.efi\ %{nil}\ %{expand:%%postun %{?1:%{1}-}uki-virt}\ -rm -f /boot/efi/EFI/Linux/vmlinuz-%{KVERREL}%{?1:+%{1}}-virt.efi\ +entry_token=$(kernel-install inspect | grep KERNEL_INSTALL_ENTRY_TOKEN: | cut -d ' ' -f2)\ +rm -f /boot/efi/EFI/Linux/${entry_token}-%{KVERREL}%{?1:+%{1}}.efi\ %{nil}
#
-- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391
From: Vitaly Kuznetsov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1340490...
Looks good to me, thanks!
From: Luis Claudio R. Goncalves on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1340781...
I have the impression you need to update the %files section for uki-virt, specifically, the line
From: Vitaly Kuznetsov on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1340821...
Oh, true, the file is '%ghost' so the build is not broken but we certanly want to have it fixed. Thanks!
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348248...
@lgoncalv indeed I missed that line.
I'm seeing two problems with it. 1) %files is determined during build but the entry token can only be determined during install so we cannot provide the exact file name here. And 2) there is no entry in %files for the corresponding type #1 (aka. /boot/loader/entries/*.conf) either. So having an entry for type #2 is kind of inconsistent.
All in all I'm tempted to simply drop the line. Is that ok with you? Do you have a better solution for the problems described above?
Thanks!
From: Luis Claudio R. Goncalves on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348312...
@prudo1 you have a great point wrt the token not being known at that point. I have the impression that even though the kernel does not point to the type 1 entry in /boot/loader/entries, the uninstall script ties that to the kernel version. Not sure if that would happen to the type 2 entry, if that would be removed during kernel uninstall or left there.
If the suggestion below does not solve the problem, I am OK with leaving it out of the %files section. The suggestion is tying the %ghost file to the kernel version, something long the lines of:
`%ghost /%{image_install_path}/efi/EFI/Linux/*-%{KVERREL}%{?3:+%{3}}-virt.efi`
So, if existing, a type 2 file with the same Version and Release of the kernel would be tied to that kernel.
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348622...
Uninstalling isn't a problem for type 2 entries as they are currently explicitly removed in %postun. So at least in this case you don't need to have an entry in %files.
Using a wildcard was also my alternative solution. Originally I refrained from using it as you could construct situations where it doesn't work as intended. In particular you could have a dual boot system with identical kernel versions but different machine-ids. Using the wildcard could then lead to situations where system A claims ownership over a UKI installed by system B and thus breaking it. But that's more a theoretical problem.
Anyway, please see v2.
kernel@lists.fedoraproject.org