efibootmgr failing to autodetect EDD 3.0

rlees85 commented 6 years ago

Please bear with me as this could be a firmware issue with my laptop but I have absolutely no clue how to tell. I am as equally confident it could be a change/bug in efibootmgr, efivar or the Linux kernel.

Problem Brief:

When installing grub with grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck it results in an unbootable EFI boot entry.

Running efibootmgr manually adding -e 3 to the command that grub-install normally runs makes a working boot entry. As does just adding a boot entry using the firmware directly.

efibootmgr is failing to auto-detect edd 3.0

Broken Entries

grub-install creates the below, which fails:

Boot0000* grub  HD(1,GPT,a8b1f8a8-8ce6-4f0c-a2f5-0b78be2b6e2a,0x800,0x80000)/File(\EFI\grub\grubx64.efi)

Manually adding -e 3 to the efibootmgr creates the below, which works:

Boot0000* grub  PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-08-0D-02-00-30-55-62)/HD(1,GPT,a8b1f8a8-8ce6-4f0c-a2f5-0b78be2b6e2a,0x800,0x80000)/File(\EFI\grub\grubx64.efi)

Full Story

This might not be so important but I'll include it as its strange.

This used to work, on the same system. The story is as follows:

Installed Arch Linux on brand new system. Everything worked including the creation of the boot entry when running grub-install. In short, edd 3.0 autodetection USED to work on this system!
Arch Linux had been updated a few times over the period of a few months. grub, efivar and the Linux kernel had all received updates during this time without me re-installing grub!
The laptops firmware had been updated a number of times during this period. Again without re-installing grub and without any issues booting.
One day I booted Windows 10 installation media but did NOT carry out an installation. At the welcome screen I quit and powered off the laptop. The laptop then failed to boot at all.
Booting from live boot CD, chrooting in and re-installing grub (method above) to re-add EFI boot entries worked - but fail to boot.

From this point, no matter what, I cannot get valid EFI boot entries using grub-install. The ONLY way is to use the firmware directly or to manually run efibootmgr adding -e 3 to the command grub normally runs.

System Details

DMI: Dell Inc. XPS 13 9360/06CC14, BIOS 2.5.1 01/25/2018
Kernel: 4.15.10-1-ARCH

$ efibootmgr --version
version 15

efivar 34 (tried to roll back to 31 but still fails)

boot device is NVME

Further Details

get_edd_version(void)
{
    efi_guid_t guid = BLKX_UNKNOWN_GUID;
...

...

#define BLKX_UNKNOWN_GUID \
EFI_GUID( 0x47c7b225, 0xc42a, 0x11d2, 0x8e57, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)

Which seems to produce blk0-47c7b225-c42a-11d2-8e57-00a0c969723b

This variable cannot be found in /sys/firmware/efi/efivar/. No idea if it should be or not.

spagy commented 5 years ago

I seem to be having the same issue. Is there any further useful information I can provide? Or any steps I can take to help?

Perhaps this is an XPS specific issue? I have a also have a Dell XPS 13 (but the 9370 rather than 9360).

kanru commented 5 years ago

Facing the same issue.

This is the efibootmgr output after grub-install and manually add the entry via bios

% efibootmgr --verbose
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0002,0003,0004,0005,0006
Boot0000* Windows Boot Manager  HD(1,GPT,0b92c60d-fa9a-486c-91e2-3a1a6a11871b,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}..._................
Boot0001* debian    HD(1,GPT,8308d846-a622-4a0d-8de7-f4875b4ad394,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0002* Diskette Drive    BBS(Floppy,Diskette Drive,0x0)..BO
Boot0003* M.2 PCIe SSD  BBS(HD,P0: KXG50ZNV512G NVMe TOSHIBA 512GB,0x0)..BO
Boot0004* USB Storage Device    BBS(USB,USB Storage Device,0x0)..BO
Boot0005* CD/DVD/CD-RW Drive    BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0006* debian    PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-08-0D-02-00-3B-6D-86)/HD(1,GPT,8308d846-a622-4a0d-8de7-f4875b4ad394,0x800,0x100000)/File(\EFI\debian\grubx64.efi)
Boot0007* Linux Firmware Updater    HD(1,GPT,8308d846-a622-4a0d-8de7-f4875b4ad394,0x800,0x100000)/File(\EFI\debian\fwupdx64.efi)

System details

Dell Inc. XPS 13 9370 BIOS Version: 1.11.1

% efibootmgr -V version 15

boot device is NVME

spagy commented 4 years ago

Relevant thread: https://bbs.archlinux.org/viewtopic.php?pid=1856027#p1856027

vathpela commented 4 years ago

I have no idea what's going wrong here; I've tried this, but using shim rather than grub as the first stage bootloader, on the XPS-13 9350 and XPS-13 9380 with a lot of different firmware versions, and they both work with the abbreviated paths just fine. @superm1, you have any ideas here?

superm1 commented 4 years ago

Well just a wild guess based on some weird bugs I've heard in the past; does it help if you touch one of these files (no need to do them all)?

\EFI\Microsoft\Boot\bootmgfw.efi
\EFI\Ubuntu\shimx64.efi
\EFI\boot\bootx64.efi

kanru commented 4 years ago

My problem is fixed after removing all other seemly invalid boot entry. Now my XPS 9370 boots with following entries:

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000
Boot0000* debian    HD(1,GPT,8308d846-a622-4a0d-8de7-f4875b4ad394,0x800,0x100000)/File(\EFI\debian\grubx64.efi)

So it seems the firmware can boot with abbrev path but can be confused if there were some other invalid entries.

superm1 commented 4 years ago

Can you please confirm what files are actually on the ESP while that configuration is working?

kanru commented 4 years ago

I have those

└── EFI
    ├── debian
    │   ├── fw
    │   │   ├── fwupd-3b8c8162-188c-46a4-aec9-be43f1d65697.cap
    │   │   └── fwupd-7ceaf7a8-0611-4480-9e30-64d8de420c7c.cap
    │   ├── fwupdx64.efi
    │   ├── fwupx64.efi
    │   └── grubx64.efi
    └── Dell
        ├── Bios
        │   └── Recovery
        │       ├── BIOS_CUR.RCV
        │       └── BIOS_PRE.rcv
        └── logs
            ├── diags_current.xml
            └── diags_previous.xml

superm1 commented 4 years ago

OK thanks. Then I would confirm it sounds like invalid boot entries were throwing some things off perhaps.

manninej commented 4 years ago

Had the same issue with a number of Dell laptops/PCs. Updating to the latest BIOS seems to fix the issue. Edit: Actually... powering off and booting with EFI capable USB stick just nuked the boot entry. It is there when looking with efibootmgr, but wont show up in the boot menu. It is just plain gone. Reset is not a problem, coming from a power cycle is...

So -e3 seems to be the solution.

noureddine-taleb commented 3 years ago

I have the same issue with efibootmgr, my temporary workaround, is to boot into efi shell, in the Arch boot media, and add the entry from there, but later I found that the -e 3 flag solve the issue with efibootmgr, not sure if this is a bug

rhboot / efibootmgr