Grub

GRUB is the GRand Unified Bootloader.  It exists in two versions Grub and Grub 2. Both RHEL and Suse 10 use old Grub.  The key feature of GRUB is that it is a mini OS in its own right and able to boot all the installed major operating systems by the method known as Chain loading.

If you type space or other key when grub is showing you the menu it switches to interactive mode. In this mode you can edit entries present in the menu which permit to recover from many otherwise catastrophic errors that you made before rebooting system. Among them: incorrect SELinux configuration, errors is key files like /etc/passwd and /etc/shadow, etc.

Useful commands

• The help command will display a list of the 40 or so commands available in GRUB. Typing the name a particular command after help will produce on-line help for that particular command. So grub> help kernel will tell you all about using the kernel command.
• The cat command can be used to view the contents of a file. For example, grub> cat (hd0,2)/etc/fstab will show the contents of the /etc/fstab file in the Debian installation. This is a very handy way of pulling out system configuration information if your normal boot loader gets whacked. Note also as you are using the GRUB command line that, like bash, up and down arrows will scroll through command history, and a tab will complete the name of a GRUB command or filename.
• You can try different menu interfaces with the configfile command. For example:

  grub> configfile (sha0)/grub/menu.lst

  This will switch GRUB into its menu mode with an interface defined by the file, menu.lst.

GRUB is a very flexible boot loader. Among its capabilities are:

• Remapping disks and partition hiding, so you can even run multiple versions of Linux and Windows, on other than the first hard disk.
• Network booting with BOOTP and DHCP protocols
• Keyboard remapping, disk geometry access, memory reading, I/O port and processor probes
• Root password recovery.

Solaris x86 used GRUB as its bootloader on x86 systems since the Solaris 10 1/06 release.

Booting with GRUB

Booting proceed in two stages:

• Stage 1 consists of 512 bytes and is written to the MBR or the boot sector of a hard disk partition or floppy disk. The only task of the first stage is to load the second stage of the boot loader.
• Stage 2. This stage is contained in file stage2 which is the actual Grub executable.  Location of stage2 is determined in /etc/grub.config and if you need to move boot partition you need to correct this file and reinstall grub via command grub-install /dev/sda, where sda is your bootable disk See moving boot partition for details. 

stage2 is able to access Linux file systems. Currently, Ext2, Ext3, ReiserFS, and FAT filesystems are supported.  Since version 0.95, GRUB is also able to boot from a CD or DVD containing an ISO 9660 standard file system pursuant to the “El Torito” specification. Even before the system is booted, GRUB can access file systems of supported BIOS disk devices (floppy disks or hard disks, CD drives, and DVD drives detected by the BIOS). Therefore, changes to the GRUB configuration file (menu.lst) no longer require a reinstallation of the boot manager. When the system is booted, GRUB reloads the menu file together with the valid paths and partition data of the kernel or the initial RAM disk (initrd) and locates these files.

The actual configuration of GRUB is based on two files that are described below:

/boot/grub/menu.lst

This file contains all information about partitions or operating systems that can be booted with GRUB. Without this information, the system control cannot be passed to the operating system.

/boot/grub/device.map

This file translates the device names from the GRUB and BIOS notation to Linux device names.

GRUB can be controlled in various ways. Boot entries from an existing configuration can be selected from the graphical menu (splash screen). The configuration is loaded as it is from the file menu.lst.

All boot parameters can be changed prior to booting

For example, errors made when editing the menu file can be corrected in this way. Boot commands can also be entered interactively over a kind of input prompt  GRUB offers the possibility of determining the location of the kernel and the initrd prior to booting. In this way, you can even boot an installed operating system for which no entry exists in the boot loader configuration.

The GRUB shell provides an emulation of GRUB in the installed system. It can be used to install GRUB or test new settings before applying them.

The GRUB Boot Menu

The graphical splash screen with the boot menu is based on the GRUB configuration file /boot/grub/menu.lst, which contains all information about all partitions or operating systems that can be booted by means of the menu.

Every time the system is booted, GRUB loads the menu file from the file system. For this reason, GRUB does not need to be reinstalled after every change to the file.

