Red Hat Bugzilla – Bug 473212
Makedumpfile -b Not Documented
Last modified: 2018-04-11 10:10:43 EDT
Description of problem:
$ makedumpfile --help
# makedumpfile [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE DUMPFILE
Outputting the dump data in the flattened format to the standard output:
# makedumpfile -F [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE
Rearranging the dump data in the flattened format to a readable DUMPFILE:
# makedumpfile -R DUMPFILE
# makedumpfile -g VMCOREINFO -x VMLINUX
Creating DUMPFILE of Xen:
# makedumpfile -E [--xen-syms XEN-SYMS|--xen-vmcoreinfo VMCOREINFO] VMCORE DUMPFILE
Generating VMCOREINFO of Xen:
# makedumpfile -g VMCOREINFO --xen-syms XEN-SYMS
Compress dump data by each page.
A user cannot specify this option with -E option, because the ELF format
does not support compressed data.
THIS IS ONLY FOR THE CRASH UTILITY.
Specify the type of unnecessary page for analysis.
Pages of the specified type are not copied to DUMPFILE. The page type
marked in the following table is excluded. A user can specify multiple
page types by setting the sum of each page type for Dump_Level (DL).
The maximum of Dump_Level is 31.
Note that Dump_Level for Xen dump filtering is 0 or 1.
Dump | zero cache cache user free
Level | page page private data page
1 | X
2 | X
4 | X X
8 | X
16 | X
31 | X X X X X
Create DUMPFILE in the ELF format.
This option cannot be specified with -c option, because the ELF
format does not support compressed data.
Specify the first kernel's VMLINUX to analyze the first kernel's
The page size of the first kernel and the second kernel should match.
Specify VMCOREINFO instead of VMLINUX for analyzing the first kernel's
VMCOREINFO should be made beforehand by makedumpfile with -g option,
and it contains the first kernel's information. If Dump_Level is 2 or
more and [-x VMLINUX] is not specified, this option is necessary.
Generate VMCOREINFO from the first kernel's VMLINUX.
VMCOREINFO must be generated on the system that is running the first
kernel. With -i option, a user can specify VMCOREINFO generated on the
other system that is running the same first kernel. [-x VMLINUX] must
Output the dump data in the flattened format to the standard output
for transporting the dump data by SSH.
Analysis tools cannot read the flattened format directly. For analysis,
the dump data in the flattened format should be rearranged to a readable
DUMPFILE by -R option.
Rearrange the dump data in the flattened format from the standard input
to a readable DUMPFILE.
Specify the XEN-SYMS to analyze Xen's memory usage.
Specify the VMCOREINFO of Xen to analyze Xen's memory usage.
Exclude all the user domain pages from Xen kdump's VMCORE, and extract
the part of Xen and domain-0.
Specify the message types.
Users can restrict output printed by specifying Message_Level (ML) with
this option. The message type marked with an X in the following table is
printed. For example, according to the table, specifying 7 as ML means
progress indicator, common message, and error message are printed, and
this is a default value.
Note that the maximum value of message_level is 31.
Message | progress common error debug report
Level | indicator message message message message
1 | X
2 | X
4 | X
* 7 | X X X
8 | X
16 | X
31 | X X X X X
Print debugging message.
Overwrite DUMPFILE even if it already exists.
Show help message.
Show the version of makedumpfile.
This is a pathname to the first kernel's vmlinux.
This file must have the debug information of the first kernel to analyze
the first kernel's memory usage.
This is a pathname to the first kernel's memory core image.
This argument is generally /proc/vmcore.
This is a pathname to a file created by this command.
This is a pathname to the xen-syms.
This file must have the debug information of Xen to analyze
Xen's memory usage.
# makedumpfile -b
makedumpfile: option requires an argument -- 'b'
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.
# makedumpfile -b 1 vmcore vmcore-new
[ 0 %]
# echo $?
Version-Release number of selected component (if applicable):
-b works, and returns code 0.
Should return code other than 0.
There is nothing to triage here.
Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.
Note, yes I can fully reproduce here.
Submitted upstream, and fixed in 2.0.0-6. Thanks!
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I've submitted a patch upstream to include the needed documentation. I'll pull it into rawhide with the next makedumpfile update from upstream