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.
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:
Finally got the time to circle back and resolve this issue. Of course the original problem was not addressed and instead of fixing the the legacy boot problems I leaned into resolving it via EFI. I tried the approach given below and cross referenced it with other questions as well. Some other resources I found helpful:
Eventually got stuck on a "Error: no such device" grub error. Which may have been the result of my fstab file not being updated when I switched back and forth between MBR and GPT. But I was able to get things functioning with Boot-Repair (and fixing the fstab file when it mounted filesystem as read only):
https://help.ubuntu.com/community/Boot-Repair
Looks like UEFI/grub is not going to get any better with time. My takeaway are this:
User contributions licensed under CC BY-SA 3.0