On Mon, Apr 11, 2016 at 8:56 PM, Adam Carter <adamcart...@gmail.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
