Bug#1017858: grub-efi-amd64-signed: Failed to Perform SecureBoot Grub EFI Installation via Debootstrap

[Chew Kean Ho]

Package: grub-efi-amd64-bin
Version: 1+2.04+20
Severity: important
X-Debbugs-Cc: hollowaykeanho at gmail.com

Dear Maintainer,


   * What led up to the situation?
When building a new minimal Debian OS (Bullseye stable) via debootstrap
non-interactively using a script tool, the resulting medium failed to build
a SecureBoot capable Grub EFI bootloader Debian OS without heavy manual
interventions.

The reason this path is pursued over Calamares is the precise minimal setup and
seamless build automation for various targets, especially for building a
firmware-like OS image consistently (e.g. generate an img file and set it up for
disk flashing). Additionally, it has pinpoint percision for OS configurations
without too much manual interventions (e.g. percisely install non-free firmware,
fleet management configurations in 1 go).

There are 2 expectations:

1. Maintainer: keep everything inside `shim-signed` and `grub-efi-ARCH-signed`
   packages' automation and any additional steps are considered as bugs as noted
   in https://lists.debian.org/debian-efi/2022/08/msg00019.html.
2. Me: as long as the Grub-EFI removable SecureBoot installation using
   `grub-install` is working accordingly will do.


   * What exactly did you do (or not do) that was effective (or
     ineffective)?

The ideal build step specified by Maintainer failed to install SecureBoot
grub-efi into the target OS at all (after Maintainer's guidance). Both apt
packages did not setup a grub inside /boot directory. The build steps are
available at (look for Apt installing bullseye-backports' SecureBoot EFI Grub
bootloader): https://salsa.debian.org/-/snippets/615

The workaround I'm looking for a fix (currently failed) would be having a
removable Secureboot grub-efi properly installed (without disabling SecureBoot
at target BIOS). The current result is that the target enters a boot-loop at EFI
level (contiue boot --> reset system) when SecureBoot is enabled at BIOS.
Disabling SecureBoot at BIOS works fine but SecureBoot benefits were forfeited.
The build steps are available at (look for Apt installing bullseye-backports'
SecureBoot EFI Grub bootloader...): https://salsa.debian.org/-/snippets/616

The only workaround left is to directly build the target OS on the target system
(breaking the firmware build tool's purpose) and must mess with its efi nvram.
This breaks existing Linux benefits where the installed medium can be swapped
across different (but same type) of hardware. The build steps are available at
(look for Apt installing bullseye-backports' SecureBoot EFI Grub bootloader...):
https://salsa.debian.org/-/snippets/614

NOTE:
1. all methods were properly investigated on a SecureBoot laptop target, with
   a complete built Debian OS using method in
   https://salsa.debian.org/-/snippets/614 manually.
2. Both `shim-signed` and `grub-efi-amd64-signed` packages where investigated
   with `defconf-show` command. No `debconf-set-selections` options available
   like `locales` and `keyboard-configuration` packages.


   * What was the outcome of this action?
Maintainer: apt installing `shim-signed` and `grub-efi-amd64-signed` packages
failed to install a working SecureBoot capable grub bootloader.

Me: Both removable and non-removable SecureBoot `grub-install` command failed
to install SecureBoot capable Grub bootloader. However, `shim-signed` and
`grub-efi-amd64-signed` current status are within expectations (I don't expect
them to smartly know what I'm planning to do BUT I don't mind for having
Maintainer's expectations).


   * What outcome did you expect instead?
Maintainer:
`apt install shim-signed grub-efi-amd64-signed` should automatically installed
everything. There is no need to manually setup or mess with `grub-install`.

Me:
`grub-install` command works for removable SecureBoot should work without any
manual intervention without forcing a requirement to mess with target's EFI
nvram stats. The built-target must maintain the Linux swappable capability in
both SecureBoot and non-SecureBoot UEFI boot boundaries.

Legacy boot support is outside of this report scope (I won't be looking for
non-SecureBoot hardware around year 2022).




-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.38+15.4-7

grub-efi-amd64-signed suggests no packages.

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64-bin recommends:
ii  efibootmgr  17-1

-- no debconf information