Overview of Boot Prompt Arguments

# 2. Overview of Boot Prompt Arguments

Contents of this section

This section gives some examples of software that can be used to pass kernel boot-time arguments to the kernel itself. It also gives you an idea of how the arguments are processed, what limitations there are on the boot args, and how they filter down to each appropriate device that they are intended for.

## 2.1 LILO (LInux LOader)

The LILO program (LInux LOader) written by Werner Almesberger is the most commonly used. It has the ability to boot various kernels, and stores the configuration information in a plain text file. Most distributions ship with LILO as the default boot-loader. LILO can boot DOS, OS/2 Linux, FreeBSD, etc. without any difficulties, and is quite flexible.

LILO ships with excellent documentation, and for the purposes of boot args discussed here, the LILO `append=` command is of significant importance.

## 2.2 LoadLin

The other commonly used Linux loader is `LoadLin' which is a DOS program that has the capability to launch a Linux kernel from the DOS prompt (with boot-args) assuming that certain resources are available. This is good for people that use DOS and want to launch into Linux from DOS.

It is also very useful if you have certain hardware which relies on the supplied DOS driver to put the hardware into a known state. A common example is `SoundBlaster Compatible' sound cards that require the DOS driver to twiddle a few mystical registers to put the card into a SB compatible mode. Booting DOS with the supplied driver, and then loading Linux from the DOS prompt with loadlin avoids the reset of the card that happens if one rebooted instead. Thus the card is left in a Sb compatible mode and hence is useable under Linux.

There are also other programs that can be used to boot Linux. For a complete list, please look at the programs available on your local Linux ftp mirror, under `system/Linux-boot/`.

## 2.3 The ``rdev'' utility

There are a few of the kernel boot parameters that have their default values stored in various bytes in the kernel image itself. There is a utility called `rdev` that is installed on most systems that knows where these values are, and how to change them. It can also change things that have no kernel boot argument equivalent, such as the default video mode used.

The rdev utility is usually also aliased to swapdev, ramsize, vidmode and rootflags. These are the five things that rdev can change, those being the root device, the swap device, the RAM disk size, the default video mode, and the readonly/readwrite setting of root device.

More information on `rdev` can be found by typing `rdev -h` or by reading the supplied man page.

## 2.4 How the Kernel Sorts the Arguments

Most of the boot args take the form of:

            name[=value_1][,value_2]...[,value_11]

where `name' is a unique keyword that is used to identify what part of the kernel the associated values (if any) are to be given to. Multiple boot args are just a space separated list of the above format. Note the limit of 11 is real, as the present code only handles 11 comma separated parameters per keyword. (However, you can re-use the same keyword with up to an additional 11 parameters in unusually complicated situations, assuming the setup function supports it.)

Most of the sorting goes on in `linux/init/main.c`. First, the kernel ckecks to see if the argument is any of the special arguments `root=', `ro', `rw', or `debug'. The meaning of these special arguments is described further on in the document.

Then it walks a list of setup functions (contained in the `bootsetups` array) to see if the specified argument string (such as `foo') has been associated with a setup function (`foo_setup()') for a particular device or part of the kernel. If you passed the kernel the line `foo=3,4,5,6` then the kernel would search the `bootsetups` array to see if `foo' was registered. If it was, then it would call the setup function associated with `foo' (foo_setup()) and hand it the arguments 3, 4, 5 and 6 as given on the kernel command line.

## 2.5 Setting Environment Variables.

Anything of the form `foo=bar' that is not accepted as a setup funtion as described above is then interpreted as an environment variable to be set. A (useless?) example would be to use `TERM=vt100' as a boot argument.

## 2.6 Passing Arguments to `init'

Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto process one, which is usually the `init` program. The most common argument that is passed to the `init` process is the word single which instructs `init` to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of `init` installed on your system to see what arguments it accepts.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter