Bug 55844 - RFE: improved creation of initial ramdisk image
RFE: improved creation of initial ramdisk image
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-07 12:25 EST by Michael Schwendt
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-16 20:15:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2001-11-07 12:25:49 EST
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
Comment 1 Arjan van de Ven 2001-11-07 12:37:14 EST
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 ;(
Comment 2 Michael Schwendt 2001-11-07 13:19:18 EST
Upgrade, not install: rpm -Uvh --force leaves modules from the old kernel
package behind?
Comment 3 Michael Schwendt 2001-11-08 10:17:38 EST
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?

Note You need to log in before you can comment on or make changes to this bug.