Migrate to GRUB 2

astrotycoon 2015-07-04

展开全文

Develop and deploy your next
app on the IBM Bluemix
cloud platform.

To most people, boot loaders aren't the most exciting aspect of an operating system, but they are extraordinarily important. Without a functioning boot loader, nothing else works. Currently, a transition from the old Grand Unified Bootloader (GRUB) Legacy tool to the new GRUB 2 is underway. GRUB 2 is the default boot loader in Ubuntu 9.10, and it's an option in most other major Linux distributions. Sooner or later, other distributions will deploy GRUB 2 as the default boot loader.

Anatomy of a boot loader

Figure 1 shows the boot process as implemented by both GRUB Legacy and GRUB 2. The basic input/output system (BIOS) is the first code to run on the computer, and it's stored in the computer's firmware. The BIOS loads the first sector of the boot device and executes the code it contains. In the case of a hard disk, this first sector is also known as the master boot record (MBR), and it contains both the first stage of the boot loader and the MBR partition table. Because most disk devices use a sector size of 512 bytes, the first-stage boot loader code must be very small. Most boot loaders, including both GRUB Legacy and GRUB 2, place additional code elsewhere on the disk. In the case of GRUB Legacy, this additional code is known as stage 1.5, and it's often placed in an unallocated area immediately following the MBR. Still more code, known as stage 2, is stored in files in the Linux boot partition (typically in the /boot directory), although Figure 1 omits these files for simplicity's sake. Likewise, in a multiple-operating system configuration, the secondary boot loader may store additional configuration files elsewhere.

Figure 1. GRUB and GRUB 2 consist of several subcomponents that are loaded and run in sequence

Block diagram of the boot process used by GRUB and GRUB 2; several subcomponents are loaded and run in squence

GRUB 2 is similar to GRUB Legacy in overall form, but it eliminates stage 1.5 and implements a modular configuration approach in which code to handle various partitioning systems, file systems, and other extensions are stored in disk files—typically, in /boot/grub.

Variants on the configuration just described are possible with both GRUB Legacy and GRUB 2. For instance, it's possible to install GRUB's stage 1 code in a Linux boot partition's first sector rather than in the MBR. Used in this way, another boot loader resides in the MBR, and GRUB's menu appears only when that boot loader chain-loads GRUB. Because the Extensible Firmware Interface (EFI), which is likely to eventually supplant the BIOS as standard PC firmware, provides a built-in boot loader, a configuration akin to this one is available for GRUB 2 on EFI-based systems.

If you want to replace GRUB Legacy with GRUB 2 on a working system, you must install a new GRUB 2 package, configure its files, and run a special command to have GRUB 2 replace the existing GRUB Legacy MBR and special hidden code with the GRUB 2 equivalents. If you're switching to GRUB 2 because you're installing a new distribution that uses GRUB 2 as its default boot loader, you shouldn't need to deal with these steps. In either case, you must understand the new GRUB 2 configuration file's format as well as the new boot loader's overall features.

GRUB 2's improvements

For Linux-only systems, GRUB Legacy handles the boot loader job perfectly well. The reason for the transition has partly to do with boot loader development. GRUB Legacy contains code that the developers consider messy and unmaintainable. To add new features, they chose to rewrite the boot loader from scratch rather than build on such a base. As a practical matter to systems administrators, GRUB 2 supports several features that are important now or that may become important in the future:

Platform support. GRUB Legacy works on x86 and x86-64 systems only. GRUB 2 is intended to work across a wider range of architectures, although documentation on using it on anything but x86 or x86-64 is scant. It does work on PowerPC? and Scalable Process Architecture (SPARC) systems, though.
Firmware support. GRUB 2 supports additional firmware types, including BIOS, EFI, and OpenFirmware. As with support for unusual CPUs, at least some support for unusual firmware is present, but you should consider it highly experimental.
Partition tables. Officially, GRUB Legacy supports only the old MBR partitioning scheme. Most Linux distributions, however, ship with versions of GRUB Legacy that incorporate unofficial GUID Partition Table (GPT) support. GRUB 2 includes official GPT support.
RAID and LVM. GRUB Legacy doesn't support software-based redundant array of independent disks (RAID) or Logical Volume Manager (LVM) configurations. This means that you must have at least one file system in a standard partition (or in a RAID 1 configuration) so that GRUB Legacy can read its configuration files. GRUB 2 supports Linux's forms of RAID and LVM. Thus, you can configure your system with nothing but RAID or LVM partitions.
File system support. To read configuration files, GRUB must be able to read the file system in which such files are stored. GRUB Legacy supports fewer than a dozen file systems, including the Second Extended Filesystem (ext2fs), File Allocation Table (FAT), Journaling File System (JFS), ReiserFS, and Extents File System (XFS). For a Linux-only system, file system support in GRUB 2 is similar to that in GRUB Legacy; however, GRUB 2 supports some additional non-Linux file systems, such as Apple's Hierarchical File System Plus (HFS+), Microsoft's NTFS file system, and Sun's ZFS.
Kernel support. GRUB Legacy can directly boot Linux, FreeBSD, NetBSD, OpenBSD, and all operating systems that follow the Multiboot Specification, which includes the GNU HURD kernel, OpenSolaris, and a few others. GRUB 2 can directly boot all these same kernels plus XNU (the Mac OS X and Darwin kernel). Booting other operating systems, such as Windows?, requires both GRUB Legacy and GRUB 2 to chain-load another boot loader.

