On Mon, 14 Nov 2016 14:04:41 -0800 Tianon Gravi <[email protected]> wrote: > On 4 November 2016 at 02:34, Bjørn Mork <[email protected]> wrote: > > + /bin/efibootmgr -c -l '\EFI\refind\refind_x64.efi' -L 'rEFInd Boot > > Manager' -d /dev/nvme0n1 -p 1 > > I just tested this on a friend's machine which has NVMe and uses > rEFInd and we had to change the "-d" value to be "/dev/nvme0n1p1" > (full path to the partition itself) for the entry to be created > correctly (otherwise "efibootmgr -v" afterwards shows > "HD(1,0,000...000,0x0,0x0)/File(...)" instead of the correct > "HD(1,GPT,xxx...xxx,0x800,0x200000)/File(...)", which we got after > adjusting the "-d" path). > > Rod, any ideas for why that might be the case (and how it might be > handled properly in "refind-install")? :/
I've now got a couple of systems with NVMe drives, so I've dug through the refind-install script and completely re-worked the ESP-detection code. It seems to be working now, at least for me. This is available in git commit 07d08b on Sourceforge: https://sourceforge.net/p/refind/code/commit_browser Note that I released rEFInd 0.11.5 a few days ago, and this commit is the first since then. As to efibootmgr requiring "/dev/nvme0n1p1", rather than the as-expected "/dev/nvme0n1", as an option to "-d", that sounds like an efibootmgr bug, and on my main test system (running Linux Mint 19, using efibootmgr 15-1), it takes "/dev/nvme0n1" and works correctly. -- Rod Smith [email protected] http://www.rodsbooks.com
