From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 Description of problem: Upgrading the kernel package with option --force (for instance, when moving from i386 kernel to Pentium/i586 or from i686 to Athlon) fails to create a new initrd image because mkinitrd would need option -f in order to overwrite an existing initrd image: /boot/initrd-2.4.9-13.img already exists. A possible solution would be either to put the name of the kernel target architecture into the initrd file name or apply a change to the kernel rpm's post-install script like this: --- postin.orig Wed Nov 7 18:16:21 2001 +++ postin Wed Nov 7 18:19:19 2001 @@ -6,5 +6,6 @@ depmod -ae -F /boot/System.map-2.4.9-13 2.4.9-13 [ -x /sbin/mkkerneldoth ] && /sbin/mkkerneldoth if [ -x /sbin/new-kernel-pkg ] ; then + /sbin/new-kernel-pkg --rminitrd --remove 2.4.9-13 /sbin/new-kernel-pkg --mkinitrd --depmod --install 2.4.9-13 fi The latter method would also get rid of duplicate kernel entries in GRUB's grub.conf. Version-Release number of selected component (if applicable): <= 2.4.9-13 How reproducible: Always
the initrd is the least of your problems when you --force install a kernel. You should REALLY not do that, ever. It will leave modules behind from the other kernel, and those either don't work at all, or appear to work but crash the kernel. rpm -e + rpm -i is the only way to go ;(
Upgrade, not install: rpm -Uvh --force leaves modules from the old kernel package behind?
OK, as another thought let's consider the scenario of a user installing/upgrading Red Hat provided packages only: 1) When the user installs a new kernel package with a higher version-release tag while keeping a previous kernel installed, there's should be no problem upon creating the initial ramdisk image file (since the file name would not be used already). 2) When he erases any installed kernel packages before installing a new kernel package (or one for a different archictecture), the pre-uninstall script gets rid of any corresponding initrd-%{version}-%{release}.img file upon package removal. 3) But when can it happen that a file with the same name than the new initial ramdisk image file to be installed exists already? Why would using mkinitrd's option -f hurt? --- /sbin/new-kernel-pkg Wed Sep 5 22:51:53 2001 +++ /tmp/new-kernel-pkg Thu Nov 8 16:01:37 2001 @@ -72,7 +72,7 @@ mkinitrd() { [ -n "$verbose" ] && echo "creating initrd $initrdfile using $version" - /sbin/mkinitrd --ifneeded $initrdfile $version + /sbin/mkinitrd -f --ifneeded $initrdfile $version } rminitrd() { And last but not least, as an addition to point 3), removal of the kernel package that failed to create an initrd file (!) would delete the existing initrd file nevertheless in its pre-uninstall script. At that point, the user would not have the new RH kernel installed and would have lost a possibly important initrd file. So, why not force mkinitrd?