Step 5: Configure Your Boot Loader

The previous four steps are used to install any program, but the Linux kernel executable is part of the operating system, so we have to do a few additional things to cause the computer to recognize the kernel at boot time.

To complete this step, you must know what type of boot loader your system is using. Newer Linux distributions use GRUB as the boot loader of choice, but many older distributions use the LILO boot loader. (Reboot your system and watch it boot if you are not sure—the type of boot loader you are using will be displayed during bootup.)

Note

If you are using a SCSI boot disk, see the "SCSI Gotchas" section later in the chapter.

Both LILO and GRUB give you the ability at boot time to select which kernel to boot from, selecting from those listed in their configuration files. This is useful if your new kernel doesn't work properly. Therefore, you should always add a reference to your new kernel in the boot loader configuration file and leave the references to the previous kernels as a precaution.

If you are using LILO, you'll modify the /etc/lilo.conf file; if you are using GRUB, you'll modify the /boot/grub/grub.conf file (or the /boot/grub/ menu.lst if you installed GRUB from source).

Add your new kernel to lilo.conf with an entry that looks like this:

 image=/boot/vmlinuz-<version>     label=linux.orig     initrd=/boot/initrd-<version>.img     read-only     root=/dev/hda2

Add your new kernel to grub.conf with an entry that looks like this:

 title My New Kernel (<version>)     root (hd0,0)     kernel /vmlinuz-<version> ro root=/dev/hda2     initrd /initrd-<version>.img

You do not need to do anything to inform the GRUB boot loader about the changes you make to the grub.conf configuration file, because GRUB knows how to locate files even before the kernel has loaded. It can find its configuration file at boot time. However, when using LILO, you'll need to enter the command lilo -v to install a new boot sector that tells LILO where the configuration file resides on the disk (because LILO doesn't know how to use the normal Linux filesystem at boot time).

BOOT LOADERS AND ROOT FILESYSTEMS

The name / is given to the Linux root filesystem mount point. This mount point can be used to mount an entire disk drive or just a partition on a disk drive, though normally the root filesystem is a partition. (On Red Hat systems, Linux uses the second partition of the first disk device at boot time; the first partition is usually the /boot partition).

To find out which root partition or device your system is using, use the df command. For example, the following df command shows that the root filesystem is using the /dev/hda2 partition:

 # df Filesystem     1K-blocks   Used Available Use% Mounted on /dev/hda2      8484408  1195652  6857764 15% / /dev/hda1       99043   9324   84605 10% /boot

When you modify the boot loader configuration file, you must tell the Linux kernel which device, or device and partition, to use for the root filesystem. When using LILO as your boot loader, you specify the root filesystem in the lilo.conf file with a line that looks like this:

 root=/dev/hda2

The grub.conf configuration file entry looks like this:

 kernel /vmlinuz-<version> ro root=/dev/hda2

Note, however, that the Red Hat kernel allows you to use a symbolic name that looks like this:

 kernel /vmlinuz-<version> ro root=LABEL=/

Using the syntax LABEL=/ to specify the root filesystem is only possible when using Red Hat kernels. If you compile the stock kernel, you must specify the root partition device name, such as /dev/hda2.

One final concern when specifying the root filesystem using GRUB is that the GRUB boot loader also has its own root filesystem. The GRUB root filesystem has nothing to do with the Linux root filesystem and is usually on a different partition (it is the /boot partition on Red Hat systems).

To tell GRUB which disk partition to use at boot time as its root filesystem, create an entry such as the following in the grub.conf configuration file:

 root (hd0,0)

This tells GRUB to use the first partition of the first hard drive as the GRUB root filesystem. GRUB calls the first hard drive hd0 (whether it is SCSI or IDE), and partitions are numbered starting with 0. So to use the second partition of the first drive, the syntax would be as follows:

 root (hd0,1)

Note

see the /boot/grub/device.map file for the list of devices on your system.^[8]

Again, this is the root filesystem used by GRUB when the system first boots, and it is not related to the root filesystem used by the Linux kernel after the system is up and running. To list all of the partitions on a device, you can use the command sfdisk -l.

Now you are ready to reboot and test the new kernel.

Enter reboot at the command line, and watch closely as the system boots. If the system hangs, you may have selected the wrong processor type. If the system fails to mount the root drive, you may have installed the wrong filesystem support in your kernel. (If you are using a SCSI system, see the "SCSI Gotchas" section for more information.)

If the system boots but does not have access to all of its devices, review the kernel options you specified in step 2 of this chapter.

Once you can access all of the devices connected to the system, and you can perform normal network tasks, you are ready to test your application or applications.

SCSI GOTCHAS

If you are using a SCSI disk to boot your system, you may want to avoid some complication and compile support for your SCSI driver directly into the kernel, instead of loading it as a module. If you do this on a kernel version prior to version 2.6, you will save yourself the trouble of building the initial RAM disk. However, if you are building a modular kernel from version 2.4 or an earlier series, you will still need to build an initial RAM disk so the Linux kernel can boot up far enough to load the proper module to communicate with your SCSI disk drive. (See the man page for the mkinitrd Red Hat utility for the easiest way to do this on Red Hat systems. The mkinitrd command automates the process of building an initial RAM disk.) The initial RAM disk, or initrd file, must then be referenced in your boot loader configuration file so that the system knows how to mount your SCSI boot device before the modular kernel runs.

Also, if you recompile your 2.4 modular kernel without changing the EXTRAVERSION number in the Makefile, you may accidentally overwrite your existing /lib/modules libraries. If this happens, you may see the error "All of your loopback devices are in use!" when you run the mkinitrd command. If you see this error message, you must rebuild the kernel (before rebooting the system!) and add the SCSI drivers into the kernel. Do not attempt to build the drivers as modules and skip the mkinitrd process altogether.

^[8]The /boot/grub/device.map file is created by the installation program anaconda on Red Hat systems.