The menu file contains commands. The syntax is very simple. Every line contains a command followed by optional parameters separated by spaces like in the shell. For historical reasons, some commands permit an = in front of the first parameter. Comments are introduced by a hash (#).

To identify the menu items in the menu overview, specify a title for every entry. The text (including any spaces) following the keyword title is displayed as a selectable option in the menu. All commands up to the next title are executed when this menu item is selected.

The simplest case is the redirection to boot loaders of other operating systems. The command is chainloader and the argument is usually the boot block of another partition in GRUB block notation. For example:

chainloader (hd0,3)+1

The device names in GRUB are explained below. The above example specifies the first block of the fourth partition of the first hard disk.

Use the command kernel to specify a kernel image. The first argument is the path to the kernel image in a partition. The other arguments are passed to the kernel on the command line.

If the kernel does not have built-in drivers for access to the root partition, initrd must be specified with a separate GRUB command whose only argument is the path to the initrd file. Because the loading address of the initrd is written to the loaded kernel image, the command initrd must follow immediately after the kernel command.

The command root simplifies the specification of kernel and initrd files. The only argument of root is a GRUB device or a partition on a GRUB device. This device is used for all kernel, initrd, or other file paths for which no device is explicitly specified until the next root command. This command is not used in the menu.lst file generated during the installation. It merely facilitates manual editing.

The boot command is implied at the end of every menu entry, so it does not need to be written into the menu file. However, if you use GRUB interactively for booting, you must enter the boot command at the end. The command itself has no arguments. It merely boots the loaded kernel image or the specified chain loader.

After writing all menu entries, define one of them as the default entry. Otherwise, the first one (entry 0) is used. You can also specify a time-out in seconds after which the default entry should boot. timeout and default usually precede the menu entries.

 Naming Conventions for Hard Disks and Partitions

The naming conventions GRUB uses for hard disks and partitions differ from those used for normal Linux devices. In GRUB, the numbering of the partitions starts with zero. Thus, (hd0,0) is the first partition of the first hard disk. On a common desktop machine with a hard disk connected as primary master, the corresponding Linux device name is /dev/hda1.

GRUB does not distinguish between IDE, SCSI, and RAID devices. All hard disks recognized by the BIOS or other controllers are numbered according to the boot sequence preset in the BIOS.

Unfortunately, GRUB is not able to map the Linux device names to BIOS device names exactly. It generates this mapping with a help of an algorithm and saves it to the file device.map, which can be edited if necessary. Information about the file device.map is available in 7.4.2. “The File device.map”.

A complete GRUB path consists of a device name written in parentheses and the path to the file in the file system in the specified partition. The path begins with a slash. For example, the bootable kernel could be specified as follows on a system with a single IDE hard disk containing Linux in its first partition:

(hd0,0)/boot/vmlinuz

An Example Menu File

The following example shows the structure of a GRUB menu file. The example installation comprises a Linux boot partition under /dev/hda5, a root partition under /dev/hda7, and a Windows installation under /dev/hda1.

# Modified by YaST2. Last modification on Thu May 13 13:43:35 EDT 2010
default 0
timeout 8
gfxmenu (hd0,1)/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux Enterprise Server 10 SP3
    root (hd0,1)
    kernel /vmlinuz-2.6.16.60-0.54.5-smp root=/dev/vg01/root vga=0x317 splash=silent  showopts
    initrd /initrd-2.6.16.60-0.54.5-smp

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE Linux Enterprise Server 10 SP3
    root (hd0,1)
    kernel /vmlinuz-2.6.16.60-0.54.5-smp root=/dev/vg01/root vga=0x317 showopts ide=nodma apm=off acpi=off noresume edd=off 3
    initrd /initrd-2.6.16.60-0.54.5-smp

The first block defines the configuration of the splash screen:

gfxmenu (hd0,1)/message

The background image message is located in /dev/hda5.

default 0

The first menu entry title linux is the one to boot by default.

timeout 8

After eight seconds without any user input, GRUB automatically boots the default entry.

The second and largest block lists the various bootable operating systems. The sections for the individual operating systems are introduced by title.

• The kernel (vmlinuz) is located in the first logical partition (the boot partition) of the first hard disk. Kernel parameters, such as the root partition and VGA mode, are appended here. The root partition is specified according to the Linux naming convention (root=/dev/vg01/root), because this information is read by the kernel and has nothing to do with GRUB.
• The boot option failsafe starts Linux with a selection of kernel parameters that enables Linux to boot even on problematic systems.

The menu file can be changed whenever necessary. GRUB then uses the modified settings during the next boot. Edit the file permanently using YaST or an editor of your choice.

 Editing Menu Entries during the Boot Procedure

After activating the editing mode, use the arrow keys to select the menu entry of which to edit the configuration. To make the configuration editable, press E once more. In this way, edit incorrect partition or path specifications before they have a negative effect on the boot process. Press Enter to exit the editing mode and return to the menu. Then press B to boot this entry. Further possible actions are displayed in the help text at the bottom.

To enter changed boot options permanently and pass them to the kernel, open the file menu.lst as the user root and append the respective kernel parameters to the existing line, separated by spaces. GRUB automatically adopts the new parameters the next time the system is booted. Alternatively, this change can also be made with the YaST boot loader module. Append the new parameters to the existing line, separated by spaces.

• To put into particular runlevel append the corresponding digit to the kernel line
• To disable SElinux

  kernel /boot/vmlinuz-2.4.20-selinux-2003040709 ro root=/dev/hda1 nousb selinux=0

Boot Directly into a Shell

You can boot your system directly into a shell. In this case you need to add to the kernel statement

init=/bin/bash

Within this shell, you automatically have root permissions. This permits to fix even more severs errors then booting to level 1.

To boot directly into the shell Bash, enter the following at the boot prompt of your system:

After booting, the system prompt looks like this:

■You have only US English keyboard layout.

3019_11_manual

The File device.map

The file device.map maps GRUB device names to Linux device names. In a mixed system containing IDE and SCSI hard disks, GRUB must try to determine the boot sequence by means of a special procedure, because GRUB does not have access to the BIOS information on the boot sequence. GRUB saves the result of this analysis in the file /boot/grub/device.map. For a system on which the boot sequence in the BIOS is set to IDE before SCSI, the file device.map could appear as follows:

(fd0)  /dev/fd0
(hd0)  /dev/hda
(hd1)  /dev/sda

Because the order of IDE, SCSI, and other hard disks depends on various factors and Linux is not able to identify the mapping, the sequence in the file device.map can be set manually. If you encounter problems when booting, check if the sequence in this file corresponds to the sequence in the BIOS and use the GRUB shell to modify it temporarily if necessary (see 7.4.4. “The GRUB Shell”). Once the Linux system has booted, the file device.map can be edited permanently with the YaST boot loader module or an editor of your choice.

After manually changing the file device.map, execute the following command to reinstall GRUB. This command causes the file device.map to be reloaded and the commands listed in grub.conf to be executed:

grub --batch < /etc/grub.conf
  

The File /etc/grub.conf

The third important GRUB configuration file apart from menu.lst and device.map is /etc/grub.conf. This file contains the parameters and options the command grub needs for installing the boot loader correctly:

root (hd0,4)
install /grub/stage1 d (hd0) /grub/stage2 0x8000 (hd0,4)/grub/menu.lst
quit

Meaning of the individual entries:

root (hd0,4)

This command tells GRUB to apply the following commands to the first logical partition of the first hard disk (the location of the boot files).

install parameter

The command grub should be run with the parameter install. stage1 of the boot loader should be installed in the MBR of the first hard disk (/grub/stage1 d (hd0)). stage2 should be loaded to the memory address 0x8000 (/grub/stage2 0x8000). The last entry ((hd0,4)/grub/menu.lst) tells GRUB where to look for the menu file.

7.4.4. The GRUB Shell

GRUB actually exists in two versions: as a boot loader and as a normal Linux program in /usr/sbin/grub. This program is referred to as the GRUB shell. The functionality to install GRUB as boot loader on a hard disk or floppy disk is integrated in GRUB in the form of the commands install and setup. This is available in the GRUB shell when Linux is loaded.

However, the commands setup and install are also available during the boot procedure before Linux is started. This facilitates the repair of a defective system that can no longer be booted, because the faulty configuration file of the boot loader can be circumvented by manually entering parameters. The manual specification of parameters during the boot procedure is also useful for testing new settings to avoid impairing the native system. Simply enter the experimental configuration file with a syntax similar to that in menu.lst. Then test the functionality of this entry without changing the existing configuration file. For example, to test a new kernel, enter the command kernel and the path to the new kernel. If the boot procedure fails, you can continue using the intact menu.lst the next time you boot. Similarly, the command line interface can also be used to boot a system despite a faulty menu.lst file by entering the corrected parameters. In the running system, the correct parameters can be entered in menu.lst to make the system permanently bootable.

The mapping of GRUB devices to Linux device names is only relevant when running the GRUB shell as a Linux program (by entering grub as described in 7.4.2. “The File device.map”). For this purpose, the program reads the file device.map. For more information, see 7.4.2. “The File device.map”.

Booting Single-User Mode

You may be able to boot single-user mode directly. If your system boots, but does not allow you to log in when it has completed booting, try single-user mode.

If you are using GRUB, use the following steps to boot into single-user mode:

1. If you have a GRUB password configured, type p and enter the password.
2. Select Red Hat Linux with the version of the kernel that you wish to boot and type e for edit. You will be presented with a list of items in the configuration file for the title you just selected.
3. Select the line that starts with kernel and type e to edit the line.
4. Go to the end of the line and type single as a separate word (press the [Spacebar] and then type single). Press [Enter] to exit edit mode.
5. Back at the GRUB screen, type b to boot into single user mode.

If you are using LILO, specify one of these options at the LILO boot prompt (if you are using the graphical LILO, you must press [Ctrl]-[x] to exit the graphical screen and go to the boot: prompt):

boot: linux single boot: linux emergency

In single-user mode, you computer boots to runlevel 1. Your local filesystems will be mounted, but your network will not be activated. You will have a usable system maintenance shell.

Red Hat Linux 7.3 Manuals - Init Runlevels

If you are using GRUB as your boot loader, you can enter single-user mode using the following steps.

• In the graphical GRUB boot loader screen, select the Red Hat Linux boot label and press [e] to edit it.
• Arrow down to the kernel line and press [e] to edit it.
• At the prompt, type single and press [Enter].
• You will be returned to the GRUB screen with the kernel information. Press the [b] key to boot the system into single user mode.

A very bare system will boot, and you will have a command shell from which you can fix things.

If this does not work, you will need to boot by typing linux init=/bin/bash at the LILO boot: prompt. This places you at a shell prompt; note that no filesystems other than the root filesystem are mounted, and the root filesystem is mounted in read-only mode. To mount it in read-write mode (to allow editing of a broken /etc/inittab, for example) do:

mount -n /proc mount -o rw,remount /

NEWS CONTENTS

[Dec 1, 2007] SUSE Linux Enterprise troubleshooting Fixing boot problems by repairing a broken initrd by Sander van Vugt

Troubleshooting is a near-science by itself on which I could spend many articles, but I'll try to keep it brief. During the system boot procedure, several phases occur, starting in GRUB, the Linux boot loader. Roughly, these are the following:

1. GRUB loads the kernel
2. GRUB loads the initrd
3. The root file system is accessed by the kernel
4. The /sbin/init process takes over.
5. The initial boot stage happens
6. The default runlevel is activated
7. A login prompt occurs.

When a problem occurs, try to pin-point it to any of these seven phases. In some cases it is possible to tell exactly what happens, more often you will see that you can only give a rough indication of what is happening. In the case of a kernel panic, you can be sure about one thing: GRUB has loaded successfully and you are not yet at phase 4 of the boot procedure where the init process takes over. If a kernel panic occurs immediately after a driver installation, this is often caused by an error in the initrd.

How can we be sure? Sometimes it is quite obvious that the error is in initrd, as GRUB tells you that it failed to load the file /boot/initrd, in other cases some forensic work is needed as only a vague driver error message is generated. In the latter case, you have to check if the driver that fails is included in the initrd, as this helper file is used by the kernel to include drivers that are needed immediately. On SUSE Linux Enterprise, the file /etc/sysconfig/kernel contains a list of all drivers that should be included in the initrd. When you run the mkinitrd command, these drivers are written to your new initrd. When this happens automatically, something could go wrong.

Step 2: Fixing it
If an error occurs in the initrd, you will not be able to boot your server anymore. So, to fix it, you need the rescue system that is available from the installation dvd. This rescue system loads a complete Linux system off of the installation media. The next step is to mount all your Linux file systems off of that disk. Next, you need to run mkinitrd. You can only do this once the local file systems are all mounted, because the initrd has to be written to the local file systems. However, there is a caveat.

The problem with this approach is in the disk devices access in combination with the necessary use of a chroot environment. To start, you need to mount your server's file systems on a temporary mount point like /mnt. Let's say that you have the /boot directory on /dev/sda1 and your / directory on /dev/sda2. To mount them, you need the following two commands:

1. mount /dev/sda2 /mnt
2. mount /dev/sda1 /mnt/boot

Since the mkinitrd command wants to write the new initrd in /boot and the /boot on your hard drive is now in /mnt/boot, you need to change the root directory to be set to /mnt. You can use chroot to do that:

chroot /mnt

The contents of /mnt now becomes /, so all path references are OK. But we still have a problem. If you look in the /proc and /dev directory on your new root environment, you'll see that /proc is empty and /dev is as good as empty. Both are dynamically created file systems and they are created at the moment that your server boots. This means that they were created in / when the server booted from the rescue cd. Now, since the new root is in /mnt, you cannot access them anymore. We need to fix this.

1. Type exit to exit from the chroot environment. You'll now get back to the original /mnt under which your servers local file systems where mounted.
2. Use mount -t proc none /mnt/proc to make the proc file system available from the /mnt environment.
3. Use mount -o bind /dev /mnt/dev which will make the original /dev which was filled by the udev process when booting available from /mnt/dev.

Now that you have the repair environment all in place, you need to check that the line in /etc/sysconfig/kernel that is used to generate a new initrd is as it should be. You are looking for the following line:

INITRD_MODULES="ata_piix processor thermal fan jbd ext3 dm_mod edd pciback"

This line will be different on every server, so check to make sure that all modules are included that are necessary to start your server (your server's documentation will help you with that.)

Now under /mnt you have the complete environment that is needed to repair your server, so take the following two steps to fix your server.

1. Activate /mnt using cd /mnt and make it your new root environment using chroot .
2. Issue the command mkinitrd to write the new initrd to /boot.

You have now fixed the initrd. Reboot your server and check that everything is working all right.

[May 1, 2001] Boot with GRUB by Wayne Marshal

May 1st, 2001 | linuxjournal.com

Especially useful for multiboot, partitioned systems, GRUB offers flexibility and convenience for startup.

GRUB: it's neither larva, fast food nor the loveliest of acronyms in the GNU herd of free software. Rather, GRUB is the GNU GRand Unified Bootloader. And, it is truly the greatest loader for booting Linux and practically any other OS-open source or otherwise-you may have scattered on your platters.

GRUB is independent of any particular operating system and may be thought of as a tiny, function-specific OS. The purpose of the GRUB kernel is to recognize filesystems and load boot images, and it provides both menu-driven and command-line interfaces to perform these functions. The command-line interface in particular is quite flexible and powerful, with command history and completion features familiar to users of the bash shell.

GRUB is in its element with the multiboot, multidisk systems typical of Linux and open-source adventurers who may simultaneously test or track several Linux distributions, the BSDs, GNU/Hurd, BeOS and perhaps that vestigial partition for Mr. Bill. Even if you stick with LILO as your system's primary boot loader, it's smart to keep a GRUB boot floppy handy as the best and fastest way to get your system back if you otherwise cream your master boot record (MBR). If you have done any number of multiboot installations, you know exactly what I'm talking about. Should you need any more reasons for considering GRUB, check out the sidebar, "Why GRUB". Let's get started!

Installation

Installation of GRUB is a two-step process. The first step is to install or build GRUB in a host OS environment, and for this we will, of course, use Linux. The second step is to install and configure GRUB as the boot loader for your system.

The first step is the usual: download the source archive, untar it, configure and make install. Assuming you have found a source mirror (see www.gnu.org/software/grub/grub.html) and downloaded the source distribution into a suitable working directory, continue with:

tar -xzvf grub-0.5.96.1.tar.gz
cd grub-0.5.96.1
./configure
make
make install

This should create the executables: grub, grub-install and mbchk; install support files in /usr/local/share/grub/i386-pc/, and install the GNU information manual and man pages.

For the second step of installation, we will first build and work with a GRUB boot floppy. This way we can use GRUB to learn about its features while testing various configurations for our particular system. After getting comfortable with the GRUB setup on floppy, we will then install it onto the MBR of the system's first hard disk. Even if you decide not to install GRUB on your hard disk right away, no harm done: you will now have your own GRUB boot floppy available to rescue systems with trashed boot loaders.

Preparing a GRUB floppy

GRUB recognizes a number of different filesytem types, including Linux ext2fs, Reiser, MINIX, BSD's ffs, as well as FAT, so it is possible to make a GRUB boot floppy with any of these filesystems. We will stick to FAT for this example, however, because it is the lowest common denominator, and most OSes have tools for mounting and reading/writing files on FAT floppies. That way, we will always be able to get to its menu configuration file if we need to.

Scrounge around in your junk drawer for some unused floppy (a new one would be even better), and give it a fresh format and FAT filesystem:

fdformat /dev/fd0
mkfs -t msdos /dev/fd0

We are going to put some files on this disk, so go ahead and mount to your usual floppy mount point (here I use /floppy):

mount -t msdos /dev/fd0 /floppy

Now install the directories and files GRUB will need:

grub> root (fd0)
grub> setup (fd0)
grub> quit

And that's it! This sequence of commands completes the installation of GRUB on the floppy disk. It is now bootable and will allow us to boot any other OS on our system.

Demonstrating GRUB

To see how GRUB may be used to boot a multitude of different operating systems, consider this example setup:

First Hard Disk (SCSI, Linux /dev/sda): 1st primary partition: Win982nd primary partition: Linux-Slackware3rd primary partition: Linux-Debian4th primary partition: Linux SwapSecond Hard Disk (SCSI, Linux /dev/sdb)1st primary partition: FreeBSD2nd primary partition: OpenBSD3rd primary partition: BeOS

Note that although GRUB and Linux are capable of dealing with installations in extended partitions, here we show a preference for using primary partitions whenever possible. Filesystems in primary partitions are often mountable by other operating systems, whereas cross-OS mounting filesystems in extended partitions is often not supported.

This system has two hard disks with six different operating systems using seven partitions. As you probably know, each OS has its own nomenclature for naming devices and partitions. For example, the Slackware installation would be known to Linux as /dev/sda2 (with swap on /dev/sda4), while FreeBSD would recognize its filesystem on /dev/da1s1a. Alternatively, if the system were configured with IDE hard disks, Slackware would be on /dev/hda2, and FreeBSD would refer to its root directory on /dev/ad1s1a. You get large helpings of this alphabet soup whenever maintaining any multiboot setup.

Since GRUB also needs to be capable of loading any of these systems, it has its own OS-neutral naming conventions for referring to devices. Hard disks are all hd, floppy disks are fd, device numbering starts from zero, partition numbering starts from zero and complete device names are enclosed in parentheses.

With these naming rules, the floppy disk is (fd0), the Win98 partition is (hd0,0), and GRUB recognizes the Slackware and Debian partitions respectively as (hd0,1) for slackware and (hd0,2) for debian.

The BSDs further subdivide their own partitions (or "slices" in BSD terms), and GRUB would refer to the root mount for the FreeBSD system on (hd1,0,a).

Okay, ready to give GRUB a taste? Slide the GRUB floppy in the drive and reboot your system (with your system's BIOS configured to boot from A: drive). You should see GRUB's terse boot messages and then find yourself in the GRUB command-line environment as shown in Figure 1.

To start, let's boot Slackware. Enter the following commands at the grub prompt:

grub> root (hd0,1)
grub> kernel /vmlinuz root=/dev/sda2 ro vga=791
grub> boot

Badda-bing, badda-boom, that postage-stamp-sized Tux appears in the upper-left corner of your screen (yes, Slackware is configured to use the framebuffer device), and Linux bootstraps its jolly way into glorious being.

Another example. Reboot the system again with the GRUB floppy, and enter the following commands at the grub prompt:

grub> rootnoverify (hd0,0)
grub> makeactive
grub> chainloader +1
grub> boot

Now your screen turns into a vague blue cloud, and you think you have made some horrible mistake. Then you realize it's only Windows and you remind yourself to expunge this partition one day soon.

Let's take a closer look at these examples. In the Slackware boot, we first used the GRUB root command to specify the device for GRUB to access. If the device has a filesystem recognized by GRUB (that is, one of ext2fs, reiser, ffs, etc.), it attempts to mount it and get its partition information, then reports its success following the command. Thus, you would see the following command/response dialog on your screen:

grub> root (hd0,1)
Filesystem type is ext2fs, partition type 0x83

Next, we used the GRUB kernel command to specify the boot image for GRUB to load. The argument to the kernel command is the filename of the boot image relative to the device specified by the root command above. The kernel image file can also be specified in explicit (device)/filename terms as follows:

grub> kernel (hd0,1)/vmlinuz

The kernel command gives you great flexibility for specifying the boot image you wish to load. For example, if we saved a previous version of a kernel to the file /vmlinuz.old, we could specify it with this command (which shows GRUB's response):

grub> kernel /vmlinuz.old root=/dev/sda2 ro vga=ask
[Linux-bzImage, setup=0xe00, size=0xfad30]

The arguments following the name of the boot image are passed to the target kernel and aren't related to GRUB. For Linux, these kernel arguments are pretty much what you would specify them to be in lilo.conf. In our example, we tell the kernel what device to mount for the root partition (root=/dev/sda2 ro), using the device nomenclature expected by Linux. Note here that we also use the ro flag to mount the root filesystem read-only initially while it performs its filesystem check. The other kernel argument in our example simply demonstrates setting another kernel variable (vga=791) to use a particular vga mode for the framebuffer display.

Finally, the last command is grub> boot. The kernel image specified is now loaded and sent rolling down the royal road to bootdom.

The second example, using Win98, demonstrates the use of GRUB's chain-loading mechanism. This method of booting loads the target OS's own boot-chain-loader rather than a kernel image of the OS. In this instance, we specified:

grub> rootnoverify (hd0,0)
grub> chainloader +1

First, the rootnoverify command is for OS filesystems not specifically recognized by GRUB, so that GRUB will not try to mount the partition. Next, the chainloader command will use the first sector of the partition of device (hd0,0) and attempt to boot whatever it finds there. This is a common means of booting OSes that install their own boot loaders in the first sector of the partition where they are installed (this is sometimes called the partition boot sector or PBR).

Finally, the makeactive command sets the active flag in the partition table for the device specified by the root command, as some operating systems, like Win98, require.

The GRUB command line is easy and fun, and you should boot the different OSes on your system a few times to get the hang of it. While you are testing, be sure to keep any notes specific to getting your particular kernels successfully loaded. This information will be useful later when you configure the menu system of GRUB to perform these command-line steps automatically.

But before we leave the command line, here are a few more GRUB commands to look at.

The help command will display a list of the 40 or so commands available in GRUB. Typing the name a particular command after help will produce on-line help for that particular command. So grub> help kernel will tell you all about using the kernel command.

The cat command can be used to view the contents of a file. For example, grub> cat (hd0,2)/etc/fstab will show the contents of the /etc/fstab file in the Debian installation. This is a very handy way of pulling out system configuration information if your normal boot loader gets whacked. Note also as you are using the GRUB command line that, like bash, up and down arrows will scroll through command history, and a tab will complete the name of a GRUB command or filename.

Finally, you can call up a specific menu interface with the configfile command as in:

grub> configfile (fd0)/boot/grub/menu.lst

This will switch GRUB into its menu mode with an interface defined by the file, menu.lst. We haven't created that file yet, but-look out, segue coming!-that's exactly what we will do next.

Menu Configuration

Using the GRUB command line is cool, but after a few thousand system starts, you will probably get a little tired of entering the same commands at the GRUB prompt and long for something a little more automated. Good news from the GRUB gang: you get a fully configurable menu interface at no extra charge! The GRUB boot menu gives you point-and-shoot boot selection, unattended default boot after a configurable timeout, any number of fallback boots if previous boots fail, toggle between command-line and menu modes, and interactive editing of menu selections and password protection. These features give GRUB an ease of use to match its tremendous functionality.

When GRUB boots, it automatically looks for the /boot/grub/menu.lst file on its boot device (the last three letters are "ELL ess tee" and not "one ess tee"). If the file is found, GRUB automatically enters its menu mode and presents the user with a stunning interface, as shown in Figure 2.

Figure 2. GRUB's Boot Menu Interface

Listing 1 [found at LJ's web site] shows the configuration file responsible for this demonstration menu. As you can see, it is a simple text file typical of many UNIX configuration files, where lines starting with hashes (#) and blank lines are ignored.

The first set of commands sets general configuration variables. The timeout command sets the time in seconds to wait for the user to make a selection before proceeding automatically to the default boot. The default command sets which of the following boot stanzas GRUB should attempt to boot automatically. Boot stanzas are numbered implicitly, starting from zero, according to their order of appearance in the configuration file. This order is also how they will be listed in the menu.

The fallback command specifies which of the boot stanzas to load if the default should fail. It is possible to set more than one fallback, as is shown in the example.

The color command lets you breathe a bit of life into the text-mode menu screen. The syntax for the color command is

color  foreground/background  [ hilite-fg/hilite-bg ]

where each of the foreground/background colors is specified with a name from the set of black, blue, green, cyan, red, magenta, brown and light-gray; dark-gray, light-blue, light-green, light-cyan, light-cyan, light-red, light-magenta, yellow and white. Among these colors, only the first eight are used for the background. The optional highlight color pair, if specified, will be used to show the current menu selection. When not specified, GRUB will use the inverse of the normal colors.

The rest of the configuration file consists of the boot stanzas for our demonstration system. The title command marks the beginning of a new boot stanza, and its argument is the label that will be displayed for its entry in the menu, from the first non-white-space character to the end of the line. The remaining commands in each stanza are identical to those used when working from the GRUB command line. The exception here is that we no longer need to give a boot command; GRUB does this job without asking.

This example configuration gives only a sample of the many flexible uses of the GRUB boot loader. Besides multiple OSes, you can use GRUB to set up menu selections for test kernels, rescue kernels, different kernel options and so on.

All in all, the GRUB configuration file will be very similar to your /etc/lilo.conf. And after working with the GRUB command line and these examples, it should be a simple matter of firing up your favorite text editor and creating a menu configuration file suitable for your own system and preferences. Don't worry if it's not perfect the first time; you will see that you can make changes interactively, and the GRUB command line is always available as a fallback.

Once you've got your configuration file, mount your GRUB floppy again, and copy the file (say it has been saved as mygrub.conf) into the magic location:

cp  mygrub.conf /floppy/boot/grub/menu.lst

Now when you boot with your GRUB floppy-presto!-you will be greeted with a lovely boot menu like the one in Figure 2. If you like, just stare at it for the few seconds it needs to count down from the timeout setting, and then it will automatically boot into your default OS. Or, use the arrow keys to highlight the OS you want to load and press return. Or, type c to go to the now-familiar GRUB command prompt. From the command prompt, press ESC to go back to the boot menu again.

It is also possible to edit the entries displayed in the menu. Typing e will open a simple vi-like editor interface for the highlighted entry. This allows you to adjust or add any settings to the configuration before booting. Any changes made here will then remain in effect for the duration of the GRUB session. To make permanent changes, you will later need to edit the configuration file on the boot disk, saving the changes with your text editor.

Play with your GRUB floppy configuration until you have it set up the way you like. After just a few system boots, you'll be slinging through GRUB like hashbrowns in a diner.

Hard Disk Installation

By this time you may be thinking, "Okay, GRUB has got it goin' on. But do I have to keep booting from this lame floppy all the time?" Of course not. Booting from floppy is for weenies.

The operation for installing GRUB on the master boot record of your hard disk is similar to the creation of a GRUB floppy. The one difference is that our floppy has all the resources GRUB needs in one place. That is, the boot image, support and configuration files are all on the floppy device MBR and /boot/grub/ directory. In a hard disk setup, you can choose where you want these resources to be.

For example, you could set up a /boot/grub directory on the first partition of your first hard disk and copy all GRUB's files into it as we did in our floppy setup. In our demonstration system, this would be the Win98 partition, and you may choose to do it that way if you want. But you can also set up the /boot/grub directory up in any device/partition on your machine with a filesystem supported by GRUB. In practice it is usually best to install this support directory in your most frequently used and/or most stable partition; that is, one that you aren't reinstalling all the time.

For this example, we will use the Slackware partition since this stays pretty stable, and I tend to do more tracking and installations in the Debian system. Once this decision is made, everything else is simple. First, boot into Slackware, create the /boot/grub directory and copy GRUB's files into it (these are all the files that the GRUB build installed in the /usr/local/share/grub/i386-pc directory). Make sure to put your handcrafted menu.lst configuration file in here, too.

Next, start GRUB, either with the grub executable you built in Linux or by rebooting with the GRUB floppy. If GRUB starts in menu mode, press c to go to command-line mode. Enter the following commands at the grub prompt:

grub> root (hd0,1)
grub> setup (hd0)
grub> quit

You're done. Your system is now fully GRUB'd, installed in the MBR of your hard disk. Type reboot as root (or take the floppy out and jab the keyboard with the old three-prong) and watch just how fast GRUB comes up now!

A few words of explanation about these installation commands. The first, root (hd0,1), tells GRUB to mount this device, in this case the partition with the Slackware installation. All files will now be relative to this device, so the GRUB installer will know to look for its support files in the /boot/grub directory we created in the Slackware partition.

The second command, setup (hd0), is a simplified front end to GRUB's install command. Note in particular that we specify the device as (hd0) and not (hd0,0). Device (hd0) results in GRUB's installation to the master boot record, which is what we want. If we had instead used (hd0,0), GRUB would be installed to the boot sector of the first partition, rather than the MBR. The difference is crucial; your technical writer makes mistakes like this so you don't have to. While each partition can have a boot sector, your hard disk will have only one master boot record the BIOS loads every time you start your machine. Unless you are doing some kind of funky boot-chaining, like using LILO to boot GRUB, you will usually want to install GRUB in the master boot record.

When GRUB installs itself on a device, it first copies a small piece of itself to the MBR, which it calls stage1. Then it follows stage1 with just enough information about where to find the rest of GRUB. In our example, GRUB will put stage1 in the MBR, followed by a blocklist that points to the Slackware partition. GRUB will then find the rest of what it needs (its stage2 files) in the /boot/grub directory.

To check this setup, just edit the menu configuration file in Slackware's /boot/grub/menu.lst at any time. Any changes will be reflected in the next boot.

Error Recovery

If you should foul up the hard disk installation somehow or want to uninstall GRUB from your system, here's what you need to know.

First, if you ever want to clean your MBR from whatever is installed there, the canonical method is to use the fdisk program from an MS-DOS boot floppy:

A:> FDISK /MBR

Of course, this isn't necessary if you just want to go back to LILO as your system's boot manager. In that case, simply make sure your /etc/lilo.conf file has a line that reads boot=/dev/hda. Then, when the rest of the lilo.conf file is the way you want, just rerun LILO. This will put LILO back on the MBR of your system.

If you install GRUB in the boot sector of a partition, instead of the MBR (such as specifying setup (hd0,0) instead of setup (hd0)), you may need to reinstall that OS's boot loader. In the case of DOS/Windows, this means running the sys command from your DOS/Windows boot floppy: A:> SYS C:.

If, this is a Linux partition, it is again effective to rerun LILO, where /etc/lilo.conf has a line in the boot stanza that reads root=/dev/hda1.

In general, most OSes will have a way to reinstall their partition's boot sector without doing a full reinstallation from scratch. (For FreeBSD, see boot0cfg(8); for OpenBSD, see installboot(8).)

In practice, especially if you followed through on the GRUB floppy examples, you should find that GRUB itself is one of the best rescue and system recovery tools in your toolkit. For example, if you have ever made a screwup in your lilo.conf file, you know you can be in for some major pain if your system won't boot. With GRUB, you always have a miniature, self-contained operating system that can recognize and mount different filesystems, find files, locate kernels and boot them, bringing your system back to life so you can work on it. At times like these, GRUB can save your bacon.

Conclusions

As is typical of GNU software, GRUB is rich with capabilities beyond what are described here. Some of these include:

• Remapping disks and partition hiding, so you can even run multiple versions of DOS/Windows, on other than the first hard disk.
• Network booting with BOOTP and DHCP protocols, to support multiboot schemes across a network and diskless operation.
• Keyboard remapping, disk geometry access, memory reading, I/O port and processor probes, password protection, decompression support, etc.

See the GNU information manual for more information on these topics. GRUB is under active development, and even more features are planned for future releases.

In this brave GNU world, with vast acreage of cheap hard disk and a glut of great free OSes available, you really need a flexible and user-friendly boot loader to manage them all. Grab GRUB and give it a go.

Why GRUB?

Wayne Marshall ([email protected]) is a UNIX programmer and technical consultant currently living in Guinea, West Africa. When not grubbing about with computers, he enjoys taking the pirogue for day trips to the local islands near Conakry with his wife, Paula.

Repair Linux Boot failures in Grub 2 rescue mode