This has gotten worlds easier with the advent of GRUB (the grand unified bootloader), and some horse-sense on the part of Red Hat circa 7.2 releases. Take a look at the notes below if you run an older system, or just want to know how far we have come.
I just finished a no-brainer kernel upgrade of my 7.2 system to the 2.4.9 kernel, and here is all that was required:
In my case, I actually installed both an smp and uniprocessor kernel, since I sometimes fiddle with some non-smp aware drivers.
The kernel rpm now contains an initrd image, so the whole mess of saving the /lib/modules, fighting with the loopback device, and building an initrd are now ancient history.
If you are running GRUB now (as I am), there is no need to edit lilo.conf and to rerun lilo as before, GRUB apparently is clever enough to rummage through the filesystem and find the kernel. Wow, we are finally where BSD systems were 10 years ago! (oops, I didn't say that!!).
These are a mirror (now perhaps out of date) of the real instructions (that never really get revised) from these on the Red Hat site.
The basic plan is this:
If you don't need to rebuild an initrd (which should be the case if you run an IDE disk based system), this is pretty easy. You can probably avoid the backup step above. Do an ls of /boot before you do the upgrade and then again after, and a look at your old lilo.conf should tell you in a minute what to do.
If you do need to build a new initrd (such as I did with my scsi based system), you could be dealing with hell on wheels. In my case, the command gave me the error:
mkinitrd initrd-2.2.16-3smp.img 2.2.16-3smp All of your loopback devices are in use!It turns out that what was really going on was that the loop.o module was not loaded, and the rpm -Uvh of the new kernel had removed it from my disk entirely. I managed to get out of this mess by doing an
rpm -Uvh --force kernel-OLDxxxxx.rpmFrom the original install CD, but I wasn't smiling for quite a while.
All this would have been easier if the rpm of the new kernel hadn't obliterated my old one. This is why I recommend the backup step at the start. What I do is to use tar to create boot.tar and modules.tar before I install the kernel rpm's. Then you can just untar them back where they belong after the rpm -Uvh of the new kernel blows them away. I used insmod loop.o to load the loopback module and a quick test with /sbin/losetup verified it was OK (take a look at /sbin/mkinitrd if you are curious about all this). Then initrd can be run OK. It is possible that the insmod is not needed since the loop.o module is now back where it belongs, but you can try this out and let me know.
An addendum about a year later ... this hassle with loopback devices seems to be absent in recent upgrades of 6.1 and 7.0 kernels, so it would seem that someone got a clue and decided to not make the loopback device a module or something like that.
The above is not a detailed recipe, but it is late and I just finished all this and want to go home.
Here is a play by play description of doing the upgrades for a Red Hat 6.2 kernel (from 2.2.14 to 2.2.16). In particular these are for intel based machines, since these are the only ones I deal with or know anything about.
First off you find 3 directories:
You will find in the i386 directory (along with all the other updates) the following files:
[root@lardbucket i386]# rpm -qa | grep kern kernel-headers-2.2.14-5.0 kernel-2.2.14-5.0 kernel-doc-2.2.14-5.0 kernel-ibcs-2.2.14-5.0 kernel-pcmcia-cs-2.2.14-5.0 kernel-source-2.2.14-5.0 kernel-utils-2.2.14-5.0 kernelcfg-0.5-5If you get curious about what is in an rpm, you can do this:
rpm -qlp blatz.rpmAlso, while we are on the subject, the following command will show you what rpm's are loaded on your system.
rpm -qa
OK, what do you do??
First try to rpm in the innocuous stuff:
rpm -Uvh kernel-doc-2.2.14-5.0.rpm rpm -Uvh kernel-ibcs-2.2.14-5.0.rpm rpm -Uvh kernel-pcmcia-cs-2.2.14-5.0.rpm rpm -Uvh kernel-utils-2.2.14-5.0.rpm rpm -Uvh kernel-source-2.2.14-5.0.rpm kernel-headers-2.2.14-5.0.rpm
Notice that I do source and headers in one swipe (since these typically have interdependencies and this solves that). Also note that I am omitting the kernel (and modules) itself, namely: kernel-2.2.14-5.0.rpm This particular step is fraught with peril and may render your system unbootable unless you generate a new initrd (if you need one) and rerun lilo and go through various painful experiences involved in that.
After one kernel upgrade episode, I found that the following links had to be recreated:
cd /usr/include ln -s ../src/linux/include/linux linux ln -s ../src/linux/include/asm asmAfter that, the kernel build went OK. YMMV
Adventures in Computing / ttrebisky@as.arizona.edu