[CentOS] Re-enable grub boot in UEFI (Windows took over it)

Thu Feb 1 20:25:14 UTC 2018
Chris Murphy <lists at colorremedies.com>

On Thu, Feb 1, 2018 at 10:13 AM, wwp <subscript at free.fr> wrote:
> Hello Chris,
>
>
> On Thu, 01 Feb 2018 17:00:03 +0000 Chris Murphy <lists at colorremedies.com> wrote:
>
>> You can to use efibootmgr for this. NVRAM boot entry is what changed, not
>> the contents of the EFI System partition.
>>
>> efibootmgr -v
>>
>> Will list all entries and Boot Order. You need to use --bootorder to make
>> sure the CentOS entry is first.
>
> Interesting.. thanks for your reply!
>
> Too bad I never run this command when things were OK (in order to
> compare), 'cause now, what it says doesn't mention anything that seem
> related to the CentOS partition or I read wrong:
>
> BootCurrent: 0007
> Timeout: 0 seconds
> BootOrder: 0001,0002,0003,0004,0005,0006,0007
> Boot0000* Windows Boot Manager  HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
> Boot0001* UEFI: A400 NVMe SanDisk 512GB, Partition 1    HD(1,GPT,a6b87338-9b9c-4a50-8fde-2447e8fdebb6,0x800,0xfa000)/File(EFI\Microsoft\Boot\bootmgfw.efi)..BO
> Boot0002* Diskette Drive        BBS(Floppy,Diskette Drive,0x0)..BO
> Boot0003* M.2 PCIe SSD  BBS(HD,P0: A400 NVMe SanDisk 512GB,0x0)..BO
> Boot0004* USB Storage Device    BBS(USB,KingstonDataTraveler 3.0PMAP,0x0)..BO
> Boot0005* CD/DVD/CD-RW Drive    BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
> Boot0006* Onboard NIC   BBS(Network,Onboard NIC,0x0)..BO
> Boot0007* UEFI: KingstonDataTraveler 3.0PMAP, Partition 1       PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/HD(1,MBR,0x61f11812,0x800,0x737f800)..BO
>
> I don't know what 0001 and 0002 refer to exactly (there's only one SSD
> drive in this laptop).

For whatever reason the CentOS entry is missing.

Option 1:

A relatively easy cheat is to mount your root volume to /mnt and then search

grep efibootmgr /mnt/var/log/anaconda/program.log     ##this is the
path and name on Fedora, not 100% certain on CentOS

And what you'll get back is a line that contains the efibootmgr
command that was used during the installation. So you'll need to
modify the forward slashes for it to work, something like this:

sudo efibootmgr -c -w -L CentOS -d /dev/sda -p 2 -l
\\EFI\\redhat\\grub\\shimx64.efi

Option 2:

At least on Fedora 27 + Windows 10, this is what my ESP contains:

├── EFI
│   ├── Boot
│   │   ├── bootx64.efi
│   │   ├── fallback.efi
│   │   └── fbx64.efi

Those are Fedora installed default bootloaders. So if you wipe out all
the NVRAM boot entries, these get used first. And when fallback.efi
figures out that there isn't a proper NVRAM boot entry, it's supposed
to insert one, just like the Option 1 command above does. You'll use
'efibootmgr -b XXXX -B' to delete them one by one; looks like you
might be able to get away with just deleting 0001 and 0000. Of course
it means the Windows boot entry is blown away, which might make you
nervous - but the way it's supposed to work is the GRUB menu should
have a Windows boot option in it, and you just pick that for booting
Windows.


I've mainly used option 1.



-- 
Chris Murphy