Created attachment 906753 [details] /etc/grub.d/05_uki I'm not sure to what degree you're comfortable maintaining an extra grub.d script but I managed to create a script largely based on, and comprising the bulk of /etc/grub.d/10_linux that uses glob patterns to find UKIs, specifically "/boot/*EFI/Linux/*-*.efi /efi/EFI/Linux/*-*.efi", and adds appropriate entries based on the GRUB chainloader command instead of the GRUB linux command. > menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os > $menuentry_id_option 'gnulinux-simple-cc267496-0418-468c-934c-b4dd04dab0d8' { > load_video > insmod chain > insmod part_gpt > insmod fat > search --no-floppy --fs-uuid --set=root D313-9444 > echo 'Loading Linux 6.11.5-gentoo ...' > chainloader /EFI/Linux/8e6dfbd2da15a3abb3e1a5a862dd78f4-6.11.5-gentoo.efi > root=UUID=cc267496-0418-468c-934c-b4dd04dab0e9 ro rootflags=subvol=@gentoo > root=LABEL=linux rootfstype=btrfs mitigations=auto apparmor=1 security=apparmor > systemd.unified_cgroup_hierarchy=1 fsck.repair=yes quiet splash
I am not interesting in maintaining this. I would suggest submitting it upstream.
Pardon the knee-jerk reaction. So long as somebody keeps it working, I guess it would be fine to add this.
(In reply to Mike Gilbert from comment #2) > Pardon the knee-jerk reaction. So long as somebody keeps it working, I guess > it would be fine to add this. I don't mind helping to maintain it if CCed with relevant bugs. I'd just want to adjust for aesthetics before submitting upstream.
(In reply to Peter Levine from comment #3) > (In reply to Mike Gilbert from comment #2) > > Pardon the knee-jerk reaction. So long as somebody keeps it working, I guess > > it would be fine to add this. > > I don't mind helping to maintain it if CCed with relevant bugs. I'd just > want to adjust for aesthetics before submitting upstream. I think it would be a good idea to also work on the multi-profile UKI support before submitting it upstream. In essence what would need to be done is: 1) List the number of .profile sections in the found UKI: "objdump -h ${uki} | grep -o .profile | wc -l" 2) If zero found, no change in behaviour, it is not a multi-profile UKI. 3) If one or more are found, loop over the number of found .profile's and: 4) Extract the "TITLE=" of the ${i}'th .profile section (with e.g. objcopy) and use this title to make a chainload entry that loads "${uki} @${i} ${usual_cmdline}". See also here: https://github.com/uapi-group/specifications/pull/108/files
There seems to be something additional required to support UKIs in GRUB with secureboot enabled: https://forums.gentoo.org/viewtopic.php?p=8845252 I don't understand why but it seems the chainload command works differently then a direct load by UEFI, and somehow works differently when secureboot is enabled.
(In reply to Nowa Ammerlaan from comment #5) > I don't understand why but it seems the chainload command works differently > then a direct load by UEFI, and somehow works differently when secureboot is > enabled. Now I understand why, upstream grub's chainload command requests the firmware directly to load the EFI file and does not use the shim protocol when it is booted via shim. Fedora/Ubuntu/SUSE carry (different) patches for this: [1] [1] https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0215-Add-secureboot-support-on-efi-chainloader.patch By the way, there is also this Fedora patch [2] for BLS type 1 support, and this pending patch [2] that extends that support to BLS type 2 (i.e. UKI support). In principle this could be re-used instead of starting from scratch. [2] https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0053-Add-BLS-support-to-grub-mkconfig.patch [3] https://github.com/rhboot/grub2/pull/119 It's a bit frustrating that none of this has made it upstream.
(In reply to Nowa Ammerlaan from comment #4) > I think it would be a good idea to also work on the multi-profile UKI > support before submitting it upstream. In essence what would need to be done > is: > 1) List the number of .profile sections in the found UKI: "objdump -h ${uki} > | grep -o .profile | wc -l" > 2) If zero found, no change in behaviour, it is not a multi-profile UKI. > 3) If one or more are found, loop over the number of found .profile's and: > 4) Extract the "TITLE=" of the ${i}'th .profile section (with e.g. objcopy) > and use this title to make a chainload entry that loads "${uki} @${i} > ${usual_cmdline}". > > See also here: https://github.com/uapi-group/specifications/pull/108/files I'm fine with working on this but I doubt objdump/objcopy would be adequate. There's a lot about the systemd's multi-profile UKI implementation that poses some problems. For instance, to avoid creating temp files by outputting a section to stdout, one can do something like `objcopy -O binary -j .profile /boot/vmlinuz.efi >(cat)`. But because there are multiple .profile sections, I get "ID=mainobjcopy: /dev/fd/63[.profile]: Illegal seek". I'd have to parse the output of `objdump -h vmlinuz.efi` for .profile section offset addresses and output one or more temp files just to examine them. And if the UKI was created using ukify's "--join-profile" parameter without an initial .profile in the main file, it will insert an initial .profile section with "ID=main" and no "Title", implicitly inheriting the preceding sections. For that corner-case, I'd need to look for ID=main and, if found, setup the title using the filename instead. Ultimately, it would be much easier and less prone to error with the aid of `ukify inspect`. There doesn't have to be an explicit dependency on ukify. You could just add: > pkg_postinst() { > optfeature "multi-profile UKI support" sys-apps/systemd[ukify] sys-apps/systemd-utils[ukify] > } And AFAICT, ukify is the only tool as of now that is designed to build and work with multi-profile UKIs.
(In reply to Peter Levine from comment #7) > Ultimately, it would be much easier and less prone to error with the aid of > `ukify inspect`. Yeah this approach does sound a lot simpler
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ebfd0b7f956e8d37c620ccaf41476dd3697e46a commit 8ebfd0b7f956e8d37c620ccaf41476dd3697e46a Author: Nowa Ammerlaan <nowa@gentoo.org> AuthorDate: 2025-02-21 18:39:48 +0000 Commit: Nowa Ammerlaan <nowa@gentoo.org> CommitDate: 2025-02-21 18:44:35 +0000 sys-kernel/installkernel: add 54 Leaving the bug open because the secureboot/shim situation needs resolving upstream. Bug: https://bugs.gentoo.org/942201 Closes: https://github.com/gentoo/gentoo/pull/39113 Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org> sys-kernel/installkernel/Manifest | 1 + sys-kernel/installkernel/installkernel-54.ebuild | 236 +++++++++++++++++++++++ 2 files changed, 237 insertions(+)
