Using Linux with EFI, Part III: Installing Linux on an EFI Computer

Roderick W. Smith

Issue #215, March 2012

This installment covers booting in EFI mode, quirks of different distributions in EFI mode and converting a BIOS-based installation to boot in EFI mode.

In Part II of this series in the January 2012 issue, I described the prerequisites for installing Linux on a computer that uses an Extensible Firmware Interface (EFI) or Unified EFI (UEFI) as opposed to a more traditional Basic Input/Output System (BIOS) firmware. If you're lucky, you might be able to forego some of these preparatory steps, because your distribution's installer might boot properly and manage the steps correctly. All too often though, Linux distributions handle these tasks poorly enough that you'll want to prepare your computer first by partitioning manually and determining how to boot your computer in UEFI mode for installation—or in BIOS mode, in some cases.

In this article, I look at the nuts and bolts of installing Linux on an EFI-based computer. The topics I cover are booting in EFI mode; quirks of Debian, Ubuntu, Fedora and OpenSUSE in EFI mode; and converting a BIOS-based installation to boot in EFI mode. My next article will conclude this series with a look at the tools and techniques you can use to troubleshoot and keep an EFI-based Linux installation working correctly.

Booting in EFI Mode

In most cases, launching a Linux installer on an EFI-based computer is just like launching the same installer on a BIOS-based computer. You insert the disc, boot the computer and perhaps select a boot-time option to boot from the optical disc rather than from a hard disk. On most UEFI-based PCs, you must be sure to use a 64-bit version of your distribution; the 32-bit versions usually lack EFI boot files, and such files generally are useful only on early Intel-based Macs in any event.

Unfortunately, the fact that most EFI implementations provide a BIOS compatibility mode (also known as a Compatibility Support Module, or CSM) can make it hard to control whether your computer boots using EFI or BIOS mode. I've heard of some implementations that provide such poor control that the only way to switch modes is to employ tricks like rebuilding the installation medium to omit the files for the mode you don't want to use! In most cases though, firmware boot options provide some way to launch the disc in one mode or another (as described in Part II of this series).

Some distributions, such as Debian, don't yet ship with any EFI boot support, at least not for the x86-64 platform. With such distributions, you have three choices:

  • You can install Linux in BIOS mode and continue booting in BIOS mode, ignoring the computer's EFI features.

  • You can install Linux in BIOS mode and then convert the working installation to boot in EFI mode, if this is necessary or desirable.

  • You can install an EFI bootloader on your hard disk or installation medium and use that to boot the installer in EFI mode. (Part II of this series covered EFI bootloader installation.)

Which method works best depends on your computer and your needs. For instance, BIOS-mode booting is usually fine for a Linux-only installation, although it's a bit slower than a native EFI boot. You even can use the GUID Partition Table (GPT) on your disks, if necessary. If you have a working EFI-mode Windows installation though, switching between EFI- and BIOS-mode boots for the two OSes may be awkward.

