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 ? ” .