UEFI Boot Process
The UEFI boot specification offers new capabilities – and new headaches if you aren’t ready for it.
Master Boot Record
Until
recently, most computers used the Basic Input Output System (BIOS or
legacy BIOS) for managing the boot process. The BIOS performs a few
preliminary tasks and then loads the boot sector of the hard disk. This
boot sector is called the Master Boot Record (MBR). The MBR is the first
512 bytes at the beginning of the disk that describe not only the
layout of the disk (partitions), but also how to start loading the
operating system. The MBR has changed slightly over the years, but it is
not radically different from when it was first created in 1983.
The
MBR contains four primary partitions, and one of these partitions is
set as the active or bootable partition. Along with a list of the
partitions, the MBR contains a very small (approximately 440 bytes)
bootloader to load the operating system. This bootloader will find the
active partition and then proceed to execute the Volume Boot Record (the
first sector of that partition), which will continue the process of
loading the operating system.
The MBR has some
limitations that have held back progress. Two such limitations are that
the number of primary partitions is limited to four, and the size of
disk partitions is limited to 2TB. These limits were not a problem when
the MBR first appeared, but now that it is possible to purchase a 3TB
USB drive for less than Rs 10000/- , these issues have become more and more
visible.
Experts have long recognized a need to
break with the past and produce a modern, operating-system-independent
firmware with support for booting from large disks, as well as a
flexible pre-OS environment, network capability, and a modular design.
The Extended Firmware Interface from Intel is the result. An
industry-wide organization was formed in 2005 to promote adoption of the
EFI specification, and the specification was then renamed Unified EFI (UEFI).
Unified Extended Firmware Interface
The
UEFI brings the concept of the BIOS to a whole new level. Instead of a
512-byte MBR and some boot code, the UEFI, in contrast to the legacy
BIOS option, knows what a filesystem is and even has its own filesystem,
with files and drivers. This filesystem is typically between 200 and
500MB and formatted as FAT32.
Instead of a few
bytes of assembly code for loading the operating system, each installed
OS should have its own bootloader (e.g., grubx64.efi). This
bootloader will have enough logic to either display some sort of boot
menu or start loading an operating system. Basically, UEFI is its own
mini-operating system.
UEFI has thrown out the old MBR partition methodology and instead uses GPT for managing partition tables. Using GPT
eliminates the limitation on the number of partitions and also ensures
support for larger partitions of up to 9ZB. (A zettabyte is 1021
bytes.) The GPT partition is part of the UEFI standard, but it is
limited to just a list of partitions with no bootloader logic. The
specification allows for nearly an unlimited number of partitions, but
specific implementations might impose more practical limits. (Windows,
for instance, actually limits the number of partitions to 128.) Like the
MBR, UEFI marks one of the partitions with the boot flag, but this is
only the EFI partition, never any of the OS partitions.
The
general structure of the EFI filesystem means that each operating
system (or vendor) has its own directory. This directory can contain any
and all necessary files for loading the operating system:
/EFI /Boot /Microsoft/ /ubuntu /refind
Some directories have a fairly
flat hierarchy, whereas others (e.g., Microsoft’s) are less so. The
bootloader programs by default have the extension .efi; however, this is just convention: Bootloader files that are properly created and called work even without this extension.
Looking
at the EFI directory structure gives hope that, with the next install
or reinstall, another Microsoft operating system will not clobber my
existing Linux installation, but I haven’t tried that yet.
One
especially convenient thing about how UEFI has been implemented in
Linux is that, after the computer is booted up, the EFI partition, at
least in Kubuntu, is mounted under the boot partition (/boot/efi), which makes it easy to change or experiment with this filesystem.
Taking
this one step further, though, a bootloader is just a program that
performs the operation of loading the operating system. What if this
program were a shell? A UEFI-capable shell would allow the user to
interact with the UEFI system to modify boot parameters, launch
bootloaders, and obtain information on the firmware environment.
The drive designation FS0 refers to File System 0; depending on your configuration, you might also have an FS1 or FS2.
You
can register a new shell, a new operating system, or multiple operating
systems with UEFI. Thus, the computer itself can seamlessly support
multiple operating systems or shells. You have a couple of different
options for maintaining these entries.
The first would be using the Linux efibootmgr
program to manipulate entries stored in the non-volatile RAM (NVRAM).
Depending on the UEFI implementation, your UEFI might actually support
efibootmgr when booting into the UEFI/BIOS screen. The Asus N76, which
uses the Aptio UEFI-based firmware system from AMI, allows the user to
register the program directly with the option Add New Boot Option (Figure 1).
Eventually, I was able to get this to work when I stopped trying to refer to the drive explicitly (in my case, \EFI\path versus FSO:\EFI\path). It was then possible to try out new bootloaders and a shell. The path entries are relative to the installed EFI partition.
Secure Boot
UEFI
offers a lot of flexibility, more partitions, larger partitions, and an
easy and standard way for setting up multiple operating systems. What’s
not to like? Perhaps you’ve heard of UEFI’s infamous “secure boot”
feature.
Secure boot will secure the boot
process, preventing drivers or bootloaders that are not signed with a
known key. As several sources in the open source community have already
reported, this feature would effectively prevent someone from compiling
their favorite distribution and installing it on their own PC (at least
in the worse case – a somewhat better case would be if the user has the
ability to turn off the secure boot feature.)
Fixing My Laptop
My configuration was as follows:
Drive 0:
- GPT partitioned
- UEFI filesystem
- Non-functional Windows installation
Drive 1:
- MBR partitioned
- A couple of partitions full of data
- Non-functional Linux installation
The incompatibility of GPT and MBR, and my
subsequent repair efforts, left the system unbootable. When I first
added Linux, the pre-existing bootloader couldn't boot the Linux system
on the MBR-partitioned Drive 1. I tried changing the boot drive, which
gave me my Linux back–including a GRUB menu that pointed to the Windows
boot option, but Windows would not start successfully. To get Windows
back, I tried to use the Windows Restore option, but it actually caused
even more problems, eventually rendering my Linux system unbootable.
How
did I correct the problems with my dual-boot mess? The ease of my
recovery was because I had a backup image of the first disk prior to any
installation of Linux, because Linux was being installed on the second
disk, and because I recognized the need to install ubuntu with EFI
support.
The list of tasks was quite small:
1. Convert drive 1 from MBR to GPT
2. Add/modify partitions on drive 1
3. Install ubuntu with EFI support
4. Save all EFI configuration from ubuntu install
5. Restore disk image for drive 0
6. Restore ubuntu setup to EFI partition
7. Reboot and test
Note: When dealing with partitions, it is important to back up important data.
Convert MBR to GPT
The
laptop was booted with ubuntu 16.04 with a Live DVD. The partitions
were fine; the problem was the partitioning, so the easiest thing was to
use the sgdisk command to read in the old MBR partition table and write out a new GTP partition table.
It
is important to keep in mind that there must be some free space to hold
the new GPT structures. This might require resizing the first partition
to leave some space free at the start of the disk, as well as resizing
the final partition to leave some space at the end.
Once all preparation has been done, the following command performs the conversion:
sgdisk -g /dev/sdX
This command will do the proper conversion but will leave the drive without any bootable operating system.
Add/Modify Partitions
All
partitioning was done during my previous install; no additional
partitioning was necessary in this case. (You could also perform
partitioning in the step in which you install ubuntu.)
Install ubuntu 16.04 with EFI Support
This
step is easy but not 100% obvious. When you put a CD or DVD into the
optical drive and boot, the UEFI will examine what media might be
available; this could be a USB stick or a bootable DVD.
However,
at least for my lapi, both a normal MBR-bootable DVD and a
UEFI-bootable DVD were found in the list of bootable devices. Even
though both entries refer to the same disk, it is important that the
UEFI entry is chosen because the UEFI entry seems to be the trigger for
using the EFI GRUB rather than the standard MBR setup. On my Asus,
UEFI-bootable devices are prefixed with UEFI: in the boot list (Figure 2).
When you boot ubuntu as a UEFI
device, it will bring up a familiar GRUB menu list. It is possible that
any of these choices will successfully install any UEFI-compliant
system, but I chose Install Expert Mode.
The process closely follows a standard graphic installation; I set up my swap (/) and /home partitions and selected GRUB as the bootloader. The only trick for this step is how you boot the disk.
Save ubuntu Configuration Files
The
EFI partition is simply a FAT32 file system. Backing up the setup
simply means copying the files to a safe location. Simply mount the EFI
filesystem and copy the necessary files elsewhere:
mount /dev/sdX1 /mnt/mountpoint cp -rp /mnt/mountpoint/EFI/refind /media/usbstick cp -rp /mnt/mountpoint/EFI/ubuntu /media/usbstick
Note: your EFI directory will probably be partition 1, sdX1, but this doesn’t have to be the case.
Restore the Disk Image for disk1
I had never planned to make a mess of my installation, but before I started this grand adventure, I backed up drive 0 using dd:
Save: dd bs=1M if=/dev/sdX of=/media/usbdevice/saved-image
Restore:
dd bs=1M if=/media/usbdevice/saved-image of=/dev/sdX
At
this point, the laptop drive 0 has the original Windows 7 installation,
but the ubuntu bootloader setup has been lost. This has nothing to do
with Microsoft or Windows but rather how I backed up the disk.
Restore the ubuntu EFI Configuration
The laptop was booted with ubuntu 16.04 on a Live DVD for this next step.
The EFI partition is simply a FAT32 file system. Restoring the setup simply means copying the files from a safe location:
mount /dev/sdX1 /mnt/mountpoint cp -rp /media/usbstick/refind /mnt/mountpoint/EFI cp -rp /media/usbstick/ubuntu /mnt/mountpoint/EFI
After restoring these files, I was able to reboot the lapi and start Linux or Windows 7.