3. General Non-Device Specific Boot Args

Contents of this section

These are the boot arguments that are not related to any specific device or peripheral. They are instead related to certain internal kernel parameters.

3.1 The `no387' Argument

Some i387 coprocessor chips have bugs that show up when used in 32 bit protected mode. For example, some of the early ULSI-387 chips would cause solid lockups while performing floating point calculations. Using the `no387' boot arg causes Linux to ignore the maths coprocessor even if you have one. Of course you must then have your kernel compiled with math emulation support!

3.2 The `no-hlt' Argument

The i386 (and sucessors thereof) family of CPUs have a `hlt' instruction which tells the CPU that nothing is going to happen until an external device (keyboard, modem, disk, etc.) calls upon the CPU to do a task. This allows the CPU to enter a `low-power' mode where it sits like a zombie until an external device wakes it up (usually via an interrupt). Some of the early i486DX-100 chips had a problem with the `hlt' instruction, in that they couldn't reliably return to operating mode after this instruction was used. Using the `no-hlt' instruction tells Linux to just run an infinite loop when there is nothing else to do, and to not halt your CPU when there is no activity. This allows people with these broken chips to use Linux, although they would be well advised to seek a replacement through a warranty where possible.

3.3 The `root=' Argument

This argument tells the kernel what device is to be used as the root filesystem while booting. The default of this setting is the value of the root device of the system that the kernel was built on. For example, if the kernel in question was built on a system that used `/dev/hda1' as the root partition, then the default root device would be `/dev/hda1'. To override this default value, and select the second floppy drive as the root device, one would use `root=/dev/fd1'.

Valid root devices are partitions on any of the following disk devices:

(1) /dev/hdaN to /dev/hddN, which is partition N on ST-506 compatible disk `a to d'.

(2) /dev/sdaN to /dev/sdeN, which is partition N on SCSI compatible disk `a to e'.

(3) /dev/xdaN to /dev/xdbN, which is partition N on XT compatible disk `a to b'.

(4) /dev/fdN, which is floppy disk drive number N. Having N=0 would be the DOS `A:' drive, and N=1 would be `B:'.

The more awkward and less portable numeric specification of the above possible root devices in major/minor format is also accepted. (e.g. /dev/sda3 is major 8, minor 3, so you could use root=0x803 as an alternative.)

This is one of the few kernel boot arguments that has its default stored in the kernel image, and which can thus be altered with the rdev utility.

3.4 The `ro' Argument

When the kernel boots, it needs a root filesystem to read basic things off of. This is the root filesystem that is mounted at boot. However, if the root filesystem is mounted with write access, you can not reliably check the filesystem integrity with half-written files in progress. The `ro' option tells the kernel to mount the root filesystem as `readonly' so that any filesystem consistency check programs (fsck) can safely assume that there are no half-written files in progress while performing the check. No programs or processes can write to files on the filesystem in question until it is `remounted' as read/write capable.

This is one of the few kernel boot arguments that has its default stored in the kernel image, and which can thus be altered with the rdev utility.

3.5 The `rw' Argument

This is the exact opposite of the above, in that it tells the kernel to mount the root filesytem as read/write. The default is to mount the root filesystem as read/write anyways. Do not run any `fsck' type programs on a filesystem that is mounted read/write.

The same value stored in the image file mentioned above is also used for this parameter, accesible via rdev.

3.6 The `debug' Argument

The kernel communicates important (and not-so important) messages to the operator via the printk() function. If the message is considered important, the printk() function will put a copy on the present console as well as handing it off to the klogd() facility so that it gets logged to disk. The reason for printing important messages to the console as well as logging them to disk is because under unfortunate circumstances (e.g. a disk failure) the message won't make it to disk and will be lost.

The threshold for what is and what isn't considered important is set by the console_loglevel variable. The default is to log anything more important than DEBUG (level 7) to the console. (These levels are defined in the include file kernel.h) Specifying debug as a boot argument will set the console loglevel to 10, so that all kernel messages appear on the console.

The console loglevel can usually also be set at run time via an option to the klogd() program. Check the man page for the version installed on your system to see how to do this.

3.7 The `reserve=' Argument

This is used to protect I/O port regions from probes. The form of the command is:

reserve=iobase,extent[,iobase,extent]...

In some machines it may be necessary to prevent device drivers from checking for devices (auto-probing) in a specific region. This may be because of poorly designed hardware that causes the boot to freeze (such as some ethercards), hardware that is mistakenly identified, hardware whose state is changed by an earlier probe, or merely hardware you don't want the kernel to initialize.

The reserve boot-time argument addresses this problem by specifying an I/O port region that shouldn't be probed. That region is reserved in the kernel's port registration table as if a device has already been found in that region. Note that this mechanism shouldn't be necessary on most machines. Only when there is a problem or special case would it be necessary to use this.

The I/O ports in the specified region are protected against device probes. This was put in to be used when some driver was hanging on a NE2000, or misidentifying some other device as its own. A correct device driver shouldn't probe a reserved region, unless another boot argument explicitly specifies that it do so. This implies that reserve will most often be used with some other boot argument. Hence if you specify a reserve region to protect a specific device, you must generally specify an explicit probe for that device. Most drivers ignore the port registration table if they are given an explicit address.

For example, the boot line


        reserve=0x300,32  blah=0x300

keeps all device drivers except the driver for `blah' from probing 0x300-0x31f.

As usual with boot-time specifiers there is an 11 parameter limit, thus you can only specify 5 reserved regions per reserve keyword. Multiple reserve specifiers will work if you have an unusually complicated request.

3.8 The `ramdisk=' Argument

This specifies the size in kB of the optional RAM disk device. For example, if one wished to have a root filesystem on a 1.44MB floppy loaded into the RAM disk device, they would use:


        ramdisk=1440

This is one of the few kernel boot arguments that has its default stored in the kernel image, and which can thus be altered with the rdev utility.

3.9 The `mem=' Argument

The original BIOS call defined in the PC specification that returns the amount of installed memory was only designed to be able to report up to 64MB. (Yes, another lack of foresight, just like the 1024 cylinder disks... sigh.) Linux uses this BIOS call at boot to determine how much memory is installed. If you have more than 64MB of RAM installed, you can use this boot arg to tell Linux how much memory you have. Here is a quote from Linus on usage of the `mem=' parameter.

``The kernel will accept any `mem=xx' parameter you give it, and if it turns out that you lied to it, it will crash horribly sooner or later. The parameter indicates the highest addressable RAM address, so `mem=0x1000000' means you have 16MB of memory, for example. For a 96MB machine this would be `mem=0x6000000'.

NOTE NOTE NOTE: some machines might use the top of memory for BIOS cacheing or whatever, so you might not actually have up to the full 96MB addressable. The reverse is also true: some chipsets will map the physical memory that is covered by the BIOS area into the area just past the top of memory, so the top-of-mem might actually be 96MB + 384kB for example. If you tell linux that it has more memory than it actually does have, bad things will happen: maybe not at once, but surely eventually.''

Note that the argument does not have to be in hex, and the suffixes `k' and `M' (case insensitive) can be used to specify kilobytes and Megabytes, respectively. (A `k' will cause a 10 bit shift on your value, and a `M' will cause a 20 bit shift.) The above warning still holds, in that a 96MB machine may work with mem=97920k but fail with either mem=98304k or mem=96M.


Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter