This used to drive me crazy when I was upgrading a kernel that used scsi drivers. Here is a short explanation of why this has to be fiddled with. The real trick is when the root filesystem is on some device that must be accessed by a driver which exists in the form of a module. We have a real chicken and egg problem. We need the module to read the file containing the module.
Initrd to the rescue. What is done is that a ramdisk image serves temporarily as a root filesystem during the first stages of system initialization. The modules (it seems only scsi at this juncture) are loaded from the ramdisk, and then the root is switched to the real device once the module is available. Pretty much that is how it works, except for the details of putting the initrd image in place if you are building or upgrading a kernel.
Making the ram disk image is easy, just follow these simple steps. (Or you could look at the mkinitrd man page and think this over carefully). As near as I can tell, this doesn't depend on the kernel image at all. All that mkinitrd seems to need to do is find the proper subdirectory under /lib/modules and then grab scsi driver modules out of there.
... suppose the kernel is built from 2.2.14 sources and that the modules are found in /lib/modules/2.2.14-5.0 cd /boot mkinitrd initrd-2.2.14-5.0.img 2.2.14-5.0 ... then make sure /etc/lilo.conf has an entry like this: image=/boot/vmlinuz-new label=linux initrd=/boot/initrd-2.2.14-5.0.img read-only root=/dev/sda5
Now, suppose you do all this and get the following:
[root@chiboni /boot]# mkinitrd initrd-2.2.16-3.img 2.2.16-3 All of your loopback devices are in use!
I have run into this twice now, and been absolutely puzzled both times. Thank God I keep notes, here is the story: what is happening is that your currently running kernel is trying to load a module to get the loopback device and getting into trouble. What this means is that you are in the middle of a kernel upgrade and the kernel you are now running is now finding the modules for the kernel you are upgrading to. A nasty chicken and egg problem, that you will have to solve by some combination of using rpm to restore the modules your kernel needs, or anticipating this mess and keeping your modules in some backup location on disk where they won't get overwritten. To be more specific, let us say you are running a 2.2.15 kernel, which is gonna look at /lib/modules/2.2.15/ to find the loopback driver. You are upgrading to a 2.2.16 kernel, so those modules are gone and /lib/modules/2.2.16 is all that is there. You could have tarred up all those 2.2.15 modules, let the rpm -Uvh for the 2.2.16 modules blow them away, then untar them so you can do the initrd. What a pain.
Apart from the nasty business with modules and the silly loopback device message (maybe this driver should be in the kernel and not a module??), initrd is dog easy. Notice that you don't need to rebuild the initrd image unless you either change kernel versions, or you are actually making changes to the scsi module itself.