Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Grub

News

Recommended Books

Recommended Links Disk Repartitioning Linux Disk Partitioning Moving /boot partition to another partition  Filesystems

 Installation Checklist

Runlevels

 serial console

YaST Root password recovery

Booting into Rescue Mode

Etc

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.

When GRUB boots, it looks for the /boot/grub/menu.lst file  on its boot device. If the file is found, GRUB automatically enters its menu mode and presents the user with a command line menu, which consists of items found in /boot/grub/menu.lst. This menu is editable and provides a lot of flexibity to the boot process. Usually at least two kernels are available: regular mode and failsafe mode, but if you upgraded the kernel previous version of kernel is also available from the menu. In case of crashes you can just boot it and then change the order of entries in /boot/grub/menu.lst  until you debug the situation.

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

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

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:

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.

The four possible primary partitions are assigned the partition numbers 0 to 3. The logical (extended) partitions are numbered from 4 even if when there is just one primary partitions

(hd0,0)   first primary partition of the first hard disk
(hd0,1)   second primary partition
... ... 

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 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

In the graphical GRUB boot menu, the operating system to boot can be selected with the arrow keys. If you select a Linux system, you can enter additional boot parameters at the boot prompt. To edit individual menu entries directly, press Esc to exit the splash screen and press E. Changes made in this way only apply to the current boot procedure and are not adopted permanently.

 
Keyboard Layout during the Boot Procedure
The US keyboard layout is the only one available when booting.

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.

Tips:

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.

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 /

Top updates

Bulletin Latest Past week Past month
Google Search


NEWS CONTENTS

Old News ;-)

[Apr 03, 2014] Fixing grub menu file

Sometime SLES insalls menu file with wrong partition as boot partiton. For example 9 despite the fact that it does not exists at all. It should have been looking for Partition 1 for the root filesystem.

Here is df -f of the system in question

Device Boot Start End Blocks Id System

/dev/sda1 * 1 652 5237158+ 83 Linux

/dev/sda2 653 1957 10482412+ 82 Linux swap / Solaris

/dev/sda3 1958 3262 10482412+ 83 Linux

/dev/sda4 3263 8924 45480015 f W95 Ext'd (LBA)

/dev/sda5 3263 4567 10482381 83 Linux

/dev/sda6 4568 5872 10482381 83 Linux

/dev/sda7 5873 7177 10482381 83 Linux

/dev/sda8 7178 8924 14032746 83 Linux

The correction can be done using "yast". Making a mistake can make the server unbootable. Here it the sequence.

First check /etc/fstab to make sure you know which partition or device root is on. Then:

yast2 &

Boot Loader

  • Click on "Other" (at the bottom right)

  • Select "Propose New Configuration"

  • It should change all the configurations shown, default, failsafe, etc. If it does not enter the correct device, you can use Edit or other choices and do it manually.

  • Set the first (not failsafe) as Default (if it is not already selected as default).

  • Hit "Okay" to finish.

Then you can look at the file /boot/grub/menu.lst to confirm the results:

Before:

# cat ./grub/menu.lst
# Modified by YaST2. Last modification on Tue Apr  1 15:21:40 EDT 2014
default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,0)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux Enterprise Server 11
    root (hd0,0)
    kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-3500000e01259f830-part1    resume=/dev/disk/by-id/scsi-3500000e01259f830-part2 splash=silent showopts vga=0x317
    initrd /boot/initrd

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE Linux Enterprise Server 11
    root (hd0,0)
    kernel /boot/vmlinuz root=/dev/disk/by-id/scsi-3500000e01259f830-part1 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset  x11failsafe vga=0x317
    initrd /boot/initrd

###Don't change this comment - YaST2 identifier: Original name: linux###
title Kernel-2.6.32.12-0.7-default
    root (hd0,0)
    kernel /boot/vmlinuz-2.6.32.12-0.7-default root=/dev/disk/by-id/scsi-3500000e01259f830-part1    resume=/dev/disk/by-id/scsi-3500000e01259f830-part2 splash=silent showopts vga=0x317
    initrd /boot/initrd-2.6.32.12-0.7-default

