Bug 511003
Summary: | mkdumprd copy vmcore without --sparse=always | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | masanari iida <masanari_iida> | |
Component: | kexec-tools | Assignee: | Neil Horman <nhorman> | |
Status: | CLOSED ERRATA | QA Contact: | Red Hat Kernel QE team <kernel-qe> | |
Severity: | low | Docs Contact: | ||
Priority: | low | |||
Version: | 5.2 | CC: | qcai | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 600578 (view as bug list) | Environment: | ||
Last Closed: | 2010-03-30 07:47:47 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: |
Description
masanari iida
2009-07-13 08:25:48 UTC
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 |