Re-enable Grub Boot In UEFI (Windows Took Over It)

Home » CentOS » Re-enable Grub Boot In UEFI (Windows Took Over It)
CentOS 7 Comments

Hello there,

Dell XPS-15-9560 laptop (SSD drive, UEFI, secure boot off).. Windows 10
pre-installed, CentOS7 installed in a separate partition and running for months w/o issue. Don’t know what happened but at reboot yesterday
(not even booted in Windows, just rebooted), grub has disappeared, booted in Windows by default, which apparently has taken over the UEFI

By booting from a USB drive w/ CentOS7 LiveGnome, I could use its grub command prompt to inspect the UEFI of the local SSD drive, see that the CentOS/ sub-directory and files are still there.

fonts grub.cfg grub.cfg.1501243846.rpmsave grub.cfg.1505469290.rpmsave grubenv grubx64.efi mmx64.efi shim.efi shimx64-CentOS.efi shimx64.efi

maybe /boot/efi/EFI/Boot/ contents has been altered?

bootx64.efi fbx64.efi

I had a backup of the full efi partition (`dd`) but it’s outdated and I feel it’s a bad idea to restore the partition from it.

Still from this “external” grub prompt, I could boot into my CentOS7
configfile (hd0,gpt1)/EFI/CentOS/grub.cfg

At least I know how to get back to it :-).

But now, how could I give the UEFI control back to grub? Is there a grub2 or grubby command I can run to make grub the default? I’ve read a lot and still cannot figure out exactly what to do or don’t dare running commands that could make things worse.

And I have the feeling the at next Windows boot, I may need to do it again..


7 thoughts on - Re-enable Grub Boot In UEFI (Windows Took Over It)

  • 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.

    Chris Murphy

  • Hello Chris,

    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.}……………….. 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

    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

  • The DELL XPS-13-9360 in its BIOS has an option (named “auto boot recovery” or similar – sorry the machine is somewhere else) that is by default enabled. I guess you have it enabled as well.

    This option is triggered by two unsuccessful boot trials, and leads to the loss of the grub menu, and restoration of the (non-grub) “Windows boot manager” (or whatever it’s called).

    After being bit by it once, I disabled it.



    P.S. I recovered my Ubuntu grub menu by booting from the Ubuntu live USB, and then sudo su mount /dev/nvme0n1p7 /mnt cd /mnt mount /dev/nvme0n1p1 boot/efi mount –bind /proc proc mount –bind /sys sys mount –bind /dev dev chroot /mnt grub-install /dev/nvme0n1

    On CentOS, the last two lines would be

    grub2-install /dev/nvme0n1
    grub2-mkconfig -o etc/grub2.cfg

  • Running this on computers with UEFI firmware is not good advice, it’s an obsolete command. People should use the prebaked grubx64.efi binary that comes in the grub2-efi package, and is a signed binary so it can support UEFI Secure Boot.

    If you run grub2-install, a new unsigned grub binary is created, replacing grubx64.efi. If you have Secure Boot enabled, you will not be able to boot, until you either reinstall the grub2-efi package (or you self-sign the grub2-install created binary and then go through the process of informing the firmware this is a valid binary by using mokutil – but I estimate maybe 1 in 50 people might do this).

  • Did you read my sentence “I recovered my Ubuntu grub menu …” and that this mentions grub-install, not grub2-install ? The procedure that I
    describe is correct for Ubuntu – see e.g.

    The important point of my posting was to tell the OP the reason and mechanism which leads to a loss of the grub menu. The OP already described how s/he got the machine to boot again.