Hide Forgot
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, Rhys
Apologies, RHN Satellite 5.3.0, kickstarting systems with RHEL5u5 tree kexec-tools-1.102pre-96.el5_5.2.x86_64 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.