RFC: Use dpkg triggers to reinstall EFI GRUB upon signed grub or shim change
Pascal Hambourg
pascal at plouf.fr.eu.org
Sun Jul 23 15:24:26 BST 2023
[Note: This text mentions only amd64 packages for clarity and brevity
(*cough*), but I guess most of it also applies to arm64 and i386/ia32]
Dear GRUB and shim maintainers,
*Background*
grub-efi-amd64 postinst script runs grub-install to reinstall the boot
loader upon package install or upgrade.
grub-install takes GRUB signed image grubx64.efi.signed (provided by
grub-efi-amd64-signed) if available.
grub-install takes shim files shimx64.efi.signed fbx64.efi.signed
mmx64.efi.signed BOOTX64.CSV (provided by shim-signed,
shim-helpers-amd64-signed and shim-unsigned) if grubx64.efi.signed and
shimx64.efi.signed are available.
This is reflected in the package dependency tree:
grub-efi-amd64
depends: grub-efi-amd64-bin
recommends: grub-efi-amd64-signed (grubx64.efi.signed)
recommends: shim-signed (shimx64.efi.signed)
depends: grub-efi-amd64-bin
depends: grub2-common (grub-install)
depends: shim-signed-common (update-secureboot-policy)
depends: shim-helpers-amd64-signed (fbx64.efi.signed mmx64.efi.signed
depends: shim-unsigned (BOOTX64.CSV)
grub-efi-amd64 package description states "Installing this package
indicates that this version of GRUB should be the active boot loader",
which I read as "other packages should not run grub-install if this
package is not installed". However, shim-signed and
shim-helpers-amd64-signed maintainer scripts also run grub-install even
if grub-efi-amd64 is not installed. Although this implementation has
worked fairly well in the standard use case, it comes in the way of edge
cases and has several shortcomings:
- grub-install may be run by maintainer scripts even if grub-efi-amd64
is not installed.
- shim-signed and shim-helpers-amd64-signed maintainer scripts duplicate
parts of grub-efi-amd64 postinst. These parts should be kept in sync but
they are currently out of sync.
- grub-install may be run needlessly or multiple times during a package
processing batch.
- grub-efi-amd64-signed has no maintainer scripts, so its installation,
upgrade or removal does not run grub-install.
- shim-signed depends on grub packages.
(non-exhaustive list)
*Proposal*
I propose to use triggers upon signed grub and shim package change in
order to run grub-install (and possibly ESP cleanup) only in
grub-efi-amd64 postinst instead of shim-* maintainer scripts. If this
proposal receives positive feedback, I volunteer to write and submit a
more detailed specification, then work on its implementation.
Benefits:
- run grub-install only if grub-efi-amd64 is installed
- avoid duplicating maintainer scripts and keeping them in sync
- run grub-install at most once per package processing batch
- allow to run grub-install only when needed (e.g. shim changes are
irrelevant if grub-efi-amd64-signed is not installed)
- remove shim-signed dependency on grub packages
- fix other shortcomings
Additional goals:
- clarify ESP (EFI System Partition) cleanup policy
- allow use of shim with other boot loaders than GRUB
- prepare support for multi-arch secure boot with 32 and 64-bit x86 UEFI
Note: grub-cloud-amd64 is a special case which already uses triggers on
grub and shim directories to run grub-install. It is out of the scope of
this proposal and should not be affected.
*Clarify ESP cleanup policy*
Currently, shim-signed postrm deletes shimx64.efi from the ESP target
directory /boot/efi/EFI/$bootloader_id.
shim-helpers-amd64-signed postrm deletes fbx64.efi and mmx64.efi from
the ESP target directory.
BOOTX64.CSV is not deleted from the ESP even though it points to deleted
shimx64.efi.
shim files are not deleted from the ESP removable media path
(/boot/efi/EFI/BOOT) even if debconf item
grub2/force_efi_extra_removable is set to true.
I believe it would be best if grub-install did ESP cleanup on its own.
Meanwhile, what grub-efi-amd64 postinst should do is an open point:
- delete all shim files (shimx64.efi fbx64.efi mmx64.efi BOOTX64.CSV)
from the ESP target directory if source files are not installed ?
- always delete shim files from the ESP target directory before running
grub-install ? what if grub-install fails ?
- also delete shim files from the ESP removable media path if
grub2/force_efi_extra_removable=true ?
- or do no ESP cleanup at all ?
- other ?
In any case, if GRUB and shim files are installed into the ESP by
grub-efi-amd64 only, then ESP cleanup should not be done by other packages.
*Allow use of shim with other boot loaders than GRUB*
(E.g. systemd-boot, cf. bug #1039058)
shim packages should not depend on any grub packages.
shim packages should not use any grub-specific triggers.
*Prepare support for multi-arch secure boot with 32 and 64-bit x86 UEFI*
(My use case for this is to install a regular Debian amd64 system on a
removable disk and make it bootable on both 32 and 64-bit UEFI with
secure boot (and BIOS), just like amd64 installation and live images.
This is not currently possible because of grub and shim package conflicts.)
grub-efi-* and shim-* packages for a given EFI architecture should not
share any triggers with another EFI architecture.
shim-unsigned control file should have "Multi-Arch: same" (like
shim-signed) so that packages of different architectures can be
installed together.
Thanks for reading me and thanks in advance for your comments.
More information about the Pkg-grub-devel
mailing list