It is the usual industry practice to have a debug PC box, a test PC box, and a production PC box. Nobody works directly on a production box without experimenting first on debug PC and test PC. This is because the skills of a person varies and every person needs a warm-up exercise before doing the final show. A computer hardware is a very sophisticated technology like "Space Shuttle" and risks are involved as it can fail unexpectedly. Eventhough efforts are made to ensure that this document is upto-date and all commands are pre-tested, it is strongly recommended that you should practice your skills first on a trainer test PC before you do anything to "LIVE" production box. You will sharpen your skills and hone your knowledge first on a test PC running Linux and after everything works, then change the production box with extreme caution. Even if you break the test PC with dangerous commands you will learn by doing mistakes and you can afford breaking the test PC. You will be more confident working first on Test PC. Most companies purchase old PCs for using them as "Trainer Machines". Please understand that there is no warranty or guaranty on this document and you can build your own warranty by checking this document with your test PC or your home PC (low risk environments). (Write your own warranty document and hang it on wall near your computer!!)

Before you build kernel, it is a good idea to do a backup of the system. If you had not backed up your system recently then you can do it now. You can use commercial backup tools like BRS Backup-Recovery-Software (also in this page you can find open-source/freeware backup tools listed under 'Backup and Restore Utility'). Backup is just a suggestion and it is not mandatory to do backup before building the Linux kernel.

If you had already built the kernel and you want to upgrade to next patch release, then you can simply copy the existing config file and reuse it. (For example you have built kernel 2.4.19 and want to upgrade to 2.4.20).

For minor upgrades : This step may save you time, if you want to reuse the old settings. Whenever you install the kernel, generally you put the config file in /boot. Do not save the .config as .config.save because 'make mrproper' will wipe out all .config* files!! So, you can use the existing version of config file:

	bash# mkdir /usr/src/kernelconfigs 
	bash# cp /usr/src/linux/.config  /usr/src/kernelconfigs/.config.save
	bash# cp /usr/src/linux/.config  /usr/src/linux/configs/.config.save  # ExtraSafe
	bash# cp /boot/config*  /usr/src/linux/configs/  # ExtraSafe
	bash# cp /boot/config-2.4.18-19.8.0  /usr/src/linux/.config
        

Or another method is - you can copy the .config file from your old linux kernel source tree to new kernel tree.

	bash# ls -l /usr/src/lin*  # You can see that /usr/src/linux is a soft link
	bash# cd /usr/src/linux 
	bash# cp ../linux-old-tree/.config .  # Example cp ../linux-2.4.19/.config .
        

or one other method is - you can use "make oldconfig" which default all questions based on the contents of your existing ./.config file.

NOTE: If you do not have lot of disk space in /usr/src then you can unpack the kernel source package on any partition where you have free disk space (like /home). Because kernel compile needs lot of disk space for object files like *.o. For this reason the /usr/src/linux MUST be a soft link pointing to your source directory.

After this, look in the next section to do make and install.

If you downloaded the new kernel sources, then make sure you read the following files in /usr/src/linux/Documentation

See details of above steps in the following sections....

Details of the steps mentioned in the previous section:

Note: Below 'bash#' denotes the bash prompt, you should type the commands that appear after the 'bash#' prompt. Below are commands tested on Redhat Linux Kernel 2.4.7-10, but it should work for other distributions with very minor changes. It should also work for older kernel versions like 2.2, 2.0 and 1.3. It should also work for future or newer versions of kernel (with little changes - let me know).

Having any problems? See the Section 19, “ Appendix E - Troubleshoot Common Mistakes ” .

See the Section 18, “ Appendix D - Post Kernel Building ” .

You tried everything above and you think it seems to be a kernel bug. You may want to report this bug so that it will be fixed. You can see the file /usr/src/linux/REPORTING-BUGS and visit the following site - Reporting Bugs for the Linux Kernel .

You can install the Module Utilities RPM with:

	bash# rpm -i /mnt/cdrom/Redhat/RPMS/modutils*.rpm
        

insmod inserts a module into the running kernel. Modules usually have a .o extension; the example driver mentioned above is called drv_hello.o , so to insert this, one would say ` insmod drv_hello.o '. To see the modules that the kernel is currently using, use lsmod . The output looks like this: blah# lsmod Module: #pages: Used by: drv_hello 1 ` drv_hello ' is the name of the module, it uses one page (4k) of memory, and no other kernel modules depend on it at the moment. To remove this module, use ` rmmod drv_hello '. Note that rmmod wants a module name, not a filename; you get this from lsmod 's listing. The other module utilities' purposes are documented in their manual pages.

As of version 2.0.30, most of everything is available as a loadable modules. To use them, first make sure that you don't configure them into the regular kernel; that is, don't say y to it during ` make config '. Compile a new kernel and reboot with it. Then, cd to /usr/src/linux again, and do a ` make modules '. This compiles all of the modules which you did not specify in the kernel configuration, and places links to them in /usr/src/linux/modules . You can use them straight from that directory or execute ` make modules_install ', which installs them in /lib/modules/x.y.z , where x.y.z is the kernel release.

This can be especially handy with filesystems. You may not use the minix or msdos filesystems frequently. For example, if I encountered an msdos (shudder) floppy, I would insmod /usr/src/linux/modules/msdos.o , and then rmmod msdos when finished. This procedure saves about 50k of RAM in the kernel during normal operation. A small note is in order for the minix filesystem: you should always configure it directly into the kernel for use in ``rescue'' disks.

Let us assume that you already did 'make modules' and 'make modules_install'. And later you did 'make clean' to free up disk space. And now, you want to change a "C" file in one of the modules and want to rebuild just that module and copy the module file to /lib/modules. How do you do it? And, you do not want to give 'make modules' as that will rebuild everything and will take about 2 to 3 hours!

You can compile just a single module file (say like foo.o) and install it. For this simply edit the Makefile and change the SUBDIRS to add only those directories you are interested.

A good example is - I found that my default kernel did not include the NTFS filesystem support (I did make clean after make modules. Darn and Damn it!). So, I decided to compile the loadable module of NTFS. I did not want to compile the whole set (as it will take me about 2 hours), so I followed the procedure below and compiled just the fs/ntfs and did 'insmod ntfs'. It just took me about 5 minutes!!

Another example: If I am interested in installing only fs/autofs module, then I do the following :

	cd /usr/src/linux
	mv Makefile Makefile.original
	cp Makefile.original Makefile.my
	ln -s Makefile.my Makefile   # Because some files underneath still need "Makefile"
	vi Makefile.my
	# And comment out the line having 'SUBDIRS' and add the 
	# directory you are interested, for example like fs/autofs as below :
		#SUBDIRS	=kernel drivers mm fs net ipc lib abi crypto
		SUBDIRS		=fs/autofs
	# Save the file Makefile.my and give -
	make -f Makefile.my modules
	# This will create module autofs.o
	# Now, copy the module object file to destination /lib/modules
	# DANGER: Do NOT DO THIS - "make -f Makefile.my modules_install" This may
	# clean up other good ones in /lib/modules !! But just copy as below:
	cp autofs.o /lib/modules/2.4.18-19.8.0/kernel/fs/autofs
	  
	# Now, reset everything back to normal
	rm Makefile  # This is a link to Makefile.my
	ln -s Makefile.original Makefile
	  
	# Record your changes to the config file for future use
	# Edit the /usr/src/linux/.config file and set the item as module
	cd /usr/src/linux
    mkdir /usr/src/kernelconfigs ;
    cp /usr/src/linux/.config  /usr/src/kernelconfigs/.config.save;
	cp /usr/src/linux/.config  /usr/src/linux/configs/.config.save  # ExtraSafe
	cp /boot/config*  /usr/src/linux/configs/  # ExtraSafe
	vi /usr/src/linux/.config 
	# And change the config parameter. For example in case of my
	# ntfs module I did CONFIG_NTFS_FS=m  to indicate as module.
        

