UEFI not seeing bootable drive

0

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.

Info

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?

ubuntu
boot
partitioning
uefi
mbr
asked on Super User Nov 3, 2019 by Jacks_Gulch • edited Nov 3, 2019 by Jacks_Gulch

2 Answers

1

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.

Update

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.
answered on Super User Nov 3, 2019 by user1686 • edited Jun 12, 2020 by Community
0

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:

  1. Always disable secure boot before installing an OS on a computer.
  2. Disable backwards compatibility in the BIOS before installing an OS.
  3. All good Grub documentation seems to be covered up with the same "just run this command" advice. You're unlikely to learn what's actually wrong. Which leads us to...
  4. When the installer fails (because it always does) use the boot repair tool first.
answered on Super User Jun 27, 2020 by Jacks_Gulch

User contributions licensed under CC BY-SA 3.0