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
  • Can you post the output from parted /dev/sda print plz? – 0xSheepdog Apr 20 '17 at 22:12
  • @0xSheepdog I added it – skdys Apr 20 '17 at 22:17

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.


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 '17 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 '17 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.


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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.