Learn more about Makefile and make. See the manual for GNU make at

Get familiar with the Makefile which makes the modules. The Makefile has module line like

	modules: $(patsubst %, _mod_%, $(SUBDIRS))
        

The patsubst function has the syntax $(patsubst pattern,replacement,text). It uses the percent symbol ([percnt]) the same way pattern rules do - as a string which matches in both the pattern and the replacement text. It searches the text for whitespace-separated words that match the pattern and substitutes the replacement for them.

This makefile includes shell functions as well as standard make functions. The syntax for a shell function is $(shell command). This returns the output of the shell function (stripping new lines).

The Unix kernel acts as a mediator for your programs and your hardware. First, it does (or arranges for) the memory management for all of the running programs (processes), and makes sure that they all get a fair (or unfair, if you please) share of the processor's cycles. In addition, it provides a nice, fairly portable interface for programs to talk to your hardware.

There is certainly more to the kernel's operation than this, but these basic functions are the most important to know.

Newer kernels generally offer the ability to talk to more types of hardware (that is, they have more device drivers), they can have better process management, they can run faster than the older versions, they could be more stable than the older versions, and they fix silly bugs in the older versions. Most people upgrade kernels because they want the device drivers and the bug fixes.

See the Hardware-HOWTO . Alternatively, you can look at the ` config.in ' file in the linux source, or just find out when you try ` make config '. This shows you all hardware supported by the standard kernel distribution, but not everything that linux supports; many common device drivers (such as the PCMCIA drivers and some tape drivers) are loadable modules maintained and distributed separately.

Linus recommends a version of gcc in the README file included with the linux source. If you don't have this version, the documentation in the recommended version of gcc should tell you if you need to upgrade your libc. This is not a difficult procedure, but it is important to follow the instructions.

See the Modules chapter at Section 3, “ Loadable Modules ” .

It depends on your particular system configuration. First, the compressed linux source is nearly 14 megabytes large at version 2.2.9. Many sites keep this even after unpacking. Uncompressed and built with a moderate configuration, it takes up another 67 MB.

With newer machines, the compilation takes dramatically less time than older ones; an AMD K6-2/300 with a fast disk can do a 2.2.x kernel in about four minutes. As for old Pentiums, 486s, and 386s, if you plan to compile one, be prepared to wait, possibly hours, days..

If this troubles you, and you happen to have a faster machine around to compile on, you can build on the fast machines (assuming you give it the right parameters, that your ulilities are up-to-date, and so on), and then transfer the kernel image to the slower machine.

