Troubleshooting and other EFI maintenance.
In my last article, I described the process of installing Linux on an EFI-based computer. With any luck, that should have gotten your system up and running; however, a number of problems can occur during or after installation. In this article, I look at these issues, as well as general EFI maintenance. Specifically, I describe how to use an emergency disc on an EFI system, how to make your firmware recognize your bootloader, how to configure GRUB and rEFIt to chainload to Windows (or to other OSes), how to update your kernel and how to deal with miscellaneous kernel problems.
If you're like me, you keep a number of Linux emergency discs on hand. These include both distribution installation discs, many of which contain recovery systems, and specialized tools, such as Parted Magic, SystemRescueCD and RIPLinuX. Such tools can be invaluable aids in recovering from various system problems.
Unfortunately, most emergency discs don't yet include EFI boot support, the rescue mode of distribution installers being an exception to this rule. Thus, if you want to use a rescue disc, such as Parted Magic, SystemRescueCD or RIPLinuX, you may need to do so in BIOS mode. This is usually not difficult. Most EFI implementations automatically switch to BIOS mode when they detect BIOS-bootable optical discs; however, some might need some coaxing to boot the disc. Check your firmware boot options if you have problems booting a rescue disc in BIOS mode.
For the most part, using a BIOS-mode emergency disc is fine. You can mount or repair your filesystems, edit configuration files, modify your partition layout and even edit your EFI bootloader configuration. There is, however, one important exception to this rule: the efibootmgr program, which you use to register a bootloader with the EFI, is useless when the computer is booted in BIOS mode. This program also is missing from the usual emergency disc programs.
If you're having problems that necessitate using efibootmgr, therefore, your best bet may be to use a distribution's installer in EFI mode. For this purpose, you even can use a distribution other than the one you normally use. Ubuntu includes a good live CD mode, and you can install software to it using apt-get, as in sudo apt-get install efibootmgr. Thereafter, you can use efibootmgr to manage bootloaders, even if your computer doesn't normally run Ubuntu.
One common post-installation problem on EFI computers is that the computer doesn't recognize your bootloader. The computer might inform you that it couldn't find a bootable OS, or it might boot directly into Windows, OS X or whatever other OS you had installed previously. Several solutions to this problem exist, such as renaming your bootloader to the default name or using efibootmgr to manage your EFI's list of bootloaders.
If no other OS exists on the computer, the simplest solution to the problem is to rename your bootloader to use the default bootloader name, EFI/BOOT/bootx64.efi on the EFI System Partition (ESP). As described in Part II of this series, this is the filename the EFI uses when you haven't registered any other bootloader with the firmware. Thus, you can rename your bootloader's default location (such as EFI/SuSE or EFI/ubuntu) to EFI/BOOT and then rename the bootloader file itself (such as grub.efi or elilo.efi) to bootx64.efi. In the case of GRUB Legacy, you should rename the configuration file from grub.conf to bootx64.conf too.
If the computer boots straight into another OS, you may be able to rename an existing EFI/BOOT directory and then rename your Linux bootloader as just described. Alternatively, you can boot Linux in EFI mode using an EFI-enabled emergency system and use efibootmgr to add your bootloader to the EFI's boot list:
efibootmgr -c -l \\EFI\\elilo\\elilo.efi -L ELILO
The details vary depending on the bootloader, of course. You may need to change the path to the bootloader, which is specified using double backslashes (\\) rather than the more conventional forward slash (/). You can use efibootmgr to manipulate the boot list in other ways too. Table 1 summarizes some of efibootmgr's options, but you can consult its man page for more obscure options.
Table 1. The efibootmgr utility manages the EFI's list of bootloaders.
| Long Option | Short Option | Description |
|---|---|---|
| --active | -a | Activates a bootloader |
| --inactive | -A | Deactivates a bootloader |
| --bootnum X | -b X | Modifies bootloaderX (hexadecimal) |
| --delete-bootnum | -B | Deletes a bootloader |
| --create | -c | Creates a new bootloader entry |
| --disk dev | -d dev | Sets the disk to modify (default is /dev/sda) |
| --loader name | -l name | Specifies a bootloader's filename |
| --label label | -L label | Specifies a label for the bootloader |
| --bootnext X | -n X | Sets the bootloader to use on the next boot |
| --bootorder order | -o order | Sets the order in which the EFI tries bootloaders |
| --part num | -p num | Specifies the ESP's partition number (defaults to 1) |
| --timeout sec | -t sec | Sets the boot managers timeout, in seconds |
| --verbose | -v | Produces extra output |
If you use efibootmgr without any options, it displays a summary of the system's current bootloaders. You can add the -v option to produce additional information. The preceding example used the -c option to create a new boot manager entry, thus adding ELILO to the list of boot options that the firmware provides. This command, though, might leave another bootloader earlier in the EFI's boot order. If you want to change that order, you would use the -o option, as in:
efibootmgr -o 5,A,3
This example tells the EFI to attempt to boot using bootloader #5; if that fails, to try #A (hexadecimal); and if that fails, to try #3. The -n option sets the bootloader to use on the next boot, overriding the default boot order for that boot.
Some options require you to use the -b option to identify a specific bootloader. For instance, if you want to give a bootloader a new name in a menu, you might type the following:
efibootmgr -b 3 -L "Windows 7"
This example gives entry #3 the label “Windows 7”.
Unfortunately, efibootmgr's effects are not 100% reliable. For instance, on one of my computers, the -o option has no real effect. I must use the firmware's own interface to adjust the boot order. More distressingly, some reports indicate that efibootmgr damages some Macs' firmware, requiring re-flashing the firmware. (The OS X “bless” utility serves a role similar to efibootmgr on Macs.) Nonetheless, it's worth trying efibootmgr if you want to add bootloaders or adjust the boot order on a UEFI-based PC.
If you're using GRUB Legacy or GRUB 2 and you want to dual-boot with Windows, you may need to add an entry to the bootloader to make it work correctly. On a BIOS-based computer, this entry would reference the Windows boot partition, where part of the Windows bootloader resides. On an EFI-based computer though, you must reference the Windows bootloader on the ESP. A suitable entry in GRUB Legacy's grub.conf file looks like this:
title Windows 7
root (hd0,0)
chainloader /EFI/microsoft/bootmgfw.efi
This entry might need to be changed if your ESP is not the first partition on the first disk, or if the bootloader isn't in its usual location. An equivalent entry in GRUB 2's grub.cfg file looks like this:
menuentry "Windows 7" {
set root='(hd0,gpt1)'
chainloader /EFI/microsoft/bootmgfw.efi
}
In GRUB 2, you probably would add such an entry to /etc/grub.d/40_custom and then rebuild grub.cfg by using update-grub or some other configuration script.
You can chainload other bootloaders in a similar way. One twist on Macs is that the OS X bootloader resides on the OS X boot partition, as /System/Library/CoreServices/boot.efi. GRUB Legacy can't mount Mac OS X's HFS+ though, so you can't chainload OS X using GRUB Legacy. GRUB 2 can mount HFS+ and so can chainload OS X in this way. GRUB 2 also can load the OS X kernel directly, and your GRUB 2 configuration scripts might create a rather wordy entry that does just that. If you want to dual-boot Linux and OS X though, rEFIt is generally the best way to do the job. It gives you a graphical menu showing OS X and your Linux bootloader.
If you use ELILO to boot Linux, you'll need to use another boot manager to boot non-Linux OSes. Although EFI implementations provide boot managers for this purpose, they're generally quite awkward, so you may want to use rEFIt to present a friendlier menu for dual booting.
As described in Part I of this series, rEFIt can chainload another bootloader, but it can't load a Linux kernel itself. You don't need to configure rEFIt explicitly to boot any OS; it scans all the partitions it can read for EFI bootloader files and generates a menu automatically. Thus, rEFIt should detect Microsoft's bootloader file (called bootmgfw.efi) and label it appropriately.
The trick is in rEFIt installation. The version available from the rEFIt Web site is a “fat binary” (32-/64-bit) that works only on Macs. To use rEFIt on a UEFI-based PC, you need a 64-bit-only version. Debian and Ubuntu both ship with such versions; check the Resources section of this article for another source.
Assuming you've successfully installed Linux on an EFI-based computer, you can use the system just as you'd use a BIOS-based installation. Most operations, including most software updates, will work just as they do on a BIOS-based computer. One possible exception to this rule is in kernel updates.
Most distributions include scripts that automatically update your bootloader configuration to add a new kernel when you install one via the distribution's package management system. This process usually works fine if you use the distribution's own bootloader; however, as detailed in previous articles in this series, you're more likely to have to deviate from your distribution's default bootloader if you use EFI than if you use BIOS. If this happens, you may need to manage the bootloader configuration yourself manually.
Details of bootloader configuration vary with the bootloader. Part II of this series described ELILO configuration, so you can use it as a reference if you use ELILO. If you use GRUB Legacy or GRUB 2, any source of documentation on those bootloaders under BIOS applies almost as well to the EFI version. The main exception is in handling chainloading, as noted earlier.
If you manage your bootloader yourself, the biggest problem is to note carefully when you upgrade your kernel so that you can make suitable changes to your bootloader configuration. If you miss an update, you'll end up booting an old kernel. If your distribution uninstalls your old kernel, your system might end up being unbootable. If you're comfortable compiling your own kernel, you might consider doing so. That should give you a kernel you manage yourself outside the package system, which should give you a secure backup kernel.
For the most part, Linux works equally well on BIOS-based and EFI-based computers. The kernel interacts directly with hardware; once it's booted, it has little need to use the firmware. There are exceptions to this rule though. Sometimes, kernel options (passed via your bootloader configuration) can be helpful. Specifically:
noefi — this option disables the kernel's support for EFI runtime services. Ordinarily, you wouldn't want to do this, but sometimes bugs cause Linux's EFI runtime services to misbehave, causing a failure to boot or other problems. Using the noefi option can work around such problems, at the cost of an inability to use the efibootmgr utility.
reboot_type=k — this option disables the EFI's reboot runtime service. This option can work around problems with failed reboot operations.
reboot=e — this option is essentially the opposite of the preceding one; it tells the kernel to attempt to reboot using the EFI's reboot runtime service. It's normally the default on EFI boots, but you can try it if Linux is rebooting improperly.
reboot=a,w — this option tells Linux to perform warm reboots using ACPI. This can work around bugs in some EFI implementations that cause a system hang when rebooting.
add_efi_memmap — this option alters how Linux allocates memory, which can avoid memory conflicts with some EFI implementations.
nomodeset — this option sometimes works around problems that cause a blank video display.
EFI implementations vary among themselves, and the Linux kernel has yet to incorporate surefire workarounds for every quirk and bug. Thus, you may need to experiment with these and perhaps with other options.
If you build your own kernel, you should be sure to include a few options:
CONFIG_EFI — this option, near the end of the Processor Type and Features kernel configuration area, enables Linux to use the EFI runtime services.
CONFIG_FB_EFI — EFI provides its own framebuffer device, and this option (available in the Graphics Support→Support for Frame Buffer Devices kernel configuration area) enables the kernel to use the EFI's framebuffer. You often can use a more device-specific framebuffer driver, but this one can be an important fallback on some computers.
CONFIG_EFI_VARS — this option, available in the Firmware Drivers kernel area, provides access to EFI variables via Linux's sysfs. You need this support to use efibootmgr.
CONFIG_EFI_PARTITION — you'll find this option in the File Systems→Partition Types kernel area. It enables support for GPT, so of course you need it to boot from a GPT disk.
Some EFI-based computers present video difficulties. Such problems are particularly common with Macs booted in EFI mode. Typically, the video display goes blank in text mode, in X or in both. Unfortunately, there's no easy solution to such problems. Sometimes though, switching bootloaders can help. You also can try experimenting with framebuffer options and your X configuration. Typing Xorg -configure as root and with X not running generates an X configuration file, /root/xorg.conf.new. Copying and renaming this file to /etc/X11/xorg.conf sometimes gets X up and running.
EFI provides a number of improvements over the older BIOS it replaces. These include quicker boot times, an integrated boot manager and the ability to manage more complex bootloaders as files on a filesystem. In an ideal world, the transition from BIOS to EFI should be painless, but in the real world, developers require time to write the software to use EFI. At the moment, all of the pieces for handling EFI exist—you have a choice of EFI bootloaders, partitioning tools exist, the Linux kernel supports EFI, and you even can use efibootmgr to configure the EFI's boot manager. Distribution maintainers, however, have not yet worked out all the kinks in integrating all of these tools. A few programs also have bugs or are awkward to use. Knowing your way around these problems will help you make the transition from a BIOS-based computer to one built around EFI. I hope this series of articles helps you with that task.