On Mon, Aug 22, 2016 at 1:24 PM, James A. Peltier <jpeltier at sfu.ca> wrote: > > > When running grub2-install from within recovery mode I can assure you it is not a user error because simply installing the grub2-efi-modules package allows for grub2-install to work. No, this logic is flawed. Running grub2-install is obsolete on UEFI, it only applies for users who know exactly what they're getting themselves into and have a use case for modules in grub2-efi-modules that are not already in the grubx64.efi binary that's included in the grub2-efi package. If you run grub2-install, it blows away that grubx64.efi from the grub2-efi package in favor of a custom built one, which has completely different and for the most part undocumented behavior. For example the grubx64.efi bootloader in grub2-efi expects to find grub.cfg on the ESP in the same directory as the grubx64.efi binary. If you run grub2-install, the resulting grubx64.efi expects to find grub.cfg in /boot/grub2/ which is on your boot volume, not the EFI System Partition. If this is UEFI system with Secure Boot enabled, the grub2-install created grubx64.efi is not signed, so it'll fail Secure Boot unless you go down the rabbit hole of signing it yourself. Whereas the CentOS supplied grubx64.efi in the grub2-efi package is already signed. And so on. How are you booting the CentOS installation media? How was that media created? This matters because it's possible to end up with a CSM-BIOS boot inadvertently, and the installer will install a grub for BIOS firmware, and not the entirely separate bootloader for UEFI. So it might be worth booting from that install media, and get to a shell and check if in fact this is an UEFI mode boot by running efibootmgr. If you get an error message, it's not a UEFI mode boot, it's using CSM-BIOS mode, and that would explain why the wrong bootloader is being installed by the installer. -- Chris Murphy