If you're not sure whether your distribution supports EFI-mode boot, you can check the files on the installation disc. Discs that support EFI-mode boots typically include files with names that end in “efi”, such as boot/x86_64/efi (OpenSUSE) or EFI/BOOT/BOOTX64.efi (Fedora or, in all lowercase, Ubuntu). In actuality, EFI-bootable discs use a secondary El Torito entry, so these files might not be present in the main ISO-9660 filesystem, but they usually are. If you don't see such files, you can try booting the disc, but if it boots, you might be left with the question of whether it booted in BIOS mode or in EFI mode. To make this determination, try this:

  1. Boot the installation disc.

  2. Switch to a text-mode console by pressing Ctrl-Alt-F2 (or some other function key, if F2 doesn't work).

  3. Type dmesg | grep EFI.

If the dmesg command produces no output, or perhaps just one or two lines, you've booted in BIOS mode. If the dmesg output includes numerous lines, most of which relate to memory mappings, you've booted in EFI mode. An example EFI boot might include lines like these (the full output is much longer than this):

[    0.000000] Command line: BOOT_IMAGE=
               atapi2:\EFI\ELILO\bzImage-3.0.4
	       root=/dev/seeker/u1104  ro
[    0.000000] EFI v2.00 by American Megatrends
[    0.000000] Kernel-defined memdesc doesn't match
               the one from EFI!
[    0.000000] EFI: mem00: type=3, attr=0xf, range=
             [0x0000000000000000-0x0000000000048000)
	       (0MB)

Once you've verified that you've booted in EFI mode, you can press Alt-F7 (or Alt-F1 in Fedora) to return to the installer and proceed with installation. Alternatively, on some systems, it may be easier to install Linux in BIOS mode and then install an EFI-capable bootloader to enable the computer to boot in that way. Such a switch is especially likely to be useful with Debian and Ubuntu installs, as I describe shortly.

Debian's EFI Support

As of version 6.0.3, you can install Debian on an EFI system in EFI mode, but only by adding your own EFI bootloader; the standard install DVD image lacks this critical feature. To do a native EFI installation, you can install ELILO (or another bootloader, if you prefer) to the computer's EFI System Partition (ESP), as described in Part II of this series. You must copy the vmlinuz and initrd.gz files from the disc's install.amd subdirectory (assuming an x86-64 installation) as the kernel and initial RAM disk files. You can omit the root= line in the elilo.conf file.

Unfortunately, the reward for making this extra effort is an installer that runs but has some serious bugs, which are identical to those for Ubuntu. I describe them shortly in the Ubuntu section, because Ubuntu officially supports booting its standard installation discs in EFI mode. In addition, the Debian installer installs a BIOS version of GRUB, so you'll need to install an EFI-capable bootloader manually when you're done.

Instead of installing Debian in EFI mode, it's usually easier and safer, particularly for multiboot systems, to install the OS in BIOS mode, install an EFI-enabled bootloader, and then switch the computer into EFI boot mode to use the computer in this way. I cover this procedure in more detail later.

Debian's repositories include ELILO (elilo), the EFI-enabled version of GRUB 2 (grub-efi) and rEFIt (refit), so you can install any of these via packages. However, you will need to copy the relevant files to the ESP, as described in Part II of this series.

Ubuntu's EFI Support

As of version 11.10, Ubuntu can install directly in EFI mode, and on a single-boot computer, such an installation can work fairly well. One important caveat exists: if you use the advanced partitioning option (called “Something Else” on the “Installation Type” screen), you must identify the ESP as such by selecting the ESP, clicking Change and selecting “EFI Boot Partition” in the “Use As” field, as shown in Figure 1. If you don't identify the ESP in this way, the installer won't install the bootloader to the ESP, rendering the system unbootable. If this happens, you can install a bootloader using an emergency boot system.

Figure 1. Ubuntu identifies the ESP as an “EFI boot partition”.

Another problem is that if you don't create an ESP before you begin the installation, Ubuntu creates one that's on the small side—often well under 100 MiB, depending on your hard disk's size. Such a small ESP is fine if you use Ubuntu's GRUB 2 bootloader, but not if you use ELILO. Thus, I recommend creating an ESP before you begin the Ubuntu installation process.

More serious complications arise in a multiboot environment. Specifically, when you properly identify the ESP, Ubuntu creates a fresh FAT-16 filesystem on the ESP. This has two undesirable consequences:

  • If you install Ubuntu after another OS, the Ubuntu installation process destroys your existing OS's bootloader.

  • If you install Ubuntu before Windows 7, the Windows installer may not like the fact that the ESP uses FAT-16—Windows 7 is a stickler for the ESP being FAT-32. The result is that Windows either will complain that there's no ESP or it will create a new ESP, proceed most of the way through the installation and become confused late in the process. Either way, the result is a failed Windows installation.

Several workarounds to this problem exist, such as:

  • You can install Windows (or any other OS) first, back up the ESP, install Ubuntu, and then restore the backed-up ESP files atop the Ubuntu ESP files. This procedure works well, but it leaves the ESP as a FAT-16 partition, which could cause problems if you need to re-install Windows in the future.

  • You can install Ubuntu first, back up its ESP, create a fresh FAT-32 filesystem on the ESP, restore the ESP files, edit /etc/fstab to mount the ESP using its new UUID value, and then install your other OSes.

  • You can install Ubuntu and deliberately not identify the ESP, or you can install it in BIOS mode rather than in EFI mode. Either way, this will leave the ESP untouched. You then will have to install a bootloader manually.

  • You can prepare a FAT-32 ESP, and when you install Ubuntu, deliberately not identify the ESP. Once you've passed the partitioning screen, press Ctrl-Alt-F1 to open a text-mode terminal and manually mount the ESP at /target/boot/efi. The installer then will add Ubuntu's GRUB 2 to the ESP but leave its existing contents untouched. In many ways, this is the best solution, but it requires that you be prompt in manually mounting the ESP.

By default, Ubuntu uses GRUB 2 as its EFI bootloader, installed from a package called grub-efi. Ubuntu also provides elilo and refit packages, should you prefer one of these bootloaders; however, Ubuntu's package management system includes scripts to update the GRUB 2 configuration when you upgrade a kernel, and these scripts won't update an ELILO configuration. Thus, if you want the easiest configuration, GRUB 2 has an edge. On the other hand, GRUB 2 is less reliable than ELILO, in my experience. Overall, I recommend you try GRUB 2, and if it gives you problems, switch to ELILO (with rEFIt, if necessary, to select a non-Linux OS).

Fedora's EFI Support

Fedora 16 provides the most complete and reliable EFI support during installation of any of the distributions described here. Unlike Ubuntu, Fedora doesn't replace a working ESP with a new one; it adds its own files to the working ESP, as a well-behaved EFI OS installer should. Fedora does, however, have a tendency to create ESPs that are on the large side—often well over a gigabyte. Also, if you install in BIOS mode to a GPT disk, Fedora mis-labels its /boot partition (or the Fedora root, /, partition if you don't create a separate /boot partition) as an ESP. This last bug doesn't affect native EFI installations.

