In Kali, UEFI users are no longer able to boot their system:
https://bugs.kali.org/view.php?id=4956

The problem seems to come down to the fact that during initial installation,
(at least) when the install picks the new *-signed packages, they get
installed to /EFI/kali but the binary installed inside is actually
expecting the configuration file in /EFI/debian/grub.cfg.

Control: tags -1 + patch

I'm attaching a possible patch. I checked that the package builds, but I
did not test the resulting package.

Since the EFI image hardcodes the patch in the EFI partition, I modified
/etc/default/grub to contain GRUB_BOOTLOADER_ID initialized with the
value of SB_EFI_VENDOR coming from debian/rules. grub-install has been
patched to initialize the default value of its --bootloader-id parameter
with this variable.

I opted to not modify GRUB_DISTRIBUTOR since this contains the
user-visible name of the derivative and we want to keep that obviously.

Cheers,

PS: I pushed my branch here too: https://salsa.debian.org/hertzog/grub

On Fri, 7 Sep 2018 15:57:48 +0200 Raphael Hertzog <hertzog@debian.org> wrote:
installation,
get
but I
modified
been
parameter
obviously.
b

Hi Raphael,

Maybe the changes could be simplified a bit by using the Efi-Vendor
package metadata that was added in the same version?
Something like this might work:

dpkg-query -f='${Efi-Vendor}' -W @PACKAGE@-bin

Hi Luca,

I'm not quite sure what part you would like to simplify. My patches do
hardcode this value in the (generated) postinst instead but it's
effectively the same value that is injected in that field and that is
hardcoded in the postinst.

The number of lines of code is the same in both cases. Maybe you move
one line from debian/rules in the postinst, but I don't think it's
a real improvement.

Cheers,

Dear Maintainer,

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

    * What led up to the situation?
    On my server, I'd like to have the grub installed on all disks of
the RAID.
    I'd like to be able to see which disk was the system booted from.
Because of that,
    I'd like to use custom bootloader-ids to distinguish between the
boot disks.
    However, when the grub is installed with alternative bootloader-id,
it fails to locate
    its config file.

    * What exactly did you do (or not do) that was effective (or
      ineffective)?
    I installed the grub with the command:
    # grub-install --bootloader-id=debian-sda /dev/sda1
    This installs grub into /EFI/debian-sda directory including the
config file grub.cfg.
    However, the first stage of grub hardcodes the path to be /EFI/debian,
    and fails to load the config file.
    As a workaround, the config file can be manually copied into
/EFI/debian directory.

    * What was the outcome of this action?
    System failed to boot, being stuck at first stage grub prompt.

    * What outcome did you expect instead?
    First stage of GRUB should correctly locate the config file grub.cfg
according to
    the bootloader-id and proceed to the second stage.

*** End of the template - remove these template lines ***