search

rhboot / efibootmgr

efibootmgr development tree
GNU General Public License v2.0
519 stars 99 forks source link

Wrong EFI path (Dell XPS 9350 + NVMe) #48

Closed badeball closed 8 years ago

badeball commented 8 years ago

Hello,

I am attempting to create a boot entry on my Dell EPS 9350, but the generated EFI path isn't correct and won't boot. I am using BIOS 1.3.3 (latest).

The BIOS interface for adding entries create the following entry.

Arch Linux  PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-4C-F1-B0-BD-A1)/HD(1,GPT,a651f0c4-fca9-438a-b3c1-dfb46662d91c,0x800,0x100000)/File(\EFI\arch\vmlinuz-linux)

efibootmgr with -e 3 creates the following entry.

Arch Linux  PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,a651f0c4-fca9-438a-b3c1-dfb46662d91c,0x800,0x100000)/File(\EFI\arch\vmlinuz-linux)

efibootmgr without -e 3 creates the following entry.

Arch Linux  HD(1,GPT,a651f0c4-fca9-438a-b3c1-dfb46662d91c,0x800,0x100000)/File(\EFI\arch\vmlinuz-linux)

Is this possibly related to #47?

superm1 commented 8 years ago

To be clear - you're saying that both with and without -e 3 it won't boot? Or you mean that only the entry with -e 3 isn't booting?

badeball commented 8 years ago

Yes, neither will boot. With -e 3 creates an entry that has some traces of "NVMe", but the guuid is wrong (as seen by the entry created with the BIOS interface). Without -e 3 creates an entry without traces of "NVMe" at all.

superm1 commented 8 years ago

Yeah to me it looks like the one with -e 3 is definitely wrong. Can you confirm what version of efibootmgr and efivar you have? There was bits that changed between efivar 0.23 and efivar 0.24 specifically about creation for NVMe entries, but I'm unsure if they will affect EDD built entries. If you can confirm this still happens with efivar 0.24 and efibootmgr master that would be great.

That's odd that the one without -e 3 not working though. The abbreviated path stuff definitely looks correct in that instance. Something else that was mentioned as a result of #47 is that if you have two entries that point to the same file, the BIOS does simplify the boot order and will only offer one of them. Do you possibly have some other entries in boot order (possibly that one from creating in the BIOS setup menu) that is pointing to that same file?

badeball commented 8 years ago

I've compiled and installed both efivars (efivar-git-0.24.1.gd48451f) and efibootmgr (efibootmgr-git-0.12.28.g94a9adc) from source and the results remain unchanged. There's no other entries pointing to the same file.

superm1 commented 8 years ago

Sounds like this is really two separate issues. The -e 3 one is something in the Linux stack, the non -e 3 one is something BIOS related most likely but it's not clear to me what is happening.

I don't expect that 1.4.4 should change this, but it is available on the 9350 and it would be worth double checking for completeness sake. http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=25F29&fileId=3551114498&osCode=NAA&productCode=xps-13-9350-laptop&languageCode=en&categoryId=BI You can flash it from the F12 boot menu if you put it on a FAT32 USB stick or the ESP.

Also you are adding it to the BootOrder when creating the entries right?

Lastly, can you duplicate your file (say to EFI\arch\vmlinuz-linux2 and EFI\arch\vmlinuz-linux3) and have all of your different entry attempts (one from BIOS, one with EDD3, one without EDD set) point to a different file? Then check (and share) full efibootmgr -v output. I'd like to see if the BIOS simplifies any of them into VenHw(99E275E7-75AO-4B37) or something similar.

badeball commented 8 years ago

Sure thing. I copied Arch Linux to three directories and created all entries again. I also updated the BIOS to 1.4.4 and did it again. The results remains the same, unfortunately.

Created using the BIOS interface

Arch Linux 1    PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-4C-F1-B0-BD-A1)/HD(1,GPT,a651f0c4-fca9-438a-b3c1-dfb46662d91c,0x800,0x100000)/File(\EFI\arch1\vmlinuz-linux)

Created using efibootmgr with -e 3

Arch Linux 2    PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,a651f0c4-fca9-438a-b3c1-dfb46662d91c,0x800,0x100000)/File(\EFI\arch2\vmlinuz-linux)

Created using efibootmgr without -e 3

Arch Linux 3    HD(1,GPT,a651f0c4-fca9-438a-b3c1-dfb46662d91c,0x800,0x100000)/File(\EFI\arch3\vmlinuz-linux)
vathpela commented 8 years ago

So that looks like the EUI is getting parsed wrong, and indeed that code doesn't look like it'll work right... Can you try with an efivar build with this patch: https://github.com/rhinstaller/efivar/pull/63 ?

badeball commented 8 years ago

Thanks for the response, @vathpela. However, the patch did not change the created entry. The outputs are still identical to that shown above.

krivenko commented 8 years ago

Thanks for the patch, @vathpela. I had to make one more adjustment to sysfs_parse_nvme() in order to make efibootmgr create a valid boot record on my Dell XPS 9350. The correct path to the EUI file seems to be "/sys/class/block/nvme%dn%d/eui".

badeball commented 8 years ago

@krivenko, THAT did indeed make it work for me as well!