Bug 55844
| Summary: | RFE: improved creation of initial ramdisk image | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | Keywords: | FutureFeature |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-12-17 01:15:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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?
|
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