The Linux Boot Prompt

The LILO and GRUB processes are modified through their configuration files. The kernel boot process is modified through input to the boot prompt. As with the LILO append option and the GRUB kernel command, the boot prompt is used to pass parameters to the kernel. The difference, however, is that the boot prompt is used to manually enter kernel parameters, whereas the append and kernel commands are used to automate the process when the same parameters must be passed to the kernel for every boot. Use the boot prompt for special situations, such as repairing a system or getting an unruly piece of equipment running; or to debug input before it is stored in the lilo.conf or grub.conf file.

You rarely need to pass parameters to the kernel through the boot prompt. When you do, it is either to change the boot process or to help the system handle a piece of unknown hardware. The kernel command from the grub.conf file shown in Listing 1.1 is an example of using boot input to change the boot process:

kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/hda3

This line comes from the grub.conf file, but it also can be entered interactively during the boot process. When the GRUB menu is displayed at boot time, the operator is given 10 seconds to select an optional menu item, or interrupt the boot process. Interrupt the boot by pressing the Escape key. If a password is defined in the grub.conf file, press P, and enter the GRUB password. Then, press C for command mode, and a command line prompt appears. This is the boot prompt that allows arguments to be sent to the kernel using the kernel command interactively. The format of the kernel command is kernel file arguments where kernel is the command, file is the name of the file that contains the Linux kernel, and arguments are any optional arguments you wish to pass to the kernel. In the preceding kernel command example, ro root=/dev/hda3 are arguments that change the default boot behavior so that the root filesystem is mounted read-only. The possible arguments depend on the kernel, not on whether GrUb or LILO is used to control the boot process. Any of the kernel arguments described in this section can be sent to the kernel in this manner on a system that uses GRUB. The LILO boot prompt is different, but the function is the same.

When the system is booted by LILO, the string boot: is displayed as the boot prompt. The operator can boot any operating system defined in the lilo.conf file by entering its name at the prompt (for example, linux, or dos). Arguments are passed to the selected operating system by placing them on the command line after the operating system name. An example of passing kernel parameters on a system booted by LILO is boot: linux panic=60

In this example, boot: is the prompt, linux is the kernel name, and panic=60 is the parameter passed to that kernel. The keyword linux is the label assigned to the Linux kernel in the LILO configuration. Use the label to tell LILO which kernel should receive the parameter. The panic argument changes the boot behavior after a system crash. It is possible for the Linux kernel to crash from an internal error, called a kernel panic. If the system crashes from a kernel panic, it does not automatically reboot—it stops at the boot prompt waiting for instructions.

Normally, this is a good idea. The exception is an unattended server. If you have a system that does not have an operator in attendance and that remote users rely on, it might be better to have it try an automatic reboot after it crashes. The example shown previously tells the system to wait 60 seconds and then reboot.

Note This might surprise Windows administrators, but I have never had a Linux system crash. In fact, I had one specialized system (collecting network measurement data, and providing Web access to that data) that ran continuously for more than a year without a single problem.

In a normal boot process, the kernel starts the /sbin/init program. Using the init argument, it is possible to tell the kernel to start another process instead of /sbin/init. For example, init=/bin/sh causes the system to run the shell program, which then can be used to repair the system if the / sbin/init program is corrupted.

Booting directly to the shell looks very much like booting to single-user mode with the single argument, but there are differences. init=/bin/sh does not rely on the init program. single, on the other hand, is passed directly to init so that init can perform selected initialization procedures before placing the system into single-user mode. In both of these cases, the person who boots the computer is given password-free access to the shell unless password and restrict are defined in the lilo.conf file, as described in the previous section.

Handling undetected hardware is the second reason for entering data at the boot prompt, and it is the most common reason for doing so during the initial installation. Sometimes, the system has trouble detecting hardware or properly detecting the hardware's configuration. In those cases, the system needs your input at the boot prompt to properly handle the unknown hardware.

A large number of the boot input statements pass parameters to device driver modules. For example, there are about 20 different SCSI host adapter device drivers that accept boot parameters. In most cases, the system detects the SCSI adapter configuration without a problem. But if it doesn't, booting the system may be impossible. An example of passing kernel parameters to Linux to identify an undetected SCSI adapter device is boot: linux aha152x=0x340,11,7

All hardware parameters begin with a driver name. In this case, it is the aha152x driver for Adaptec 1520 series adapters. The data after the equal sign is the information passed to the driver. In this case, it is the I/O port address, the IRQ, and the SCSI ID.

Another boot argument that is directly related to the configuration of device drivers is the reserve argument. reserve defines an area of I/O port address memory that is protected from auto-probing. To determine the configuration of their devices, most device drivers probe those regions of memory that can be legitimately used for their devices. For example, the 3COM EtherLink III Ethernet card is configured to use I/O port address 0x300 by default, but it can be configured to use any of 21 different address settings from 0x200 to 0x3e0. If the 3c509 driver did not find the adapter installed at address 0x300, it could legitimately search all 21 base address regions. Normally, this is not a problem. On occasion, however, auto-probing can return the wrong configuration values. In extreme cases, poorly designed adapters can even hang the system when they are probed. I have never personally seen an adapter hang the system, but some years ago I had an Ethernet card that returned the wrong configuration. In that case, I combined the reserve argument with device driver input, as in this example:

boot: linux reserve=0x210,16 ether=10,0x210,eth0

This boot input prevents device drivers from probing the 16 bytes starting at memory address 0x210. The second argument on this line passes parameters to the ether device driver. It tells that driver that the Ethernet adapter uses interrupt 10 and I/O port address 0x210. This specific adapter will be known as device eth0, which is the name of the first Ethernet device. Of course, you'll want to use the Ethernet adapter every time the system boots. Once you're sure this boot input fixes the Ethernet problem, store it as a kernel-specific option in the lilo.conf file. For example:

image = /boot/vmlinuz-2.2.5-15 label = linux root = /dev/hda3 read-only append = "reserve=0x210,16 ether=10,0x210,eth0"

The ether argument is also used to force the system to locate additional Ethernet adapters. Suppose that the system detects only one Ethernet adapter, and you have two Ethernet devices installed: eth0 and eth1. Use this boot input to force the system to probe for the second device:


Old Ethernet cards are a major reason for boot prompt input. If you have an old card and experience a problem, read the Ethernet-HOWTO for configuration advice on your specific card. New PCI Ethernet cards do not usually require boot input. Most current Ethernet cards use loadable modules for device drivers. If your Ethernet card is not recognized during the boot, it may be that its module is not loaded. The first step is to check the module's configuration.

Note See the "Loadable Modules" section later in this chapter for information about managing modules and for specific examples of loadable modules used for Ethernet device drivers.

This section has barely touched upon the very large number of arguments that can be entered at the boot prompt. See the "BootPrompt-HOWTO" document, by Paul Grotmaker, for the details of all of them. Most Linux systems include the HOWTO documents in /usr/doc.

Was this article helpful?

0 0

Post a comment