Unbootable entries generated for nvme device

[xnox]

On ubuntu, grub-install in the end calls $ efibootmgr -c -d /dev/nvme0n1p1 -p 1 -w -L ubuntu -l \EFI\ubuntu\shimx64.efi

Which seems mostly alright. That generates entries in the form of: Boot0006* ubuntu HD(1,0,0,1b960301)File(\EFI\ubuntu\shimx64.efi)

Which fails to boot, however setting up the same device from tianocore boot manager results in the following entry: Boot0007* custom ACPI(a0341d0,0)PCI(4,0)03171000010000000000000000000000HD(1,800,f3800,9265fded-5be9-4265-a2c7-d5ebeba33954)File(\EFI\ubuntu\shimx64.efi)

Which does boot correctly.

How come the entries are so different?

To reproduce you can use the following:

$ qemu-img create nvme.img 10G
$ wget http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64.iso
$ wget http://de.archive.ubuntu.com/ubuntu/pool/multiverse/e/edk2/ovmf_0~20131112.2590861a-2_all.deb
$ dpkg-deb -x ovmf_0~20131112.2590861a-2_all.deb .
$ mv usr/share/ovmf/OVMF.fd .
$ qemu-system-x86_64 -pflash OVMF.fd -m 1024 -cdrom trusty-desktop-amd64.iso -drive file=nvme.img,if=none,id=D22 -device nvme,drive=D22,serial=1234 --enable-kvm

Which should boot a VM, in UEFI mode with nvme device.

[vathpela]

Yeah, looks like nvme just isn't implemented fully at all.

[xnox]

Is there anything I can write to get them supported? I do wonder where/how Tianocore defines the drives and how I can arrive at the same values from within efibootmgr. I'll poke both Tianocore & efibootmgr, but pointers as to which functions need adjustment would be useful.

[xnox]

I'm starting to read up on this as per UEFI spec:

HD(Partition,Type,Signature,Start, Size)
HD(Partition,Type,Signature) (Display Only)
The Partition is an integer representing the partition number. It is 
optional and the default is 0. If Partition is 0, then Start and Size are 
prohibited.
The Type is an integer between 0-255 or else the keyword MBR (1) or 
GPT (2). The type is optional and the default is 2. 
The Signature is an integer if Type is 1 or else GUID if Type is 2. The 
signature is required.
The Start is a 64-bit unsigned integer. It is prohibited if Partition is 0. 
Otherwise it is required.
The Size is a 64-bit unsigned integer. It is prohibited if Partition is 0. 
Otherwise it is required.

This probably means a edk2 bug as 2-4 parameters in HD(1,800,f3800,9265fded-5be9-4265-a2c7-d5ebeba33954) are not defined at all.... I wonder if i'll be able to boot with a GPT entry against this device.

[xnox]

never mind, i found the spec entry for nvme devices (UEFI v2.4A 9.3.5.22)

[vathpela]

Okay, so a couple of things upon further consideration.

HD(1,0,0,1b960301)File(\EFI\ubuntu\shimx64.efi) does look like a valid device path that should boot, except HD(1,0,0,1b960301) looks like a very unlikely device. So there's a question as to how we're coming up with that; it probably needs some local debugging.

Failing that, I've pushed a patch to add nvme support when you use "-e 3"; that should get a full device path including the NVME bits. That said, there's a reasonable chance we'll add the same (wrong) HD() entry at the end and it will fail the same way. Either way, I'd like to see if it adds the device correctly, so please give it a try and show me what it says ;)

[xnox]

1) the mystery of HED(1,0,0,.*) is solved -> it happens if i pass device /dev/nvme0n1p1 (aka first partition ~= /dev/sda1), when i pass "normal" device /dev/nmve0n1 (aka ~= /dev/sda) current efibootmanager generates a normal boot entry e.g. HD(1,800,10000, $UUID)

2) that patch is not good, and/or latest master, i get

Unknown interface type.
Unknown interface type.
BootCurrent: 0007
BootOrder: 000A,0009,0008,0007,0006
... boot entries upto Boot0005 only ...
Boot0006*
*** Error in efibootmgr: munmap_chunk(): invalid pointer: 0x00007fff9c1e21d0 ***
Aborted (core dumped)

I've stripped debugging symbols in this VM so didn't run a debugger... if you want a back trace i guess i could do that.

In the mean time, i'll go debug our installer to see why we are passing "/dev/nvme0n1p1" instead of "/dev/nvme0n1 -p 1" or somesuch.

[xnox]

core dump was with:

efibootmgr --verbose -c -d /dev/nvme0n1 --loader "\EFI\ubuntu\shimx64.efi" --label ubuntu_try_new_again

[vathpela]

A back trace would definitely help.

[vathpela]

I think this should all work in the current version. Please re-open if it doesn't.

[jscinoz]

I can confirm that this issue is still present in efibootmgr 0.12.

Correct, bootable entries added in the laptop's EFI UI directly:

PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-41-61-B2-92-E6)/HD(1,GPT,bac2dd8d-9777-487f-858e-88306848948e,0x800,0xf3800)/File(\vmlinuz-4.5.0-gentoo)

Incorrect, unbootable entries added by efibootmgr (run with -c -d /dev/nvme0n1 -p 1 -l '\vmlinuz-4.5.0-gentoo' -L "from efibootmgr"):

HD(1,GPT,bac2dd8d-9777-487f-858e-88306848948e,0x800,0xf3800)/File(\vmlinuz-4.5.0-gentoo)

[real-or-random]

Indeed, this should be re-opened. The issue is still present in version 15. The "PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-41-61-B2-92-E6)" or similar part is just missing in the created entry.