Configuring GRUB 2

If you're already familiar with GRUB Legacy, you'll find that the GRUB 2 configuration file is similar in broad strokes, but it varies in many details. You should be aware of alternative means of configuring GRUB 2, as well.

An example configuration file

The default location for the GRUB 2 configuration file is /boot/grub/grub.cfg. Some Linux distributions use /boot/grub2/grub.cfg instead, enabling side-by-side GRUB Legacy and GRUB 2 installations. Listing 1 shows a sample GRUB 2 configuration file.

Listing 1. Sample GRUB 2 configuration file

set timeout=10
set default=0

menuentry "Linux (2.6.32.2 kernel)" {
        set root=(hd1,8)
        linux /bzImage-2.6.32.2 ro root=/dev/sdb4
        initrd /initramfs-x86_64-2.6.32.2
}

menuentry "Windows 7" {
        set root=(hd1,2)
        parttool (hd0,1) hidden+
        parttool (hd1,5) hidden-
        chainloader +1
}

If you're familiar with GRUB Legacy, you'll find this basic GRUB 2 configuration file similar. As with GRUB Legacy configuration files, the GRUB 2 file begins with a section that sets various global options—in this case, setting a timeout value to 10 seconds and setting the default menu entry.

The file continues with a series of menu entries. The form of these entries is different from those for GRUB Legacy, but the purpose is the same: Each defines a single operating system or boot variant, such as a different Linux kernel. Each menu entry begins with the keyword menuentry followed by a name in quotation marks, which appears in the GRUB 2 menu. The options that relate to that menu entry appear between curly braces ({}).

Configuration file changes

Several changes between the configuration file formats of GRUB Legacy and GRUB 2 deserve mention:

GRUB 2 uses the set keyword and an equal sign (=) between the names of options and their values. Equivalent options in GRUB Legacy omit both the set keyword and the equal sign.
In GRUB Legacy, menu entries begin with the keyword title, and the text up to the end of the line is the title. The remainder of the menu entry definition appears on the following lines, with no curly braces defining it; an entry ends with the start of the next menu definition.
GRUB Legacy uses the kernel keyword to specify a Linux kernel; GRUB 2 uses linux, instead.
Some more specific option names have changed. For instance, Listing 1 uses the new parttool command, which can perform simple partition manipulations, in the Windows 7 definition. Listing 1 uses this feature to hide or reveal certain partitions so as to control which partitions Windows 7 attempts to mount. The equivalent commands in GRUB Legacy are hide and unhide.

Another change is extremely important but not obvious from Listing 1: Partitions are numbered starting from 1 in GRUB 2, whereas partition numbering begins with 0 in GRUB Legacy. An equivalent change in disk numbering is not implemented. Thus, the first partition on the first disk is (hd0,0) in GRUB Legacy, but the same partition is (hd0,1) in GRUB 2. You should pay careful attention to this detail, because it's a major source of potential problems!

Using new GRUB 2 features

Of course, GRUB 2 implements many new features. Some of these have little bearing on a standard Linux installation or don't directly affect the configuration file. Some important options you might need to adjust include the following:

GRUB 2's modular nature means that you can explicitly load modules to support various features. The insmod keyword loads a named module, as in insmod lvm, which loads LVM support. Modules are stored in /boot/grub, and their file names end in .mod. In many cases, explicit use of insmod isn't necessary, because GRUB 2 auto-loads most modules; however, you may need to manually load a module on occasion.
GRUB 2 implements new scripting features to enable saving data, taking actions conditionally, and so on. These features are as yet poorly documented; however, they are similar to bash scripting features in syntax.

Alternative methods of reconfiguring GRUB 2