Incremental upgrades of the kernel are distributed as patches. For example, if you have Linux v1.1.45, and you notice that there's a ` patch46.gz ' out there for it, it means you can upgrade to version 1.1.46 through application of the patch. You might want to make a backup of the source tree first (` make clean ' and then ` cd /usr/src; tar zcvf old-tree.tar.gz linux ' will make a compressed tar archive for you.).

So, continuing with the example above, let's suppose that you have ` patch46.gz ' in /usr/src . cd to /usr/src and do a ` zcat patch46.gz [verbar] patch -p0 ' (or ` patch -p0 [lt ] patch46 ' if the patch isn't compressed). You'll see things whizz by (or flutter by, if your system is that slow) telling you that it is trying to apply hunks, and whether it succeeds or not. Usually, this action goes by too quickly for you to read, and you're not too sure whether it worked or not, so you might want to use the -s flag to patch , which tells patch to only report error messages (you don't get as much of the ``hey, my computer is actually doing something for a change!'' feeling, but you may prefer this..). To look for parts which might not have gone smoothly, cd to /usr/src/linux and look for files with a .rej extension. Some versions of patch (older versions which may have been compiled with on an inferior filesystem) leave the rejects with a # extension. You can use ` find ' to look for you; find . -name '*.rej' -print prints all files who live in the current directory or any subdirectories with a .rej extension to the standard output.

If everything went right, do a ` make clean ', ` config ', and ` dep ' as described in sections 3 and 4.

There are quite a few options to the patch command. As mentioned above, patch -s will suppress all messages except the errors. If you keep your kernel source in some other place than /usr/src/linux , patch -p1 (in that directory) will patch things cleanly. Other patch options are well-documented in the manual page.

(Note: this section refers mostly to quite old kernels)

The most frequent problem that used to arise was when a patch modified a file called ` config.in ' and it didn't look quite right, because you changed the options to suit your machine. This has been taken care of, but one still might encounter it with an older release. To fix it, look at the config.in.rej file, and see what remains of the original patch. The changes will typically be marked with ` + ' and ` - ' at the beginning of the line. Look at the lines surrounding it, and remember if they were set to ` y ' or ` n '. Now, edit config.in , and change ` y ' to ` n ' and ` n ' to ` y ' when appropriate. Do a patch -p0 < config.in.rej and if it reports that it succeeded (no fails), then you can continue on with a configuration and compilation. The config.in.rej file will remain, but you can get delete it.

If you encounter further problems, you might have installed a patch out of order. If patch says ` previously applied patch detected: Assume -R? ', you are probably trying to apply a patch which is below your current version number; if you answer ` y ', it will attempt to degrade your source, and will most likely fail; thus, you will need to get a whole new source tree (which might not have been such a bad idea in the first place).

To back out (unapply) a patch, use ` patch -R ' on the original patch.

The best thing to do when patches really turn out wrong is to start over again with a clean, out-of-the-box source tree (for example, from one of the linux-x.y.z.tar.gz files), and start again.

After just a few patches, the .orig files will start to pile up. For example, one 1.1.51 tree I had was once last cleaned out at 1.1.48. Removing the .orig files saved over a half a meg. find . -name '*.orig' -exec rm -f {} ';' will take care of it for you. Versions of patch which use # for rejects use a tilde instead of .orig .

There are better ways to get rid of the .orig files, which depend on GNU xargs : find . -name '*.orig' | xargs rm or the ``quite secure but a little more verbose'' method: find . -name '*.orig' -print0 | xargs --null rm --

There are other patches (I'll call them ``nonstandard'') than the ones Linus distributes. If you apply these, Linus' patches may not work correctly and you'll have to either back them out, fix the source or the patch, install a new source tree, or a combination of the above. This can become very frustrating, so if you do not want to modify the source (with the possibility of a very bad outcome), back out the nonstandard patches before applying Linus', or just install a new tree. Then, you can see if the nonstandard patches still work. If they don't, you are either stuck with an old kernel, playing with the patch or source to get it to work, or waiting (possibly begging) for a new version of the patch to come out.

How common are the patches not in the standard distribution? You will probably hear of them. I used to use the noblink patch for my virtual consoles because I hate blinking cursors (This patch is (or at least was) frequently updated for new kernel releases.). With most newer device drivers being developed as loadable modules, though, the frequecy of ``nonstandard'' patches is decreasing significantly.

If you would like logs of what those ` make ' or ` patch ' commands did, you can redirect output to a file. First, find out what shell you're running: ` grep root /etc/passwd ' and look for something like ` /bin/csh '.

If you use sh or bash, (command) 2>&1 | tee (output file) will place a copy of (command) 's output in the file ` (output file) '.

For csh or tcsh, use (command) |& tee (output file)

For rc (Note: you probably do not use rc) it's (command) >[2=1] | tee (output file)

Other than using floppy disks, there are several methods of testing out a new kernel without touching the old one. Unlike many other Unix flavors, LILO has the ability to boot a kernel from anywhere on the disk (if you have a large (500 MB or above) disk, please read over the LILO documentation on how this may cause problems). So, if you add something similar to image = /usr/src/linux/arch/i386/boot/bzImage label = new_kernel to the end of your LILO configuration file, you can choose to run a newly compiled kernel without touching your old /vmlinuz (after running lilo , of course). The easiest way to tell LILO to boot a new kernel is to press the shift key at bootup time (when it says LILO on the screen, and nothing else), which gives you a prompt. At this point, you can enter ` new_kernel ' to boot the new kernel.

If you wish to keep several different kernel source trees on your system at the same time (this can take up a lot of disk space; be careful), the most common way is to name them /usr/src/linux-x.y.z , where x.y.z is the kernel version. You can then ``select'' a source tree with a symbolic link; for example, ` ln -sf linux-1.2.2 /usr/src/linux ' would make the 1.2.2 tree current. Before creating a symbolic link like this, make certain that the last argument to ln is not a real directory (old symbolic links are fine); the result will not be what you expect.

Russell Nelson ( nelson@crynwr.com ) summarizes the changes in new kernel releases. These are short, and you might like to look at them before an upgrade. They are available with anonymous ftp from "ftp://ftp.emlist.com" in pub/kchanges or through the URL "http://www.crynwr.com/kchanges"

Download the ftpfs and install it on your system. The ftpfs is installed as a module in /lib/modules/2.4.18-19.8.0/kernel/fs/ftpfs/ftpfs.o. And also the command ftpmount is in /usr/bin/ftpmount. And you can do the following:

Login as root (su - root) and run this script:

	#!/bin/sh -x
	# Use this script to mount ftp redhat cdroms rpms directory disk1,2,3
	# Built rpm by name ftpfs.
	# http://lufs.sourceforge.net/main/projects.html
	# ftpmount --help
	# Try this: ftpmount [user[:pass]@]host_name[:port][/root_dir] mount_point [-o]
	# [-uid=id] [gid=id] [fmask=mask] [dmask=mask]
	#ftpmount anonymous:pass@ftp.kernel.org /mnt/ftpfs
	#mkdir -p /mnt/ftpfs /mnt/ftpfs/updates /mnt/ftpfs/rpms /mnt/ftpfs/contrib
	# Redhat ftp mirror sites - http://www.redhat.com/download/mirror.html
	FTPSITE="csociety-ftp.ecn.purdue.edu"
	USER="anonymous:pass"
	ftpmount $USER@$FTPSITE/pub/redhat/redhat  /mnt/ftpfs/site
	ftpmount $USER@$FTPSITE/pub/redhat/redhat/linux/updates/8.0/en/os  /mnt/ftpfs/updates
	ftpmount $USER@$FTPSITE/pub/redhat/redhat/linux/8.0/en/os/i386/RedHat /mnt/ftpfs/rpms
	ftpmount $USER@$FTPSITE/pub/redhat-contrib /mnt/ftpfs/contrib
        

Before you even start thinking about mounting FTP volumes, make sure you have a decent bandwidth or it's gonna suck.

	cd /mnt/ftpfs/[user:pass@]ftp_server[:port]
          

	The parameters: [defaults]
	    * user: The user to be used for logging on the FTP server. [anonymous]
	    * password: The password for that user. [user@ftpfs.sourceforge.net]
	    * hostname: The FTP server.
	    * port: The port the server is listening on. [21]
	    * root_dir: The directory on the FTP server you want to be mounted. This should be specified without the trailing slash (that is "/home/duru", not "/home/duru/"). [/]
	    * mount_point: The local directory you want to mount the FTP server onto.
	    * own: Flag to force ownership on all remote files. Useful for FTP servers that list user IDs instead of user names.
	    * uid: The local user ID you want to be the owner of the mounted tree.
	    * gid: The local group ID you want to own the mounted tree.
	    * fmask: The numeric mode to be ORed on all mounted files.
	    * dmask: The numeric mode to be ORed on all mounted dirs.
	    * active: Flag to enable active mode for FTP transfers. Useful if you're behind some firewall and cannot connect to random ports.
          

	umount mount_point
          

The "vm" stands for "Virtual Memory". Linux supports virtual memory unlike old operating systems like DOS which have a hard limit of 640KB memory. Linux can use the hard disk space as "virtual memory" and hence the name "vm". The vmlinuz is the Linux kernel executable. This is located at /boot/vmlinuz. This can be a soft link to something like /boot/vmlinuz-2.4.18-19.8.0. The vmlinuz is created by "make zImage" and you do "cp /usr/src/linux/arch/i386/linux/boot/zImage /boot/vmlinuz". The vmlinuz is a compressed file of vmlinux. The zImage is there for backward compatibility (smaller kernels). Note that, in near future zImage may be dropped in favor of 'make bzImage' (big zImage). The zImage (vmlinuz) is not just a compressed image, but has gzip decompressor code built into it as well (at the beginning). So you cannot use gunzip or gzip -dc to unpack vmlinuz.

Both zImage and bzImage are compressed with gzip. The kernel includes a mini-gunzip to uncompress the kernel and boot into it. The difference is that the old zImage uncompresses the kernel into low memory (the first 640k), and bzImage uncompresses the kernel into high memory (over 1M).

The vmlinux is the uncompressed built kernel, vmlinuz is the compressed one, that has been made bootable. (Note both names vmlinux and vmlinuz look same except for last letter z). Generally, you don't need to worry about vmlinux, it is just an intermediate step.

The kernel usually makes a bzImage, and stores it in arch/i386/boot, and it is up to the user to copy it to /boot and configure GRUB or LILO.

The .b files are "bootloader" files. they are part of the dance required to get a kernel into memory to begin with. You should NOT touch them.

	ls -l /boot/*.b
	-rw-r--r--    1 root     root         5824 Sep  5  2002 /boot/boot.b
	-rw-r--r--    1 root     root          612 Sep  5  2002 /boot/chain.b
	-rw-r--r--    1 root     root          640 Sep  5  2002 /boot/os2_d.b
        

The 'message' file contains the message your bootloader will display, prompting you to choose an OS. So DO NOT touch it.

	ls -l /boot/message*
	-rw-r--r--    1 root     root        23108 Sep  6  2002 /boot/message
	-rw-r--r--    1 root     root        21282 Sep  6  2002 /boot/message.ja
        

See the Appendix A at Section 15, “ Appendix A - Creating initrd.img file ” .

The bzImage is the compressed kernel image created with command 'make bzImage' during kernel compile. It important to note that bzImage is not compressed with bzip2 !! The name bz in bzImage is misleading!! It stands for "Big Zimage". The "b" in bzImage is "big". Both zImage and bzImage are compressed with gzip. The kernel includes a mini-gunzip to uncompress the kernel and boot into it. The difference is that the old zImage uncompresses the kernel into low memory (the first 640k), and bzImage uncompresses the kernel into high memory (over 1M). The only problem is that there are a very few machines where bzImage is known to have problems (because the machines are buggy). The bzImage actually boots faster, but other than that, there's no difference in the way the system *runs*. The rule is that if all drivers cannot fit into the zImage, then you need to modularize more.

If the kernel is small, it will work as both a zImage and a bzImage, and the booted system runs the same way. A big kernel will work as a bzImage, but not as a zImage. Both bootimages are gzipped, (bzImage is not bzipped as the name would suggest), but are put together and loaded differently, that allows the kernel to load in higher address space, that does not limit it to lower memory in the pathetic intel architecture. So why have both? Backward compatability. Some older lilos and loadlins don't handle the bzImage format. Note, they *boot* differently, but *run* the same. There is a lot of misinformation given out about what a bzImage file is (mostly about it being bzip2ed).

This file "module-info" is a symbolic link:

	$ uname -r
	2.4.18-19.8.0custom
	  
	# ls -l /boot/module-info*
	lrwxrwxrwx    1 root     root           25 Jan 26 10:44 /boot/module-info ->
 module-info-2.4.18-19.8.0
	-rw-r--r--    1 root     root        15436 Sep  4  2002 /boot/module-info-2.4.18-14
	-rw-r--r--    1 root     root        15436 Jan 26 01:29 /boot/module-info-2.4.18-19.8.0
        

Note above that it is not a requirement is make module-info symlink to a kernel specific file like the way System-map and vmlinuz is required. It's just a text file so as long as module-info list is recent, you'll be fine. Before removing all the stock RH kernels from your system, you should make a backup of this file:

# cp /boot/module-info-2.4.20-19.9 /boot/module-info-2.4.20-19.9.backup 
        

It should be safe to do this as module-info rarely changes within the same point release of RH kernels.

This file 'module-info' is created by anaconda/utils/modlist (specific to Redhat Linux Anaconda installer). Other Linux distributions may be having equivalent command. Refer to your Linux distributor's manual pages.

See this script and search for "module-info" updmodules .

Below is a cut from this script:

	#!/bin/bash
	# updmodules.sh
		MODLIST=$PWD/../anaconda/utils/modlist
		MODINFO=$KERNELROOT/boot/module-info-$version
	-- snip cut 
	blah blah blah 
	-- snip cut 
	    # create the module-info file
	    $MODLIST --modinfo-file $MODINFO --ignore-missing --modinfo \
			$(ls *.o | sed 's/\.o$//') > ../modinfo
        

The program anaconda/utils/modlist is located in anaconda-runtime*.rpm on the Redhat CDROM

	cd /mnt/cdrom/RedHat/RPMS
	rpm -i anaconda-8.0-4.i386.rpm
	rpm -i anaconda-runtime-8.0-4.i386.rpm
	ls -l /usr/lib/anaconda-runtime/modlist
        

Get the source code for anaconda/utils/modlist.c from anaconda*.src.rpm at "http://www.rpmfind.net/linux/rpm2html/search.php?query=anaconda" Read online at modlist.c . .

The file 'module-info' is generated during the compile. It is an information file that is at least used during filing proper kernel OOPS reports. It is a list of the module entry points. It may also be used by depmod in building the tables that are used by insmod and its kith and kin. This includes dependancy information for other modules needed to be loaded before any other given module, etc.

Bottom line is: "Don't remove this file module-info."

Some points about module-info:

Everytime you compile and install the kernel image in /boot, you should also copy the corresponding config file to /boot area, for documentation and future reference. Do NOT touch or edit these files!!

	ls -l /boot/config-*
	-rw-r--r--    1 root     root        42111 Sep  4  2002 /boot/config-2.4.18-14
	-rw-r--r--    1 root     root        42328 Jan 26 01:29 /boot/config-2.4.18-19.8.0
	-rw-r--r--    1 root     root        51426 Jan 25 22:21 /boot/config-2.4.18-19.8.0BOOT
	-rw-r--r--    1 root     root        52328 Jan 28 03:22 /boot/config-2.4.18-19.8.0-26mar2003
        

If you are using GRUB, then there will be 'grub' directory.

	ls /boot/grub
	device.map     ffs_stage1_5  menu.lst        reiserfs_stage1_5  stage2
	e2fs_stage1_5  grub.conf     minix_stage1_5  splash.xpm.gz      vstafs_stage1_5
	fat_stage1_5   jfs_stage1_5  stage1          xfs_stage1_5
        

See also Section 17, “ Appendix C - GRUB Details And A Sample grub.conf ” file.

System.map is a "phone directory" list of function in a particular build of a kernel. It is typically a symlink to the System.map of the currently running kernel. If you use the wrong (or no) System.map, debugging crashes is harder, but has no other effects. Without System.map, you may face minor annoyance messages.

Do NOT touch the System.map files.

	ls -ld /boot/System.map*
	lrwxrwxrwx    1 root     root           30 Jan 26 19:26 /boot/System.map -> System.map-2.4.18-19.8.0custom
	-rw-r--r--    1 root     root       501166 Sep  4  2002 /boot/System.map-2.4.18-14
	-rw-r--r--    1 root     root       510786 Jan 26 01:29 /boot/System.map-2.4.18-19.8.0
	-rw-r--r--    1 root     root       331213 Jan 25 22:21 /boot/System.map-2.4.18-19.8.0BOOT
	-rw-r--r--    1 root     root       503246 Jan 26 19:26 /boot/System.map-2.4.18-19.8.0custom
        

How The Kernel Symbol Table Is Created ? System.map is produced by 'nm vmlinux' and irrelevant or uninteresting symbols are grepped out, When you compile the kernel, this file 'System.map' is created at /usr/src/linux/System.map. Something like below:

	nm /boot/vmlinux-2.4.18-19.8.0 > System.map
	# Below is the line from /usr/src/linux/Makefile 
	nm vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
	cp /usr/src/linux/System.map /boot/System.map-2.4.18-14   # For v2.4.18
        

From "http://www.dirac.org/linux/systemmap.html"

	   c03441a0 B dmi_broken
	   c03441a4 B is_sony_vaio_laptop
	   c03441c0 b dmi_ident
	   c0344200 b pci_bios_present
	   c0344204 b pirq_table
	   c0344208 b pirq_router
	   c034420c b pirq_router_dev
	   c0344220 b ascii_buffer
	   c0344224 b ascii_buf_bytes
          

	   EIP: 0010:[<00000000>]
	   Call Trace: [<c010b860>]
          

	   # strace -f /sbin/klogd | grep 'System.map'
	   31208 open("/boot/System.map-2.4.18", O_RDONLY|O_LARGEFILE) = 2
          

	   satan# strace lsof 2>&1 1> /dev/null | grep System
	   readlink("/proc/22711/fd/4", "/boot/System.map-2.4.18", 4095) = 23
          

	   satan# strace ps 2>&1 1> /dev/null | grep System
	   open("/boot/System.map-2.4.18", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
          

	   /boot/System.map-2.2.14
	   /boot/System.map-2.2.13
          

	   /boot/System.map-2.2.14
	   /boot/System.map-2.2.14.nosound
          

	   System.map-2.2.14
	   System.map-2.2.14.sound
	   ln -s System.map-2.2.14.sound System.map     # Here System.map -> System.map-2.2.14.sound
          

You can download and recompile the apt-get source code for your distro. Download source code of apt-get from http://ftp.freshrpms.net/pub/freshrpms/redhat/9/apt .

Apart from apt-get you can also use rpmfind tool in redhat. The rpmfind tool has some similarities with apt-get. Visit the rpmfind site at : http://rpmfind.net/linux/rpmfind . The rpmfind is a utility that will find, install, autoupgrade RPM files on rufus to your local computer. The main site of rpmfind "search site" is http://rpmfind.net .

Refer to following resources :

PDF file can be generated from postscript file using either acrobat distill or Ghostscript . And postscript file is generated from DVI which in turn is generated from LaTex file. You can download distill software from "http://www.adobe.com" . Given below is a sample session:

	bash$ man sgml2latex
	bash$ sgml2latex filename.sgml
	bash$ man dvips
	bash$ dvips -o filename.ps filename.dvi
	bash$ distill filename.ps
	bash$ man ghostscript
	bash$ man ps2pdf
	bash$ ps2pdf input.ps output.pdf
	bash$ acroread output.pdf &
        

Or you can use Ghostscript command ps2pdf . ps2pdf is a work-alike for nearly all the functionality of Adobe's Acrobat Distiller product: it converts PostScript files to Portable Document Format (PDF) files. ps2pdf is implemented as a very small command script (batch file) that invokes Ghostscript, selecting a special "output device" called pdfwrite . In order to use ps2pdf, the pdfwrite device must be included in the makefile when Ghostscript was compiled; see the documentation on building Ghostscript for details.

This document is written in linuxdoc SGML format. The Docbook SGML format supercedes the linuxdoc format and has lot more features than linuxdoc. The linuxdoc is very simple and is easy to use. To convert linuxdoc SGML file to Docbook SGML use the program ld2db.sh and some perl scripts. The ld2db output is not 100[percnt] clean and you need to use the clean_ld2db.pl perl script. You may need to manually correct few lines in the document.

The ld2db.sh is not 100[percnt] clean, you will get lot of errors when you run

		bash$ ld2db.sh file-linuxdoc.sgml db.sgml
		bash$ cleanup.pl db.sgml > db_clean.sgml
		bash$ gvim db_clean.sgml 
		bash$ docbook2html db.sgml
        

And you may have to manually edit some of the minor errors after running the perl script. For e.g. you may need to put closing tag < /Para> for each < Listitem>

You can convert the SGML howto document to Microsoft Windows Help file, first convert the sgml to html using:

		bash$ sgml2html xxxxhowto.sgml     (to generate html file)
		bash$ sgml2html -split 0   xxxxhowto.sgml (to generate a single page html file)
        

Then use the tool HtmlToHlp . You can also use sgml2rtf and then use the RTF files for generating winhelp files.

In order to view the document in dvi format, use the xdvi program. The xdvi program is located in tetex-xdvi*.rpm package in Redhat Linux which can be located through ControlPanel [verbar] Applications [verbar] Publishing [verbar] TeX menu buttons. To read dvi document give the command -

          xdvi -geometry 80x90 howto.dvi man xdvi 
        

And resize the window with mouse. To navigate use Arrow keys, Page Up, Page Down keys, also you can use 'f', 'd', 'u', 'c', 'l', 'r', 'p', 'n' letter keys to move up, down, center, next page, previous page etc. To turn off expert menu press 'x'.

You can read postscript file using the program 'gv' (ghostview) or 'ghostscript'. The ghostscript program is in ghostscript*.rpm package and gv program is in gv*.rpm package in Redhat Linux which can be located through ControlPanel [verbar] Applications [verbar] Graphics menu buttons. The gv program is much more user friendly than ghostscript. Also ghostscript and gv are available on other platforms like OS/2, Windows 95 and NT, you view this document even on those platforms.

To read postscript document give the command -

          gv howto.ps ghostscript howto.ps 
        

You can read HTML format document using Netscape Navigator, Microsoft Internet explorer, Redhat Baron Web browser or any of the 10 other web browsers.

You can read the latex, LyX output using LyX a X-Windows front end to latex.

The mkinitrd utility creates an initrd image in a single command. This is command is peculiar to RedHat. There may be equivalent command of mkinitrd in other distributions of Linux. This is very convenient utility.

You can read the mkinitrd man page.

	/sbin/mkinitrd --help   # Or simply type 'mkinitrd --help'
	usage: mkinitrd [--version] [-v] [-f] [--preload <module>]
	       [--omit-scsi-modules] [--omit-raid-modules] [--omit-lvm-modules]
	       [--with=<module>] [--image-version] [--fstab=<fstab>] [--nocompress]
	       [--builtin=<module>] [--nopivot] <initrd-image> <kernel-version>
	       (example: mkinitrd /boot/initrd-2.2.5-15.img 2.2.5-15)
	# Read the online manual page with .....
	man mkinitrd
	su - root
	# The command below creates the initrd image file
	mkinitrd  ./initrd-2.4.18-19.8.0custom.img   2.4.18-19.8.0custom
	ls -l initrd-2.4.18-19.8.0custom.img
	-rw-r--r--    1 root     root       127314 Mar 19 21:54 initrd-2.4.18-19.8.0custom.img
	cp  ./initrd-2.4.18-19.8.0custom.img   /boot
        

See the following sections for the manual method of creating an initrd image.

To create /boot/initrd.img see the documentation at /usr/src/linux/Documentation/initrd.txt and see also Loopback-Root-mini-HOWTO .

A cut from "http://www.linuxman.com.cy/rute/node1.html" chapter 31.7.

SCSI Installation Complications and initrd

Some of the following descriptions may be difficult to understand without knowledge of kernel modules explained in Chapter 42. You may want to come back to it later.

Consider a system with zero IDE disks and one SCSI disk containing a LINUX installation. There are BIOS interrupts to read the SCSI disk, just as there were for the IDE, so LILO can happily access a kernel image somewhere inside the SCSI partition. However, the kernel is going to be lost without a kernel module [lsqb ]See Chapter 42. The kernel doesn't support every possible kind of hardware out there all by itself. It is actually divided into a main part (the kernel image discussed in this chapter) and hundreds of modules (loadable parts that reside in /lib/modules/) that support the many type of SCSI, network, sound etc., peripheral devices.] that understands the particular SCSI driver. So although the kernel can load and execute, it won't be able to mount its root file system without loading a SCSI module first. But the module itself resides in the root file system in /lib/modules/. This is a tricky situation to solve and is done in one of two ways: either (a) using a kernel with preenabled SCSI support or (b) using what is known as an initrd preliminary root file system image.

The first method is what I recommend. It's a straightforward (though time-consuming) procedure to create a kernel with SCSI support for your SCSI card built-in (and not in a separate module). Built-in SCSI and network drivers will also autodetect cards most of the time, allowing immediate access to the device--they will work without being given any options [lsqb ]Discussed in Chapter 42.] and, most importantly, without your having to read up on how to configure them. This setup is known as compiled-in support for a hardware driver (as opposed to module support for the driver). The resulting kernel image will be larger by an amount equal to the size of module. Chapter 42 discusses such kernel compiles.

The second method is faster but trickier. LINUX supports what is known as an initrd image ( initial rAM disk image). This is a small, +1.5 megabyte file system that is loaded by LILO and mounted by the kernel instead of the real file system. The kernel mounts this file system as a RAM disk, executes the file /linuxrc, and then only mounts the real file system.

31.6 Creating an initrd Image

Start by creating a small file system. Make a directory [nbsp ]/initrd and copy the following files into it.

	drwxr-xr-x    7 root     root         1024 Sep 14 20:12 initrd/
	drwxr-xr-x    2 root     root         1024 Sep 14 20:12 initrd/bin/
	-rwxr-xr-x    1 root     root       436328 Sep 14 20:12 initrd/bin/insmod
	-rwxr-xr-x    1 root     root       424680 Sep 14 20:12 initrd/bin/sash
	drwxr-xr-x    2 root     root         1024 Sep 14 20:12 initrd/dev/
	crw-r--r--    1 root     root       5,   1 Sep 14 20:12 initrd/dev/console
	crw-r--r--    1 root     root       1,   3 Sep 14 20:12 initrd/dev/null
	brw-r--r--    1 root     root       1,   1 Sep 14 20:12 initrd/dev/ram
	crw-r--r--    1 root     root       4,   0 Sep 14 20:12 initrd/dev/systty
	crw-r--r--    1 root     root       4,   1 Sep 14 20:12 initrd/dev/tty1
	crw-r--r--    1 root     root       4,   1 Sep 14 20:12 initrd/dev/tty2
	crw-r--r--    1 root     root       4,   1 Sep 14 20:12 initrd/dev/tty3
	crw-r--r--    1 root     root       4,   1 Sep 14 20:12 initrd/dev/tty4
	drwxr-xr-x    2 root     root         1024 Sep 14 20:12 initrd/etc/
	drwxr-xr-x    2 root     root         1024 Sep 14 20:12 initrd/lib/
	-rwxr-xr-x    1 root     root           76 Sep 14 20:12 initrd/linuxrc
	drwxr-xr-x    2 root     root         1024 Sep 14 20:12 initrd/loopfs/
        

On my system, the file initrd/bin/insmod is the statically linked [lsqb ]meaning it does not require shared libraries.] version copied from /sbin/insmod.static--a member of the modutils-2.3.13 package. initrd/bin/sash is a statically linked shell from the sash-3.4 package. You can recompile insmod from source if you don't have a statically linked version. Alternatively, copy the needed DLLs from /lib/ to initrd/lib/. (You can get the list of required DLLs by running ldd /sbin/insmod. Don't forget to also copy symlinks and run strip -s {lib} to reduce the size of the DLLs.)

Now copy into the initrd/lib/ directory the SCSI modules you require. For example, if we have an Adaptec AIC-7850 SCSI adapter, we would require the aic7xxx.o module from /lib/modules/{version}/scsi/aic7xxx.o. Then, place it in the initrd/lib/ directory.

	-rw-r--r--    1 root     root       129448 Sep 27  1999 initrd/lib/aic7xxx.o
        

The file initrd/linuxrc should contain a script to load all the modules needed for the kernel to access the SCSI partition. In this case, just the aic7xxx module [lsqb ] insmod can take options such as the IRQ and IO-port for the device. See Chapter 42.]:

	#!/bin/sash
	 
	aliasall
	 
	echo "Loading aic7xxx module"
	insmod /lib/aic7xxx.o 
        

Now double-check all your permissions and then chroot to the file system for testing.

	chroot ~/initrd /bin/sash
	/linuxrc
        

Now, create a file system image similar to that in Section 19.9:

	dd if=/dev/zero of=~/file-inird count=2500 bs=1024
	losetup /dev/loop0 ~/file-inird
	mke2fs /dev/loop0
	mkdir ~/mnt
	mount /dev/loop0 ~/mnt
	cp -a initrd/* ~/mnt/
	umount ~/mnt
	losetup -d /dev/loop0
        

Finally, gzip the file system to an appropriately named file:

	gzip -c ~/file-inird > initrd-<kernel-version>
        

31.7 Modifying lilo.conf for initrd

Your lilo.conf file can be changed slightly to force use of an initrd file system. Simply add the initrd option. For example:

	boot=/dev/sda
	prompt
	timeout = 50
	compact
	vga = extended
	linear
	image = /boot/vmlinuz-2.2.17
	        initrd = /boot/initrd-2.2.17
	        label = linux
	        root = /dev/sda1
	        read-only
        

Notice the use of the linear option. This is a BIOS trick that you can read about in lilo(5). It is often necessary but can make SCSI disks nonportable to different BIOSs (meaning that you will have to rerun lilo if you move the disk to a different computer).

See also following documents:

The beeper error codes :

2 short beeps : POST not correct. Error in a Harware test. 1 short & 2 long beeps : video error. 1) Video ROM BIOS, parity error. 2) Problem with the horizontal retour from the video adapter. 1 long & 3 short beeps: video error. 1) videocard defect. 2) wrong detection from used monitor. 3) Video RAM error. 1 long beep : POST was correct If there is a posterror, there is a hardwareproblem. Check the extentioncards for a bad contact

See also http://www.preggers.easynet.be/lilo.html

If you get problems in LILO, refer to following tips. During boot if you get error "L0101010101010101 ....", then do this

Always give a date extension to the filename, because it tells you when you built the kernel, as shown below:

	bash# man lilo
	bash# man lilo.conf
	And edit /etc/lilo.conf file and put these lines - 
		image=/boot/bzImage.myker.26mar2001 
		label=myker
		root=/dev/hda1 
		read-only 
	You can check device name for 'root=' with the command - 
		bash# df   / 
	Now give -
		bash# lilo 
		bash# lilo -q 
      

You must re-run lilo even if the entry 'myker' exists, everytime you create a new bzImage.

Given below is a sample /etc/lilo.conf file. You should follow the naming conventions like ker2217 (for kernel 2.2.17), ker2214 (for kernel 2.2.14). You can have many kernel images on the same /boot system. On my machine I have something like:

	boot=/dev/hda
	map=/boot/map
	install=/boot/boot.b
	prompt
	timeout=50
	default=firewall
	image=/boot/vmlinuz-2.2.14-5.0
		label=ker2214
		read-only
		root=/dev/hda9
	image=/boot/vmlinuz-2.2.17-14
		label=ker2217
		read-only
		root=/dev/hda9
	#image=/usr/src/linux/arch/i386/boot/bzImage 
	#	label=myker 
	#	root=/dev/hda7
	#	read-only 
	image=/boot/bzImage.myker.11feb2001
		label=myker11feb 
		root=/dev/hda9
		read-only 
	image=/boot/bzImage.myker.01jan2001
		label=myker01jan 
		root=/dev/hda9
		read-only 
	image=/boot/bzImage.myker-firewall.16mar2001
		label=firewall 
		root=/dev/hda9
		read-only 
      

See

	bash# man grub
	bash# man grubby   # (command line tool for configuring grub, lilo, and elilo)
	bash# man grub-install
      

Edit the file /etc/grub.conf to make entries for the new kernel. See the sample file below:

In Redhat Linux, during grub display, just type c for command-line option of GRUB:

	To boot Linux do this:
    grub> help
	  
    grub> root
        (hd1,1): Filesystem is type ext2fs, partition type 0x83
    grub> root (hd1,0)
	  
    grub> kernel / <Press-TAB-KEY>
    This will list all files
	  
    grub> kernel /boot <Press-TAB-KEY>
    This will list all files in /boot
	  
    grub> kernel /boot/vmlinuz
	  
    grub> boot
      

See also the GRUB Manual . To boot MS Windows 95/2000 etc do this: If you want to boot an unsupported operating system (e.g. Windows 95), chain-load a boot loader for the operating system. Normally, the boot loader is embedded in the boot sector of the partition on which the operating system is installed.

	grub> help
	grub> help rootnoverify
	grub> rootnoverify (hd0,0)
	grub> makeactive
	grub> chainloader +1
	grub> boot
      

	# grub.conf generated by anaconda
	#
	# Note that you do not have to rerun grub after making changes to this file
	# NOTICE:  You do not have a /boot partition.  This means that
	#          all kernel and initrd paths are relative to /, eg.
	#          root (hd0,8)
	#          kernel /boot/vmlinuz-version ro root=/dev/hda9
	#          initrd /boot/initrd-version.img
	#boot=/dev/hda
	# By default boot the second entry
	default=1
	# Fallback to the first entry.
	fallback 0
	# Boot automatically after 2 minutes
	timeout=120
	splashimage=(hd0,8)/boot/grub/splash.xpm.gz
	title Windows 2000 
	unhide (hd0,0)
	hide (hd0,1)
	hide (hd0,2)
	rootnoverify (hd0,0)
	chainloader +1
	makeactive
	title Red Hat Linux (2.4.18-19.8.0.19mar2003)
		root (hd0,8)
		kernel /boot/bzImage.2.4.18-19.8.0.19mar2003 ro root=LABEL=/ hdd=ide-scsi
		initrd /boot/initrd-2.4.18-19.8.0custom.img.19mar03
	title Red Hat Linux (2.4.18-19.8.0custom)
		root (hd0,8)
		kernel /boot/vmlinuz-2.4.18-19.8.0custom ro root=LABEL=/ hdd=ide-scsi
		initrd /boot/initrd-2.4.18-19.8.0custom.img
	title Red Hat Linux (2.4.18-14)
		root (hd0,8)
		kernel /boot/vmlinuz-2.4.18-14 ro root=LABEL=/ hdd=ide-scsi
		initrd /boot/initrd-2.4.18-14.img
	title MyKernel.26jan03 (Red Hat Linux 2.4.18-14)
		root (hd0,8)
		kernel /boot/bzImage.myker.26jan03 ro root=LABEL=/ hdd=ide-scsi
		initrd /boot/initrd-2.4.18-19.8.0.img
	title Windows 98
	hide (hd0,0)
	hide (hd0,1)
	unhide (hd0,2)
	rootnoverify (hd0,2)
	chainloader +1
	makeactive
	title DOS 6.22
	hide (hd0,0)
	unhide (hd0,1)
	hide (hd0,2)
	rootnoverify (hd0,1)
	chainloader +1
	makeactive
	title Partition 2 (floppy)
	hide (hd0,0)
	unhide (hd0,1)
	hide (hd0,2)
	chainloader (fd0)+1
	title Partition 3 (floppy)
	hide (hd0,0)
	hide (hd0,1)
	unhide (hd0,2)
	chainloader (fd0)+1
      

Sympton: The kernel compiles ok producing bzImage but 'make modules' fails.

Solution: This problem is most tricky - there can be many subtle reasons. May be related to Linux distro or dependencies of packages are not uptodate. This one is very peculiar of Redhat distribution but may happen to other distributions. There are some "left over" files which are hanging and causing problems. The remedy is to do 'make mrproper' and 'make clean' and then do 'make modules'. But you may want to copy the saved config file as shown below:

bash# cd /usr/src/linux 
bash# mkdir /usr/src/kernelconfigs ;
bash# cp /usr/src/linux/.config  /usr/src/kernelconfigs/.config.save;
bash# cp /usr/src/linux/.config  /usr/src/linux/configs/.config.save  # ExtraSafe
bash# cp /boot/config*  /usr/src/linux/configs/  # ExtraSafe
bash# make clean
bash# make mrproper  # "MUST DO THIS mrproper", otherwise you will face hell lot of problems !!
bash# make clean
bash# cp /usr/src/kernelconfigs/.config.save .config  # In case you want to reuse the config file ??
	  	

	bash# cp /usr/src/linux/configs/kernel-2.4.18-i686.config  /usr/src/linux/.config
	Or for athlon processors
	bash# cp /usr/src/linux/configs/kernel-2.4.18-athlon.config  /usr/src/linux/.config
			  

Sympton: If the kernel compiles ok but booting never works and it always complains with a kernel panic about /sbin/modprobe.

Solution: You did not create initrd image file. See the Appendix A at Section 15, “ Appendix A - Creating initrd.img file ” .

Also, you must do 'make modules' and 'make modules_install' in addition to creating the initrd image file. Even if you had run 'make modules' before, try running again for the second time (does not hurt). Give 'make modules' and 'make modules_install' once again to make sure for certain that all the loadable modules are put in place.

Sympton: After you build the kernel and reboot, the system hangs just before LILO.

Reason: Probably you did not set the BIOS to pick up the proper Primary Master IDE and Secondary Slave IDE hard disk partition.

Solution: Power on the machine and press DEL key to do setup of the BIOS (Basic Input Output system). Select the IDE settings and set proper primary hard disk partition and slave drives. When the system boots it looks for the primary IDE hard disk and the Master Boot Record partition. It reads the MBR and starts loading the Linux Kernel from the hard disk partition.

The following mistake is commited very frequently by new users.

If your new kernel does not boot and you get -

	Warning: unable to open an initial console
	Kernel panic: no init found. Try passing init= option to kernel
        

The problem is that you did not set the "root=" parameter properly in the /etc/lilo.conf. In my case, I used root=/dev/hda1 which is having the root partition "/". You must properly point the root device in your lilo.conf, it can be like /dev/hdb2 or /dev/hda7.

There may be errors just before this Kernel panic. Look for and read any error messages just above the like 'Kernel panic:'. The failure may be due to any error messages just before this one (it is cummulative effect). For example, before the 'Kernel panic' error you might have got error like 'kernel-module version mismatch' or 'something-else-some-other-error-message'. Try to correct the FIRST error reported by the system.

The kernel looks for the init command which is located in /sbin/init. And /sbin directory lives on the root partition. For details see -

	bash# man init
        

See the Section 17, “ Appendix C - GRUB Details And A Sample grub.conf ” file and see the Section 16, “ Appendix B - Sample lilo.conf ” .

The 'make', 'make bzImage', 'make modules' or 'make modules_install' gives compile problems. You should give 'make mrproper' before doing make.

	bash# make clean && make mrproper # "MUST DO THIS mrproper", otherwise you will face hell lot of problems !!
        

If this problem persists, then try menuconfig instead of xconfig. Sometimes GUI version xconfig causes some problems:

	bash# export TERM=VT100
	bash# make menuconfig  # Newer, uses ncurses/curses, may fail if not installed
        

When you run depmod it gives "Unresolved symbols". A sample error message is given here to demonstrate the case:

	bash$ su - root
	bash# man depmod
	bash# depmod
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/linear.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/multipath.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid0.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid1.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid5.o
        

Reason: You did not make modules and install the modules after building the new kernel with "make bzImage" .

Solution: After you build the new kernel, you must do:

	bash$ su - root
	bash# cd /usr/src/linux
	bash# make modules
	bash# make modules_install
        

When you boot kernel and system tries to load any modules and you get "Unresolved symbol : __some_function_name" then it means that you did not clean compile the modules and kernel. It is mandatory that you should do make clean and make the modules. Do this -

		bash# cd /usr/src/linux
		bash# make dep
		bash# make clean
		bash# make mrproper  # "MUST DO THIS mrproper", otherwise you will face hell lot of problems !!
		bash# make clean
		bash# nohup make bzImage &  
		bash# tail -f nohup.out     (.... to monitor the progress) 
		bash# make modules
		bash# make modules_install
        

If the kernel fails to load a module (say loadable module for network card or other devices), then you may want to try to build the driver for device right into the kernel. Sometimes loadable module will NOT work and the driver needs to be built right inside the kernel. For example - some network cards do not support loadable module feature - you MUST build the driver of the network card right into linux kernel. Hence, in 'make xconfig' you MUST not select loadable module for this device.

You can install default loadable modules with -

The step given below may not be required but is needed ONLY FOR EMERGENCIES where your /lib/modules files are damaged. If you already have the /lib/modules directory and in case you want replace them use the --force to replace the package and select appropriate cpu architecture.

For new versions of linux redhat linux 6.0 and later, the kernel modules are included with kernel-2.2*.rpm. Install the loadable modules and the kernel with

		This will list the already installed package.
	bash# rpm -qa | grep -i kernel
		
	bash# rpm -U --force  /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i686.rpm
	(or)
	bash# rpm -U --force  /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i586.rpm
	(or)
	bash# rpm -U --force  /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i386.rpm
        

This is only for old versions of redhat linux 5.2 and before. Boot new kernel and install the loadable modules from RedHat Linux "contrib" cdrom

	bash# rpm -i /mnt/cdrom/contrib/kernel-modules*.rpm 
	....(For old linux systems which do not have insmod pre-installed) 
        

More problems. You can read the /usr/src/linux/README (at least once) and also /usr/src/linux/Documentation.

	bash [/] # cd /usr/src/linux/Documentation
	  
	bash [/usr/src/linux/Documentation] # ls *.txt
	  
	binfmt_misc.txt  ioctl-number.txt           nbd.txt               serial-console.txt
	cachetlb.txt     IO-mapping.txt             nfsroot.txt           sgi-visws.txt
	cciss.txt        IRQ-affinity.txt           nmi_watchdog.txt      smart-config.txt
	computone.txt    isapnp.txt                 oops-tracing.txt      smp.txt
	cpqarray.txt     java.txt                   paride.txt            sonypi.txt
	devices.txt      kernel-doc-nano-HOWTO.txt  parport-lowlevel.txt  specialix.txt
	digiboard.txt    kernel-docs.txt            parport.txt           spinlocks.txt
	digiepca.txt     kernel-parameters.txt      pci.txt               stallion.txt
	DMA-mapping.txt  kmod.txt                   pcwd-watchdog.txt     svga.txt
	dnotify.txt      locks.txt                  pm.txt                swsusp.txt
	exception.txt    logo.txt                   ramdisk.txt           sx.txt
	floppy.txt       magic-number.txt           riscom8.txt           sysrq.txt
	ftape.txt        mandatory.txt              rtc.txt               unicode.txt
	hayes-esp.txt    mca.txt                    SAK.txt               VGA-softcursor.txt
	highuid.txt      md.txt                     sched-coding.txt      watchdog-api.txt
	i810_rng.txt     memory.txt                 sched-design.txt      watchdog.txt
	ide.txt          modules.txt                scsi-generic.txt      zorro.txt
	initrd.txt       mtrr.txt                   scsi.txt
        

If your new kernel does really weird things after a routine kernel upgrade, chances are you forgot to make clean before compiling the new kernel. Symptoms can be anything from your system outright crashing, strange I/O problems, to crummy performance. Make sure you do a make dep , too.

If your kernel is sucking up a lot of memory, is too large, and/or just takes forever to compile even when you've got your new Quadbazillium-III/4400 working on it, you've probably got lot of unneeded stuff (device drivers, filesystems, etc) configured. If you don't use it, don't configure it, because it does take up memory. The most obvious symptom of kernel bloat is extreme swapping in and out of memory to disk; if your disk is making a lot of noise and it's not one of those old Fujitsu Eagles that sound like a jet landing when turned off, look over your kernel configuration.

You can find out how much memory the kernel is using by taking the total amount of memory in your machine and subtracting from it the amount of ``total mem'' in /proc/meminfo or the output of the command ` free '.

Configuration options for PCs are: First, under the category `General Setup', select `Parallel port support' and `PC-style hardware'. Then under `Character devices', select `Parallel printer support'.

Then there are the names. Linux 2.2 names the printer devices differently than previous releases. The upshot of this is that if you had an lp1 under your old kernel, it's probably an lp0 under your new one. Use ` dmesg ' or look through the logs in /var/log to find out.

If it does not compile, then it is likely that a patch failed, or your source is somehow corrupt. Your version of gcc also might not be correct, or could also be corrupt (for example, the include files might be in error). Make sure that the symbolic links which Linus describes in the README are set up correctly. In general, if a standard kernel does not compile, something is seriously wrong with the system, and reinstallation of certain tools is probably necessary.

In some cases, gcc can crash due to hardware problems. The error message will be something like ``xxx exited with signal 15'' and it will generally look very mysterious. I probably would not mention this, except that it happened to me once - I had some bad cache memory, and the compiler would occasionally barf at random. Try reinstalling gcc first if you experience problems. You should only get suspicious if your kernel compiles fine with external cache turned off, a reduced amount of RAM, etc.

It tends to disturb people when it's suggested that their hardware has problems. Well, I'm not making this up. There is an FAQ for it -- it's at "http://www.bitwizard.nl/sig11" .

You did not run LILO, or it is not configured correctly. One thing that ``got'' me once was a problem in the config file; it said ` boot = /dev/hda1 ' instead of ` boot = /dev/hda ' (This can be really annoying at first, but once you have a working config file, you shouldn't need to change it.).

Ooops! The best thing you can do here is to boot off of a floppy disk or CDROM and prepare another bootable floppy (such as ` make zdisk ' would do). You need to know where your root ( / ) filesystem is and what type it is (e.g. second extended, minix). In the example below, you also need to know what filesystem your /usr/src/linux source tree is on, its type, and where it is normally mounted.

In the following example, / is /dev/hda1 , and the filesystem which holds /usr/src/linux is /dev/hda3 , normally mounted at /usr . Both are second extended filesystems. The working kernel image in /usr/src/linux/arch/i386/boot is called bzImage .

The idea is that if there is a functioning bzImage , it is possible to use that for the new floppy. Another alternative, which may or may not work better (it depends on the particular method in which you messed up your system) is discussed after the example.

First, boot from a boot/root disk combo or rescue disk, and mount the filesystem which contains the working kernel image:

mkdir /mnt mount -t ext2 /dev/hda3 /mnt

If mkdir tells you that the directory already exists, just ignore it. Now, cd to the place where the working kernel image was. Note that /mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot Place a formatted disk in drive ``A:'' (not your boot or root disk!), dump the image to the disk, and configure it for your root filesystem:

cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1

cd to / and unmount the normal /usr filesystem:

cd / umount /mnt

You should now be able to reboot your system as normal from this floppy. Don't forget to run lilo (or whatever it was that you did wrong) after the reboot!

As mentioned above, there is another common alternative. If you happened to have a working kernel image in / ( /vmlinuz for example), you can use that for a boot disk. Supposing all of the above conditions, and that my kernel image is /vmlinuz , just make these alterations to the example above: change /dev/hda3 to /dev/hda1 (the / filesystem), /mnt/src/linux to /mnt , and if=bzImage to if=vmlinuz . The note explaining how to derive /mnt/src/linux may be ignored.

Using LILO with big drives (more than 1024 cylinders) can cause problems. See the LILO mini-HOWTO or documentation for help on that.

This can be a severe problem. Starting with a kernel release after Linux v1.0 (around 20 Apr 1994), a program called ` update ' which periodically flushes out the filesystem buffers, was upgraded/replaced. Get the sources to ` bdflush ' (you should find it where you got your kernel source), and install it (you probably want to run your system under the old kernel while doing this). It installs itself as ` update ' and after a reboot, the new kernel should no longer complain.

Strangely enough, lot of people cannot get their ATAPI drives working, probably because there are a number of things that can go wrong.

If your CD-ROM drive is the only device on a particular IDE interface, it must be jumpered as ``master'' or ``single.'' Supposedly, this is the most common error.

Creative Labs (for one) has put IDE interfaces on their sound cards now. However, this leads to the interesting problem that while some people only have one interface to being with, many have two IDE interfaces built-in to their motherboards (at IRQ15, usually), so a common practice is to make the soundblaster interface a third IDE port (IRQ11, or so I'm told).

This causes problems with older Linux versions like 1.3 and below. in that versions Linux don't support a third IDE interface. To get around this, you have a few choices.

If you have a second IDE port already, chances are that you are not using it or it doesn't already have two devices on it. Take the ATAPI drive off the sound card and put it on the second interface. You can then disable the sound card's interface, which saves an IRQ anyway.

If you don't have a second interface, jumper the sound card's interface (not the sound card's sound part) as IRQ15, the second interface. It should work.

Get new versions of the route program and any other programs which do route manipulation. /usr/include/linux/route.h (which is actually a file in /usr/src/linux ) has changed.

Don't use the vmlinux file created in /usr/src/linux as your boot image; [..]/arch/i386/boot/bzImage is the right one.

Change the word dumb to linux in the console termcap entry in /etc/termcap . You may also have to make a terminfo entry.

The linux kernel source includes a number of include files (the things that end with .h ) which are referenced by the standard ones in /usr/include . They are typically referenced like this (where xyzzy.h would be something in /usr/include/linux ): #include <linux/xyzzy.h> Normally, there is a link called linux in /usr/include to the include/linux directory of your kernel source ( /usr/src/linux/include/linux in the typical system). If this link is not there, or points to the wrong place, most things will not compile at all. If you decided that the kernel source was taking too much room on the disk and deleted it, this will obviously be a problem. Another way it might go wrong is with file permissions; if your root has a umask which doesn't allow other users to see its files by default, and you extracted the kernel source without the p (preserve filemodes) option, those users also won't be able to use the C compiler. Although you could use the chmod command to fix this, it is probably easier to re-extract the include files. You can do this the same way you did the whole source at the beginning, only with an additional argument:

blah# tar zxvpf linux.x.y.z.tar.gz linux/include Note: `` make config '' will recreate the /usr/src/linux link if it isn't there.

The following few example commands may be helpful to those wondering how to increase certain soft limits imposed by the kernel:

			echo 4096 > /proc/sys/kernel/file-max 
			echo 12288 > /proc/sys/kernel/inode-max 
			echo 300 400 500 > /proc/sys/vm/freepages 
        

See 'Quick Steps - Kernel Compile' in the Section 2.8, “ Where to Report Bugs ? ” .