to prepare the source tree for your new build.
make zdisk #good for testing
The command you’ll end up using for modern compilations is:
Yes, that’s it. After a lengthy compilation, the resulting image will be in /usr/src/linux/arch/i386/boot/. The image itself likely will be called bzImage.
You must copy this file to /boot, as well as the file /usr/src/linux/System.map.
Remember those patch files I mentioned at the beginning of this lesson? If you’re a genuine kernel-jockey and have already built a kernel on your current machine, you may be interested in patching your kernel. Patching is actually very simple, but it does require existing source code in /usr/src/linux. Download the next numerical version patch for your kernel. You must patch one version at a time: to go from 2.6.5 to 2.6.7, you must install the 2.6.6 patch first, then the 2.6.7 patch.
Uncompress the patch into your /usr/src/linux directory, and command:
patch < patchfile
You will then need to compile your kernel as I described above.
Make Any Modules
If you’ve chosen the M option in the configuration stage (and there are many defaults that use this setting), you’re also going to have modules to compile in your working directory. Command:
They’ll end up in the /lib/modules/kernel_version directory.
Module: a file containing code for a specific driver
See the man pages for the modprobe and insmod commands, for info on loading and unloading modules on the fly. With the 2.6 kernel, this is usually unnecessary. In most cases kudzu will detect hardware properly, which means the right modules for any new hardware get loaded automatically.
Generally, a list of modules is loaded at boot, taken from the file /etc/modprobe.conf. (Older distros may have the files /etc/modules.conf or /etc/conf.modules.)
However, here is some basic information for those occasions when you have to load modules yourself, or load them from a script.
You will typically find kernel modules in a subdirectory of /lib/modules/<kernel_version>/. Typically they are compiled files with a .ko (kernel object) file extension. (Older kernels, 2.4 and prior, used a .o extension.) insmod requires that you know the exact name of the module to be inserted, so most likely you will have to look in this directory. If I have an SIS video card, for instance, I can issue the command:
This will load the module, but won’t check for any dependencies it may have. To do a dependency check as well as loading the module, use the modprobe command:
creates a dependency file for modules, which then can be used by modprobe
creates dependency files for modules listed in /etc/conf.modules
Some modules, whether very new or very old, may require manual editing of the /etc/modprobe.conf file.
cat this file to see its format. The syntax of each line is:
alias <device_alias> <driver_module>
For example, to load a DEC Tulip NIC with the device name of eth0, you would add the line:
alias eth0 tulip
loads a module into the kernel; once upon a time you had to do this manually or with a script to initialize, for instance, a sound card.
lists all loaded modules and their size (in units of 4k)
unloads a module or list of modules from the kernel (this only works if they are not currently in use)
“recursively” removes all modules, i.e., if dependent modules are left behind on the first pass, they’ll be removed in another pass
attempts to load the specified module and any dependent modules. Note that if you list more than one module, the others will load only if the first one fails.
modprobe –a module(s)
loads all of the modules, not just the first one
modprobe –r module(s)
removes specified modules and their dependencies.
Make an Initial RamDisk
Your kernel will need to load several modules at boot, which is tricky because the kernel needs the filesystem modules to access the filesystem (among other problems). The solution is a ramdisk: a filesystem image that is loaded into RAM at boot, as a step in the bootstrap process.
mkinitrd -v /boot/initrd-<kernel_version>.img <kernel_version>