FS#76454 - [edk2-shell] feature request: bundle script to allow grub2 to chainload uefi-shell

Attached to Project: Arch Linux
Opened by Niccolò Belli (darkbasic) - Sunday, 06 November 2022, 18:06 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:25 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Some motherboards don't allow you to boot into UEFI shell, so it's necessary to use your bootloader to chainload it.
Bundling a grub.d script to automatically generate the grub entry comes in handy.
For those who don't use grub the script will simply do nothing.
Script attached.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:25 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/edk2/issues/2
Comment by Toolybird (Toolybird) - Sunday, 06 November 2022, 22:37 GMT
First reaction is this seems like wiki material..
Comment by Niccolò Belli (darkbasic) - Monday, 07 November 2022, 07:43 GMT
It may be, but there are other packages (mainly in the AUR) like memtest which bundle their own grub scripts and it's a nice convenience.
Comment by David Runge (dvzrv) - Monday, 07 November 2022, 09:23 GMT
@darkbasic: Thanks for the ticket and suggestion.

We're quite intentionally not packaging the shell file in /boot (because frankly no package should own files in /boot, but that's another discussion).
If this snippet was to be added, I'm not even sure it would work out of the box, because for the binary to be used, the root filesystem would need to be unlocked (if the system is encrypted).
Have you tested your snippet on a system with full disk encryption?

From what I can tell, the only way this could work is by:
* providing a per shell (we have x64/x86_64 and ia32/x86, depending on the host's firmware architecture!) alpm hook [1] - in a non-active location from where the users need to symlink them to /etc/pacman.d/hooks/ - that copies the UEFI shell file to /boot
* providing a grub snippet (for UEFI shell(s) below /boot) - in a non-active location - from where the users need to symlink it to /etc/grub.d/

All of the above begs the question though, why we would only want to do this for grub, as there are other bootloaders around, too (e.g. systemd-boot [2], refind).
Providing a solution, that can be used bootloader agnostic (e.g. the alpm hook) and is not on by default, would be preferable.

[1] https://man.archlinux.org/man/alpm-hooks.5
[2] https://man.archlinux.org/man/systemd-boot.7
[3] https://www.rodsbooks.com/refind/
Comment by Niccolò Belli (darkbasic) - Monday, 07 November 2022, 15:41 GMT
Every solutions has its pros and cons.

memtest86-efi (AUR) uses an alpm hook to copy the image to the EFI partition. It also creates grub/systemd-boot/whatever hooks depending on what's installed.

https://aur.archlinux.org/cgit/aur.git/tree/memtest86-efi-update.hook?h=memtest86-efi
https://aur.archlinux.org/cgit/aur.git/tree/memtest86-efi?h=memtest86-efi

I like this approach and I thought it would have been too cumbersome to be accepted in the main repo, but since you like it I'm all in for this because it works every single time (encrypted root, encrypted boot and whatever the bootloader).

I offered a simpler solution like the attached one because memtest86+-efi is packaged in the official arch repos and that's exactly what it does:
https://github.com/archlinux/svntogit-packages/blob/packages/memtest86%2B/trunk/60_memtest86%2B-efi

memtest86+-efi copies the image to the boot and loads it using the "linux" loader. Root being encrypted would not be a problem and the boot can be encrypted as well since grub is in charge to decrypt it.

Our problem is that we're using "chainloader" instead of the "linux" loader. That means that grub will fail to load it if you're using an encrypted boot (like me).

The solution would be to use the memtest86-efi approach: alpm hooks + copying the image to the EFI partition.
Comment by Niccolò Belli (darkbasic) - Friday, 11 November 2022, 20:45 GMT
Let me know if the "alpm hooks + copying the image to the EFI partition" approach is good for you and how I should proceed: another attachment? Do you have a mirror repo where users can PR?
Comment by David Runge (dvzrv) - Sunday, 27 November 2022, 16:27 GMT
@darkbasic: Will look into it for the next iteration on the package.
Comment by David Runge (dvzrv) - Sunday, 27 November 2022, 21:47 GMT
@darkbasic: FWIW, the memtest86-efi libalpm hook would be fine, if we wouldn't have to duplicate the "find and mount ESP, copy to ESP" effort every time.

I'll need to think about how to best approach this, likely cross-package so that we only implement this once.

Loading...