Understanding the Default Configuration Files
To recap, there are key startup configuration files for hardware, for the bootloader, and for runlevels. The hardware configuration files help you determine what was detected . The bootloader enables you to trace the location of the kernel, the Initial RAM disk, and any other operating systems on your computer. The directories for each runlevel help you customize the processes that start and stop on your Linux computer.
Hardware Detection
Once GRUB or LILO finds your boot files, the next step is to make a connection between the Linux kernel and your computer s hardware. The Linux hardware detection process consists of several parts . First, Linux takes data related to basic hardware from your BIOS. Next, it uses the kudzu utility to look for new hardware on your system. Assuming you have a default modular kernel, it then inserts any modules related to specialized hardware from the /etc/modules.conf file. You can inspect the messages related to this process with the dmesg command.
Kernel Connections
The dmesg command should show you how your kernel interacts with your hardware as Linux starts on your computer. It starts with your BIOS; uses related information to find your CPU, hard drives , PCI (Peripheral Component Interconnect) devices, and communications ports; starts the appropriate filesystems on the right partitions; and finally configures other basic devices related to keyboards and mice. Figure 11.1 shows an excerpt from my dmesg output.
Figure 11.1: Excerpt from dmesg
From the sample output, you can identify one CPU and 128MB of memory. If you actually have more than one CPU and additional RAM installed, this output tells you that Linux did not detect this additional hardware.
Kudzu
The current version of Kudzu is the culmination of Linux efforts to support plug-and-play hardware. In the past, using plug-and-play hardware on Linux was at best an uncertain venture. Now it manages any new hardware that you throw at it without a hitch.
Kudzu works by looking at the various ports on your computer. If it detects and recognizes new hardware, it adds the relevant information, such as device and driver names , to /etc/sysconfig/hwconf .
If special hardware drivers are required, specifications are added to /etc/modules.conf . Linux reads this file during the boot process to load the required drivers the next time you start your computer.
If you ve just added new hardware and want to make sure Red Hat Linux detects it properly, just run the kudzu command. If additional configuration is required, you could be taken to a text version of redhat-config-mouse (See Chapter 19 ); the steps look similar to the deprecated mouseconfig utility. In rare cases, you may be prompted to add information such as IRQ ports, I/O addresses, or DMA channels.
Kernels and Hardware
Linux makes it easy to see how the Linux kernel views your hardware. Just look in the /proc directory. As shown in Table 11.1, various files in /proc can give you additional information on the hardware that is connected to Red Hat Linux.
| File | Description |
|---|---|
| apm | Advanced power management battery status |
| cpuinfo | Detected CPUs |
| dma | Assigned DMAs |
| ide | Directory specifying attached IDE devices |
| interrupts | Assigned IRQs |
| ioports | Assigned I/O addresses |
| modules | Installed driver modules; same as lsmod output |
| partitions | Basic partition information |
| pci | Detected PCI devices |
| scsi | Directory specifying attached SCSI devices |
The information is quite detailed. For example, take a look at the /proc/cpuinfo file in Figure 11.2. Not only does it show the rated and the effective speed of the CPU, but it also shows the cpu family , which helps you find the optimized Linux kernel to use for your system. In this case, I d use the kernel- versionnumber .i686.rpm package. You ll see how this helps in the next chapter .
Figure 11.2: Kernel information on the CPU
The /etc/modules.conf Settings
Sometimes Red Hat Linux needs a little help with kernel configuration settings. There are cases where default plug-and-play settings for different components might interfere with each other. That s where the /etc/modules.conf configuration file steps in. It s where Linux stores driver, device, and address settings for various hardware components. Take the following excerpt from my /etc/modules.conf file:
alias eth0 pcnet32 alias usb-controller usb-uhci options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
Note how this defines drivers for the first Ethernet card, the USB controller, and a SoundBlaster ( sb ) card. As Linux detects more and more hardware, the importance of this file will decline over time.
When you change the /etc/modules.conf file, you can test the results immediately. For example, if you re trying to find the right settings for the SoundBlaster card, you could use the following command:
# modprobe sb
If you don t see an error message, check the lsmod command again. Your sound card is probably now installed. Otherwise, check the error messages carefully for clues on your next step, which is probably to try different hardware settings.
Listing Modules
You can verify whether Red Hat was able to detect your hardware. Besides reviewing the earlier discussion on the /proc directory, you can review installed modules with the lsmod command. For example, this command on my computer lists a series of modules in Figure 11.3.
Figure 11.3: lsmod lists installed modules.
As you can see, each module has a file size in bytes. Some modules depend on others; for example, note how the mii module is required for the pcnet32 network driver module. In other words, if you tried to remove the mii module with the following command, you d get an error message:
# rmmod mii mii: Device or resource busy
If you remove the pcnet32 network card from your computer, Linux won t install either module the next time you start your computer. Alternatively, you could shut down networking and then remove the modules in order:
# rmmod pcnet32 # rmmod mii
You could install modules just as easily; for example, if you need to install a new 3Com EtherLink network card and Linux isn t detecting it, you might try installing the associated module with the following command:
# insmod 3c589_cs
If successful, you won t see any error messages; check the result with the lsmod command. You should see the network card module in the output.
The Bootloader
As we mentioned earlier, the default Red Hat Linux bootloader is known as GRUB. It is a significant improvement over LILO in a number of ways, including:
-
It can be password-protected.
-
It is easy to edit during the boot process. You can try different boot parameters without permanent changes to the GRUB configuration file.
-
It can boot Windows NT operating systems from the Master Boot Record area of your hard drive.
-
It supports Logical Block Addressing (LBA) mode, which can help your computer find the /boot files, especially if they are beyond the 1024th cylinder on your hard drive.
LILO is now deprecated; Red Hat plans to remove LILO from Red Hat Linux, probably in the near future. Therefore, this older bootloader is not covered in this book.
Take a look at a typical GRUB configuration file in Figure 11.4, from /boot/grub/grub.conf .
Figure 11.4: Dual-boot GRUB
The variables shown in Figure 11.4 are explained in Table 11.2.
| Variable | Comment |
|---|---|
| password | Password-protects GRUB. With the --md5 switch, the password can be entered in encrypted format. |
| default | Specifies the default operating system. If default=0 , the operating system shown in the first stanza boots automatically if there is no user input. |
| timeout | Sets the time limit before GRUB starts the default, in seconds. |
| splashimage | Notes the default GRUB image. |
| title | Sets the option as shown in the GRUB menu. |
| root | Specifies the partition with the /boot files. |
| kernel | Notes the location of the Linux kernel. |
| initrd | Points to the location of the Initial RAM disk. |
| rootnoverify | Specifies the partition with boot files for a sensitive operating system such as Windows XP. |
| chainloader | With +1 , looks for boot files in the first sector of the noted partition. |
The root variable in GRUB may be confusing, because it actually refers to the partition with the /boot directory. Note the data associated with root, such as (hd0,0) or (hd0,1) . This data points to the partition with the boot files for that operating system.
If you re having trouble with hardware, use the hardware modules described earlier as much as possible. However, you may need to give Linux some help finding hardware critical to the boot process, such as a hard drive or a SCSI controller for a hard drive. In that case, you should specify a module in the kernel line. For example, if you want to specify an IRQ of 9, an IO address of 0x330, and a SCSI ID of 7 for an older Adaptec controller, add the following command to the kernel line in your grub.conf configuration file:
kernel /vmlinux-2.4.20-2.2 ro root=LABEL=/ aha152x=0x330,9,7
The boot hard disk is shown as a comment as /dev/sda . Therefore, root (hd0,1) points to Linux boot files on the first SCSI hard drive, on the second partition, also known as /dev/sda2 . Similarly, the root (hd0,0) setting points to DOS boot files on the first SCSI hard drive, on the first partition ( /dev/sda1 ).
| Note | For convenience, /etc/grub.conf is linked to the actual bootloader configuration file, /boot/grub/grub.conf . |
| Tip | The word root has several meanings in Linux. There is the root user, with a home directory of /root . There is the top-level root directory, associated with the forward slash, / . And in GRUB, the root variable actually points to the partition with the /boot directory. So when you see / in the GRUB configuration file, it s really the /boot directory. |
 |
