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.

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.

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

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

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.

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset