Mastering Kernel Modules with Caldera
You shouldn't have to read this article. The concept of Linux kernel modules is fairly simple. Unfortunately, information needed to compile, install and use modules is scattered over several HOWTOs, READMEs, and man pages. Plus, the files which need to be modified are in several obscure directories.
I finally wrote this cookbook approach to get myself, and you, started. Once you are up and running with modules, you can dig into the details later. I tested this material on an X86 processor running Caldera Open Linux 1.1, which is close to Red Hat 4.2. Your mileage with other processors and distributions may vary.
Why use modules? They let you compile a small, fast kernel, then install and remove device drivers on demand. Without modules, the Linux kernel could become bloated and resemble a certain commercial OS.
First, I recommend you compile a base kernel including all essential capabilities for your system without modules. I know this sounds like we are going backwards, but you don't want to lose the ability to boot up because you messed up your modules. The README in /usr/src/linux is your guide, but basically you execute the command:
make mrproper; make xconfig
(or menuconfig or config) to include all needed capabilities, then run:
make dep; make clean; make zImageSave your kernel configuration to a file named kernelconf.base, in case you need to recompile. The xconfig menu prompts you to save and load configuration files. If you use menuconfig or config, the current configuration is in the file /usr/src/linux/.config; copy that file to kernelconf.base. If you configured too big a kernel, final compilation will fail. If this happens, execute make bzImage instead of zImage. Your compiled kernel will be in the directory /usr/src/linux/arch/i386/boot.
You might have made a mistake in compiling your base kernel, so don't throw away your old one. If you are running LILO, rename your new kernel to zImage.base and copy it to the location of your current kernel, usually / or /boot. Add a section to /etc/lilo.conf that lets you select either your default or base kernel on bootup. My lilo.conf is shown in Listing 1, minus some comment lines.
The important addition to lilo.conf is the last section (#base kernel) which tells LILO about your new kernel. Also, be sure lilo.conf has prompt and timeout lines. Now execute lilo and then reboot. LILO will pause, giving the prompt boot:. If you hit TAB, you will be given the choices linux and base. Enter base and your new kernel will boot. You may get complaining messages about bad module dependencies, but if your base kernel is complete, that shouldn't bother you. If something goes wrong, reboot and enter linux (or just wait through the timeout interval) and your old kernel will boot. Make sure you have a working base kernel before proceeding. With this approach, you never burn your bridges (or kernel) behind you.
If you don't use LILO, make a boot floppy for your base kernel. To do this, insert a floppy and execute make zdisk, instead of zImage.
You are now ready to compile a kernel with modules tailored to your system. Execute the same commands as above, but when you execute xconfig or menuconfig, pick some features to compile as modules. I suggest you experiment first by picking nice-to-have, but not-necessary, modules to add to zImage.base. Good choices might be printer support or floppy support (unless you are booting from the floppy). Save your configuration as kernelconf.mod in case you need to go back. Also, write down which modules you are compiling. To know exactly which modules are compiled, I suggest you move or delete your old modules (if any). The Caldera release includes a lot of modules. They are in /lib/modules/2.0.29. I moved my old ones into subdirectories rather than deleting them, in case I needed to back up. If you are working with a different release of the kernel, instead of subdirectory 2.0.29 you will have a subdirectory corresponding to your release number.
After executing make zImage, run:
make modules; make modules_install
As before, go (using cd) to the directory containing zImage, rename it zImage.mod and move it to the directory where LILO will look for it. Put a new section at the bottom of lilo.conf to let you boot this kernel with the label modules. If you don't use LILO, make another zDisk.
Now, execute depmod -a. This creates /lib/modules/2.0.29/modules.dep, needed by module utilities. Next, execute the following:
modprobe -c | grep -v '^path' > /etc/conf.modules
This command sets up another file needed by the module utilities.
Now reboot, choosing label modules at the boot prompt. Next, move to the /etc/modules/2.0.29 directory. It should contain a file with a very long name like the following:
#1 Tue Feb 11 20:36:48 MET 1997.default
This file is read at boot time by /etc/rc.d/rc.modules. [Debian and Red Hat use /etc/modules—Ed.] It contains a list of the default modules loaded when the kernel boots. You need to change both the name and the contents. Fixing the name is the hard part. In directory /etc/modules/2.0.29, execute the commands:
FILE=`uname -v`.default cp "#1 Tue"* "$FILE"This magic creates a file with the name that rc.modules will look for on bootup. The name is based on the time the kernel was compiled. If you recompile the kernel, you must repeat the magic.
Edit this file to contain just the modules you want loaded at bootup. For example, it might contain the lines
floppy lp
which would load the floppy and printer modules, assuming you compiled them as modules. To get your editor to accept this file, you may need to put quotes around the name.
To load a module manually, execute insmod with your module name as argument. To remove it, execute rmmod with your module name as argument. To tell which modules are currently loaded, execute lsmod.
The best toy is kerneld; it automatically loads and unloads modules as needed. Assume you have compiled the floppy driver as a module. Check whether it is loaded by executing lsmod. If it is, remove it by executing rmmod floppy. Then execute kerneld. Now execute mount /mnt/floppy (or whatever mounts your floppy). Magically, kerneld installs the floppy module when needed. It will also uninstall modules which haven't been used for a while, keeping your kernel lean and mean.
You now know enough to experiment with modules without crashing your kernel on bootup. Read the Module mini-HOWTO, the kerneld mini-HOWTO, and the man pages for the utilities to become a real expert. Happy moduling!

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- RSS Feeds
- Trying to Tame the Tablet
- New Products
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




31 min 15 sec ago
5 hours 10 min ago
7 hours 32 min ago
1 day 21 min ago
1 day 2 hours ago
1 day 4 hours ago
1 day 4 hours ago
1 day 5 hours ago
1 day 9 hours ago
1 day 10 hours ago