Managing EFI Boot Loaders for Linux:
Using GRUB 2

by Rod Smith,

Originally written: 9/23/2011; last update: 7/7/2018

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

Overall, conditions when you might want to consider using GRUB 2 include:

Conditions in which GRUB 2 may not be the best choice include:

GRUB 2 is the default EFI-mode boot loader for many distributions, including current releases of Ubuntu, OpenSUSE, and Fedora. Therefore, GRUB 2 is usually easy to install and use from such distributions. If you install Linux in EFI mode and if the OS installer configures GRUB 2 properly, it is likely to work adequately. Its biggest flaw is that its support scripts tend to get hung up on complex configurations—for instance, when you install multiple Linux distributions on one computer. In general, I prefer to use the kernel's EFI stub loader in conjunction with an EFI boot manager (typically my own rEFInd) on such computers.

Installing GRUB 2

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

The second and third methods have 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.

Typically, you must compile GRUB 2 from source code to get the first method working, which complicates setup. (Fedora 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 if you're trying to set things up manually. 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.

The grub-install script will install GRUB 2 on most systems, provided the relevant packages have been installed using your package manager. This script can greatly simplify installation or re-installation. Of course, since many distributions install GRUB 2 automatically as part of the OS installation, you may not need to to anything at all to install GRUB 2. The Boot Repair tool also deserves mention. This is a popular tool in the Ubuntu community; it will install or re-install GRUB 2 and automatically repair some common configuration problems. Boot Repair is not 100% reliable (no automatic repair tool can make that claim), but it is useful in many situations. I don't know how well it deals with non-Ubuntu distributions, though, so you may want to be cautious about using it with them.

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'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 10" {
        insmod part_gpt
        insmod chain
        set root='(hd0,gpt1)'
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi

In theory, this example should chainload to the Windows 10 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.

Additional GRUB 2 options and defaults are stored in other configuration files. Most importantly, /etc/default/grub includes several GRUB 2 global defaults, such as its menu timeout value and which entry it launches by default.

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.

Instead of or in addition to manually editing configuration files, you may want to use the GRUB Customizer tool. (See here for an Ubuntu PPA of this tool.) GRUB Customizer provides a GUI method of selecting boot options that will then be written into the GRUB configuration file.

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

copyright © 2011–2018 by Roderick W. Smith

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

Return to my main Web page.