| Library routines | Contains zlib compression support. |
After you select all the options you want, you can save the configuration file and continue with step 7 in the kernel compiling checklist shown earlier.
Creating an Initial RAM Disk Image
If you require special device drivers to be loaded to mount the root file system (for SCSI drives, network cards or exotic file systems, for example), you must create an initial RAM disk image named /boot/initrd.img. For most users, it is not necessary to create this file, but if you are not certain, it really does not hurt. We covered the initrd.img in Chapter 34. To create an initrd.img file, use the shell script /sbin/mkinitrd.
The format for the command is the following:
/sbin/mkinitrd
where filename is the name of the image file you want created.
mkinitrd looks at /etc/fstab, /etc/modprobe.conf, and /etc/raidtab to obtain the information it needs to determine which modules should be loaded during boot. For our personal systems, we use the following:
# mkinitrd initrd-2.6.7-1.img 2.6.7-1
When Something Goes Wrong
Several things might go wrong during a kernel compile and installation, and several clues will point to the true problem. You will see error messages printed to the screen, and some error messages will be printed to the file /var/log/messages, which can be examined with a text editor. If you have followed our directions for patching the kernel, you will have to examine a special error log as well. Do not worry about errors because many problems are easily fixed with some research on your part. Some errors may be unfixable, however, depending on your skill level and the availability of technical information.
Errors During Compile
Although it is rare that the kernel will not compile, there is always a chance that something has slipped though the regression testing. Let's take a look at an example of a problem that might crop up during the compile.
It is possible that the kernel compile will crash and not complete successfully, especially if you attempt to use experimental patches, add untested features, or build newer and perhaps unstable modules on an older system. For example, the kernel compile will fail on an older-stock Red Hat 7.2 installation using the 2.4.9 kernel when the NTFS file system is selected, either as a loadable module or inline, as shown here:
gcc -D__KERNEL__ -I/usr/src/kernels/linux-2.4.9/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon - DMODULE -DMODVERSIONS -include /usr/src/kernels/linux-2.4.9/include/linux/modversions.h -DNTFS_VERSION= '1.1.16' -c -o unistr.o unistr.c
unistr.c: In function 'ntfs_collate_names':
unistr.c:99: warning: implicit declaration of function 'min'
unistr.c:99: parse error before 'unsigned'
unistr.c:99: parse error before ')'
unistr.c:97: warning: 'c1' might be used uninitialized in this function
unistr.c: At top level: unistr.c:118: parse error before 'if'
unistr.c:123: warning: type defaults to 'int' in declaration of 'c1'
unistr.c:123: 'name1' undeclared here (not in a function)
unistr.c:123: warning: data definition has no type or storage class
unistr.c:124: parse error before 'if'
make[2]: *** [unistr.o] Error 1
make[2]: Leaving directory '/usr/src/kernels/linux-2.4.9/fs/ntfs'
make[1]: *** [_modsubdir_ntfs] Error 2
make[1]: Leaving directory '/usr/src/kernels/linux-2.4.9/fs'
make: *** [_mod_fs] Error 2
At this juncture, you have two options:
> Fix the errors and recompile
> Remove the offending module or option and wait for the errors to be fixed by the kernel team
Most users will be unable to fix some errors because of the complexity of the kernel code, although you should not rule out this option. It is possible that someone else discovered the same error during testing of the kernel and developed a patch for the problem: Check the Linux kernel mailing list archive. If the problem is not mentioned there, a search on Google might turn up something.
The second option, removing the code, is the easiest and is what most people do in cases in which the offending code is not required. In the case of the NTFS module failing, it is almost expected because NTFS support is still considered experimental and subject to errors. This is primarily because the code for the file system is reverse-engineered rather than implemented via documented standards. Read-only support has gotten better in recent kernels; write support is still experimental.
Finally, should you want to take on the task of trying to fix the problem yourself, this is a great opportunity to get involved with the Linux kernel and make a contribution that could help many others.
If you are knowledgeable about coding and kernel matters, you might want to look in the MAINTAINERS file in the /usr/src/kernels/linux-2.6/ directory of the kernel source and find the maintainer of the code. The recommended course of action is to contact the maintainer and see if he is aware of the problems you are having. If nothing has been documented for the specific error, submitting the error to the kernel mailing list is an option. The guidelines for doing this are in the README file in the 'If Something Goes Wrong' section under the base directory of the kernel source.
Runtime Errors, Boot Loader Problems, and Kernel Oops
Runtime errors occur as the kernel is loading. Error messages are displayed on the screen or written to the /var/log/messages file. Bootloader problems display messages to the screen; no log file is produced. /var/log/messages file.
Excellent documentation on the Internet exists for troubleshooting just about every type of error that LILO, GRUB, or the kernel could give during boot. The best way to find this documentation is to go to your favorite search
