How to get Asus motherboard to recognize EFI system partition?

Question

A short while ago I decided to resize my EFI partition. Don't ask why... Ever since, I can no longer boot normally. To resize I used gparted, and changed to partition size to 268MB. After being unable to boot I changed it back to the original 512MB without success. I am now booting my system through Super Grub Disk.

I have 2 disks in my system. 1 main GTP disk (kingston), and one with MBR (WD) just for data. Ignore the MBR one. You will also see a Transcend USB stick holding the Super Grub Disk.

My current layout for the main disk is as follows:

sudo gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/sda: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): EA79EA21-C913-462F-9A23-9CD5D1E74496
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System Partition
   2         1050624         1550335   244.0 MiB   8300  
   3         1550336       234440703   111.1 GiB   8E00  

So I clearly have the ESP on /dev/sda. This is the output of parted. To give you some info on the partition details:

(parted) print
\Model: ATA KINGSTON SH103S3 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name                  Flags
 1      1049kB  538MB  537MB  fat32        EFI System Partition  boot, hidden, esp
 2      538MB   794MB  256MB  ext2
 3      794MB   120GB  119GB                                     lvm

Now to the boot problem... When I launch my bios, I get the following boot options: (sorry for having to use pictures...)

Based on the fact the tag "UEFI" is not present for the kingston disk I think Asus did not detect this disk as GPT/EFI. Certainly since it is present for my SuperGrubDisk flash drive (which is also GPT with an ESP).

When trying to boot from the disk anyway Im presented with a black screen. That makes me assume its trying to boot from the MBR, which has nothing useful in it.

So when I launch super grub disk, I get the following options: So it looks like the ESP is right there on HD1,GPT1 as expected, and that boots perfectly fine.

I already flashed the last version of the firmware in the hopes of solving this. My last resort is backing up data and doing a full reinstall, but I want to try to solve this the right way first.

Answer 1

First, some key points about EFI-mode booting:

• EFI firmware includes a boot manager that maintains a list of bootable files and devices in NVRAM, along with a priority list of what should be booted first.
• EFI boot loaders installed by OSes are files stored on the ESP. Thus, you don't "boot a disk" or "boot a partition" the way you do under BIOS; you boot a file.
• A partial exception to the above: There's a special fallback filename (EFI/BOOT/bootx64.efi for x86-64 systems) that can be launched if no other entry is valid. This filename was originally intended for use on installation media (CDs, USB flash drives, etc.), but can also be used on ESPs on hard disks.
• Many (but not all) EFIs automatically remove boot entries from their built-in boot managers when they detect that entries are no longer valid.
• Resizing FAT partitions is unreliable, in my experience, and sometimes results in the filesystem becoming unreadable to some or all OSes. (For the purpose of this bullet point, the EFI is an OS.)
• Even if resizing is successful, it might change the GUID value of the partition, which is used as part of the path to the boot loader in the EFI's boot manager configuration.

Putting all of the above together, my suspicion is that when you resized your ESP, you rendered the Ubuntu boot loader inaccessible to the firmware, which then deleted it from its built-in boot manager. Resizing the partition back to its original size might or might not have fixed the access problem, but even if the filesystem is now accessible, with the NVRAM-based boot entry gone, you can no longer boot the boot loader -- at least, not without jumping through some extra hoops, like using Super GRUB Disk.

As a first step to fixing your problem, I recommend you run dosfsck (or some equivalent tool from another OS) on the ESP. This should fix any lingering filesystem problems.

With that done, you need to create a new NVRAM entry for the boot entry. The least intrusive way to do this is to use efibootmgr from Linux, bcfg from an EFI shell, EasyUEFI or bcdedit from Windows, or some similar tool. Since you can boot to Ubuntu now, the following command should do the trick:

efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\shimx64.efi -L ubuntu

If you're booting with Secure Boot disabled, you can change shimx64.efi to grubx64.efi; however, shimx64.efi should work with or without Secure Boot enabled, so it's best to use it unless it doesn't work. Note also the double backslashes (\\) as directory separators; EFI uses DOS/Windows-style backslashes (\) rather that Unix/Linux-style slashes (/) as directory separators, and the backslashes must be doubled up or enclosed in quotes in Bash because they're used as escape characters in Bash. (I hear that recent versions of efibootmgr can convert slashes to backslashes, but I don't know the version in which this change has appeared, so it's safest to use the doubled-up backslashes.)

A caveat: If your Super GRUB Disk is booting in BIOS/CSM/legacy mode, efibootmgr won't work. If this is true, you'll need to do the above using a Linux emergency disk booted in EFI/UEFI mode. Alternatively, you could use my rEFInd boot manager on USB flash disk or CD-R to boot Ubuntu in EFI mode, then use efibootmgr to re-activate GRUB.