I messed up the EFI partition and now when I boot my computer it opens the BIOS interface without any boot option, as if my disk has been erased. However using a live USB (which is correctly recognised and booted) and using grub command line I've been able to boot my principal OS (Ubuntu). However I don't know how to fix this problem. I've tried running grub-install /dev/sda but it didn't changed anything.

The EFI partition seems completely fine: it has the correct flag (esp, boot) and there are all the correct files inside.

tree /boot/efi/
└── EFI
    ├── Boot
    │   └── bootx64.efi
    ├── Microsoft
    │   ├── Boot
    │   .....
    └── ubuntu
        ├── fbx64.efi
        ├── fw
        ├── fwupx64.efi
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi

What I should check? What I'm missing?

This is my partition table:

parted /dev/sda print
Model: ATA Crucial_CT525MX3 (scsi)
Disk /dev/sda: 525GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  1612MB  1611MB  fat32        EFI System Partition          boot, esp
 2      1612MB  87.9GB  86.3GB  ext4         Ubuntu
 3      87.9GB  281GB   193GB   ext4         Home
 5      290GB   290GB   16.8MB               Microsoft reserved partition  msftres
 6      290GB   405GB   115GB   ntfs         Basic data partition          msftdata
 8      405GB   500GB   94.4GB  ntfs         Data                          msftdata
 9      500GB   525GB   25.3GB  ext4         Backup OS

6 Answers 6


I had to rename /EFI/my-custom-label/grubx64.efi to /EFI/boot/bootx64.efi for my Asus UEFI BIOS to start recognizing it.

This problem occurred on Asus Maximus VII Impact (Z97 chipset). My friend has a similar issue on an Z87-based Asus motherboard.


There is another issue that can cause this, which I have recently hit.

To detect this issue, boot from a Linux live and run gdisk /dev/sd[whatever-your-disk-is] , usually /dev/sda or /dev/sdb or /dev/sdc .

Give the p command to ensure you see the right list of partitions (if not, this might not be your disk).

Then give the v command. And it might respond with this:

Warning: The 0xEE protective partition in the MBR is marked as active. This is
technically a violation of the GPT specification, and can cause some EFIs to
ignore the disk, but it is required to boot from a GPT disk on some BIOS-based
computers. You can clear this flag by creating a fresh protective MBR using
the 'n' option on the experts' menu.

If this is the response, use the commands: e, n, w. Then reboot and you might have your EFI back!

  • 1
    This fixed my issue! One note: For my installation, to get to the expert menu in gdisk I needed to press 'x' instead of 'e'. FWIW, I was following these instructions when I encountered this issue: redhat.com/sysadmin/bios-uefi. My disk was already using GPT, but I wanted to switch from BIOS to UEFI boot.
    – J3RN
    May 18, 2022 at 17:40

My guess is your EFI system variables aren't being set to point to the right bootloader. The program you want to check this is efibootmgr. This will show you all of the boot entries stored in NVRAM.

In theory, grub-install should handle this, but you may not be passing the right options. This sample command SHOULD work:

grub-install --target=x86_64-efi --efi-directory=ESP_MOUNT_PATH --bootloader-id=grub

Change ESP_MOUNT_PATH to the path of your EFI dir.

If this doesn't work, you can try using efibootmgr directly:

efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/ubuntu/grubx64.efi --label "GRUB"

I think on some systems you may have to use /EFI/ubuntu/shimx64.efi. So try something like this and see what works.

  • I've tried both the commands: they worked correctly (the second had created a new boot entry which i can display trough efibootmgr ) however when I turn on my pc I get to the BIOS screen with no boot options
    – skdys
    Apr 21, 2017 at 9:46
  • Couple things: * it LOOKS ok, but can you print /dev/sda's partition table in gdisk, to make sure that has the correct partition type: EF00? * Also, check in your BIOS settings for things like 'Legacy Boot', or CSM (Compatability Support Module) - try disabling those, to force the BIOS to ONLY go for GPT/EFI boot, and totally skip its MBR booting logic - see if that helps. * Do you have any other hard drives, that may have another EFI system partition on them?
    – ceezy
    Apr 21, 2017 at 22:06

I resolved the problem simply formatting the partition (FAT32 with boot flag as obviously), mounting it and running grub-install. Then I had only to update the UUID in /etc/fstab. For Windows I had to use a USB with the installer and use the utility bcdboot to rewrite the EFI.


I also had grub not showing all partitions when booting with EFI, adding the parameter --modules="part_gpt part_msdos" to grub-install allowed it to show all partitions with ls and ls -l.


In my case I had to run gdisk to write a GPT instead of an MBR to the disk.

  • 2
    It does appear that the OP has: "Partition Table: gpt"
    – Jeff Schaller
    Jan 4, 2021 at 21:00
  • You're right, I missed that in the output of parted. But maybe I'll leave that here, because for me that solved the issue when I had the very same symptoms. Jan 4, 2021 at 22:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .