Bug 253196

Summary: ramdisk images for kdump are left behind after kernel is gone
Product: Red Hat Enterprise Linux 5 Reporter: Markus Armbruster <armbru>
Component: kexec-toolsAssignee: Neil Horman <nhorman>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 5.0CC: qcai
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0313 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 15:22:50 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:

Description Markus Armbruster 2007-08-17 12:33:55 UTC
Description of problem:
Removing a kernel doesn't remove the associated kdump initrd.  These initrds can
fill up /boot.

How reproducible:
Always

Steps to Reproduce:
1. Remove a kernel that has been booted with kdump active.  yum update did this
for me.
2. Optional: reboot into the new kernel, with kdump active.
  
Actual results:
After yum update removed my kernel-2.6.18-34.el5, initrd-2.6.18-34.el5kdump.img
was left behind.

Expected results:
The stale initrd gets deleted when the kernel is removed, or when a new initrd
is created.

Comment 1 Neil Horman 2007-08-21 11:48:09 UTC
Ok, this should be pretty easy to handle with a %trigger-un script I think.

Comment 3 Neil Horman 2007-08-22 17:39:49 UTC
http://people.redhat.com/nhorman/rpms/kexec-tools-1.101-195.el5.tbz2

The above link is a tarball of test kexec-tools rpms which contain a fix for
this bz.  Please test them and confirm the fix to smooth the checkin process
once the tree opens.  Thanks!



Comment 4 Markus Armbruster 2007-08-23 09:51:47 UTC
I updated my kexec-tools from your archive, then ran yum update, which installed
a kernel 2.6.18-43.el5 and removed 2.6.18-36.el5.  This did not remove my stale
kdump initrds.  They were already stale before the update.

I don't know whether this is supposed to work.  Please advise.


Comment 5 Neil Horman 2007-08-23 11:14:09 UTC
please provide a listing of the the contents of your boot directory

Comment 6 Markus Armbruster 2007-08-23 11:51:14 UTC
# ls -F /boot
config-2.6.18-37.el5              symvers-2.6.18-43.el5xen.gz
config-2.6.18-37.el5xen           System.map-2.6.18-37.el5
config-2.6.18-38.el5              System.map-2.6.18-37.el5xen
config-2.6.18-38.el5xen           System.map-2.6.18-38.el5
config-2.6.18-40.el5              System.map-2.6.18-38.el5xen
config-2.6.18-40.el5xen           System.map-2.6.18-40.el5
config-2.6.18-43.el5              System.map-2.6.18-40.el5xen
config-2.6.18-43.el5xen           System.map-2.6.18-43.el5
grub/                             System.map-2.6.18-43.el5xen
initrd-2.6.18-34.el5kdump.img     vmlinuz-2.6.18-37.el5
initrd-2.6.18-34.el5xenkdump.img  vmlinuz-2.6.18-37.el5xen
initrd-2.6.18-37.el5.img          vmlinuz-2.6.18-38.el5
initrd-2.6.18-37.el5xen.img       vmlinuz-2.6.18-38.el5xen
initrd-2.6.18-38.el5.img          vmlinuz-2.6.18-40.el5
initrd-2.6.18-38.el5xen.img       vmlinuz-2.6.18-40.el5xen
initrd-2.6.18-40.el5.img          vmlinuz-2.6.18-43.el5
initrd-2.6.18-40.el5kdump.img     vmlinuz-2.6.18-43.el5xen
initrd-2.6.18-40.el5xen.img       xen.gz
initrd-2.6.18-43.el5.img          xen.gz-2.6.18-37.el5
initrd-2.6.18-43.el5xen.img       xen.gz-2.6.18-38.el5
lost+found/                       xen.gz-2.6.18-40.el5
symvers-2.6.18-37.el5.gz          xen.gz-2.6.18-43.el5
symvers-2.6.18-37.el5xen.gz       xen-syms*
symvers-2.6.18-38.el5.gz          xen-syms-2.6.18-37.el5*
symvers-2.6.18-38.el5xen.gz       xen-syms-2.6.18-38.el5*
symvers-2.6.18-40.el5.gz          xen-syms-2.6.18-40.el5*
symvers-2.6.18-40.el5xen.gz       xen-syms-2.6.18-43.el5*
symvers-2.6.18-43.el5.gz


Comment 7 Neil Horman 2007-08-23 18:59:08 UTC
http://people.redhat.com/nhorman/rpms/kexec-tools-1.101-196.tbz2

Sorry, yes, thats the way it should work, as you tested it in comment #4.  The
file globbing i did in my trigger script was wrong.  I've fixed it and confired
that it works for me here.  Pleaese download the new version from the link above
and confirm.  Thanks!

Comment 8 Markus Armbruster 2007-08-24 07:29:34 UTC
This one seems to fix it.  I updated my kexec-tools from your archive, then ran
rpm -e kernel-2.6.18-37.el5, which removed the stale kdump initrds.


Comment 9 Neil Horman 2007-08-24 11:47:06 UTC
great, thanks!  As soon as we release 5.1 I'll merge this in.

Comment 10 RHEL Program Management 2007-10-16 03:47:37 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 14 Qian Cai 2008-03-20 07:55:03 UTC
On IA64 boxes, it removed all ramdisk images for kdump whenever erasing a kernel
package. We may need the following patch to fix that,

--- kexec-tools.spec.orig       2008-03-20 03:45:13.000000000 -0400
+++ kexec-tools.spec    2008-03-20 03:46:12.000000000 -0400
@@ -232,7 +232,7 @@
 for i in `ls $IMGDIR/initrd*kdump.img 2>/dev/null`
 do
        KDVER=`echo $i | sed -e's/^.*initrd-//' -e's/kdump.*$//'`
-       if [ ! -e /boot/vmlinuz-$KDVER ]
+       if [ ! -e $IMGDIR/vmlinuz-$KDVER ]
        then
                # We have found an initrd with no corresponding kernel
                # so we should be able to remove it


Comment 15 Qian Cai 2008-03-20 08:31:38 UTC
In addition, does it necessary to do the same thing (%triggerpostun) for
kernel-debug and kernel-xen, as they have kdump initrd as well?


Comment 16 Neil Horman 2008-03-20 12:34:48 UTC
oops, thank you!  good catch, I'll check that in asap (which may be a few
minutes, given that cvs is currently having trouble recognizing that this bug is
approved for commit.

As for kernel-debug and kernel-xen, I've not tested them specifically, but they
should work, given that mkdumprd generates initramfs image names by just tacking
on kdump.img to the end of of the kernel version.  The triggerpostun script just
drops that suffix to re-extract the origional kernel version and look for it.

Comment 18 Qian Cai 2008-03-21 03:02:07 UTC
Neil, I have investigated further, and found in order to fix the same problem
for kernel-debug and kernel-xen, we may need the following patch,

--- kexec-tools.spec.orig       2008-03-20 22:14:43.000000000 +0800
+++ kexec-tools.spec    2008-03-21 10:44:39.000000000 +0800
@@ -215,7 +215,7 @@
 %triggerun -- firstboot
 rm -f %{_datadir}/firstboot/modules/firstboot_kdump.py
 
-%triggerpostun -- kernel
+%triggerpostun -- kernel kernel-xen kernel-debug
 # List out the initrds here, strip out version nubmers
 # and search for corresponding kernel installs, if a kernel
 # is not found, remove the corresponding kdump initrd


Comment 20 Qian Cai 2008-03-21 08:01:29 UTC
Actually, to deal with all cases for RHEL 5.2 kernel variants, we probably need
the following patch,

--- kexec-tools.spec.orig       2008-03-20 22:14:43.000000000 +0800
+++ kexec-tools.spec    2008-03-21 10:44:39.000000000 +0800
@@ -215,7 +215,7 @@
 %triggerun -- firstboot
 rm -f %{_datadir}/firstboot/modules/firstboot_kdump.py
 
-%triggerpostun -- kernel
+%triggerpostun -- kernel kernel-xen kernel-debug kernel-PAE kernel-kdump
 # List out the initrds here, strip out version nubmers
 # and search for corresponding kernel installs, if a kernel
 # is not found, remove the corresponding kdump initrd

Comment 23 errata-xmlrpc 2008-05-21 15:22:50 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0313.html