$esp location in Nvme devices

gohlip · 9 May 2018 04:08

Is there anyone here with nvme devices and other disks with the $esp location in the other disk and not in the nvme $esp device? If there is, also let us know if there is a windows OS and where that windows $esp is, in nvme device partition or in the other disk. Thanks.

Check-list
o nvme disk
o other disk
o uefi boots
o location of $esp
o windows OS (just tell us, not necessary to have windows)
o location of windows $esp (if any)

Background - For some topics here with boot problems on nvme disks, the case is that the $esp is set not to the nvme partition but to the other disk and boot fails. Resetting the $esp to the nvme disk partition solves the problem.

However I cannot find any (credible) link that explicitly states the $esp has to be on the nvme device (other than my posts ). So a reference to this technical restriction, if any, would be nice. Thanks.

Or debunking my 'solution' would also be nice.
(But would entail another issue how the 'solution' remedies the situation).

ps: I asked about windows is because in cases of Lenovo not accepting other uefi entries but only windows, removing windows totally (including efi files) would enable linux OS's efi file to be enabled. So I wonder if this is (somewhat) similar in the case with nvme firmware.

eugen-b · 9 May 2018 10:49

Sorry if I raise an urelated issue! I will create a separate topic to prevent yours being flooded.
Edit: I lost my clipboard. Will have to write it again.

I wanted to write that I cannot boot from an M.2 "M key" SSD which is connected to PCIe with an adapter

I cannot choose that M.2 device from mainboard's boot device selection menu (F8 after power on) even if I create an ESP on it.
However I can boot with the other M.2 "B & M key" SSD which is connected to SATA by the same adapter.

gohlip · 9 May 2018 12:17

Hi, eugen-b, it's okay for your post to be here. I think otherwise this topic will be 'sparse' anyway.
If you don't mind, I want to test the theory that my 'solution' may be wrong but just that by doing again grub-install and "efibootmgr - c -d......", it would have fixed the issue; bearing in mind our grub-install and installation may have missed up creating the efi bootentry as is in many of the cases reported on the forum.

If it don't work, then we'll fix it by setting the $esp to your M.2 “M key” SSD.
But I don't have your details (parted -l, findmnt -s, blkid, efibootmgr -v, ....) to specifically spell out the commands.

So, lets boot up your installed OS, your way or this way..
Then verify your partitions, particularly the $esp with 'findmnt /boot/efi" and do the commands...

sudo grub-install 
sudo cp /boot/grub/x86_64-efi/core.efi /boot/efi/EFI/boot/bootx64.efi
sudo efibootmgr -c -d /dev/sda -p 1 -L "manjaro" -l "\EFI\Manjaro\grubx64.efi

Note last command..."sudo efibootmgr -c -d /dev/sda -p -1 xxxxxxxxxxxxxxxx"
Change accordingly to your $esp location... based on your 'findmnt /boot/efi'

Let us know if it works.
Good luck.

ps: It's good to have anyway, if it works or not, at installed OS terminal:

efibootmgr -v
sudo parted -l
sudo blkid
findmnt -s
findmnt /boot/efi

eugen-b · 9 May 2018 12:47

I ran those first two commands back then when I tried to set up the boot device, they didn't make the machine recognise the M.2 SSD. I haven't tried the third, will do!

openminded · 12 January 2019 04:10

Hi @gohlip,
Here is what I can say according to my experience on Xiaomi Mi Notebook Pro (Insyde BIOS). By default it had only one NVME SSD with Windows, I added another SSD, M.2 SATA. Almost any Linux which I tried to install on the second SSD was trying to install its GRUB onto NVME's ESP. Even when I selected SATA's one. I don't know if it's some issue or intended behavior. By "almost any Linux" I mean Manjaro, Ubuntu, openSUSE. I don't remember what Solus and PopOS did because I tried them quite long ago, but AFAIR systemd-boot-based distros were another case -- they chose sda instead of nvme0n1. Anyway as I realised that Linux distros have this "issue" I started to install them without their bootloaders because I had Manjaro's rEFInd as preferred bootloader and I know how to write its refind_linux.conf, and that's why now I'm not sure if it still the case.

Regarding Windows.
As you already understand, I have 2 ESPs: nvme0n1p1 (for Windows) and sda1 (for Linux). I had a situation when I had to reinstall Windows and I decided to try and delete NVME partitions and see what would happen if I select empty disk when installing Windows. Long story short, it detected ESP on sda1 and used it instead of making its own. Other partitions were created on NVME device. So it seems it does not matter for Windows where the ESP is located.

Out of all spoken above, I think there is (was?) some bug in GRUB that makes it prefer NVME device for installation.

gohlip · 12 January 2019 04:07

Thanks for your feedback.

There were some in this Manjaro forum where installation proceeded with $esp in non-nvme disk. But they couldn't boot up after installation. Resetting $esp to the nvme disk solves the issue. Hence this post.

There was a case elsewhere (not in Manjaro forum, in Mageia) where a user has no problem with $esp not in nvme. But his system is an Intel NUC (barebones). Hence my suspicion on motherboard firmware. Note others (in Mageia non-NUC) also need to have $esp in nvme.

So I was thinking along the line of a firmware issue not on grub.
But your input on Windows (non-nvme $esp) is interesting and confounds our unfounded theories further.

Hope others here with nvme (I don't have nvme) can chime in.
Cheers.

openminded · 12 January 2019 04:22

You are welcome.
Oh, I forgot to mention that now, if I manually move Manjaro, ubuntu, etc folders after the installation from nvme0n1p1 to sda1 (and do some amendments via efibootmgr or BIOS), or if I install such distro without NVME device plugged in so it has to choose M.2 device's ESP, its bootloader works fine from sda then. No problem with it at all, what ensures me even more that this is some GRUB issue or something.