| [ Team LiB ] |
|
C.4 Boot ParametersBoot 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 ArgumentsTable 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 ArgumentsTable 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 ArgumentsTable 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. For example, from Table C-4 you can learn that 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 To determine a proper value for options described in Table C-5, you must often know something about the hardware structure of your system. The procedures described in Chapter 2 will help you. C.4.4 IDE Hard Drive and CD-ROM Boot ArgumentsTable 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 ArgumentsTable 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.
C.4.6 Floppy Drive Boot ArgumentsA 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.
C.4.7 Bus Mouse Boot ArgumentsTwo 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 ArgumentsThe 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 DriversEarly 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 system�so-called special devices�had 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 DriverTo 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 TimeThe 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 DriversThe 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 module�that is, every module not associated with an operational device�invoke 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).  |
| [ Team LiB ] |
|