Dear Maintainer,

When executing grub-install, it executes the following command:

	efibootmgr -c -d /dev/nvme0n1 -p 1 -w -L debian -li \EFI\debian\grubx64.efi

And this commands adds the following entry in the efi boot variable:

	Boot0000* debian HD(1,GPT,4d9e9dd8-22f2-48e8-a855-dbdf2eea8421,0x800,0x100000)/File(\EFI\debian\grubx64.efi)

But to make it works in XPS 15 9550, it should contains the device path as well:

	Boot0003* Debian-koike PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-08-0D-02-00-07-1F-00)/HD(1,GPT,4d9e9dd8-22f2-48e8-a855-dbdf2eea8421,0x800,0x100000)/File(\EFI\debian\grubx64.efi)

Otherwise the firmware doesn't find the grubx64.efi file and doesn't
boot.

Please see attached the full log of grub-install.

Thanks.

It seems this is a bug in the Dell's firmware.

Sledge helped with a workaround: configure grub to self-install in the
EFI removable media path (which is a fallback path for the firmware).

    dpkg-reconfigure grub-efi-amd64

And select Yes in "Force extra installation to the EFI removable media
path?"

Then grub will also install it self at /boot/efi/EFI/BOOT/BOOTX64.EFI

Hi Geert,

This sounds like you're seeing exactly the same problem as Helen
reported (and demonstrated to me) in #905319. The onboard nvme disk on
the XPS 15 isn't properly mapped in the firmware so that new EFI boot
variables don't work. grub-install adds an entry pointing at the first
"hard disk" which should normally work on most machines.

Pending a firmware fix, there is a workaround - install to the
removable media path too. See

https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

for more information.

Dear Maintainer,

    I have encountered a similar situation. Mine's a Dell Precision 5520 from 2018. lshw lists this as the FW info:

     *-firmware
          description: BIOS
          vendor: Dell Inc.
          physical id: 0
          version: 1.21.0
          date: 10/19/2020

    DMIDecode says something similar.

    Sledge's suggestion, namely:

https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

    worked like a charm.

    ktxbye,

Dear Maintainer,

    I have encountered a similar situation. Mine's a Dell Precision 5520 from 2018. lshw lists this as the FW info:

     *-firmware
          description: BIOS
          vendor: Dell Inc.
          physical id: 0
          version: 1.21.0
          date: 10/19/2020

    DMIDecode says something similar.

    Sledge's suggestion, namely:

https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path

    worked like a charm.

    ktxbye,

grub-install does not use efibootmgr any more.

The proposal to enable this automatically during installation is still
pending.
<https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/21>

Thanks Marcos. Could you also please fill in more of the information
that you had earlier:

 * efibootmgr output
 * filesystem layouts

Thanks!
  lists asking us to send them to you.

mdione@ioniq:~$ efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0001,0002,0003,0004,0006,0007
Boot0000* ubuntu        HD(1,GPT,127eb1be-f7c7-4a2b-9745-4cb61cba7420,0x800,0x190000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* Diskette Drive        BBS(Floppy,Diskette Drive,0x0)0000424f
Boot0002* M.2 PCIe SSD  BBS(HD,P0: WDC WDS200T2B0C-00PXH0,0x0)0000424f
Boot0003* USB Storage Device    BBS(USB,SanDisk,0x0)0000424f
Boot0004* CD/DVD/CD-RW Drive    BBS(CDROM,CD/DVD/CD-RW Drive,0x0)0000424f
Boot0005* Onboard NIC   BBS(Network,Onboard NIC,0x0)0000424f
Boot0006* Onboard NIC   BBS(Network,Onboard NIC,0x0)0000424f
Boot0007* UEFI: SanDisk, Partition 1    PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/HD(1,MBR,0x52bf7ba9,0x117c,0x4a20)0000424f
Boot0008* M.2 PCIe SSD  BBS(HD,P0: PM981 NVMe Samsung 512GB,0x0)0000424f
Boot0009* debian        HD(1,GPT,127eb1be-f7c7-4a2b-9745-4cb61cba7420,0x800,0xbe5e)/File(\EFI\debian\shimx64.efi)

    This machine used to run Ubuntu, but not the disk (I transplanted
it). I don't know why the M.2 appears twice. The SanDisk is the USB
stick I have booted from with a Debian installer in rescue mode. My
Debian system is the last entry.

    That was before I fixed is as above. The new output is still the
same.

    And this is my disk layout:

mdione@ioniq:~$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0  1,8T  0 disk
├─nvme0n1p1 259:1    0 23,8M  0 part /boot/efi
├─nvme0n1p2 259:2    0  1,8T  0 part /
└─nvme0n1p3 259:3    0 48,8G  0 part [SWAP]

    Let me know if you need more info.

    Cheers,

The debian boot entry number 0009 is not in BootOrder, no wonder why it
does not boot automatically. grub-install updates BootOrder to make the
debian entry first unless --no-nvram is passed, so something is wrong here.

Weird, Debian and Ubuntu EFI partitions have the same partition GUID
(PARTUUID) but different sizes.

There are two different SSDs, 2TB Western Digital and 512GB Samsung.

The EFI partition is very small. It is big enough for GRUB but not for
systemd-boot.

    ... so it's trying to boot from where, the m.2? It's the only other
thing listed there that's still available when I boot w/o the USB stick.
What would that mean? Trying to boot from the MBR?

    The ones listed above? Yes. It _is_ weird.

    Did you mean SanDisk? That's the USB stick.

    I guess I'm not using systemd-boot, so that's OK?

    Cheers,

If the UEFI firmware follows BootOrder (not all do), it first tries to
boot from a diskette drive (0001), then from the WDC SSD (0002), then
from a USB storage device (0003), then from an optical disc drive
(0004), then from the network (0006, then from the Sandisk USB drive (0007).

No, it tries to boot from the "removable media path"
/EFI/boot/bootx64.efi in the EFI partition.

No, I mean "WDC WDS200T2B0C-00PXH0" and "PM981 NVMe Samsung 512GB".

Yes, unless GRUB monolithic image grows ridiculously big or eventually
switches to the BLS (Boot Loader Specification) which needs to put
kernel images and initramfs's into the EFI partition.