Coping with the UEFI Boot Process
The UEFI boot specification offers new capabilities – and new headaches if you aren’t ready for it. Learn how one Linux user came to a truce with the new sheriff.
Some firsts you should never forget: first car, first computer, first kiss. However, one of these first shouldn’t be how you borked your new laptop’s partitions. Unfortunately, I had that experience because I was just a bit too casual while installing Kubuntu 12.04 dual-boot with Windows 7.
The main reason I had problems was that the laptop and the original preinstalled Windows 7 system were configured to use UEFI, and the new Linux, which I added later, was not UEFI-aware.
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 EUR 200, 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. EFI-capable shells do already exist – well, except on my laptop – but you don’t need to be content with whatever shell was shipped with your UEFI installation: You can either get a new one or write your own. The Tianocore project provides an EFI-capable shell that is referenced at the Arch Linux site. The Tianocore shell includes several options that I currently have no use for but that might come in handy in the future. With this shell, it is possible to select a new boot-loader manually, do directory listings, edit text files, or remove files.
When starting your shell, you need a starting point. Oddly enough, when running my shell, the current working directory is not actually on any of the filesystems, which causes an error for each command. To create a directory listing or change to a different directory, you just select the filesystem first.
This shell was created, giving a very MS-DOS feel to it. For example, to change to a filesystem, you simply select the filesystem number:
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.
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:
- GPT partitioned
- UEFI filesystem
- Non-functional Windows installation
- 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 Kubuntu 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 Kubuntu with EFI support
4. Save all EFI configuration from Kubuntu install
5. Restore disk image for drive 0
6. Restore Kubuntu 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 Kubuntu 12.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.
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 Kubuntu.)
Install Kubuntu 12.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 Asus, 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 Kubuntu 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 Kubuntu 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:
dd bs=1M if=/dev/sdX of=/media/usbdevice/saved-image
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 Kubuntu bootloader setup has been lost. This has nothing to do with Microsoft or Windows but rather how I backed up the disk.
Restore the Kubuntu EFI Configuration
The laptop was booted with Kubuntu 12.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 laptop and start Linux or Windows 7.
 Basic instructions for using UEFI (shell command list)
 How BIOS works
 Boot initialization
 Evolution of BIOS
 Windows and GPT FAQ
 Size of GPT partitions
 Operating systems that work with GPT
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.
Founder of ownCloud launches the Nextcloud project.
Will The Machine change the way future programmers think about memory?
The new Torus distributed storage system is available under an open source license on GitHub
Juries decides Google’s use of Java APIs Was Fair Use
But if you are not using the latest Linux kernel, your system is insecure.
Home routers will give room for custom firmware but still comply with FCC rules