Commit Graph

960 Commits

Author SHA1 Message Date
WANG Chao
dd7eee7e4a makedumpfile: Fall back to read() when mmap() fails
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>
2014-01-17 11:32:48 +08:00
WANG Chao
89a4cb24e0 makedumpfile: Add --non-mmap option to disable mmap() manually
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>
2014-01-17 11:32:48 +08:00
WANG Chao
778ab7d0c4 makedumpfile: Add help and man message for '--help'
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>
2014-01-17 11:32:47 +08:00
WANG Chao
194a389a9f makedumpfile: Assign non-printable value as short options
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>
2014-01-17 11:32:47 +08:00
WANG Chao
bad556cf2e makedumpfile: Revert "makedumpfile: disable mmap"
This reverts commit 2dc9600ad1:

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>
2014-01-17 11:32:47 +08:00
WANG Chao
9b0f728d92 kdump.conf: uncomment default core_collector line
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>
2014-01-17 11:32:47 +08:00
WANG Chao
cdde81ddbd ssh: use ssh -n to redirect stdin from /dev/null
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>
2014-01-17 11:32:47 +08:00
WANG Chao
0e90b05d96 Release 2.0.4-18
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-24 14:37:13 +08:00
WANG Chao
e69a557c76 Translation, Makefile: add make tgz option to auto pack po files
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>
2013-12-24 14:25:23 +08:00
WANG Chao
1537e3ae88 Translation update
The following po files are updated:
bn_IN.po
es.po
gu.po
it.po

Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-24 14:25:20 +08:00
WANG Chao
9f7ba60b3b Translation: rename ta-IN.po to ta_IN.po
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>
2013-12-24 14:25:18 +08:00
WANG Chao
7d6ef48a5a Add makedumpfile.conf and its man page
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>
2013-12-24 14:25:11 +08:00
WANG Chao
fac2d59ae4 makedumpfile compression method default to lzo
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>
2013-12-24 14:25:07 +08:00
Ville Skyttä
3b60d01930 Drop period at end of Summary. 2013-12-21 23:26:12 +02:00
Ville Skyttä
9017c32c77 Fix Tamil (India) locale subdir name.
- Fix bogus date in %changelog.
2013-12-21 23:25:08 +02:00
WANG Chao
ce5e13266e Release 2.0.4-14
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-03 11:32:04 +08:00
WANG Chao
b82449261b makedumpfile, ppc: Support to filter dump for kernels that use CONFIG_SPARSEMEM_VMEMMAP.
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>
2013-11-28 11:39:20 +08:00
WANG Chao
296e8d3779 makedumpfile: Understand >= v3.11-rc4 dmesg.
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>
2013-11-28 11:39:20 +08:00
WANG Chao
59934ba188 kdumpctl: Avoid leaking fd to subshell
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>
2013-11-28 11:39:20 +08:00
arthur
ef9f97dcad Add rd.memdebug in kdump module
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>
2013-11-28 11:39:18 +08:00
WANG Chao
376a899b09 Release 2.0.4-13
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-11-15 13:34:11 +08:00
Dave Young
2dc9600ad1 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>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-11-15 13:32:20 +08:00
WANG Chao
c9bc5ca307 Release 2.0.4-12
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-10-29 13:44:52 +08:00
arthur
d43f2a8502 fix sadump format phys_base calculating error
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>
2013-10-29 13:28:26 +08:00
WANG Chao
bb3f341fb2 kdump, x86: Process multiple Crash kernel in /proc/iomem
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>
2013-10-29 13:17:31 +08:00
Baoquan He
55c7158d16 makedumpfile: wrong cyclic buffer size recalculation causes bitmap data corruption
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>
2013-10-29 13:15:46 +08:00
Baoquan He
6a56c56743 Fix max_mapnr issue on system has over 44-bit addressing.
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>
2013-10-28 17:33:16 +08:00
Baoquan He
daf4abdeeb Release 2.0.4-11 2013-10-12 16:05:43 +08:00
Baoquan He
a682315996 kdump-lib.sh: strip_comments is not implemented correcty
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>
2013-10-12 16:00:12 +08:00
Baoquan He
514be15bf4 Release 2.0.4-10 2013-09-27 17:15:02 +08:00
Baoquan He
377b01b270 Back port 2 revert commits
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"
2013-09-27 17:01:24 +08:00
WANG Chao
7c48f71b6f kdump.sysconfig: default to "nofail" mount
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>
2013-09-27 15:45:24 +08:00
Baoquan He
45f24f53f5 Release 2.0.4-9 2013-09-27 10:18:06 +08:00
Baoquan He
59e28ddf75 Strip inline comments from the kdump config file before use
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>
2013-09-27 10:09:25 +08:00
Baoquan He
ee524473c8 kdump-lib.sh: add common function strip_comments
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>
2013-09-27 10:08:56 +08:00
WANG Chao
a8921f04ae Introduce kdump-lib.sh for kdump shared functions
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>
2013-09-27 10:07:13 +08:00
WANG Chao
6a0fb27687 kdump.service: Start kdump after network is online and remote fs is mounted
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>
2013-09-27 10:07:13 +08:00
WANG Chao
cbbd4428ac dracut-module-setup: _dev to be a local variable
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>
2013-09-27 10:07:13 +08:00
WANG Chao
a6f03150e9 kdumpctl: Run multiple kdumpctl instances one by one in serial order
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>
2013-09-27 10:07:13 +08:00
Baoquan He
2ce047b9ed makedumpfile support kernel 3.10
This is back ported from makedumpfile upstream directly:

commit 1202589997ad008b18276f504c5c2b8529b41dfe
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date:   Fri Sep 20 09:34:57 2013 +0900

    [PATCH] Support newer kernels.

     A new makedumpfile supports newer kernels:

           - 3.10    (x86 FLATMEM)
           - 3.10    (x86 SPARSEMEM)
           - 3.10    (x86_64 SPARSEMEM)

    Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
2013-09-27 10:05:33 +08:00
Baoquan He
64ab43fb97 Release 2.0.4-8 2013-08-21 15:00:35 +08:00
dyoung@redhat.com
d4ce7e5d97 remove 98selinux dependency
Chaowang measured the selinux load_policy memory usage, it need ~50M
It's too much under kdump 2nd kernel, it cause more OOM then before.

Here is the findings from Vivek:
- If we don't load policy or don't do restorecon, kernel automatically
  uses a label for file as specified by file
  /sys/fs/selinux/initial_contexts/file

  On my system this value is "system_u:object_r:file_t:s0". Kernel
  enforces this label on a file if it is not labeled. That's the reason
  that you see above label on vmcore file when selinux policy was not
  loaded in second kernel or restorecon was not done.

  Note: I did some testing with rhel6 and there also I see file_t context.
  Not sure why that's the case.

- Relabeling of root file system over boot happens if there is a file
  /.autorelabel present. This file is touched by systemd service
  fedora-autorelabel-mark.service. And this file comes from initscritps
  package.

  So if this service thinks that system was booted with selinux disabled
  it will put this file on root and when next time system boots with
  selinux enabled, relabeling is enforced by fedora-autorelabel.service
  service.

- In our case relabeling is not happening after saving vmcore because
  there does not seem be any fedora-autorelabel-mark.service running
  from initramfs context. Looks like this service runs after switching
  to real root.

  Aug 08 10:44:13 vm9-f19 systemd[1]: Started Mark the need to relabel after reboot.

- selinux poicy is now loaded by systemd after root switch has taken
  place.

  Aug 08 10:44:10 vm9-f19 systemd[1]: Successfully loaded SELinux policy in 357.693ms.

So now we know that why selinux relabeling is not taking place. Reason
being that systemd service which marks the file system for autorelabeling
does not run from initramfs context.

And it might not make to run this service from initramfs context before
switch root. In general it makes sense to first switch to root, load
selinux policy if needed and then check whether to mark this filesystem
for relabel or not. Ideally root is mourted read only before that. It is
just that we break this rule for kdump. So as long as we make sure we
relabel files created by kdump after booting back, things should be fine.

