Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
When performing a manual grub-install in a debootstrap Debian OS setup,
installing SecureBoot Grub with --bootloader-id value other than 'debian' causes
the Grub to drop into Grub Shell (failed to locate /boot/grub/grub.cfg) despite
having the UUID and root prefix values correct at /boot/EFI/<name>/grub.cfg
level.

Exact cause is unknown (still not sure what causes the drop). The only
workaround is NOT to mess with the --bootloader-id or set --bootloader-id to
strictly 'debian' as value.

The same thing happens when SecureBoot is turned off at BIOS.

Investigation steps are properly documented, made available at:
https://salsa.debian.org/-/snippets/617


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

Don't mess with --bootloader-id or set --bootloader-id to 'debian' only have
the target OS bootable and not drop into Grub Shell.

Messing it with anything else than 'debian', Grub will drop into Grub Shell.


   * What was the outcome of this action?

Option is offered but not functioning as expected. At the moment, it's
compulsory not to use that option.


   * What outcome did you expect instead?

Some unknown bug(s) are fixed or detailed documentations are published regarding
the --bootloader-id usage.

(Not replying to the submitter because gmail rejects all my mails)

This bug should be partially fixed since version 2.06-3~deb11u5 as a
lucky side effect of embedding a grub.cfg into memdisk.

The cause is well known, see #925309. (maybe merge the two bugs ?)
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925309>

An effective workaround was to copy /boot/EFI/<name>/grub.cfg into
/boot/EFI/debian/ where GRUB expected to find it.

If secure boot is disabled, another workaround was to install GRUB
without secure boot support, either by removing shim-signed or by
running grub-install --no-uefi-secure-boot.