Ubuntu 9.10 uses the grub-mkconfig utility and its matching scripts in /etc/grub.d to automatically rewrite the /boot/grub/grub.cfg file upon system installation. This script could be run without your knowledge after a kernel upgrade or certain other actions, too. Thus, you should be careful to make backups of your grub.cfg file if you make manual changes to it.

In some cases, deliberately running grub-mkconfig may be in order. If you've got a default configuration but you've just added a new kernel to your system, this might be enough to detect the new kernel and add it to your GRUB 2 configuration file.

If you need to make more specific changes, you could directly edit the files in /etc/grub.d. These files are actually bash scripts. Each one tells the system how to locate specific types of kernels or operating systems and add appropriate entries to /boot/grub/grub.cfg.

An additional file referred to by grub-mkconfig is /etc/default/grub. This file holds global defaults for the final /boot/grub/grub.cfg file.

Third parties have written some tools and scripts to help manage GRUB 2 installations. One example is the StartUp Manager. This graphical user interface (GUI) tool ships with Ubuntu and provides a point-and-click interface for managing both GRUB Legacy and GRUB 2 installations.

Installing and using GRUB 2

GRUB 2, like GRUB Legacy, must be installed once. Thereafter, the boot loader reads its /boot/grub/grub.cfg file to present the boot menu to you. Prior to installation, though, you may want to consider your partition layout. After installing GRUB 2, you should be aware of some basic features for boot-time operation.

Preparing partitions for GRUB 2

No special preparation is required to install GRUB 2 on a disk that uses the MBR partitioning scheme. The same is technically true of GPT; however, if a GPT disk includes a BIOS boot partition, GRUB 2 will store extra code in that partition. If the BIOS boot partition is not present, GRUB 2 instead relies on a list of disk sectors that correspond to a file in your /boot directory. If you ever adjust that file system, the sector list may become invalid, resulting in GRUB's inability to boot. Thus, use of a BIOS boot partition is strongly recommended on GPT disks.

Your BIOS boot partition should be at least 31KB in size. Making it bigger will do no harm and could be useful should GRUB's needs change in the future. In recent versions of GNU Parted, you can set the bios_grub option on a partition to turn it into a BIOS boot partition. In GPT fdisk, change the partition type code to EF02.

Installing GRUB 2

You install GRUB 2 to a disk's MBR in the same way as GRUB, using the grub-install command. (Some distributions rename this command to grub2-install.) Pass the command the name of the disk device to which you want to install it—typically, /dev/sda or /dev/hda.

You can normally install GRUB Legacy to a partition's boot sector (such as /dev/sda4) by typing:

grub-install /dev/sda4

(changing the partition device file name as necessary). This doesn't work with GRUB 2, though. You may be able to overcome this problem by typing:

grub-setup --force /dev/sda4

(changing the device file name as necessary); however, this method doesn't always work.

Run time GRUB 2 use

During normal use, GRUB 2 works much like GRUB Legacy: When you boot the computer, just after the BIOS performs its checks, a menu of operating system and kernel options appears. You choose the one you want to boot using the arrow keys, and then press Enter. If you make no selection, the default may be booted, depending on the configuration file options.

If an entry doesn't work, you may be able to make a one-time change to it by using GRUB 2 edit mode. Instead of pressing the Enter key to boot an entry, press the E key to edit it. You'll see a simple editor that accepts Emacs-like editing options. When you're done, press Ctrl-X to boot your altered entry.

If GRUB 2 can't locate its configuration file, it will present you with a grub> prompt. You can type GRUB 2 commands, including those you would use in a menu entry in the configuration file. If you're familiar enough with GRUB 2, you may be able to get your computer to boot. Unfortunately, a complete description of troubleshooting using GRUB 2's command-line mode would be several times the length of this article.

Should you use GRUB 2?

The most compelling reasons for using GRUB 2 are if you're using a distribution that installs it by default or you need access to one of its unusual features, such as the ability to directly boot an XNU kernel. In most other cases, GRUB 2 offers few or no advantages over GRUB Legacy. One in-between case is if you've used GPT on a BIOS-based computer. GRUB 2 supports this configuration, but the standard GRUB Legacy does not. Patched versions of GRUB Legacy with GPT support are available and ship with most modern distributions, but you may prefer using a boot loader with official GPT support.

The bottom line is this: If what you have installed already works, it's best to keep using it. Changing boot loaders can render a system unbootable, and correcting that problem is a tedious proposition.

That said, GRUB 2 is likely to supplant GRUB Legacy moving forward, so you may want to familiarize yourself with GRUB 2, if only on a test system or virtual machine. Sooner or later, you may find that your GRUB configuration file format has changed, because your distribution has changed its boot loader. A little advance research will help you weather this change with minimal fuss.