Managing EFI Boot Loaders for Linux:
Using GRUB 2

by Rod Smith,

Originally written: 9/23/2011; last update: 4/27/2013

I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!

Donate $1.00 Donate $2.50 Donate $5.00 Donate $10.00 Donate another value
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal
Donate with PayPal

This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.

The GRand Unified Bootloader (GRUB) is actually two boot loaders. This page describes GRUB 2, which is the current version of the boot loader. The previous page, Using GRUB Legacy, describes the previous (and now discontinued) version of the boot loader.

When to Use GRUB 2

GRUB 2 is the default EFI-mode boot loader for some distributions, including the last several releases of the popular Ubuntu Linux, the latest versions of OpenSUSE, and the newest version of Fedora (18). (The previous two releases have used GRUB 2 for BIOS but GRUB Legacy for EFI.) Therefore, GRUB 2 is—or at least should be—easy to install and use from such distributions. Unfortunately, my experience with GRUB 2's pre-2.0 beta versions on EFI-based computers has been that it is, to put it bluntly, flaky and unreliable; however, my experience is now a few months out of date. It's possible that GRUB 2 has become more reliable in its final 2.0 release. Furthermore, my worst experiences with GRUB 2 have been with Ubuntu, which splits the GRUB configuration across the ESP and the Linux /boot directory. This has the effect of doubling the chances of a filesystem error causing problems, and is, in my opinion, a poor way to configure this boot loader. On the other hand, part of the problem with GRUB 2 is that it attempts to do too much, which creates opportunities for misconfiguration and errors. This is a flaw in the basic design of the software that can be covered over by better support scripts, but not completely corrected.

GRUB 2 loads Linux kernels, FreeBSD kernels, Mac OS X kernels, and several others; it can chainload other EFI boot loaders; it includes modules to read many different filesystems; it enables you to modify its boot options at boot time; it works in both BIOS and EFI modes; it uses complex scripts that detect and configure booting of a variety of OSes; it provides an interactive text-mode shell for expert troubleshooting; and more. Some of these features duplicate functionality provided by the EFI or by OS-specific boot loaders. GRUB 2's EFI features are less well-tested than its BIOS features. In my experience, GRUB 2 is finicky and difficult to get working on EFI systems. It sometimes generates bogus error messages, produces a blank display, fails to read its configuration file, or fails to launch a selected OS. Sometimes it works fine for several boots and then, with no changes in configuration, begins to fail on some boots but not on others.

Despite its finicky nature, GRUB 2 can sometimes work well. If you install Linux in EFI mode and if the OS installer configures GRUB 2 properly, it may work adequately. GRUB 2 can also work better than ELILO or GRUB Legacy on specific systems. For instance, I've had better luck with GRUB 2 than with ELILO on my Mac Mini. On UEFI-based PCs, though, I prefer to use the kernel's EFI stub loader, ELILO (with a separate boot manager, if necessary, to enable choosing non-Linux OSes), or GRUB Legacy, even when the distribution installs GRUB 2.

Installing GRUB 2

GRUB 2 installation works just as described in EFI Boot Loader Installation. It can be installed in either of two ways, depending on the way in which the program was compiled:

The first method has been less reliable for me. Splitting the files required for basic boot loader operation across two partitions means that the boot loader will stop working if either partition is damaged or deleted. If this happens, the user will be greeted by a grub> prompt—a useful tool for experts, but a sure way to cause panic among less technically-savvy users, including many of those drawn to Ubuntu! Keeping all files required for boot-time operation on the ESP, by contrast, means that the boot loader will continue operating even if you delete Linux or suffer serious filesystem damage on Linux. In sum, configuring GRUB 2 as Ubuntu and OpenSUSE do is shortsighted, in my opinion.

Typically, you must compile GRUB 2 from source code to get the second method working, which complicates setup. (Fedora 18 is an exception to this rule, though.) When the configuration and support files reside entirely on the ESP, GRUB 2 seems less finicky and is easier to get working. This page describes GRUB 2 compilation and setup in more detail than I can describe here, so I recommend you consult it if you want to attempt this method of installation and configuration. (That page in turn recommends using another page instead, but the second page is very Ubuntu-specific and describes Ubuntu installation generally, not GRUB 2 specifically.)

