Description of problem: /etc/init.d/kdump, in save_core(), the vmcore file copy is done with following command. > cp --sparse=always /proc/vmcore $coredir/vmcore-incomplete /sbin/mkdumprd command create initrd-kdump.img, if I specify /etc/kdump.conf. In init script within the initrd-kdump.img, the file copy is done without --sparse=always > if [ -z "$CORE_COLLECTOR" ]; then > CORE_COLLECTOR="cp" <== > fi > >(snip) > >$CORE_COLLECTOR /proc/vmcore \$VMCORE-incomplete > /dev/null Formar case, vmcore file is smaller than RAM size. Latter case, vmcore file is same as the RAM size. Both cases, I can open the vmcore using crash without problem. So technically speaking, this is not an issue. But I would like to know why only save_core() has that option. Version-Release number of selected component (if applicable): kexec-tools-1.102pre-56.el5_3.2 How reproducible: Always Steps to Reproduce: Compare /etc/init.d/kdump and init script within initrd-kdump.img. Actual result: vmcore file is smaller if I don't set /etc/kdump.conf. Expected result: Both "use /etc/kdump.conf" and "not use /etc/kdump.conf", the vmcore file size should be the same, or need some explanation why. Additional Info, I remember thatn IA64 vmcore file is a sparse file on RHEL4. So I wonder if initrd-kdump.img can handle the core file correctly without the option.
I think you are running into the same issue here, [5.3][RFE] Copying of Vmcore Not Sparse Awareness https://bugzilla.redhat.com/show_bug.cgi?id=465261 The developer recommended to use makedumpfile -d 1 instead there.
yeah, theres no reason we can't modify the initramfs to pass that as a option by default, I honestly just havent. Not sure its really needed though. As Cai mentioned, makedmpfile is recommended as the utility to use when trying to shrink core file size. Alternatively putting this in your kdump config: core_collector cp --sparse=always should accomplish the same thing. I'm a bit hesitant to change it, simply because it has a way to be implemented without any internal changes, but if theres really an argument for it, I'll do it. Just let me know.
Back to kexec-tools-1.101-194.4.el5 that I found one of my local system, the /etc/init.d/kdump save_core part doesn't have --sparse=always. /etc/init.d/kdump in kexec-tools-1.102pre-21.el5_3.2, save_core part does have --sparse=always. So, between these 2 versions, I suspect someone modified the script with some technical reason. Then I wonder if there was a reason to modify /etc/init.d/kdump, why not modify the mkdumprd?? This is a starting point of this BZ case. I understand adding an option "core_collector" may change the attitude to the same. But if I would like to modify it, I would ask you to modify /etc/init.d/kdump script side. Because current imprementation, _always_ the option "--sparse=always" is used even if I don't want to use it. An ehnancement idea is, Add KDUMP_CP_OPTIONS="--sparse=always" into /etc/sysconfig/kdump And modify /etc/init.d/kdump - cp --sparse=always /proc/vmcore $coredir/vmcore-incomplete + cp $KDUMP_CP_OPTIONS /proc/vmcore $coredir/vmcore-incomplete
I normally don't add config options to the initscript version of kdump (simply because I really don't want to encourage people to use the initscript for dump collection. In fact in the mkdumprd re-write, I'm not default configuring a rootfs mount). I honestly think some documentation here is whats most in order. Perhaps the easiest thing to do is change the default kdump.conf so that core_collector defaults to cp --sparse=always. I think that might be best. It puts the initscript and initramfs in line.
> Perhaps the easiest thing to do is change the default kdump.conf so > that core_collector defaults to cp --sparse=always. I think that might be > best. It puts the initscript and initramfs in line. Agree. BTW, I have one example case that I don't like rootfs mount type kexec-kdump. How to reproduce (1) set crashkernel=128M@16M (2) set min_free_kbytes to 256MB in /etc/sysctl.conf (3) set kdump to use /etc/init.d/kdump instead of initrd-kdump.img. (4) Crash the system. Expected result kexec-kdump save memory image to a file. Actual result System freeze when startup script in HD execute sysctl and reserve 256MB of low memory within 128MB of 2nd kernel memory! Comment: If this admin uses initrd-kdump.img as a kexec-kdump, this system should have succesfully saved the vmcore. In ohter word, anyone can modify the OS startup script, but only mkdumprd can control the contents of initrd-kdump.img. So that's why I personally like to use initrd-kdump.img.
I agree, nominally we should not use the rootfs to collect core dumps, its just not safe. I've updated the config file to show a cp option in -82.el5.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Kdump can be started with an initscript or with the mkdumprd command. Previously, the vmcore file created by the former method had the "--sparse=always" option applied to it when copied, resulting in a smaller file than when a dump was initiated by the mkdumprd command. The same option has now been added as a default value in the kdump.conf configuration file, therefore ensuring that the default behavior is consistent, regardless of how the dump was initiated.
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 therefore 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-2010-0179.html