Bug 253196 - ramdisk images for kdump are left behind after kernel is gone
Summary: ramdisk images for kdump are left behind after kernel is gone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools
Version: 5.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Neil Horman
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-17 12:33 UTC by Markus Armbruster
Modified: 2008-05-21 15:22 UTC (History)
1 user (show)

Fixed In Version: RHBA-2008-0313
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 15:22:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0313 0 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2008-05-20 15:27:13 UTC

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



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