You can load modules in one of three methods: manually, from initrd, or by udev. Let’s see how this process works.
Tuning initramfs
As soon as your system boots, it immediately needs some modules, such as the modules nec-essary to access the root device on your server. These modules are loaded by the initial RAM file system (initrd), which is loaded from GRUB. Normally, this initial RAM drive is created automatically, and you don’t have to worry about it. However, you may need to tune your own initrdin some situations; in this case, the mkinitramfscommand can be used.
■ Note
The correct way to refer to initrdis to call it the initial RAM file system (initramfs). In the old days, the initramfswas referred to as the initrd. It basically is the same thing, and you can use either term to refer to it.To create your own initramfs, the first thing you should tune is the /etc/initramfs-tools/initramfs.conffile. This file is used to specify generic options that should be used on your initramfs, such as a time-out parameter that specifies how long you’ll have to interrupt the boot procedure. Normally, it’s not necessary to change anything in this file. Also, there is the /etc/ initramfs-tools/modulesfile, in which you refer to the modules that you want to be loaded automatically. Next, in the /etc/initramfs-tools/scriptsdirectory you can create scripts that allow the mkinitramfscommand to find the proper modules. Done all that? Then it’s time to run the mkinitramfscommand to create your own initramfs.
When using mkinitramfs, the command needs the option -oto specify the name of the output file it needs to create; for example, mkinitramfs -o newinitrd. Once created, it is a good idea to copy newinitrdto the /bootdirectory; everything your kernel needs to boot the system must be in this directory. Next, tune /boot/grub/menu.lstto make sure the new initramfsis included in one of the GRUB sections (be aware that in the menu.lstfile it is referred to as initrdwhen doing so):
1. Open /boot/grub/menu.lstwith your favorite editor.
2. Copy the default section that is used to boot your system in the file. This will result in this section occurring twice in the menu.lstfile.
3. Change the title of the default boot section to something else (“test with new initrd”
would be a decent name while you are still testing) and make sure the initrdline refers to the new initrdthat you just created. This would result in something like the following lines:
title Test with new initrd root (hd0,0)
kernel /boot/vmlinuz-2.6.24-16-server root=/dev/sda1 ro quiet splash initrd /boot/newinitrd
4. Reboot your server, and while rebooting, select the new GRUB menu item to test if the new initrdis working properly. If it does, change /boot/grub/menu.lstto make the test section permanent.
Loading Modules on Boot
Normally, the kernel ensures that all modules you need when booting your server are loaded when the hardware that requires them is detected. In some situations, though, this doesn’t work out. If not, you can make sure that the module is loaded anyway by including it in the /etc/modulesconfiguration file. The structure of this file is not complicated; just specify the names of all the modules that you want to load, one per line, and they will be loaded when you reboot your server. The following listing shows an example of the contents of this file:
root@RNA:/etc# cat modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
loop lp sbp2 fuse
Need to add a new module? Make sure that it is listed in this file and it will be loaded when your server restarts.
Loading Modules Manually
Modules can be managed manually as well, which can be useful when testing new hardware devices. Here are the commands:
• lsmod: This command displays a list of all currently loaded modules. In this list, you’ll also see the current status of the module. The output of lsmodis given in four columns (as can be seen in Listing 6-6). The first column provides the name of the module. The second column shows its size. In the third column, a 0 indicates that the module cur-rently is not used. Everything greater than 0 indicates that the module is in use. The last column shows the name of other modules that require this module to be loaded.
Listing 6-6.Output of lsmod snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi
snd_seq 52464 6\
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 23684 2 snd_pcm,snd_seq
...
capability 5896 0
commoncap 8192 1 capability
• modprobe: If you want to load a module by hand, the modprobecommand is the way to do it. The importance of this command is that it will do a dependency check. Some modules need another module to be present before they can do their job, and modprobe makes sure that these dependencies are fulfilled. To load the dependent modules, it looks in the configuration file modules.dep, which is created automatically by the depmod command (see later in this section). Loading a module with modprobeisn’t hard; if, for example, you want to load the module vfatby hand, just use the modprobe vfat com-mand. In the early days, modprobehad an alternative: the insmodcommand. But insmod has the disadvantage that it doesn’t check for dependencies, so you probably shouldn’t use it anymore.
• rmmod: An unused module still consumes system resources. It usually won’t be much more than 50 KB of system memory, but some heavy modules (such as the XFS module that offers support for the XFS file system) can consume up to 500 KB. On a system that is short on memory, this is a waste, and you can use rmmodfollowed by the name of the module you want to remove (for example, rmmod ext3). This command will remove the module from memory and free up all the system resources it was using. A more modern alternative for rmmodis the modprobe -rcommand. The major difference is that modprobe -rtakes dependencies into consideration as well.
• modinfo: Have you ever had the feeling that a module was using up precious system resources without knowing exactly what it was doing? Then modinfois your friend. This command will show some information that is compiled in the module itself. As an example, you can see how it works on the pcnet32 network board driver in Listing 6-7.
Especially for network boards, the modinfocommand can be very useful because it shows you all the parameters the network board is started with (for instance, its duplex settings), which can be handy for troubleshooting.
Listing 6-7.The modinfoCommand Shows What a Module Is Used For myserver # modinfo pcnet32
root@ubuntu:/etc/init.d# modinfo pcnet32
filename: /lib/modules/2.6.20-15-server/kernel/drivers/net/pcnet32.ko license: GPL
description: Driver for PCnet32 and PCnetPCI based etherboards author: Thomas Bogendoerfer
vermagic: 2.6.20-15-server SMP mod_unload 686 parm: debug:pcnet32 debug level (int)
parm: max_interrupt_work:pcnet32 maximum events\
handled per interrupt (int)
• depmod: The depmodcommand is used to generate the modules dependency file in /lib/
modules/`uname -r`. The name of this file is modules.dep, and it simply contains a list of all dependencies that exist for modules on your system. As can be seen in Listing 6-7, modules normally know what dependencies they have (indicated by the dependsfield).
The depmodcommand just analyzes this data and makes sure that the dependency file is up to date. There’s normally no need to run this command manually because it’s started automatically when your system boots. If, however, you’ve installed new kernel mod-ules and you want to make sure the dependency file is up to date, run depmodmanually.