Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 614798 - Kickstarted system with kdump enabled fails to compress/strip vmcore
Kickstarted system with kdump enabled fails to compress/strip vmcore
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Cong Wang
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2010-07-15 05:59 EDT by Rhys Oxenham
Modified: 2013-09-29 22:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-16 01:06:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rhys Oxenham 2010-07-15 05:59:26 EDT
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 06:05:33 EDT

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.