Add following common variables and function:
$FENCE_KDUMP_CONIFG: configuration file /etc/sysconfig/fence_kdump
$FENCE_KDUMP_NODES: configuration file /etc/fence_kdump_nodes
$FENCE_KDUMP_SEND: executable /usr/libexec/fence_kdump_send
is_fence_kdump(): used to determine if the system is in a cluster and
configured with fence_kdump.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Since kdump already support dump in cluster environment, this patch
add a howto file to RPM package to describe how to configure kdump
in cluster environment.
Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
IBM would strongly recommend for s390x to replace "maxcpus=1" with
"nr_cpus=1" because with the "nr_cpus=1" kernel parameter only for one
CPU the per-cpu data structures are allocated. This currently saves
several MiB of memory.
IBM (michael.holzheu@de.ibm.com) has confirmed this patch worked fine.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Backport from upstream.
commit 20ecc0827e7837c52f3903638a59959f8bf17f9e
Author: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Date: Tue Nov 5 00:29:35 2013 +0900
[PATCH v2] Improve progress information for huge memory system.
On system with huge memory, percentage in progress information is
updated at very slow interval, because 1 percent on 1 TiB memory is
about 10 GiB, which looks like as if system has freezed. Then,
confused users might get tempted to push a reset button to recover the
system. We want to avoid such situation as much as possible.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit 158d763
Author: WANG Chao <chaowang@redhat.com>
Date: Tue Jan 7 01:37:34 2014 +0800
vmcore-dmesg: struct_val_u64() not casting u64 to u32
It seems gcc doesn't check return type from inline function.
struct_val_u64() should return u64 otherwise upper 32bit is lost.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
timestamp in vmcore-dmesg is u64 type but it's truncated to u32, which
results in wrong time stamp. So let's backport this patch to fix this
issue.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit 7c770ed
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date: Thu Dec 12 16:40:31 2013 +0900
[PATCH] Fall back to read() when mmap() fails.
This is a fall back path for mmap().
This patch disables mmap() when facing the issues related to mmap(),
and read() will be used to read vmcore instead.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
mmap() file operation on vmcore is working properly when the page being
accessed has different attributes on different part (ie. two different type
of memory ranges are overlapping).
A fall back mechanism is introduced in this patch, in case mmap() fails,
switch to read() afterwards.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit a895dc8
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date: Thu Dec 12 16:40:12 2013 +0900
[PATCH] Add --non-mmap option to disable mmap() manually.
When --non-mmap option is specified, makedumpfile doesn't use
mmap() even if /proc/vmcore supports mmap().
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Having this patch, user can switch between mmap() and read() when
accessing vmcore. Whenever user feels necessary to use readmem on vmcore
(buggy code in mmap path, debug purpose, etc.), --non-mmap can do this
favor.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit eb708ce
Author: Baoquan He <bhe@redhat.com>
Date: Tue Jul 2 11:11:07 2013 +0900
[PATCH 2/2] Add help and man message for '--help'.
Conventionally '-h' and '--help' are all provided. Currently makedumpfile
lacks help and man message for '--help'. Here add it.
Signed-off-by: Baoquan He <bhe@redhat.com>
It's needed for applying commit 414d3ed ("Add --non-mmap option to
disable mmap() manually").
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This is a backport of the following upstream commit:
commit bd67c1d
Author: Baoquan He <bhe@redhat.com>
Date: Tue Jul 2 11:09:20 2013 +0900
[PATCH 1/2] Assign non-printable value as short options.
Characters for short options is limited, and now makedumpfile has
considerably many options. As times go on, no enough reasonable
letters can be assigned to each functionality with short options.
E.g non-cyclic vs Y, cyclic-buffer vs Z, eppic vs S.
Now assign non-printable value to these kind of short optins, meanwhile
define them as indicative MACRO which can make code more readable.
Signed-off-by: Baoquan He <bhe@redhat.com>
It's needed for applying commit 414d3ed ("Add --non-mmap option to
disable mmap() manually").
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
This reverts commit 2dc9600ad14b8cf29f6eddbf27c7ec90426156aa:
commit 2dc9600
Author: Dave Young <dyoung@redhat.com>
Date: Thu Nov 14 10:51:47 2013 +0800
makedumpfile: disable mmap
There's a kernel bug for mapping mem ranges which end with
an address not aligned to page boundry. It's still not resolved
in upstream, so let's disable mmap read for now as a workaround.
Once upstream got a right fix we can revert this patch.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Having uncommented core_collector line in default kdump.conf would help
s-c-kdump determine which arguments to use without relying on hardcoded
values.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
When we're parsing kdump.conf, we read it from stdin in a while
loop statement. If we don't use ssh -n within the loop, all rest of the
kdump.conf options, which are in stdin, will be eaten by ssh.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
make tgz now will automatically pack the po files and Makefile to
kexec-tools-po-`date +%Y%m%d`.tgz to make life easier when we update po
files.
Signed-off-by: WANG Chao <chaowang@redhat.com>
The locale directory for Tamil (India) is
"/usr/share/locale/ta_IN/LC_MESSAGES/" but not
"/usr/share/locale/ta-IN/LC_MESSAGES/"
For the locale directory mapping purpose, need to change ta-IN to ta_IN:
$ git mv ta-IN.po ta_IN.po
Signed-off-by: WANG Chao <chaowang@redhat.com>
makedumpfile can filter out kernel data from vmcore[1]. A how-to of feature
is well explained in makedumpfile.conf, which upstream is already
shipping but we're not.
Now add makedumpfile.conf and its man page to our package the upstream
way:
makedumpfile.conf --> /etc/makedumpfile.conf.sample
makedumpfile.conf.5.gz --> /usr/share/man/man5/makedumpfile.conf.5.gz
[1]. http://lists.infradead.org/pipermail/kexec/2011-September/005466.html
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Lzo is proven faster than zlib, for large memory machine it will
extremely shorten the time for saving vmcore. Let's switch to lzo as the
default compression method for makedumpfile.
The drawback is lzo has a little less compression ratio than zlib. But
considering for most users, speed/time is a more serious concern than
vmcore size. So I think default to lzo will benefit most of the users.
v1->v2: update kdump.conf.5 [DaveY]
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
This is a backport of commit bcdba92 ("[PATCH v5] Support to filter dump
for kernels that use CONFIG_SPARSEMEM_VMEMMAP."):
commit bcdba92
Author: Hari Bathini <hbathini@linux.vnet.ibm.com>
Date: Mon Nov 25 17:20:55 2013 +0900
[PATCH v5] Support to filter dump for kernels that use CONFIG_SPARSEMEM_VMEMMAP.
Makedumpfile tool fails to filter dump for kernels that are build with
CONFIG_SPARSEMEM_VMEMMAP set, as it fails to do address translations
for vmemmap regions that are mapped out of zone normal. This patch
provides support in makedumpfile to do vmemmap to physical address
translations when they are mapped outside zone normal. Some kernel
symbols are needed in vmcoreinfo for this changes to be effective.
The kernel patch that adds the necessary symbols to vmcoreinfo has
been posted to linuxppc devel mailing list. This patch is influenced
by vmemmap to physical address translation support code in crash tool.
This patch has been tested successfully at all dump filtering levels
on kernels with CONFIG_SPARSEMEM_VMEMMAP set/unset. Also, tested dump
filtering on already filtered vmcores (re-filtering).
Changes from v4 to v5:
Trimmed patch description to be compact and readable.
Changes from v3 to v4:
Rebased to devel branch.
Signed-off-by: Onkar N Mahajan <onmahaja@in.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
On PPC platform, filter facility is broken since we use
CONFIG_SPARSEMEM_VMEMMAP. This patch fixes this issue but also needs kernel
counterpart fix to get makedumpfile filter working.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Steve Best<sbest@redhat.com>
This is a backport of commit a01b663 ("[PATCH v2] dump-dmesg: Understand
>= v3.11-rc4 dmesg."):
commit a01b663
Author: Lubomir Rintel <lkundrak@v3.sk>
Date: Fri Sep 20 15:56:49 2013 +0900
[PATCH v2] dump-dmesg: Understand >= v3.11-rc4 dmesg.
Symbol name changed with the following commit:
62e32ac printk: rename struct log to struct printk_log
Changes for v2:
* Only back values for symbol names we did actually read;
* either "log" or "printk_log"
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
makedumpfile --dump-dmesg is broken since VMCOREINFO symbol "log" has
renamed to "printk_log". This patch fixes --dump-dmesg on 3.11 kernel.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
We only allow one instance of kdump service running at each time by
flock /var/lock/kdump which is opened as fd 9 in kdumpctl script.
However a leaking fd issue has been discovered by SELinux:
When executing a specific shell command (not the shell built-in but
provided by other packages, in this case - restorecon) in kdumpctl,
current shell will fork a new subshell for executing and
the subshell will inherit open fd 9 from parent shell. And SELinux
detects that subshell is holding the open fd and consider fd 9 is
leaked.
To avoid this kind of leaking, the most easy way seems to be breaking our
kdumpctl code out into two parts:
- A top level parent shell, which is only used to deal with the lock and
invoking the subshell below.
- A 2nd tier level subshell, which is closing the inherited open fd at
very first and doing the rest of the kdumpctl job. So that it isn't
leaking fd to its subshell when executing like restorecon, etc.
To be easy to understand, the callgraph is roughly like below:
[..]
--> open(9)
--> flock(9)
--> fork
--> close(9) <-- we close 9 right here
--> main() <-- we're now doing the real job
--> [..]
--> fork()
--> restorecon <-- we don't leak fd 9 to child process
--> [..]
--> [..]
As shown above, a wrapper main() is added as the 2nd tier level shell in
this kind of call model. So we can completely avoid leaking fd to
subshell.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Description:
Currently we only added memdebug code before different dracut
hooks ie. pre-udev pre-pivot etc. Add memdebug in kdump.sh before
capturing vmcore is also good for debugging.
solution:
Add make_trace_mem before saving vmcore.
Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
There's a kernel bug for mapping mem ranges which end with
an address not aligned to page boundry. It's still not resolved
in upstream, so let's disable mmap read for now as a workaround.
Once upstream got a right fix we can revert this patch.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Description of Problem:
This is a REGRESSION issue.
At fedora makedumpfile has been updated toward v1.5.4. Unfortunately,
this version fails calculating phys_base on sadump format and then
fails converting vmcore.
x86_64 kernel is relocatable kernel and there can be a gap between
the physical address statically assigned to kernel data and texts
and the address that is really assigned to each object corresponding
to the kernel symbols. The gap is phys_base. makedump calculates the
phys_base in an ad-hoc way that comparing the addresses of some of
occurrences of "Linux kernel" strings in certain range of vmcore.
Resolution:
Fix patch has already been posted in upstream. so just back port.
The commit ID are:
commit e23dc0a1aa5fa7a4429f72ff1c2fe87a87291065
commit 92563d7a7a5175ef78c4a94ee269b1b455331b4c
Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Boot with "crashkernel=128M,high", kernel now uses "Crash kernel" in
/proc/iomem for crash kernel memory reservations at both low and high:
commit 157752d
Author: Yinghai Lu <yinghai@kernel.org>
kexec: use Crash kernel for Crash kernel low
But kexec is still scanning for "Crash kernel low" in /proc/iomem, and
will fail immediately when load/unload crash kernel.
So let's pull the following commit from kexec upstream to make
it compatible with our kernel:
commit e25e6e7
Author: Yinghai Lu <yinghai@kernel.org>
kdump, x86: Process multiple Crash kernel in /proc/iomem
(This patch from upstream is untouched and can be applied cleanly)
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Description of Problem:
In cyclic mode, makedumpfile recalculates cyclic buffer size as the
largest multiple of the largest block size managed by buddy
allocator, i.e. 4MB, smaller than the cyclic buffer size in order to
enable to process each unit of blocks managed by buddy allocator in
each cycle.
However, makedumpfile does two wrong things in the recalculations:
1) While updating size of cyclic buffer, makedumpfile doesn't update
length of range of cycle in page frame numbers, due to which, if
cyclic buffer size is updated, because cyclic buffer size is always
reduced during udpate, some buffer overrun can happen on the cyclic
buffer. This can cause segmentation violation in the worst case.
2) roundup() is used to calculate bitmap size for maximum block size
managed by buddy allocator, here divideup() is correct, due to
which, although memory filtering is not affected, cyclic buffer size
get too much aligned and less efficient.
Fix patches has already been posted and merged in makedumpfile
development devel branch.
git://git.code.sf.net/p/makedumpfile/code
f8c8218856effc43ea01cd9394761cfb8aeaa8df
a785fa7dd7a7bd7dcbb017d0bea8848243b0924f
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
The dumpfile header has this field, which was inherited from
the old "diskdump" facility:
struct disk_dump_header {
...
unsigned int max_mapnr; /* = max_mapnr */
...
and which, among other things, is used by the crash utility as a
delimiter to determine whether a physical address read request is
legitimate. And obviously the field cannot handle PFN values greater
than 32-bits.
The makedumpfile source code does have its own max_mapnr representation
in its DumpInfo structure in "makedumpfile.h":
struct DumpInfo {
...
unsigned long long max_mapnr; /* number of page descriptor */
...
But in its "diskdump_mod.h" file, it carries forward the old diskdump
header format, which has the 32-bit field:
struct disk_dump_header {
...
unsigned int max_mapnr; /* = max_mapnr */
...
And here in "makedumpfile.c", the inadvertent truncation occurs
when the PFN is greater than 32-bits:
int
write_kdump_header(void)
{
...
dh->max_mapnr = info->max_mapnr;
...
Now upstream has below commit to fix this, back port it:
commit 8e124174b62376b17ac909bc68622ef07bde6840
Author: Jingbai Ma <jingbai.ma@hp.com>
Date: Fri Oct 18 18:53:38 2013 +0900
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
In mkdumprd, strip_comments is not implemented correctly. Since arguments
passed, strip_comments only take $1 and misses others. This caused
problems. Such as below line, current code will only get "makedumpfile"
and pass it to $config_val finally, then parameters for makedumpfile
are missed.
core_collector makedumpfile -c --message-level 1 -d 31
Now modify function strip_comments.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
In 2.0.4, Cliff from HP posted 2 patches:
e35aa29 kexec: include reserved e820 sections in crash kernel
4932034 kexec: lengthen the kernel command line image
However, with both of them kdump kernel may fail to boot, and
are useless because of restriction in kernel side. In upstream,
they have been reverted. Now back port these 2 revert commits.
Also since the commit 1a4e90b has dependency, back port commit
dc607e4 which is depended on by commit 1a4e90b too.
1a4e90b Revert "kexec: include reserved e820 sections in crash kernel"
dc607e4 kexec: i386: Add cmdline_add_memmap_internal() to reduce the code duplication
8274916 Revert: "kexec: lengthen the kernel command line image"
Currently we have two issues against mounting filesystems by systemd.
1. If any failure in sysroot.mount, initrd.target won't be reached.
2. If any failure in mounting /etc/fstab, initrd.target won't be reached
Our kdump.sh is in dracut-pre-pivot hook which is ordered after
initrd.target. That means if systemd doesn't reach initrd.target,
pre-pivot service will not run.
Based on above, we can conclude that in order to run kdump.sh,
initrd.target must be reached.
To fix issue 1), we can add rootflags=nofail to 2nd kernel cmdline, so
that initrd.target will not require sysroot.mount. initrd.target
wouldn't care about the failures in sysroot.mount. That means
initrd.target can always be reached whether or not sysroot.mount fails.
So when initrd.target is reached, kdump.sh can be run.
To fix issue 2), we can append "nofail" mount options to every entry in
/etc/fstab. It has almost the same affects as to sysroot.mount.
initrd.target can be reached whether or not mount /etc/fstab fails. So
when initrd.target is reached, kdump.sh can be run.
If the mount failures block kdump from working properly (for example,
the dump target isn't mounted), the error handling will be done by
"default" action specified in /etc/kdump.conf. Otherwise kdump will
ignore the mount failures and dump as expected.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
From: Wade Mealing <wmealing@redhat.com>
The RHEL 5 release of mkdumprd allowed for comments in the kdump config
file as shown below:
net 192.168.1.1 # this is the comment part
This patch strips them out during processing, but leaves the configuration
file in original condition.
Signed-off-by: Wade Mealing <wmealing@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Add function strip_comments into kdump-lib.sh, since it's used by
several files.
Signed-off-by: Wade Mealing <wmealing@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Currently in the whole kdump framework, we have some common functions
used across not only mkdumprd context and dracut context, but also 1st
kernel and 2nd kernel. We defined these functions at each script, which
is obviously not decent.
So let's introduce kdump-lib.sh for the shared functions and put it
to /lib/kdump/kdump-lib.sh.
It starts small, as you can see, only 3 functions are extracted. But in
the future more and more common functions can be added.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Now kdump.service runs "After" network.target. But network.target
doesn't mean network is setup and online[1]. We should use
network-online.target instead for ssh/nfs dump.
And also because nfs dump requires a mounted nfs when rebuilding kdump
initrd, kdump.service should also run "After" remote-fs.target (this
means all remote fs configured in /etc/fstab is mounted).
The downside of this patch is we always need to wait for network-online.target
even when dump target is a local disk. If network fails to come up,
kdump.service have to be stuck until network-online.target timeout (90
seconds by default).
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
In kdump_setup_bridge/bond/team(), we use _dev as a global variable.
That causes following issues when network is br0 over bond0:
-> kdump_setup_bridge br0: _dev to be "bond0" as a brif
-> kdump_setup_bond bond0: _dev is modified to be eth0 as a bond slave
-> (jump back) kdump_setup_bridge br0: we really need _dev is
"bond0" not "eth0".
_dev must be a local variable because it has been used multiple places.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
There will be a race condition if multiple kdumpctl instances are
running at the same time.
By introducing a global mutex lock, only one instance can acquire this
lock and run, others will be waiting for the lock in queue. Now each
kdump instance will be run in serial order and there won't any race
condition.
This is a patch backported from RHEL6.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
WANG Chao
arthur
Baoquan He
Ville Skyttä
Dave Young