Recently upgraded on my servers from Ubuntu 14.04 to 18.04. After the usual amount of UEFI caused grub installation errors I eventually got the OS installed. However the UEFI doesn't see the drive with the OS installed as a boot option. If I manually select the dive though, it boots up just fine. Given it worked before I assume something is configured incorrectly on the drive it self.


Seems the OS doesn't see UEFI, though it is an option on this system:

# efibootmgr
EFI variables are not supported on this system.

OS installed on /dev/sdg

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.8G     0  7.8G   0% /dev
tmpfs           1.6G  1.5M  1.6G   1% /run
/dev/sdg4        45G  9.3G   34G  22% /
tmpfs           7.8G  8.0K  7.8G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sdg2        33G   58M   31G   1% /home
/dev/sdg3        33G  2.4G   29G   8% /srv
/dev/loop0       91M   91M     0 100% /snap/core/6350
/dev/loop1       98M   98M     0 100% /snap/docker/384
/dev/loop2       90M   90M     0 100% /snap/core/7917
/dev/md127       26T   15T   11T  59% /mnt/storage
tmpfs           1.6G     0  1.6G   0% /run/user/1000

I switched over to MBR thinking it might be having trouble with GPT.

# fdisk /dev/sdg

Welcome to fdisk (util-linux 2.31.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sdg: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot     Start       End  Sectors  Size Id Type
/dev/sdg1            2048      4095     2048    1M ef EFI (FAT-12/16/32)
/dev/sdg2            4096  69210111 69206016   33G 83 Linux
/dev/sdg3        69210112 138416127 69206016   33G 83 Linux
/dev/sdg4  *    138416128 234438655 96022528 45.8G 83 Linux

I am not 100% sure that first partition is of the correct type, but again, everything boots just fine when I manually select the drive. Thoughts?

More debugging thanks to grawity. lsblk and blkid seem to have no idea what that first partition is. However, gparted shows it as:

grub2 core.img

Thinking that was supposed to be /boot?


If I manually select the dive though, it boots up just fine

In the UEFI boot menu, whole-disk entries almost always represent "legacy mode" or BIOS-style booting. You aren't booting from the EFI System Partition; you are booting from the MBR bootcode.

This is why the OS cannot access EFI variables – it is not possible to call EFI Runtime Services when the OS has been booted in legacy/BIOS/CSM mode.

I am not 100% sure that first partition is of the correct type

The partition table entry is correct (EF for MBR tables, although you would be fine with GPT as well – after all, GPT is originally an EFI thing).

However, the partition contents are unclear: your df output doesn't show it as mounted anywhere, so it's unknown whether it was formatted with the correct filesystem, nor whether it has the right files inside.

Installing GRUB for UEFI

Make sure the EFI partition is actually formatted as FAT32 by running lsblk -f or sudo blkid -c /dev/null. (Ignore what fdisk shows.)

Mount it at /boot/efi, then install the EFI version of GRUB:

grub-install --target=x86_64-efi --removable --efi-directory=/boot/efi

Since you currently cannot access EFI boot variables, the --removable mode will instead set up GRUB at the "fallback" location (EFI/Boot/Bootx64.efi). This should allow the disk to show up as an UEFI-mode entry in the firmware boot menu.

After reboot, depending on motherboard, you might see two entries, for example:

Disk 0: Samsung 1234567
UEFI: Disk 0: Samsung 1234567

Here the 1st entry is for BIOS boot, the 2nd is for UEFI boot using the "fallback" Bootx64.efi loader. Select the 2nd one if it shows up.

If in doubt, dig through the UEFI settings and disable all "CSM" or "Legacy boot" options, or set the boot mode to "UEFI only" (the option name varies).

As soon as you're able to access EFI variables using efibootmgr, re-install GRUB without the --removable option, so that the proper boot entry will be set up.


However, gparted shows it as "grub2 core.img"

Thinking that was supposed to be /boot?

No. This looks very much like a "BIOS boot partition" used when you install GRUB's BIOS version into a GPT partition. On GPT disks it has a different partition type from "EFI system partition", and on MBR disks it's not used at all.

(And no, the "BIOS boot partition" is not /boot; it has no filesystem at all, just a raw chunk of GRUB's bootcode that leads it to the actual /boot.)

Also, looking again at your earlier fdisk output, it is only 1 MB in size – apropriate for GRUB's "BIOS boot partition", but much too small for an "EFI system partition" (which should be in the range of 100–500 MB).

In short, your partition layout is only suitable for BIOS-mode installation, not for UEFI-mode, and merely setting a new partition type won't fix that. Your original issue that "UEFI is not seeing the OS" is completely normal, as there was no UEFI-compatible OS on the disk. (As it's Ubuntu, I am guessing you have this because Ubuntu 14.04's installer back then did not support UEFI installation yet.)

You can leave the system as-is, since it boots normally in BIOS-mode. But if you really want to convert it to UEFI-mode, you will need to:

  1. Change the current partition 1's type to something else. (There is no MBR partition type ID for GRUB's BIOS boot partition, so just pick whatever – or delete the partition outright as GRUB does not use it anyway.)
  2. Create a new ~200 MB partition to act as the EFI System Partition. (It can be located anywhere on disk so just shrink an existing partition via GParted to make space.)
  3. Make sure the new EFI system partition has the correct type ID. Format it as FAT32, configure fstab to mount it at /boot/efi.
  4. Follow the "Installing GRUB" instructions posted earlier.

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.