efibootmgr - not creating a working entry

[StefanSalewski]

I have a problem very similar to this one:

https://forums.gentoo.org/viewtopic-t-1035390-start-0.html

After reboot, i get entries like

Boot0003* vmlinux474 VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)

Is this a failure? At least I cant boot it. Have googled for hours, still no idea.

I created that entry with

efibootmgr --create --disk /dev/nvme0n1 --part 2 --label "vmlinux474" --loader "\efi\boot\vmlinux474.efi"

[StefanSalewski]

Well, some hours later... I have an entry that is not "VenHw" after reboot now. What I had discovered was, that some people use --loader and some seems to use --load. So I switched to

efibootmgr --create-only --disk /dev/nvme0n1 --part 2 --label "vmlinux474" -l "\efi\boot\vmlinux474.efi"

And indeed, there seems to be a valid entry after reboot.

[Update] Unfortunately, after trying to boot into this entry, it is again reset to "VenHw" This is for latest gentoo efibootmgr 0.13

Another similar bug report was: http://askubuntu.com/questions/729552/efibootmgr-creates-an-entry-in-which-devpath-is-set-to-venhw-istead-of-pciroot

[vathpela]

I suspect what's going on is that efibootmgr is creating an entry but your system firmware doesn't actually know about NVMe device paths, so it's deleting it and trying to boot fallback (/EFI/BOOT/BOOTX64.EFI which then runs /EFI/BOOT/fallback.efi). Fallback gets a device handle from the firmware and uses the device path from that to create a new entry, and then boots that entry.

In this case the device path from the firmware points to a vendor-specific device path, which is actually the same as an NVMe device path, just with different identifying numbers.

[vathpela]

There is also some chance you've found a buggy version of efibootmgr or one of its libraries and we're creating an invalid NVMe device path, with the same resulting behavior. If that were the case, I would expect the firmware to create an NVMe device path rather than a Vendor HW path. So it's probably the other thing.

I'm going to close this issue, as I don't think there's any action to be taken, but if I'm wrong, please feel free to re-open it.

[StefanSalewski]

Am Dienstag, den 27.09.2016, 11:17 -0700 schrieb Peter Jones:

There is also some chance you've found a buggy version of efibootmgr or one of its libraries and we're creating an invalid NVMe device path, with the same resulting behavior. If that were the case, I would expect the firmware to create an NVMe device path rather than a Vendor HW path. So it's probably the other thing. I'm going to close this issue, as I don't think there's any action to be taken, but if I'm wrong, please feel free to re-open it.

After efibootmgr was not working as expected, I switched to systemd bootmanager (called gummiboot in the past.) That one works fine with my NVMe device. Before that I also considered Grub2, but as Google told me, at least current Grub 2.02 seems to have also problems with NVMe devices.

Thanks,

Stefan Salewski