Re: [gentoo-user] SOLVED: NVMe drive and grub

[Poison BL.]

On Mon, Apr 11, 2016 at 8:56 PM, Adam Carter <adamcarter3@×××××.com> wrote:
>
>> The problem was sys-boot/grub-2.02_beta2-r9, which UEFI never ran.
>>
>> The fix was to get rid of grub altogether and instead use
>> sys-boot/gummiboot.
>> Not only was it fully functional, it was a welcome relief not to have to
>> grapple with grub's baroque complexity and to be able to return to the
>> simple
>> booting I remember from years ago.
>>
>> I'd spent five long days wrestling with grub, going round in circles and
>> getting nowhere, before I was pointed to gummiboot.
>
>
> I also failed to get grub2 + UEFI working. So either;
> 1. We're both dummies
> 2. The handbook instructions are incorrect and/or inadequate
>
> Can anyone else that is familiar comment on the grub2 + UEFI doc quality?

Well, the uefi related commands in the kernel build section appears to
gloss over the potential issues that having a misconfigured kernel
(notably, one lacking either a builtin root= command line or an
initramfs that will handle that) directly uefi-stub booted will bring,
and installing the kernel as bootx64.efi might be contributing to grub
itself not being loaded.

The other potential source of an issue I see is that, while the kernel
build section of the handbook appears to point towards using
/boot/efi/ for the fat32 EFI partition (presumably based on earlier
usage/recommendations/commands), the grub2 part of the bootloaders
page in the handbook gives "--efi-directory=/boot". That would cause
grub to be on the wrong partition, completely out of reach of the uefi
firmware's boot process.

If it's in the right place despite that (such as, the user noticing
the discrepancy and adjusting for it, or me assuming the effect of
that flag all wrong), it's still potentially being overridden by the
bootx64.efi file put in place in the earlier chapter, unless grub
auto-adds itself to the efi boot list with a higher priority than the
generic quasi-bios-style 'disk' boot entry (with, say, efibootmgr).

The file 'bootx64.efi' is the default that uefi looks for when booting
a 'disk' in a quasi-bios-style fallback (if there's not a real 'boot
this particular thing' like the windows boot manager adds), which also
makes the efibootmgr example that sets up a boot entry for it a little
redundant (though using efibootmgr, one could add an entry for grub to
fix the whole mess).

Of course, using efibootmgr, you could also just add entries for your
kernels, having copied them to files named something sensible in the
efi filesystem, each built with an embedded command line and/or
initramfs that's sufficient to boot, and cut out the middleman. It's a
little more 'hands on' than running grub2-mkconfig when you're
changing things around for a new kernel, though.

-- 
Poison [BLX]
Joshua M. Murphy