If you forgot to add a GRUB password during Red Hat Linux installation, it s easy to add a secure MD5 password to GRUB. Just use the grub-md5-crypt command. When prompted, enter the password of your choice. You ll get a strange -looking series of characters that you can copy to the GRUB configuration file, in the format shown in Figure 11.2.
It s easy to copy this password from the command line. Just use your mouse to highlight the password. Open /etc/grub.conf in a text editor. Right-click your mouse in the desired location, and then Linux automatically inserts the highlighted MD5 password. Alternatively, if you re in the GNOME terminal, a right-click opens a pop-up menu that allows you to copy and paste the highlighted text.
| |
/etc/inittab
Linux now initializes the key files, processes, and applications on your system. The governing configuration file is /etc/inittab . Open it in your favorite text editor. The key variable in this file is initdefault; the other variables just set up important parts of the Linux environment. My /etc/inittab file is shown in Figure 11.5.
Figure 11.5: /etc/inittab
The initdefault variable sets the default runlevel, which starts when you boot Linux. For example, the following line configures your computer to start in runlevel 3.
id:3:initdefault
There are six standard Red Hat Linux runlevels, as shown in Table 11.3 (runlevel 4 is not used by Red Hat). In the next section, we ll explore what happens when Linux boots in runlevel 3.
| Runlevel | Function |
|---|---|
|
| Halt; shuts down Linux; init stops all services currently running on your computer. |
| 1 | Single-user mode; no networking; init starts just the programs needed to allow one user to log into your Linux system; as you ll see later in this chapter, you can go into single-user mode to fix critical files and more. |
| 2 | Multiuser mode; no NFS access; init starts the programs that allow multiple users to log into your Linux system simultaneously . |
| 3 | Multiuser mode with networking; init starts the network daemons on your computer after the multiuser runlevel. |
| 5 | Graphical login; init starts your network programs, and then starts X Window programs that can be split between client and server, |
| 6 | Reboot; shuts down Linux and restarts your computer at the runlevel defined by the id command in /etc/inittab . |
| Other Linux distributions may use different standard runlevels. | |
| Warning | Do not set your default runlevel to 0 or 6. If you do, your computer will either shut down or go into a continuous reboot cycle when you start Linux. |
The standard Red Hat Linux /etc/inittab file includes several other important commands. The following command
si::sysinit:/etc/rc.d/rc.sysinit
runs the rc.sysinit script, which activates configured networks, quotas, fonts; mounts filesystems; activates Logical Volume Management (LVM) and RAID partitions; loads hardware modules; and more. In short, rc.sysinit sets the stage for Linux to activate services.
To help Microsoft Windows users, /etc/inittab associates the Ctrl+Alt+Del key combination with the shutdown command.
| Tip | If you re setting up a Linux server, you may want to comment out the ca::ctrlaltdel:/sbin/ shutdown -t3 r now command. You don t want the frustration of one user to halt the system for everyone. |
By default, Red Hat Linux uses /etc/inittab to set up six virtual terminal consoles, tty1 through tty6 . You can access different virtual consoles by pressing Ctrl+Alt+F n , where n is the number of the console. Red Hat Linux allows you to configure up to 12 virtual consoles, with commands such as the following in /etc/inittab :
1:2345:respawn:/sbin/mingetty tty1
This command configures the first virtual console ( tty1 ) whenever Linux starts runlevels 2, 3, 4, or 5.
| Tip | If you ve just edited /etc/inittab , you may not need to reboot. For example, if you ve added a virtual console, the telinit q command forces Linux to reread /etc/inittab . |
| |
Closely related to /etc/inittab is the first process, init . It works at several different runlevels, primarily scripts in the /etc/rc.d directory. For example, if you run the init 5 command, Linux runs the scripts in the /etc/rc.d/rc5.d directory.
| |
Starting a Runlevel
Now we ll look at how Red Hat Linux starts a runlevel with the initdefault variable. As we described earlier, it s common for Red Hat Linux to start in runlevel 3, full multiuser mode. When Linux reads the desired runlevel, it starts the associated script. In this case, the following command starts all of the scripts associated with runlevel 3:
l3:3:wait:/etc/rc.d/rc 3
This command points to a set of scripts at the associated runlevel, and then executes kill and start scripts, in that order. It s easy to compare two different runlevels. Just examine the list of scripts in the appropriate directories. Figure 11.6 compares the scripts from runlevel 3 with runlevel 1.
Figure 11.6: Resource control scripts
| Note | The kill and start scripts that you see on your computer vary with the services that you ve installed, and those that you ve activated in that runlevel. |
The directories are fairly straightforward; kill scripts start with a K, while start scripts begin with an S. These scripts are executed in the order shown. But there are differences. Runlevel 3 starts over 25 services, many related to networking. Runlevel 1 kills just about every available service, except those needed for single-user mode. No networking or multiuser configurations are required in single-user mode.
| Note | Remember, a script such as S05kudzu starts a service and a script such as K15httpd kills a different service. For more information on service management, see Chapter 13 . |
EAN: 2147483647
Pages: 220