Since we will relabel the vmcore dir after reboot so let's remove
the selinux dracut module dependency to avoid load_policy in 2nd kernel.
If in the future load_policy memory usage shrinks to an acceptable level
or there's a better solution we can add selinux load_policy back later.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-08-21 14:54:33 +08:00
Baoquan He
65b1f9f044 Release 2.0.4-7 2013-08-02 14:59:01 +08:00
WANG Chao
7f88bc64ac dracut-kdump.sh: add do_dump() and error out if dump vmcore fails
do_dump() takes care of dump procedure. It'll error out if failing to
save vmcore.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-08-02 14:56:12 +08:00
WANG Chao
0aee2a0072 dracut-module-setup.sh: setup correct system time and time zone in 2nd kernel.
Currently in initrd, hardware clock is always considered to use UTC time
format and system time zone is also UTC. Thus system time isn't correct
if hw clock is localtime or we're using other time zone in real root.

To fix this, install /etc/adjtime and /etc/localtime to initrd.

Previously, this functionality was implemented in dracut base module:

commit 77364fd
Author: WANG Chao <chaowang@redhat.com>

    base: setup correct system time and time zone in initrd

But some people complains about a normal boot initrd needs to rebuild
every time if time zone is changed. So let's fix it on our side.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-08-02 14:56:01 +08:00
WANG Chao
12b86202b5 kernel cmdline: Remove hugepage allocations
2nd kernel has very limited memory. Allocating huge pages will probably
trigger OOM. So let's remove hugepages and hugepagesz kernel parameters
for 2nd kernel when 1st kernel are using them.

If user wants huge pages cmdline in 2nd kernel, he/she can still specify
it through KERNEL_COMMANDLINE_APPEND in /etc/sysconfig/kdump.

This patch adds a new function remove_cmdline_param(). It takes a list
of kernel parameters as its arguments and remove them from given kernel
cmdline.

update:
1. Add description of remove_cmdline_param() per Vivek.
2. Remove_cmdline_param() will take kernel cmdline as $1, then strip it
   and print the result.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-08-02 14:55:44 +08:00
Baoquan He
cc4abf52c9 Use /lib/dracut/no-emergency-shell to control action on fail
Currently when action_on_fail is enabled, the emergency_shell won't be called
either. In kdump even though user specify the default action as emergency_shell,
dracut still skip it. Now change the implementation of action_on_fail to depend
on a file which is created by kdump when making kdump initrd, then remove it
at the beginning of kdump. This can solve the explicit emergency_shell problem.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
2013-08-02 14:52:32 +08:00
Baoquan He
070a561da5 Revert: kdump.sysconfig: Add option action_on_fail and set its default as continue
This reverts commit 9e964ff4c6.

Currently, because of dracut implementation, in kdump 'default shell' will
call emergency_shell of dracut. If action_on_fail is enabled, emergency_shell
is skipped. Then 'default shell' won't work either.

Here revert the old commit 9e964ff4 so that take other implementation.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
2013-08-02 14:46:55 +08:00
WANG Chao
a88f0848dc dracut-kdump.sh: Redirect kdump script stdout/stderr to /dev/console
Currently in kdump.sh, we redirect stdout to stderr, because dracut
pre-pivot service (which kdump.sh is running within) only output stderr
to console. That behavior is defined in dracut-pre-pivot.service:

[Service]
...
StandardInput=null
StandardOutput=syslog
StandardError=syslog+console
...

But during testing, it has been observed that systemd will cache stderr
buffer, and first record to syslog (and it's own journal), then copy the
logs to /dev/console. And this practice is somehow unexpected in our
kdump script. We may have suppressed stdout/stderr that hasn't been
write to /dev/console before we run a force reboot.

With this change of redirecting stdout/stderr to /dev/console, kdump.sh
will output everything immediately to console, not cached/hidden by
systemd.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-08-02 14:46:37 +08:00
Baoquan He
5de822d48d makedumpfile: Add vmap_area_list definition for ppc/ppc64.
Build on ppc/ppc64 failed after makedumpfile-1.5.4 is pulled, since the
variable vmap_area_list is not defined. Back port below commit from
upstream to add it.

commit 150b58eb299066c65ef7713a93effc35c00be03a
Author: Baoquan He <bhe@redhat.com>
Date:   Mon Jul 15 20:37:14 2013 +0800

    [PATCH] Add vmap_area_list definition for ppc/ppc64.

    vmap_area_list is added to get vmalloc_start for ppc/ppc64, but its
    definition is missing, now add them.

    Signed-off-by: Baoquan He <bhe@redhat.com>
2013-07-18 16:05:56 +08:00