[Apr 28, 2011] Boot with GRUB Linux Journal by Wayne Marshall

Apr 30, 2001 | Linux journal

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.

SUSE LINUX Enterprise Server 9:  8.4. Booting with GRUB

From the graphical boot menu of GRUB, use the arrow keys to select the operating system to boot. If you select a Linux system, you can add boot parameters. After pressing Esc and exiting the splash screen, press E to edit individual menu entries directly. Changes made in this way only apply to the current boot procedure and are not adopted permanently.

  Keyboard Layout during the Boot Procedure
The US keyboard layout is the only one available at boot time.

After enabling the editing mode, use the arrow keys to navigate to the entry to change. To make the selected item editable, press E again. Adjust the entry as desired. Leave the editing mode with Enter and go back to the menu, where the changed entry can be booted by pressing E. In the lower part of the screen, GRUB displays further options.

Booting and Shutting Down Your SuSE Linux Enterprise Server Boot Loaders

InformIT

The GRand Unified Bootloader is more commonly called Grub. This boot loader program is significantly more dynamic than LILO. As you can see in Listing 3.2, there are many similarities between the formatting and information contained in both boot loader configuration files.

In addition to the boot options available through LILO, Grub adds the capability of redirecting the boot to a floppy. Keep in mind that even if you removed the system’s capacity to boot off a floppy in the BIOS, this boot loader, once loaded from the primary boot device, presents the floppy as a valid alternate boot device.

NOTE

LILO can be used to boot a system from a floppy if the kernel is also present on the same floppy.

LILO requires a map file to locate the kernel it wishes to boot from. Because the kernel location is not necessarily constant from floppy to floppy, if the boot loader on the primary hard drive is used, the map file stored on the hard drive may not point to the appropriate location should the incorrect floppy be entered in the drive.

GRUB, on the other hand, does not require a map file. Pointing a boot configuration to a known good kernel on a floppy is therefore possible.

Though this is technically possible, you might want to wonder about the validity of doing this. Starting a system from an incorrect kernel could yield disastrous results. Booting from an up-to-date rescue floppy would be the only scenario in which this should be considered acceptable.

LISTING 3.2: GRUB menu.lst

# Modified by YaST2. Last modification on Wed Jan 5 10:16:38 2005


color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd0,0)/boot/message

###Don’t change this comment - YaST2 identifier: Original 
name: linux###
title Linux
  kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 selinux=0 
splash=silent resume=/dev/sda2 elevator=cfq showopts
  initrd (hd0,0)/boot/initrd

###Don’t change this comment - YaST2 identifier: Original 
name: floppy###
title Floppy
  root (fd0)
  chainloader +1

###Don’t change this comment - YaST2 identifier: Original 
name: failsafe###
title Failsafe
  kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 showopts 
ide=nodma apm=off acpi=off vga=normal noresume 
selinux=0 barrier=off nosmp noapic maxcpus=0 3
  initrd (hd0,0)/boot/initrd

Grub is different from LILO in that the information in the file is interpreted dynamically as the machine is being booted. This has the benefit of allowing new kernels to be quickly added to the system. The Grub menu.lst file can be updated with any text editor, and unlike LILO, no further steps are necessary to make the option available at boot time. Additional information on GRUB can be found in the man pages or at the GRUB home page at http://www.gnu.org/software/grub/grub.html.

An additional feature available through Grub is the capability to modify the menu entries. Pressing Esc when the graphical Grub menu is present triggers Grub to offer the ncurses version of the boot menu. In this version of the menu, you can edit individual lines controlling the kernel parameters. Instructions on how to do this are provided at the bottom of the boot option screen, as shown in Figure 3.1.

Figure 3.1 GRUB edit options available a boot time.

One of the benefits of this option is that you can boot directly into single user mode. In the case of a machine going down for an unknown reason, you can carefully bring up the system in single user mode by dynamically editing the kernel line and adding the word single to the end of the line. Boot the system at this point, and you will have a minimally booted environment in which you can perform some diagnostics before trying to bring up the whole system.