Since GRUB Legacy, ELILO, rEFIt, rEFInd, and gummiboot all read their configuration files from the ESP, they can't suffer from the problem of a split configuration that plagues too many GRUB 2 installations. Only GRUB 2, configured to place its support files on a Linux partition, suffers from this deficit.

Whether you use a version of GRUB 2 that's configured to look for its support files on the ESP or on a Linux partition, the software can load the Linux kernel from just about anywhere—the ESP, a Linux partition, or even from a RAID or LVM partition. Most commonly, the kernel and initial RAM disk will reside in the Linux /boot directory. (Note that reading a kernel from somewhere other than the ESP isn't a problem by the preceding analysis—GRUB 2 can still boot other OSes even if it can't access a Linux kernel file, so long as its own configuration and support files reside on the ESP.) This is arguably GRUB 2's greatest strength; no other boot loader can read Linux kernels from such a wide variety of locations.

Developers for Red Hat/Fedora, SUSE/OpenSUSE, and Ubuntu have been hard at work incorporating Secure Boot support into GRUB 2. Depending on the implementation, a Secure Boot setup that incorporates GRUB is likely to boot only kernels that have been signed by the distribution's maintainer, or perhaps by another entity (which can include you). Actual installation on a Secure Boot system is likely to be handled by the OS's installer; but if you need to do it manually, you should consult my page on Secure Boot for general advice. I've seen numerous reports of GRUB 2 being reluctant to launch Windows 8 in Secure Boot mode, which of course is a serious problem.

Configuring GRUB 2

GRUB 2's configuration file, grub.cfg, can be as simple as that of GRUB Legacy; but with most installations, the auto-configuration scripts create a big file that's harder to edit by hand. If GRUB 2 is set up to look for its configuration file in /boot/grub, you should probably leave the configuration to its scripts, and create custom entries by editing /etc/grub.d/40_custom or other files. This task is too complex for me to describe in detail here (although I present one example below); consult a guide on GRUB 2 for help on this topic.

If you create or obtain a GRUB 2 binary that looks for its configuration file in the ESP, chances are the usual GRUB 2 configuration scripts won't create that file directly. (Fedora 18's GRUB 2 is an exception to this rule.) You'll then have to either copy the configuration file these scripts do create from /boot/grub/grub.cfg to the GRUB 2 directory on the ESP or create your own custom grub.cfg file on the ESP. The latter task is extremely tricky because of the many GRUB 2 options and the sensitivity of GRUB 2 to changes in its configuration file.

You can create custom GRUB 2 boot stanzas by editing the /etc/grub.d/40_custom file. If you want to add an entry for a Linux distribution other than the one that installed GRUB 2, you can cut-and-paste an existing entry from the /boot/grub/grub.cfg file and modify it to suit your needs. If you want to chainload another EFI boot loader, the following may serve as a useful starting point:

menuentry "Windows 7" {
        insmod part_gpt
        insmod chain
        set root='(hd0,gpt1)'
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi

In theory, this example should chainload to the Windows 7 boot loader on the ESP (partition 1 on the first hard disk). In practice, both my experience and posts I've seen in online forums suggest that entries like this are hit-or-miss—what works well on one system fails miserably on another.

If you make changes to /etc/grub.d/40_custom or similar files, you must type update-grub (in Ubuntu and some related distributions) or grub-mkconfig -o /boot/grub/grub.cfg to update the GRUB 2 configuration file in /boot/grub. If your setup looks for grub.cfg in the ESP, you must then copy /boot/grub/grub.cfg to the ESP.

Using GRUB 2

When GRUB 2 is launched, you'll see a menu of boot options, each named after an entry in the configuration file, as shown below. Select an option with the keyboard's arrow keys and press the Enter key to launch the associated kernel or EFI boot loader.

GRUB 2 works under EFI just like it works under BIOS

Maintaining GRUB 2

If your distribution includes scripts to maintain GRUB 2 automatically, you shouldn't need to do much to maintain this boot loader. In practice, though, you may need to tweak the configuration if you add an OS or kernel, typically by editing /etc/grub.d/40_custom or similar files, as just described.

Go on to "Using the Kernel's EFI Stub Loader"

Return to "Managing EFI Boot Loaders for Linux" main page

If you have problems with or comments about this web page, please e-mail me at Thanks.

Return to my main Web page.