Section 14.1. Objective 1: Boot the System | LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))

14.1. Objective 1: Boot the System

It is the job of a boot loader, such as LILO or GRUB, to launch the Linux kernel at boot time. In some cases, the boot loader has to deliver information to the Linux kernel that may be required to configure peripherals or control other behavior. This information is called a kernel parameter.

14.1.1. Boot-time Kernel Parameters

By default, your system's kernel parameters are set in your boot loader's configuration file (/etc/lilo.conf or /boot/grub/menu.lst, and boot/grub/grub.conf on Red Hat and some other distributions). However, the Linux kernel also has the capability to accept information at boot time from a kernel command-line interface. You access the kernel command line through your installed boot loader. When your system boots, you can interrupt the "default" boot process when the boot loader displays and specify your desired kernel parameters. The kernel parameters on the command line look similar to giving arguments or options to a program during command-line execution.

For an example, let's say you wanted to boot with a root partition other than your default, /dev/hda1. Using LILO, you could enter the following at the LILO prompt:

 LILO: linux root=/dev/hda9

This command boots the kernel whose label is linux and overrides the default value of /dev/hda1 to /dev/hda9 for the root filesystem.

On the Exam

There are far too many kernel parameters to list in this book. Consequently, you must familiarize yourself with them in general terms so that you can answer questions on their form. Remember that they are specified to your boot loader as either a single item, such as ro, or name=value options such as root=/dev/hda2. Multiple parameters are always separated by a space.

14.1.2. Introduction to Kernel Module Configuration

Modern Linux kernels are modular, in that modules of code traditionally compiled into the kernel (say, a sound driver) are loaded as needed. The modules are separate from the kernel and can be inserted and removed by the superuser if necessary. While parameters in the boot loader's configuration file and the kernel command line affect the kernel, they do not control kernel modules.

To send parameters to a kernel module, they are inserted into the file /etc/modules.conf as text (in the past this configuration file was /etc/conf.modules). Common module options you may find in your module configuration file are I/O address, interrupt, and DMA channel settings for your sound device. This file will also probably carry PCMCIA driver information when installed on laptops. Module configuration will probably be handled by your distribution's installation procedure but may require modifications if hardware is added or changed later. Example 14-1 shows a typical /etc/modules.conf file.

Example 14-1. A typical /etc/modules.conf file

 alias parport_lowlevel parport_pc alias eth0 8139too alias sound-slot-0 via82cxxx_audio post-install sound-slot-0 /bin/aumix-minimal \     -f /etc/.aumixrc -L >/dev/null 2>&1 || : pre-remove sound-slot-0 /bin/aumix-minimal \     -f /etc/.aumixrc -S >/dev/null 2>&1 || : alias usb-controller usb-uhci

On the Exam

Read questions that ask about kernel or module parameters carefully. Kernel options can be passed on the kernel command line; module options are specified in modules.conf.

In this example, note that an alias named sound-slot-0 is created for the audio driver via82cxxx_audio. Most devices won't need any additional configuration, but systems with older ISA cards may still need to pass options for I/O port, IRQ, and DMA channel settings. In addition, some drivers may need options to specify nonstandard settings. For example, an ISDN board used in North America will need to specify NI1 signaling to the driver.

 options hisax protocol=4 type=40

14.1.2.1. Kernel boot-time messages

As the Linux kernel boots, it gives detailed status of its progress in the form of console messages. Modules that are loaded also yield status messages. These messages contain important information regarding the health and configuration of your hardware. Generally, the kinds of messages you will see are:

Kernel identification
Memory and CPU information
Information on detected hardware, such as pointers (mice), serial ports, and disks
Partition information and checks
Network initialization
Kernel module output for modules that load at boot time

These messages are displayed on the system console at boot time but often scroll off the screen too fast to be read. The messages are also logged to disk. They can easily be viewed using the dmesg command, which displays messages logged at the last system boot. For example, to view messages from the last boot sequence, simply pipe the output of dmesg to less:

 # dmesg | less

It is also common to use dmesg to dump boot messages to a file for later inspection or archive, by simply redirecting the output:

 # dmesg > bootmsg.txt

Tip: The kernel buffer used for log messages that dmesg displays is a fixed size, so it may lose some (or all) of the boot-time messages as the kernel writes runtime messages.

14.1.2.2. Reviewing system logs

In addition to kernel messages, many other boot-time messages will be logged using the syslog system. Such messages will be found in the system log files such as /var/log/messages. For example, dmesg displays information on your network adapter when it was initialized. However, the configuration and status of that adapter is logged in /var/log/messages as a result of the network startup. When examining and debugging boot activity on your system, you need to review both kinds of information. syslogd, its configuration, and log file examination are covered in the section "Objective 3: Configure and Use System Log Files to Meet Administrative and Security Needs" in Chapter 18.