Fedora uses a modified version of GRUB Legacy on its EFI installations. (Fedora 16 has changed to GRUB 2 for BIOS installations, but has stuck with its modified GRUB Legacy for EFI.) This configuration works well on most systems in my experience.

OpenSUSE's EFI Support

OpenSUSE 12.1 supports EFI installation, although the installer creates a new ESP even if a valid one already exists. What's more, the ESP that OpenSUSE creates is a bit small (156 MiB) and is FAT-16. As noted with respect to Ubuntu, a FAT-16 ESP can cause problems if you subsequently attempt to install Windows on the computer. You can work around some of these problems by using the manual partitioning option, but that creates other problems if you're starting from scratch. For instance, the manual partitioner sets the wrong type codes on most of the partitions it creates, and you can only force it to create a FAT-32 filesystem by making the partition bigger than about 520 MiB. Therefore, if you need to dual-boot with Windows, it's probably best to prepare your partitions before you run the OpenSUSE installer and then use the manual partitioning option to identify each partition to the installer. (You can identify the ESP by telling OpenSUSE to mount it at /boot/efi.)

OpenSUSE uses ELILO as its default EFI bootloader. ELILO generally works well, in my experience. If you dual-boot with another OS, though, you'll need to replace or supplement ELILO, since it doesn't support chainloading to another OS's bootloader.

Converting an Existing System to Boot with EFI

Because of the bugs in so many distributions' installers' EFI support, it's often better to install the OS in BIOS mode and then convert it to use an EFI bootloader than it is to install directly in EFI mode. You may need to perform such a conversion if you have a working system that you want to begin booting in EFI mode. Fortunately, Linux can switch between BIOS and EFI booting with no problems, provided you have both BIOS and EFI bootloaders installed. (If you're converting permanently, you can uninstall the BIOS bootloader when you're done with the conversion.)

If you're starting from scratch, the easiest way to proceed is as follows:

  1. Partition your disk as described in Part II, with a 200–300 MiB ESP and whatever partitions you need for Linux. If your distribution uses GRUB 2, you also should create a 1 MiB BIOS Boot Partition, which is identified by a bios_grub flag in parted or GParted or by a type code of EF02 in GPT fdisk (gdisk, cgdisk or sgdisk).

  2. Boot the Linux installer and verify that it's running in BIOS mode.

  3. Install Linux normally. The result should boot in BIOS mode, but not in EFI mode.

  4. Mount your ESP at /boot/efi, creating that mountpoint if necessary. You also should create an /etc/fstab entry to make this configuration permanent.

  5. Install an EFI bootloader. Part II of this series described how to install ELILO, but you can install another bootloader if you prefer. If you install GRUB 2 using your distribution's packaging system, the package name probably will be grub-efi, and it may replace the BIOS version of GRUB 2, grub-pc. This can render the computer unbootable in BIOS mode, so you should be careful if you use this option. Note that because efibootmgr won't work in BIOS mode, you'll probably have to install the bootloader as /boot/efi/EFI/BOOT/bootx64.efi.

  6. Reboot and activate EFI boot mode in your firmware. With any luck, you'll see your Linux bootloader and be able to boot into Linux in EFI mode. If not, Part IV of this series will provide some troubleshooting tips.

At this point, you can verify that you booted in EFI mode by examining your dmesg output, as described earlier. You then can add or change bootloaders—say, adding rEFIt if you want to dual-boot with Windows.

Next Time

Part IV of this series will cover tools and techniques to help keep your EFI Linux installation working correctly. Specific issues include kernel updates, dual-boot configurations and troubleshooting procedures.

Roderick W. Smith is a Linux consultant, writer and open-source programmer living in Woonsocket, Rhode Island. He is the author of more than 20 books on Linux and other open-source technologies, as well as of the GPT fdisk (gdisk, cgdisk and sgdisk) family of partitioning software.