Restoring UEFI Boot Entry after Ubuntu Update

From Thomas-Krenn-Wiki
Jump to navigation Jump to search

The grub-efi-amd64 update package on 64-Bit Ubuntu 12.04 (Precise Pangolin) with software-RAID causes a problem where a previous manually created EFI boot entry becomes lost. Therefore, due to the failure of the first hard drive software RAID, the system is not able to boot from the second hard drive.

Problem

The system being used has two hard drives installed that are mirrored with Linux Software RAID 1 (md). In this case, two EFI System Partitions (ESP) are required. In our case /dev/sda1 and /dev/sda2 with a FAT32 file system. To our knowledge, EFI System Partitions can not be mirrored with Linux Software RAID. Therefore, only an EFI system partition is created on the first hard disk /dev/sda1 and mounted as /boot/efi. The following procedure has been chosen in order to allow booting from the second drive:

mount | grep sda1
sudo umount /boot/efi
sudo mkfs.vfat /dev/sdb1
sudo parted /dev/sdb set 1 boot on
sudo mount /dev/sdb1 /boot/efi
sudo grub-install --bootloader-id ubuntu-hdd2 /dev/sdb
sudo umount /boot/efi
sudo mount /boot/efi

This creates another UEFI BIOS entry called "ubuntu-hdd2".

The grub-efi-amd64 update package process leads to the following output:

...
Setting up grub-efi-amd64 (1.99-21ubuntu3.4) ...
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0003,0006
Boot0001* ubuntu-hdd2
Boot0003* Hard Drive 
Boot0006* UEFI: Built-in EFI Shell 
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0003,0006
Boot0003* Hard Drive 
Boot0006* UEFI: Built-in EFI Shell 
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0003,0006
Boot0003* Hard Drive 
Boot0006* UEFI: Built-in EFI Shell 
Boot0000* ubuntu
Installation finished. No error reported.
Generating grub.cfg ...
...

As is seen in the output, the two original existing entries (ubuntu, ubuntu-hdd2) are removed and then restored only as "ubuntu".

Solution

To restore the UEFI boot entry for the second hard disk a similar installation is required:

 mount | grep sda1
 sudo umount /boot/efi
 sudo mount /dev/sdb1 /boot/efi
 sudo grub-install --bootloader-id ubuntu-hdd2 /dev/sdb
 sudo umount /boot/efi
 sudo mount /boot/efi

Using the efibootmgr -v commands can then test whether both HDDs are actually contained in the UEFI Boot Manager.

sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0004,0003,0001,0000,0002,0005
Boot0000* ubuntu	HD(1,22,f4241,7354423e-45c7-48fc-83ed-b6bd42e11e42)File(\EFI\ubuntu\grubx64.efi)
Boot0001* ubuntu-hdd2	HD(1,22,f4241,E88d9466-bf9d-4a0f-aae7-ec831a74b0f4)File(\EFI\ubuntu-hdd2\grubx64.efi)
...

With the command gdisk you can check the GUID of the EFI Service Partition and compare them with the output from efibootmgr.

sudo gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.1

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

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-6): 1
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: E88D9466-BF9D-4A0F-AAE7-EC831A74B0F4
First sector: 34 (at 17.0 KiB)
Last sector: 1000034 (at 488.3 MiB)
Partition size: 1000001 sectors (488.3 MiB)
Attribute flags: 0000000000000000
Partition name: ''

Command (? for help): q


Foto Christoph Mitasch.jpg

Author: Christoph Mitasch

Christoph Mitasch works in the Web Operations & Knowledge Transfer team at Thomas-Krenn. He is responsible for the maintenance and further development of the webshop infrastructure. After an internship at IBM Linz, he finished his diploma studies "Computer- and Media-Security" at FH Hagenberg. He lives near Linz and beside working, he is an enthusiastic marathon runner and juggler, where he hold various world-records.


Related articles

Extreme Privilege Escalation UEFI Security Vulnerability
GUID Partition Table information
Introduction to the Unified Extensible Firmware Interface