C.4 Boot Parameters
Boot parameters are specified using
a three-part directive that includes the name of the
parameter and an optional list of options, which consists of an equal
sign (=) followed by a comma-separated list of
option values
No spaces may appear in the directive. As an example, the following
directive specifies the identity of the Linux root partition:
root=/dev/hda1
The installation program generally refers to partitions by using
labels, so that you can boot a system even if you move the partitions
around. A root directive referring to a label looks like this:
root=LABEL=/usr
You can specify multiple directives by separating them with a space.
For example, the following specifies the identity of the Linux root
partition and that the root partition is initially mounted read-only,
so that a thorough check of its filesystem can be performed:
root=/dev/hda1 ro
Most directives are interpreted by the kernel, though GRUB is also
capable of processing directives. If you specify a directive that
neither the kernel nor GRUB understands (assuming
you're using GRUB), a directive that includes an
equal sign is passed to the init process as an
environment variable. You learned about environment variables in
Chapter 7. A nonkernel directive that doesn't
include an equal sign is passed to the init
process. An example of this usage is specifying the directive
single, which causes init to
start your system in single-user mode:
root=/dev/hda1 ro single
C.4.1 General Boot Arguments
Table C-2
describes some of the most popular
and useful boot arguments. These arguments apply to your system as a
whole; in subsequent sections, you'll learn about
other boot arguments that apply to specific devices or functions. In
addition to boot arguments previously introduced, the table describes
the reserve argument, which is helpful in avoiding
system memory conflicts.
C.4.2 RAM Disk Boot Arguments
Table C-3
describes four boot arguments used in
working with RAM disks. You won't likely need to
specify any of these, but knowing about them may help you understand
boot specifications written by others, including those used by Red
Hat Linux.
C.4.3 SCSI Host Adapter Boot Arguments
Table C-4
describes the most often used boot
arguments related to SCSI host adapters. Table C-5
describes the options used by the SCSI host adapter boot arguments
and other boot arguments.
Adaptec aha154x SCSI host adapters use a boot argument having the
form:
iobase[,buson,busoff[,dmaspeed]]
Table C-5 helps you understand the form of the
iobase option and the other italicized options.
The iobase option, for example, lets you specify
the I/O port associated with the SCSI host adapter. For example, you
can specify a boot argument for an Adaptec aha154x SCSI host adapter
by writing only an iobase option; the remaining
options are optional. However, as indicated by the square brackets,
if you include a buson option, you
must include a busoff option. Similarly, to
include the dmaspeed option, you must include each of the
other options. Here's an example of a complete boot
argument:
aha1542=0x300,11,4
hardware structure of your system. The procedures described in
Chapter 2 will help you.
C.4.4 IDE Hard Drive and CD-ROM Boot Arguments
Table C-6 describes the most commonly used boot
arguments associated with IDE hard drives and CD-ROM drives. Refer to
Table C-5 to determine the form of the italicized
options.
C.4.5 Non-IDE CD-ROM Drive Boot Arguments
Table C-7 describes the most common boot arguments
for non-IDE CD-ROM drives. Refer to Table C-5 to
determine the form of the italicized options.
Argument | Description and options |
---|---|
aztcd= | Aztech CD-ROM: iobase[,magic_number][C] |
cdu31a= | Sony CDU-31A or CDU-33A CD-ROM: iobase,[irq[,is_pas_card] |
sonycd535= | Sony CDU-535 CD-ROM: iobase[,irq] |
gscd= | Goldstar CD-ROM: iobase |
isp16= | ISP16 CD-ROM: [port[,irq[,dma]]][[,]drive_type] |
mcd= | Mitsumi CD-ROM: iobase,[irq[,wait_value]] |
optcd= | Optical Storage CD-ROM: iobase |
cm206= | Phillips CD206 CD-ROM: [iobase][,irq] |
sjcd= | Sanyo CD-ROM: iobase[,irq[,dma_channel]] |
sbpcd= | SoundBlaster Pro CD-ROM: iobase,type |
C.4.6 Floppy Drive Boot Arguments
A few systems require special boot
arguments to best use their floppy drives. Table C-8 describes the most common boot arguments
related to floppy drives. Floppy drives that are not well behaved may
malfunction if you specify the daring option,
which you should use only with care. For additional boot arguments
related to floppy drives, see
/usr/src/linux/Documentation/floppy.txt.
Argument and option | Description |
---|---|
floppy=asus_pci | Specifies that only units 0 and 1 are allowed, to work around problem with BIOS of certain ASUS motherboards. |
floppy=daring | Specifies that the floppy controller is well behaved, allowing more efficient operation. |
floppy=0,daring | Specifies that the floppy controller may not be well behaved (default). |
floppy=thinkpad | Specifies that the system is an IBM ThinkPad. |
floppy=no_unexpected_ interrupts or floppy=L40SX | Specifies that a message should be printed when an unexpected interrupt is received. This is required by IBM L40SX laptops in certain video modes. |
C.4.7 Bus Mouse Boot Arguments
Two boot arguments provide bus mouse
support. The first supports the Microsoft bus mouse:
msmouse=irq
The second supports any non-Microsoft bus mouse:
bmouse=irq
Each argument accepts a single option specifying the IRQ associated
with the mouse.
C.4.8 Parallel Port Printer Boot Arguments
The Linux printer driver claims all
available parallel ports. If you want to access a device other than a
printer attached to a parallel port, you must instruct the printer
driver to reserve only the ports associated with printers. To do so,
use the lp boot argument, which takes as its
options a list of ports and IRQs used to support printers. For
example, the following boot argument specifies two printers:
lp=0x3bc,0,0x378,7
The first printer is on port 0x3bc and the second is on port 0x378.
The first printer uses a special IRQ-less mode known as polling, so
its IRQ is specified as 0. The second printer uses IRQ 7.
To disable all printers, specify lp=0.
C.4.9 Loadable Ethernet Drivers
Early versions of Linux used a so-called
monolithic kernel. At that time, Linux
distributions typically included several kernels, offering support
for a variety of devices that might be needed to boot and install a
Linux system. Devices not needed to boot and install a
systemso-called special deviceshad second-class status.
To access special devices, users had to compile customized
kernels that
included support for those devices. When adding a device to a system,
users often had to compile a new kernel, which was something of an
inconvenience.
More recent versions of Linux feature a modular kernel, which allows drivers to
be dynamically loaded on command. This makes it much easier than
before to configure your Linux system to support Ethernet cards and
other special devices. Red Hat Linux is generally able to configure
your primary Ethernet card automatically, by probing for it during
installation of Linux.
However, the
autoprobe doesn't always succeed. Moreover, if you
have more than one Ethernet card, the installation program sets up
only the first card it finds. To set up additional cards, you need to
know a bit about Linux's loadable modules.
C.4.10 Dynamically Loading a Modular Driver
To
dynamically load a modular driver, issue the following command:
# modprobe driver
where driver specifies the module to be loaded.
As an example, the command:
# modprobe ne2k-pci
loads the modular driver for the PCI-based NE2000 Ethernet card.To find out what network adapters are supported by Red Hat Linux or
to find out what driver to use with a particular adapter, see the Red
Hat Linux Hardware Compatibility List,
http://hardware.redhat.com.
When a driver is loaded, it generally probes to locate the supported
device. In case an autoprobe fails, most drivers let you specify the
I/O port and IRQ by using a command like the following:
# modprobe ne2k=pci io=0x280 irq=11
Some cards support additional options; these are documented in the
file /usr/src/
linux/Documentation/networking/net-modules.txt.
C.4.11 Loading Modular Drivers at Boot Time
The Linux kernel automatically loads
modules specified in the module configuration file,
/etc/modules.conf. So, once
you've determined the proper module and options
required by your Ethernet card, you can add a line or two to the
module configuration file so that your card will be made ready to
operate each time you boot your system.
The alias directive associates a logical module
name with an actual module. Logical module names specify types of
devices; for example,
eth0 specifies the first Ethernet card in a
system, and eth1 specifies the second Ethernet
card in a system. Suppose your system includes two Ethernet cards: a
non-PCI-based NE2000 and an SMC EtherPower, which is based on
DEC's TULIP chip. You could use the following
directives to automatically load these modules at boot time:
alias eth0 ne
alias eth1 tulip
If a driver requires options, you can specify them by using an
options directive, which has the following form:
options driver argument=value[,value,...] argument=value[,value,...] ...
For example, you might specify the I/O port and IRQ used by the
NE2000 card like this:
options ne io=0x280 irq=12
Most ISA modules accept parameters like io=0x340 and irq=12 on the
insmod command line. You should
supply these parameters to avoid probing for the card. Unlike PCI and
EISA devices, ISA devices sometimes cannot be safely autoprobed.
C.4.12 Administering Modular Drivers
The lsmod command, which takes no arguments,
lists the loaded modular drivers. To unload a modular driver, specify
the driver as the argument of the modprobe command and specify the -r argument. For example, to remove the ne
driver, issue the command:
# modprobe -r ne
To unload every unused modulethat is, every module not
associated with an operational deviceinvoke the rmmod command and specify the -a argument:
# rmmod -a
You can't remove a module that's in
use; therefore, you must shut down the device before removing it. To
shut down an Ethernet device, you can use Neat. Or you can issue the
following command:
# ifconfig eth n down
where ethn specifies the logical device (for
example, eth0 or eth1).