Of course, this extra flexibility is also a double-edged sword. Individuals with access to the system can also modify the kernel parameters during the boot sequence. Securing the console should mitigate against this exposure. This can be done through configuring the BIOS, GRUB, or both to require a password at boot time. This approach must be balanced against the physical security of the server and the requirements of having the machine in service. A power failure or unexpected reboot with these options configured would leave the server unable to boot until manual intervention was provided.

[May 26, 2010]   Never ever play lose with /boot partition.

Here is the recent story connected with the upgrade of the OS (in this case Suse 10) to a new service pack (SP3)

After the upgrade sysadmin discovered that instead of /boot partition mounted there is none but there is a /boot directory directory on the boot partition populated by the update. This is so called "split kernel" situation when one (older) version of kernel boots and then it finds different (more recent) modules in /lib/modules and complains. There reason of this strange behavior of Suse update was convoluted and connected with LVM upgrade it contained after which LVM blocked mounting of /boot partition.  

Easy, he thought. Let's boot from DVD, mount boot partition to say /boot2 and copy all files from the /boot directory to the boot partition.

And he did exactly that. To make things "clean" he first wiped the "old" boot partition and then copied the directory.

After rebooting the server he see GRUB prompt; it never goes to the menu. This is a production server and the time slot for the upgrade was 30 min. Investigation that involves now other sysadmins and that took three hours as server needed to be rebooted, backups retrieved to other server from the tape, etc, reveals that /boot directory did not contain a couple of critical files such as /boot/message and /boot/grub/menu.lst. Remember /boot partition was wiped clean. 

BTWs /boot/message is an executable and grub stops execution of stpped /boot/grub/menu.lst.when it encounted instruction

gfxmenu (hd0,1)/message

Here is an actual /boot/grub/menu.lst.

# 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

 

Luckily there was a backup done before this "fix". Four hours later server was bootable again. 

[Apr 19, 2010] Migrate to GRUB 2 by Roderick W. Smith

Summary:  The tools used to boot Linux® are changing. Specifically, the Grand Unified Bootloader (GRUB) is now officially in maintenance mode only, and GRUB's developers have abandoned the original GRUB in favor of an entirely rewritten package, known as GRUB 2. Discover GRUB 2's new capabilities and how to use it.

Date:  14 Apr 2010
Level:  Intermediate

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
 
 

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:

RHEL 5 Installation Guide

9.2. GRUB
9.2.1. GRUB and the x86 Boot Process
9.2.2. Features of GRUB
9.3. Installing GRUB
9.4. GRUB Terminology
9.4.1. Device Names
9.4.2. File Names and Blocklists
9.4.3. The Root File System and GRUB
9.5. GRUB Interfaces
9.5.1. Interfaces Load Order
9.6. GRUB Commands
9.7. GRUB Menu Configuration File
9.7.1. Configuration File Structure
9.7.2. Configuration File Directives
9.8. Changing Runlevels at Boot Time
9.9. Additional Resources
9.9.1. Installed Documentation
9.9.2. Useful Websites
9.9.3. Related Books

 Using Grub To Change RedHat Linux's Root Password

08/06/2008 The Linux and Unix Menagerie

On many distros the 'single' or 'rescue' boot will still ask for a password. You can get around this by starting linux without starting initd, just launch a shell instead; and it's blindingly fast.

'e' to edit the boot entry, select the kernel line and press 'e' again, then type "init=/bin/bash", enter, press 'b' to boot it. You end up at a root prompt with / mounted read-only. (depending on the distro, you might need /bin/sh instead)

# mount / -o remount,rw
# passwd
<change your root password here>
# mount / -o remount,ro
<three-finger salute or hit the reset button>

It's also useful for fixing up boot problems, if you're silly enough to have put commands in various init scripts that don't actually exit or daemonize...

shutting down after init=-bin-bash - LinuxQuestions.org

By the way, when you do init=/bin/sh (or bash), it isn't strictly necessary to reboot afterwards (well, depending on what you change I suppose), you can just do an 'exec /sbin/init' to continue the boot process. Make sure the state of the system is as it would normally be though (e.g. umount /usr, make / readonly again etc).

Boot with GRUB

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

... ... ...

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.

[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:

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 (guinix@yahoo.com) 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.

Recommended Links




Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 18, 2014