Bug 614798 - Kickstarted system with kdump enabled fails to compress/strip vmcore
Summary: Kickstarted system with kdump enabled fails to compress/strip vmcore
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools
Version: 5.5
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Cong Wang
QA Contact: Red Hat Kernel QE team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-15 09:59 UTC by Rhys Oxenham
Modified: 2013-09-30 02:19 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2010-07-16 05:06:48 UTC

Attachments (Terms of Use)

Description Rhys Oxenham 2010-07-15 09:59:26 UTC
Description of problem:
After a system is kickstarted, kdump installed and configured to strip and compress a vmcore file, then finally all components updated with latest errata available in custom channel (RHEL 5.5 with most errata), kdump ignores the stripping and compression of the vmcore file and writes out all of the memory to disk. If we change the kdump.conf file after first boot and restart kdump it recognises the stripping/compression and creates a MUCH smaller file on the disk.

Tested with kexec by triggering a kernel panic.

Version-Release number of selected component (if applicable):
RHEL 5.5

How reproducible:
Every time- we have rebuilt a virtual machine at least 20-times.

Steps to Reproduce:

Use a kickstart file to do the following...

1) Build a RHEL 5.5 host
2) Install kexec-tools and kdump
3) Write a kdump.conf file - external ext3 partition, makedumpfile -c -d 20
4) Enable kdump service to be started at boot time
5) Update all packages (including kernel)
Actual results:

Upon first boot, the system rebuilds the initrd for the newest kernel for kdump to work properly (as the service recognises there's no initrd for the new kernel running). If you trigger a kernel panic, it ignores the compression and stripping options and writes out the entire memory, e.g. 8GB in our case to our partition, so we end up with an 8GB vmcore file.

IMPORTANT: If we make a basic change, e.g. a new empty line to the kdump.conf file after first boot and force the service to restart (therefore rebuilding the initrd file) and then cause a kernel panic it compresses and strips the file down, we end up with a 50M> file which is exactly what we want.

Expected results:

After the new initrd file is created (based on the kdump.conf file) it should know that we want to compress and strip the vmcore down, yet it ignores it and puts an 8GB file down to disk. Ideally we don't want to always keep all that space there for a crash dump file, especially on some systems with >150GB RAM!

Additional info:

We're trying to achieve a perfect kickstart script that builds a system that is ready to crash dump at any time with the relevant stripping/compression and is a much smaller, managable file. The customer does not want to end up having to keep a free partition the same size of the RAM if we can help it. Perhaps a bug? Not sure, please advise.

Many thanks,

Comment 1 Rhys Oxenham 2010-07-15 10:05:33 UTC

RHN Satellite 5.3.0, kickstarting systems with RHEL5u5 tree


System gets initially installed with kernel-2.6.18-194 but gets updated during the kickstart to kernel-2.6.18-194.3.1 before testing of the kdump.

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