Commit Graph

172 Commits

Author SHA1 Message Date
Lianbo Jiang
9529191d95 earlykdump: provide a prompt message after the rebuilding of kdump initramfs.
Early kdump inherits the settings of normal kdump, so any changes that
caused normal kdump rebuilding also require rebuilding the system initramfs
to make sure that the changes take effect for early kdump.

Therefore, when the early kdump is enabled, provide a prompt message after
the rebuilding of kdump initramfs is completed.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-20 16:56:19 +08:00
Kairui Song
1c1159a586 kdumpctl: Detect block device driver change for initramfs rebuild
Previous we rebuild the initramfs when kenrel load module list changed,
but this is not very stable as some async services may load/unload
kernel modules, and cause unnecessary initramfs rebuild.

Instead, it's better to just check if the module required to dump to
the dump target is loaded or not, and rebuild if not loaded. This
avoids most false-positives, and ensure local target change is always
covered.

Currently only local fs dump target is covered, because this check
requires the dump target to be mounted when building the initramfs,
this guarantee that the module is in the loaded kernel module list,
else we may still get some false positive.

dracut-install could be leveraged to combine the modalias list with
kernel loaded module list as a more stable module list in the initramfs,
but upstream dracut change need to be done first.

Passed test on a KVM VM, changing the storage between SATA/USB/VirtIO
will trigger initramfs rebuild and didn't notice any false-positive.
Also passed test on my laptop with no false-positive.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-08 17:51:18 +08:00
Kairui Song
09f50350d9 Revert "kdumpctl: Rebuild initramfs if loaded kernel modules changed"
This reverts commit 6b479b6572.

Check initramfs rebuild by looking at if there is any change of load
kernel modules list is not very stable after all. Previously we are
counting on udev to settle before kdump is started to ensure all modules
is ready, but actually any service may cause a kernel module load, even
after udev is settled.

The previous commit is trying to workaround an issue that VM created
with disk snapshot may fail in the kdump initramfs. The better fix is to
not include the kdump initramfs in the disk snapshot at all, as the
kdump initramfs is not generated for a generic use. And With new added
"kdumpctl reload" command, admins could rebuild the image easily, and
should rebuild the initramfs on hardware change manually.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-06 17:54:26 +08:00
Kairui Song
594ac119c5 kdumpctl: add rebuild support
Use "kdumpctl rebuild" to rebuild the image directly. This could help
admins to rebuild kdump image directly.

Also merge fadump related initramfs backup/restore into setup_initrd,
and do permission only when actually trying to rebuild the image.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-04-05 02:02:43 +08:00
Hari Bathini
689fca5af3 fadump: leverage kernel support to re-regisgter FADump
With kernel commit 0823c68b054b ("powerpc/fadump: re-register firmware-
assisted dump if already registered") support is enabled to re-register
when FADump is alredy registered. Leverage that option in kdump scripts.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Kairui Song <kasong@redhat.com>
2019-03-07 13:33:17 +08:00
Hari Bathini
da6b75f59b fadump: use the original initrd to rebuild fadump initrdfrom
The idea behind adding support for dracut '--rebuild' option was to
ensure the initrd built for fadump takes into consideration all the
build parameters passed to original initrd. Pass original initrd
instead of current default initrd for rebuild as current initrd
might already have build parameters from original initrd along
with parameters from previous fadump intird build making the
build parameters look like this after a few iterations:

-H --persistent-policy 'by-uuid' -f --quiet --hostonly --hostonly-
cmdline --hostonly-i18n --hostonly-mode 'strict' -o 'plymouth dash
resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home /kdumproot
//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --quiet
--hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict'
-o 'plymouth dash resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home
/kdumproot//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --quiet
--hostonly --hostonly-cmdline --hostonly-i18n --hostonly-mode 'strict'
-o 'plymouth dash resume ifcfg' --mount '/dev/mapper/rhel_zzfp219--lp3-home
/kdumproot//home xfs defaults' -f --kver '4.18.0-60.el8.ppc64le' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs' --include
'/tmp/fadump.initramfs' '/etc/fadump.initramfs'
--

Since it is not desirable to build initrd with stale and/or  duplicate
build parameters, use original initrd (backed up) to rebuild fadump
initrd, instead of current default initrd.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-03-07 13:32:47 +08:00
Kazuhito Hagio
242da37c58 Add final_action option to kdump.conf
If a crash occurs repeatedly after enabling kdump, the system goes
into a crash loop and the dump target may get filled up by vmcores.
This is likely especially with early kdump.

This patch introduces 'final_action' option to kdump.conf, in order
for users to be able to power off the system even after capturing
a vmcore successfully.

Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Lianbo Jiang <lijiang@redhat.com>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-01-22 17:58:24 +08:00
Kazuhito Hagio
cc95f0a744 Add failure_action as alias of default and make default obsolete
In preparation for adding 'final_action' option, since it's confusing
to have the 'final_action' and 'default' options at the same time,
this patch introduces 'failure_action' as an alias of the 'default'
option to /etc/kdump.conf, and makes 'default' obsolete to be removed
in the future.

Also, the "default action" term is renamed to "failure action".

Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Lianbo Jiang <lijiang@redhat.com>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
2019-01-22 17:57:53 +08:00
Kairui Song
32fc6070a6 Add missing usage info
In commit b34ce3a reload support was added to kdumpctl but the usage
info is not updated. Now add reload to usage output to let user aware
of the new command.

Signed-off-by: Kairui Song <kasong@redhat.com>
2018-11-09 11:17:00 +08:00
Kairui Song
b34ce3a7b4 kdumpctl: Add reload support
Add reload support to kdumpctl, reload will simply unload current
loaded kexec crash kernel and initramfs, and load it again.

Changes in /etc/sysconfig/kdump will take effect with kdumpctl
reload, but reloading will not check the content of
/etc/kdump.conf and won't rebuild anything. reload is fast, the only
time-consuming part of kdumpctl reload is loading kernel and initramfs
with kexec which is always necessary.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-11-01 22:31:20 +08:00
Kenneth Dsouza
5b385cbd0c kdumpctl: Print warning in case the raw device is formatted and contains filesystem.
Currently the kdumpctl script doesn't check if the raw device is
formatted which might destroy existing data at the time of dump
capture.

This patch addresses this issue, by ensuring kdumpctl prints
a warning in case it finds the raw device to be formatted.

Signed-off-by: Kenneth D'souza <kdsouza@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2018-10-15 10:47:08 +08:00
Kenneth Dsouza
d92b9364ae kdumpctl: Error out if path is set more than once.
Currently the kdumpctl script doesn't check if the path option is
set more than once due to which a vmcore is not captured.

This patch addresses this issue by ensuring that only one path
is specified in /etc/kdump.conf file.

Signed-off-by: Kenneth D'souza <kdsouza@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2018-08-22 15:23:32 +08:00
Kairui Song
6b479b6572 kdumpctl: Rebuild initramfs if loaded kernel modules changed
Currently, we only rebuilt kdump initramfs on config file change,
fs change, or watchdog related change. This will not cover the case
that hardware changed but fs layout and other configurations still
stays the same, and kdump may fail.

To cover such case, we can detect and compare loaded kernel modules,
if a hardware change requires the image to be rebuilt, loaded kernel
modules must have changed.

Starting from commit 7047294 dracut will record loaded kernel modules
when the image is built if hostonly mode is enabled.  With this patch,
kdumpctl will compare the recorded value with currently loaded kernel
modules, and rebuild the image on change.

"kdumpctl start" will be a bit slower, as we have to call lsinitrd one
more time to get the loaded kernel modules list. I measure the time
consumption and we have an overall 0.2s increased loading time.

Time consumption of command "kdumpctl restart":

Before:
real    0m0.587s
user    0m0.481s
sys     0m0.102s

After:
real    0m0.731s
user    0m0.591s
sys     0m0.133s

Time comsumption of command "kdumpctl restart" with image rebuild:

Before (force rebuild):
real    0m10.972s
user    0m8.966s
sys     0m1.318s

After (inserted ~100 new modules):
real    0m11.220s
user    0m9.387s
sys     0m1.337s

Signed-off-by: Kairui Song <kasong@redhat.com>
2018-07-26 19:25:09 +08:00
Lianbo Jiang
b1fbeebd08 move some common functions from kdumpctl to kdump-lib.sh
we move some common functions from kdumpctl to kdump-lib.sh, the
functions could be used in other modules, such as early kdump.
It has no bad effect.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Kazuhito Hagio <khagio@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-05-29 10:18:40 +08:00
Dave Young
3578c54ff2 Fix kdumpctl showmem
showmem function mistakenly added some noise character before the
real code, it could be some copy-paste error.

Fixes: 1a6cb43a19
2018-05-24 13:27:02 +08:00
Bhupesh Sharma
5221d4b90c kdumpctl: Remove 'netroot' and 'iscsi initiator' entries from kdump cmdline
In a iSCSI multipath environment (which uses iSCSI software initiator
and target environment) when the vmcore file is saved on the target,
kdump always fails to establish a iSCSI session and also fails to
collect dump due to duplicate entries for 'netroot' and
'iscsi initiator' in the kdump bootargs:

   # echo c > /proc/sysrq-trigger

   [83471.842707] SysRq : Trigger a crash
   [83471.843233] BUG: unable to handle kernel NULL pointer dereference at           (null)
   [83471.844155] IP: [<ffffffffac82ed16>] sysrq_handle_crash+0x16/0x20
   [83471.844931] PGD 800000023f710067 PUD 229fd6067 PMD 0
   [83471.845655] Oops: 0002 [#1] SMP

   <snip..>

   [83471.861889] Call Trace:
   [83471.862162]  [<ffffffffac82f53d>] __handle_sysrq+0x10d/0x170
   [83471.862771]  [<ffffffffac82f9af>] write_sysrq_trigger+0x2f/0x40
   [83471.863405]  [<ffffffffac690630>] proc_reg_write+0x40/0x80
   [83471.863984]  [<ffffffffac61acd0>] vfs_write+0xc0/0x1f0
   [83471.864536]  [<ffffffffac61baff>] SyS_write+0x7f/0xf0
   [83471.865075]  [<ffffffffacb1f7d5>] system_call_fastpath+0x1c/0x21
   [83471.865714] Code: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 e2 f7 ff ff eb db 0f 1f 44 00 00 55 48 89 e5 c7 05 41 47 81 00 01 00 00 00 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 be
   [83471.868888] RIP  [<ffffffffac82ed16>] sysrq_handle_crash+0x16/0x20
   [83471.869700]  RSP <ffff9e7fe77b7e58>
   [83471.870074] CR2: 0000000000000000

   <snip..>

            Starting Login iSCSI Target iqn.2014-08.com.example:t1...
   [  OK  ] Stopped Login iSCSI Target iqn.2014-08.com.example:t1.
            Starting Login iSCSI Target iqn.2014-08.com.example:t1...
   [    6.607051] scsi host2: iSCSI Initiator over TCP/IP
   [FAILED] Failed to start Login iSCSI Target iqn.2014-08.com.example:t1.
   See 'systemctl status "iscsistart_\\x40...com.example:t1.service"' for details.
   [  126.572911] dracut-initqueue[243]: Warning: dracut-initqueue timeout - starting timeout scripts
            Stopping Open-iSCSI...
   [  OK  ] Stopped Open-iSCSI.
            Starting Open-iSCSI...
   [  OK  ] Started Open-iSCSI.
            Starting Login iSCSI Target iqn.2014-08.com.example:t1...
   [  OK  ] Stopped Login iSCSI Target iqn.2014-08.com.example:t1.
            Starting Login iSCSI Target iqn.2014-08.com.example:t1...
   [  131.095897] scsi host3: iSCSI Initiator over TCP/IP
   [FAILED] Failed to start Login iSCSI Target iqn.2014-08.com.example:t1.
   See 'systemctl status "iscsistart_\\x40...com.example:t1.service"' for details.
   [  251.085029] dracut-initqueue[243]: Warning: dracut-initqueue timeout - starting timeout scripts
   [  251.594554] dracut-initqueue[243]: Warning: dracut-initqueue timeout - starting timeout scripts

   <snip..>

This patch fixes the same by removing the 'netroot',
'rd.iscsi.initiator' and 'iscsi_initiator' entries from the kdump boot
cmdline.

One reason why this is safe is our kdump target setup does not
depend on 1st kernel inherited cmdline params now since the work
we dropped root dependency.

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-05-21 14:09:17 +08:00
Pingfan Liu
1a6cb43a19 kdumpctl: add showmem cmd
port from rhel, original patch is contributed by Minfei Huang:

Using /sys to determines crashkernel actual size is confusing since
there is no unit of measure.

Add a new command "kdumpctl showmem" to show the reserved memory kindly.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-05-21 14:06:30 +08:00
Lianbo Jiang
dbe8214586 kdumpctl: Check the modification time of core_collector
When core_collector is changed, the kdump initramfs needs to
be rebuilt before it is loaded.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-03-22 16:10:58 +08:00
Pingfan Liu
cde5944f93 kdumpctl: skip selinux-relabel for dracut_args --mount dump target
When using "dracut_args --mount" to specify dump target, e.g. nfs like:
    path /
    core_collector makedumpfile -d 31
    dracut_args --mount "host:/path /var/crash nfs defaults"
kdump service should neither guarantees the correctness, nor relabels it.

For current code, since dracut_args dump targets are likely not mounted
so kdump service mistakenly relabel the rootfs, which is meanless and
takes very long time.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2017-12-04 12:51:15 +08:00
Baoquan He
85156bfc66 Revert "kdumpctl: sanity check of nr_cpus for x86_64 in case running out of vectors"
This reverts commit 2040103bd7.

Reason is it's based on the environment of 1st kernel where all
present devices could be active and initialized during bootup.
Then all pci devices will request irqs. While kdump only brings
up those devices which are necessary for vmcore dumping. So this
commit is not meaningful and helpless to very large extent. And
it will print out 'Warning' when calculated result is larger than
1 cpu, actually it's a false positive report most of the time.

So revert the commit, and can check the git history for later
reference.

[dyoung]: on some machine this warning message shows up but
later we found the irq numbers with and without nr_cpus=1 is
quite different so this need more investigation since
the formula is not accurate.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-12-04 12:50:50 +08:00
Bhupesh Sharma
cb3d1c1c3f kdumpctl: Error out in case there are white spaces before an option name
Resolves: BZ1484945
https://bugzilla.redhat.com/show_bug.cgi?id=1484945

Currently the kdumpctl script doesn't handle
whitespaces (including TABs) which might be there before
an option name in the kdump.conf

This patch addresses this issue, by ensuring that the
kdumpctl errors out in case it finds any stray space(s)
or tab(s) before a option name.

Reported-by: Kenneth D'souza <kdsouza@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-10-11 09:57:31 +08:00
Hari Bathini
601766a3d9 fadump: rebuild default initrd with dump capture capability
As default initrd is used for booting fadump capture kernel, it must be
rebuilt with dump capture capability when dump mode is fadump. Check if
default initrd is already fadump capable and rebuild, if necessary.

Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
2017-09-06 15:42:13 +08:00
Xunlei Pang
2c9a863fd3 kdumpctl: remove some cmdline inheritage from 1st kernel
Now with the help of "--hostonly-cmdline", dracut will generate
the needed cmdlines for the dump target, so we can avoid the
corresponding duplicate or unnecessary inheritage.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:40:15 +08:00
Xunlei Pang
31dc60ad20 Change dump_to_rootfs to use "--mount" instead of "root=X"
Currently, we kept "root=X" for the dump_to_rootfs case, this
patch consolidates to use "--mount" for all the kdump mounts.

One advantage of this way is that dracut can correctly mark root
(in case of dump_to_rootfs is specified) as the host device when
"--no-hostonly-default-device" is added in the following patch.

Changed the code style in passing, as shellcheck tool reported:
Use $(..) instead of deprecated `..`

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:39:41 +08:00
Xunlei Pang
d5fe9022d0 kdumpctl: move is_fadump_capable() to kdump-lib.sh
Make is_fadump_capable() a library function, as we will need
it in mkdumprd.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:39:23 +08:00
Xunlei Pang
1bd757bc96 Revert "kdumpctl: use generated rd.lvm.lv=X"
This reverts commit cb38b32dfc.

We are going to add "--hostonly-cmdline" dracut argument in
the following patch.

With the help of "--hostonly-cmdline", dracut will generate
"rd.lvm.lv=X" for us, no need to implement here again.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:38:39 +08:00
Xunlei Pang
8250f23c10 Revert "mkdumprd: omit crypt when there is no crypt kdump target"
This reverts commit 54a5bcc4ee.

We are going to add "--no-hostonly-default-device" dracut argument
in the following patch.

With the help of "--no-hostonly-default-device", dracut only
adds the dump target as host devices, which naturally guarantees
only required dracut modules being selected.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:38:09 +08:00
Xunlei Pang
9df0cbbeed kdumpctl: use "apicid" other than "initial apicid"
We met a problem on AMD machines, when using "nr_cpus=4" for
kdump, and crash happens on cpus other than cpu0, kdump kernel
will fail to boot and eventually reset.

After some debugging, we found that it stuck at the kernel path
do_boot_cpu()-> ... ->wakeup_secondary_cpu_via_init():
 apic_icr_write(APIC_INT_LEVELTRIG|APIC_INT_ASSERT|APIC_DM_INIT,
            phys_apicid);
that is, it stuck at sending INIT from AP to BP and reset, which
is actually what "disable_cpu_apicid=X" tries to solve. Printing
the value of @phys_apicid showed that it was the value of "apicid"
other that of "initial apicid" showed by /proc/cpuinfo.

As described in x86 specification:
"In MP systems, the local APIC ID is also used as a processor ID by the
BIOS and the operating system. Some processors permit software to modify
the APIC ID. However, the ability of software to modify the APIC ID is
processor model specific. Because of this, operating system software
should avoid writing to the local APIC ID register. The value returned by
bits 31-24 of the EBX register (when the CPUID instruction is executed with a
source operand value of 1 in the EAX register) is always the Initial APIC ID
(determined by the platform initialization). This is true even if software
has changed the value in the Local APIC ID register."

From kernel commit 151e0c7de("x86, apic, kexec: Add disable_cpu_apicid
kernel parameter"), we can see in generic_processor_info(), it uses
a)read_apic_id() and b)@apicid to compare with @disabled_cpu_apicid.

a)@apicid which is actually @phys_apicid above-mentioned is from the
  following calltrace(on the problematic AMD machine):
    generic_processor_info+0x37/0x300
    acpi_register_lapic+0x30/0x90
    acpi_parse_lapic+0x40/0x50
    acpi_table_parse_entries_array+0x171/0x1de
    acpi_boot_init+0xed/0x50f
  The value of @apicid(from acpi MADT) is equal to the value of "apicid"
  showed by /proc/cpuinfo as proved by our debug printk.
b)read_apic_id() gets the value from LAPIC ID register which is "apicid"
  as well.

While the value of "initial apicid" is from cpuid instruction.

One example of "apicid" and "initial apicid" of cpu0 from /proc/cpuinfo
on AMD machine:
  apicid          : 32
  initial apicid  : 0

Therefore, we should assign /proc/cpuifo "apicid" to "disable_cpu_apicid=X".

We've never met such issue before, because we usually tested "nr_cpus=1",
and mostly on Intel machines, and "apicid" and "initial apicid" have the
same value in most cases on Intel machines.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-19 09:50:04 +08:00
Xunlei Pang
54a5bcc4ee mkdumprd: omit crypt when there is no crypt kdump target
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

When there is no crypt related kdump target, we can safely
omit "crypt" dracut module, this can avoid the pop asking
disk password during kdump boot in some cases.

This patch introduces omit_dracut_modules() before calling
dracut, we can omit more modules to reduce initrd size in
the future.

We don't want to omit any module for fadump, thus we move
is_fadump_capable() into kdump-lib.sh as a helper to use.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:31 +08:00
Xunlei Pang
cb38b32dfc kdumpctl: use generated rd.lvm.lv=X
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

When there is any "rd.lvm.lv=X", "lvm" dracut module will
try to recognize all the lvm volumes which is unnecessary
and probably cause trouble for us.

See https://bugzilla.redhat.com/show_bug.cgi?id=1451717#c2

Remove all the rd.lvm.lv=X inherited from the kernel cmdline,
and generate the corresponding cmdline as needed for kdump.
Because prepare_cmdline() is only used by kdump, we don't need
to add any fadump judgement(also remove the existing judgement
in passing).

Currently, we don't handle "rd.lvm.vg=X", we can add it in
when there is some bug reported in the future.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:23 +08:00
Xunlei Pang
3ee00cd384 kdump-lib.sh: introduce get_kdump_targets()
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

We need to know all the kdump targets including the dump
target and root in case of "dump_to_rootfs".

This is useful for us to do some extra work related to the
type of different targets.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:06 +08:00
Xunlei Pang
1bc78e025f kdump-lib.sh: fix improper get_block_dump_target()
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

This patch improves get_block_dump_target as follows:
-Consider block device in the special "--dracut-args --mount ..."
 in get_user_configured_dump_disk().
-Consider save path instead of root fs in get_block_dump_target(),
 and move it into kdump-lib.sh because we will have another user
 in the following patch.
-For nfs/ssh dumping, there is no need to check the root device.
-Move get_save_path into kdump-lib.sh.

After this patch, get_block_dump_target() can always return the
correct block dump target specified.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:53:43 +08:00
Ziyue Yang
0933f89f65 kdumpctl: fix infinite loop caused by running under bash
Description of problem
(https://bugzilla.redhat.com/show_bug.cgi?id=1465735):
Run `kdumpctl status` as normal user, get below error messages:

Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
Another app is currently holding the kdump lock; waiting for it to exit...
flock: 9: Bad file descriptor
...

The bug is caused by behavior difference between bash
and sh (bash in posix).

In the function single_instance_lock in kdumpctl script,
there is

exec 9>/var/lock/kdump

which will fail in user mode. However, this fail will cause
script exiting under bash but not exiting under sh, causing
infinite loop because the flock will always fail.

According to the 16th item in
ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html

If a POSIX.2 special builtin returns an error status, a non-
interactive shell exits.

And according to
https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html

exec is one of the POSIX.2 special builtin's.

This patch fixes the bug by checking exec return value.

Fixes: 9fb2996d05 ("kdumpctl: change the shebang header to use /bin/bash")
Signed-off-by: Ziyue Yang <ziyang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
2017-07-14 14:47:37 +08:00
Pingfan Liu
1ca4c9f009 kdumpctl: for fence_kdump, the ipaddr of this node should be excluded from list
kdump should not send fence_kdump notifications to local host, because
the role of the falied node (i.e local host) is to send fence_kdump
notifications to other nodes to tell them I'm kdumping, tell to itself is
nonsense. And we have excluded hostname of local host but when one use ip
address we also need exclude it.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-18 16:44:42 +08:00
Xunlei Pang
9fb2996d05 kdumpctl: change the shebang header to use /bin/bash
We met one issue that when changing softlink of "/usr/bin/sh"
to point to "ksh" instead of the default "bash", kdumpctl will
not work and go wrong.

kdumpctl is expected to run under bash like dracut, we should
change its shebang header from "#!/bin/sh" to "#!/bin/bash".

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-12 09:58:51 +08:00
Xunlei Pang
2b4b7a6374 kdumpctl: call strip_comments only when necessary to speedup
The "time kdumpctl start" command shows that strip_comments()
consumes lots of cpu time. By only calling it when necessary,
it saves us nearly half second.

Tested on my Fedora kvm machine.
Before this patch:
$ time kdumpctl start
kexec: loaded kdump kernel
Starting kdump: [OK]

real	0m1.849s
user	0m1.497s
sys	0m0.462s

After this patch:
$ time kdumpctl start
kexec: loaded kdump kernel
Starting kdump: [OK]

real	0m1.344s
user	0m1.195s
sys	0m0.195s

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-12 09:57:29 +08:00
Xunlei Pang
7f725ef13a Revert "kdumpctl: improve "while read" time for /etc/kdump.conf"
Resolves: bz1449801

"cat $KDUMP_CONFIG_FILE|grep -v "^#"|while read ..." use pipes
to invoke subshells, as a result we met "the dreaded inaccessible
variables within a subshell problem" as described in the book
"Advanced Bash-Scripting Guide".

It cause regressions, so revert it.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-12 09:57:29 +08:00
Xunlei Pang
38c0b4aa3a kdumpctl: improve "while read" time for /etc/kdump.conf
I found using "cat $KDUMP_CONFIG_FILE|grep -v "^#"|while read ..."
instead of "while read ... do ...; done < $KDUMP_CONFIG_FILE" will
make the script run faster, it saves us nearly half second.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
88a3385e96 kdumpctl: update check_dump_fs_modified() to use "lsinitrd -f"
We use faster "lsinitrd XXX -f usr/lib/dracut/build-parameter.txt"
instead of "lsinitrd XXX | grep "^Arguments:" | head -1", this can
save us around one second.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
2a5f362521 kdumpctl: improve check_wdt_modified()
Use the logic of dracut 04watchdog/module-setup.sh to check,
then we only need to compare the content of 00-watchdog.conf,
so we can save one operation of lsinitrd.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
c63c0a1084 kdumpctl: remove is_mode_switched()
handle_mode_switch() can ensure the correct logic, so remove
the needless is_mode_switched(). This helps to save one slow
lsinitrd operation for each boot.

Improved backup_default_initrd() to judge DEFAULT_INITRD.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-05 16:14:33 +08:00
Xunlei Pang
071ea2a277 kdumpctl: bail out earlier in case of no reserved memory
Some cloud people complained that VM boot speed is slower than
Ubuntu and other distributions, after some debugging, we found
that one of the causes is kdump service starts too slow(7seconds
according to the test result on the test VM), actually there is
no "crashkernel=X" specified. Although kdump service is parallel,
it affects the speed more or less especially on VMs with few cpus,
which is unacceptable. It is even worse when kdump initramfs is
built out in case of no reserved memory at first boot.

Commit afa4a35d3 ("kdumpctrl: kdump feasibility should fail if no
crash memory") can actually solve this issue.

This patch is a supplement of above-mentioned commit, we bail out
start() even earlier in case of no reserved memory.

Also made some cosmatic changes for check_crash_mem_reserved().

1) Before this patch
$ time kdumpctl start
No memory reserved for crash kernel.
Starting kdump: [FAILED]

real    0m0.282s
user    0m0.184s
sys     0m0.146s

2) After this patch
$ time kdumpctl start
No memory reserved for crash kernel
Starting kdump: [FAILED]

real    0m0.010s
user    0m0.008s
sys     0m0.001s

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-05-02 17:23:57 +08:00
Bhupesh Sharma
a284fa9005 kdump: Introduce 'force_no_rebuild' option
This patch introduces the 'force_no_rebuild' option
inside the 'kdump.conf' and its handling inside the 'kdumpctl'
script.

There might be several use cases, where a system admin
decides that he doesn't need to rebuild the kdump initrd
and wants to use an existing version of the same. In such cases,
he can set the 'force_no_rebuild' option inside 'kdump.conf'
to 1, to force the 'kdumpctl' script not to rebuild the kdump
initrd.

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-04-27 13:59:49 +08:00
Xunlei Pang
3b311653f2 Revert "kdumpctl: filter 'root' kernel parameter when running in live images"
This reverts commit 892bea7aa

We already eliminated the root filesystem by removing "root=X"
in case of non-root dumping, and for livecd it must be non-root
dumping according to "live-image-kdump-howto.txt".

So it's time to revert this commit.

Also update "live-image-kdump-howto.txt", make sure users do not
configure "default dump_to_rootfs".

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-11 16:03:12 +08:00
Xunlei Pang
b40c1f96cf kdumpctl: remove "root=X" for kdump boot
Since the current dracut of Fedora already supports not always
mounting root device, we can remove "root=X" from the command
line directly, and always get the dump target specified in
"/etc/kdump.conf" and mount it. If the dump target is located
at root filesystem, we will add the root mount info explicitly
from kdump side instead of from dracut side.

For example, in case of nfs/ssh/usb/raw/etc(non-root) dumping,
kdump will not mount the unnecessary root fs after this change.

This patch removes "root=X" via the "KDUMP_COMMANDLINE_REMOVE"
(if "default dump_to_rootfs" is specified, don't remove "root=X"),
and mounts non-root target under "/kdumproot", the root target
still under "/sysroot"(to be align with systemd sysroot.mount).

After removing "root=X", we now add root fs mount information
explicitly from the kdump side.

Changed check_dump_fs_modified() a little to avoid rebuild when
dump target is root, since we add root fs mount explicitly now.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-11 16:02:12 +08:00
Xunlei Pang
bf5b3da107 kdumpctl: fix a bug in remove_cmdline_param()
For the following scripts:
  cmdline="root=/dev/mapper/fedora-root rd.lvm.lv=fedora/root rw"
  remove_cmdline_param $cmdline "root"

  cmdline="root=nfs4:192.168.122.9:/ ip=ens3:dhcp rw"
  remove_cmdline_param $cmdline "root"

The current implementation will get the wrong results:
  "rd.lvm.lv=fedora/ rw"
  ":/ ip=ens3:dhcp rw"

After this patch we can get the correct results:
  "rd.lvm.lv=fedora/root rw"
  "ip=ens3:dhcp rw"

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by:Dave Young <dyoung@redhat.com>
2017-04-11 16:01:50 +08:00
Pratyush Anand
21dcf7e3b1 kdumpctl: fix status check when CONFIG_CRASH_DUMP is not enabled in kernel
When kexec_crash_loaded does not exist, means kdump was not enabled in
kernel we get

$ kdumpctl status
cat: /sys/kernel/kexec_crash_loaded: No such file or directory
/usr/bin/kdumpctl: line 879: [: ==: unary operator expected
Kdump is not operational

After this patch:
$ kdumpctl status
Perhaps CONFIG_CRASH_DUMP is not enabled in kernel
Kdump is not operational

Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-04-11 16:01:25 +08:00
Xunlei Pang
2040103bd7 kdumpctl: sanity check of nr_cpus for x86_64 in case running out of vectors
Check the number of cpus for x86_64 kdump kernel to boot with.
We met an issue on x86_64: kdump runs out of vectors with the
default "nr_cpus=1", when requesting tons of irqs.

This patch detects such situation and warns users about the risk.

The total number of vectors percpu is 256 defined by x86 architecture.
The available vectors can be allocated to io devices percpu starts
from FIRST_EXTERNAL_VECTOR(see kernel code), and some high-numbered
ones are consumed by some system interrupts. As a result, the vectors
for io device are within [FIRST_EXTERNAL_VECTOR, FIRST_SYSTEM_VECTOR),
with one known exception, 0x80 within the range is reserved specially
as the syscall vector.

FIRST_EXTERNAL_VECTOR is invariably 32, while FIRST_SYSTEM_VECTOR can
vary between different kernel versions. E.g. FIRST_SYSTEM_VECTOR gets
0xef(with CONFIG_X86_LOCAL_APIC on)for linux-4.10, that is 17 vectors
reserved, considering it may increase in the future and the special
vectors, we use a flexible variance and assume there are 32 reserved
from FIRST_EXTERNAL_VECTOR. Then the max vectors for device interrupts
percpu is: (256-32)-32=192, we acquire the number N of device interrupts
from /proc/irq/, then the number of minimal cpus required is calculated:
(N + 192 - 1) / 192

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-01-23 15:52:24 +08:00
Xunlei Pang
211b36b8f9 kdumpctl: change prepare_cmdline() to operate KDUMP_COMMANDLINE directly
Since KDUMP_COMMANDLINE is a global variable, prepare_cmdline can
modify it directly instead of echoing back the result. This change
enables it to output messages.

Changed some coding styles.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Pratyush Anand <panand@redhat.com>
2017-01-23 15:51:28 +08:00
Dave Young
631d979eb3 drop dracut duplicate functions
We maintained several kdump specific functions which are duplicate with the
similar versions in dracut,  Dracut upstream splitted dracut init stuff from
dracut-functions.sh so that we can source it now.

Notes about kdump_get_presistent_dev:
Dracut now has a persistent_policy feature, for kdump when we dump to
raw disks we do not care the filesystem uuid and labels so we prefer to
search disk id instead. For raw disk set the persistent_policy before calling
get_persistent_dev ensure kdump logic still work.

Tested filesystem and raw dump in kvm guests.

[Xunlei: drop other functions other than get_persistent_dev.]

Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
2016-11-28 10:41:22 +08:00
Tong Li
ac1eb7edce Correct two typos in kdumpctl and kdump.conf
Signed-off-by: Tong Li <tonli@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
2016-11-28 10:41:05 +08:00
Hari Bathini
6a5e908d85 fadump: restore default initrd when fadump mode is disabled
When fadump mode is enabled, the default initrd is rebuilt with kdump
dracut module. As the default initrd is altered, the original default
initrd is backed up. But we are not restoring it when fadump mode is
disabled. This patch tries to restore the backed up default initrd on
disabling fadump mode.

Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-11-11 11:01:13 +08:00
Tong Li
892bea7aae kdumpctl: filter 'root' kernel parameter when running in live images
Kernels of live images are booted with a kernel parameter which looks
like "root=live:CDLABEL=Fedora-WS-Live-25_A-2". This argument can't be
recognized by dracut during kdump process and will cause failure
of kdump if users didn't set KUDMP_COMMANDLINE in /etc/sysconfig/kdump.
So we should filter out 'root' when we find such a parameter in
/proc/cmdline to make kdump work correctly in live images.

Signed-off-by: Tong Li <tonli@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-11-11 10:56:35 +08:00
Pratyush Anand
4db9e59e89 kdumpctl: fix target identification for systems without initrd
We get following error on the systems that have everything built-in and no
initrd is used.

	Kernel dev name of /dev/root is not found.
	Dump target /dev/root is probably not mounted.

It happens because `df $path` gets /dev/root from /proc/self/mountinfo.

Fix this by identifying real target device when `df $path` returns
Filesystem as /dev/root.

Reported-and-tested-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-09-16 15:40:48 +08:00
Pratyush Anand
1edfff7809 kdumpctl: remove duplicate statement
Since we also check for mount point of $_target after if/else loop, so
there is no need to do the same thing specifically in else loop as well.

Remove those duplicate statement from else loop.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-09-16 15:40:48 +08:00
Pratyush Anand
1bb23e7536 kdumpctl: check /etc/fstab modification only when it exists
On a diskless client /etc/fstab does not exist. Therefore check
modification time of this file for rebuild only if it exists.

Also use --fstab option with findmnt only when /etc/fstab exists.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-09-16 15:40:48 +08:00
Pratyush Anand
9b95184251 kdumpctl: Kill duplicate code related to file modication check
commit "28e8c4b5ac89 kdumpctl: Move file modification check logic in
check_system_modified()" copied file modification check logic instead of
moving.
Kill the duplicate logic from original calling function check_rebuild().

Signed-off-by: Pratyush Anand <panand@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-09-16 15:40:48 +08:00
Xunlei Pang
74c6f46429 Support special mount information via "dracut_args"
There are some complaints about nfs kdump that users must mount
nfs beforehand, which may cause some overhead to nfs server.
For example, there're thounsands of diskless clients deployed with
nfs dumping, each time the client is boot up, it will trigger
kdump rebuilding so will mount nfs, thus resulting in thousands
of nfs request concurrently imposed on the same nfs server.

We introduce a new way of specifying mount information via the
already-existent "dracut_args" directive(so avoid adding extra
directives in /etc/kdump.conf), we will skip all the filesystem
mounting and checking stuff for it. So it can be used in the
above-mentioned nfs scenario to avoid severe nfs server overhead.

Specifically, if there is any "--mount" information specified via
"dracut_args" in /etc/kdump.conf, always use it as the final mount
without any validation(mounting or checking like mount options,
fs size, etc), so users are expected to ensure its correctness.

NOTE:
-Only one mount target is allowed using "dracut_args" globally.
-Dracut will create <mountpoint> if it doesn't exist in kdump kernel,
 <mountpoint> must be specified as an absolute path.
-Users should do a test first and ensure it works because kdump does
 not prepare the mount or check all the validity.

Reviewed-by: Pratyush Anand <panand@redhat.com>
Suggested-by: Dave Young <dyoung@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
2016-08-26 14:03:48 +08:00
Pratyush Anand
6a2b39b96e kdumpctl: force rebuild in case of watchdog state change
If state of a watchdog device is changed by an user after kdumpctl restart
then initramfs must be rebuilt on the basis of new watchdog status.

Testing:
-------------------------------------------------------
Initramfs	wdt state
		Prev	Current		Result
-------------------------------------------------------
Not Exist	NA	X		Rebuild
Exist		Inact	Inact		No Rebuild
Exist		Inact	Act		Force Rebuild
Exist		Act	Inact		Force Rebuild
Exist		Act	Act(Same wdt)	No Rebuild
Exist		Act	Act(Diff wdt)	Force Rebuild
Exist		Act	Module Removed	Force Rebuild

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-07-21 13:56:20 +08:00
Pratyush Anand
81f2c9ea6f get_persistent_dev(): fix name contention with dracut's similar function
Resolves: BZ1348898

dracut-functions.sh defines a get_persistent_dev(). Earlier, we had another
local get_persistent_dev() in mkdumprd, however that was moved to
kdump-lib.sh, so that it can be reused in kdumpctl.

Since, dracut-module-setup.sh (which is dracut's
99kdumpbase/module-setup.sh) sources kdump-lib.sh. Therefore, once dracut
will execute 99kdumpbase module, it's own get_persistent_dev() function is
overwritten by kdump's version. If any other dracut module calls
get_persistent_dev() thereafter then, kdump's version is executed, which was
not expected.

Therefore rename kdump's get_persistent_dev() as kdump_get_persistent_dev()
to avoid any name contention.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-06-28 03:28:47 +08:00
Pratyush Anand
afa4a35d3d kdumpctrl: kdump feasibility should fail if no crash memory
Currently initramfs is rebuilt even when crash kernel memory is not
available and then latter on kdump service is failed.

Its better to fail during feasibility itself when crash memory is not
reserved.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-05-16 10:15:24 +08:00
Pratyush Anand
7aeeb1d17e kdumpctl: force rebuild in case of file system is modified
kdumpctl passes --device argument if dump target is a raw device. It passes
--mount argument if dump target is either mounted as nfs or as a bulk
device. When dump target device is a root device then it does not pass any
of the above two arguments.

After kdumpctl restart, if there is any change in file system which needs
different dracut arguments, then initramfs must be rebuild.

Modification in filesystem for a raw target does not affect dracut
arguments. So, we do not consider to check any modification if raw target
was specified in kdump.conf.

We might need to change dracut arguments if there is some changes in nfs
and ssh target related files. However, we do not consider them in this
patch.

We mainly consider changes in bulk target specified in kdump.conf. We also
consider changes in bulk and nfs file system, if there was no dump target
specified in kdump.conf but dump path is mounting such file systems.

So the initramfs must be rebuild if, either dump target's persistent path
or it's mount point or its file system type changes. If there is no dump
target specified then, both dump path and root path must mount same device,
otherwise rebuild should be triggered.

Some of the examples when we can need a rebuild:

-- "dump target" is specified as one of ext[234], xfs or btrfs. But after
kdump initramfs building its UUID is changed by reformatting.
-- "dump target" is specified as file system type fs1 (say ext3). But after
kdump initramfs building, user change it to fs2 (say ext4), probably by
a mkfs.ext4 executing on the target device.
-- "dump target" is not specified, but "dump path" mounts a device which
is different than device for root path and either UUID or file system type
is modified after kdump initramfs build.
-- "dump target" is not specified, but "dump path" mounts a nfs device and
nfs host path changes after kdump initramfs build.

Some testing:

Initial conditions:
-- No dump target specified
-- dump path (/var/crash) and root(/) are on same device
-- kdumpctl was already executed once after last modification in
/etc/kdump.conf

	# kdumpctl restart
		No rebuild
	# mkfs.ext2 /dev/md0;mount /dev/md0  /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# kdumpctl restart
		No rebuild
	# umount /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# kdumpctl restart
		No rebuild
	# mount /dev/md0  /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# umount /var/crash;mkfs.ext4 /dev/md0;
	# mount /dev/md0  /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"

	# umount /var/crash;mkfs.ext4 /dev/mapper/fedora-swap
	# mount /dev/mapper/fedora-swap  /var/crash/
	# kdumpctl restart
		Rebuilt because "Detected change in File System"
	# umount /var/crash;mkfs.btrfs /dev/mapper/fedora-swap -f
	# mount /dev/mapper/fedora-swap  /var/crash/
	# kdumpctl restart
		Rebuilt because "Detected change in File System"
	# kdumpctl restart
		No rebuild
	# umount /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# mount /dev/mapper/fedora-swap  /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"

	# umount /var/crash;mkfs.minix /dev/md0
	# mount /dev/md0  /var/crash/; kdumpctl restart
		Rebuilt because "Detected change in File System"
	# kdumpctl restart
		No rebuild
	# umount /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"

	# mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# umount /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# mount 192.168.1.16:/nfsroot /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"
	# kdumpctl restart
		No rebuild
	# umount /var/crash;mount 192.168.1.12:/nfsroot /var/crash/
	# kdumpctl restart
		Rebuilt because "Detected change in File System"
	# umount /var/crash/;kdumpctl restart
		Rebuilt because "Detected change in File System"

Added "raw /dev/md0" in /etc/kdump.conf
	# kdumpctl restart
		Rebuilt because "Detected change in /etc/kdump.conf"
	# mkfs.ext4 /dev/md0 ;kdumpctl restart
		No rebuild

Added "ext4 /dev/md0" in /etc/kdump.conf
	# mkfs.ext4 /dev/md0;mount /dev/md0 /mnt
	# mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart
		Rebuilt because "Detected change in /etc/kdump.conf"
	# umount /mnt;mkfs.ext4 /dev/md0;mount /dev/md0 /mnt
	# mkdir /mnt/var;mkdir /mnt/var/crash; kdumpctl restart
		Rebuilt because "Detected change in /etc/kdump.conf"

Most of the credits for this patch goes to Xunlei Pang <xpang@redhat.com>
for suggesting several improvements.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-05-12 09:54:17 +08:00
Pratyush Anand
28e8c4b5ac kdumpctl: Move file modification check logic in check_system_modified()
Relevant kdump files are also part of system. Therefore, moving logic of
file modification checking in check_system_modified() function now.

No functional changes.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-05-12 09:53:24 +08:00
Pratyush Anand
e4143381b1 kdumpctl: force rebuild in case of dynamic system modification
There could be some dynamic system modification, which may affect kdump
kernel boot process. In such situation initramfs must be rebuilt on the
basis of changes.
Since most of these checking methods will use information from
TARGET_INITRD, therefore check its existence in common code.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Baoquan He <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-05-12 09:53:04 +08:00
Pratyush Anand
8d44a2853d kdumpctl: Do not rebuild initramfs when $KDUMP_BOOTDIR is read only
When $KDUMP_BOOTDIR is RO then kexec-tools should not try rebuild initramfs
even when conditions for rebuild is met.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2016-05-11 14:35:20 +08:00
Dangyi Liu
3ec336c06c kdump.sysconfig: add KDUMP_COMMANDLINE_REMOVE
Use KDUMP_COMMANDLINE_REMOVE config instead of hardcode them in
kdumpctl, which makes it possible system admins decide what params to
remove such as "quiet" or other debug flags.

This patch also adds backward compatibility even if an old config is
used. It will behave the same as the old version.

Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2015-12-11 15:16:35 +08:00
Dangyi Liu
088c2b2a14 kdumpctl: Remove slub_debug from cmdline
slub_debug parameter enables debug for slub, making each object take
more memory than normal. During a typical kdump, "slub_debug=FZPU" will
cost about 33MB additional memory. If users really want to enable this
parameter, they should specify it in KDUMP_COMMANDLINE_APPEND.

Signed-off-by: Dangyi Liu <dliu@redhat.com>
2015-08-24 10:04:52 +08:00
Qiao Zhao
daccbbe3af Enhance kdump.conf "default" parameters check.
According to man page, default option can only use reboot, halt, poweroff,
shell and dump_to_rootfs as parameter.
Currently, if configuration kdump.conf is:
------
path /var/crash
core_collector makedumpfile -nosuchfile
default no_such_option
------
kdump service still can be started.

Adding function "check_default_config" to kdumpctl file can solve
this problem.

I have tested this patch in my test machine(Fedora-21).

v1 --> v2
Baoquan He point "check_default_config" function should be call in
"check_config" function.
Wang Li point if kdump.conf donesn't configure the "default" option,
kdump serivce will fail.

Signed-off-by: Qiao Zhao <qzhao@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2015-07-07 16:11:19 +08:00
Minfei Huang
4a468829e7 kdump-lib: Add new function to judge the system is Atomic or not
For Atomic system, the cmdline will contain the specific string
"ostree". So we can filter out the "ostree" to judge the system is
Atomic or not.

Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
2015-04-21 10:57:28 +08:00
Baoquan He
cad991814e kdumpctl: adjust the boot dir if kernel is put in sub dir of /boot
Previously /boot is asumed as the default dir where kernel and initrd
is put. However, the directory containing the running kernel image
on Atomic systems differs in each installation. Usually something like:

/boot/ostree/rhel-atomic-host-b50a015b637c353dc6554c851f8a1212b60d6121a7316715e4a63e2a4113cd72

This means that kdump will not find vmlinuz when installed on an
Atomic host, and thus the kdump service will fail to start.

In this patch, the kdump boot dir finding behaviour is a little changed.
Firstly check whether user has specify a directory explicitly in
/etc/sysconfig/kdump. If yes that is respected. Otherwise we assume
1st kernel and kdump kernel are put in the same place under /boot.
Then find it according /proc/cmdline and append it to /boot/

Note:
So now the KDUMP_BOOTDIR in /etc/sysconfig/kdump is set as empty
by default. If user set KDUMP_BOOTDIR to a directory, then he need to
take care of all related things himself. otherwise kdump script handle
it automatically.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
2015-01-30 14:53:34 +08:00
Jerry Hoemann
d2f87357e8 Rebuild initrd dependency during kdump restart
kdumpctl now parses mount points in determining the partition to
save the dump to.  So /etc/fstab can be considered a configuration
file for kdump.

Change adds an additional depenedency check on /etc/fstab when
kdump is restarted.

Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2015-01-13 12:34:01 +08:00
Prarit Bhargava
7d8be97b64 kdump, remove panic_on_warn from 2nd kernel cmdline
With the inclusion of 'panic_on_warn',

     http://marc.info/?l=linux-api&m=141570937328528&w=2

and which is now staged in Andrew Morton's tree, we need to remove
'panic_on_warn' from the 2nd kernel's cmdline.  If it is included it is
possible a non-fatal warning could panic the second kernel.

Before:

[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+
root=/dev/mapper/rhel_intel--canoepass--05-root ro
rd.lvm.lv=rhel_intel-canoepass-05/root
rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81
LANG=en_US.UTF-8 systemd.debug panic_on_warn=1 irqpoll nr_cpus=1
reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2
panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0
elfcorehdr=839092K

After:

[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0+
root=/dev/mapper/rhel_intel--canoepass--05-root ro
rd.lvm.lv=rhel_intel-canoepass-05/root
rd.lvm.lv=rhel_intel-canoepass-05/swap console=ttyS0,115200n81
LANG=en_US.UTF-8 systemd.debug irqpoll nr_cpus=1 reset_devices
cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10
rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0
elfcorehdr=839092K

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-12-17 15:56:05 +08:00
Vivek Goyal
38329992fe kdumpctl: Use kexec file based syscall for secureboot enabled machines
Now kexec file based syscall can be used with secureboot enabled machines.
Automatically switch to using new syscall if secureboot is enabled on the
machine.

Also remove the old message where kdump service failed if secureboot is
enabled. That's not the case anymore.

v2:
  Renamed "secureboot" to "Secure Boot" in user visible message.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
2014-09-10 10:45:46 +08:00
Vivek Goyal
d301d5e542 kdumpctl: Use kexec file based mode to unload kdump kernel
Currently old kexec syscall denies unloading a kernel if secureboot is enabled.
I think this is not right behavior and should be changed. But for now, use
new syscall if secureboot is enabled and that allows unloading kernel.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
2014-09-10 10:45:41 +08:00
Vivek Goyal
7041917dbd kdumpctl: Do not redirect error messages to /dev/null
Does anybody know why are we redirecting stderr to /dev/null when using
kexec load/unload commands? This sounds wrong to me. In case of error I
have no idea what went wrong.

Systemctl already puts all the information in journal. So if we are worried
that user will be bombarded with error messages, that should not be a concern.

So do not redirect stderr to /dev/null.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
2014-09-10 10:45:37 +08:00
WANG Chao
83d14e0f39 kdumpctl, fadump: only use lsinitrd when initramfs exists in fadump mode
When there's no kdump initramfs for lsinitrd to inspect with, there will
be an error:

  # kdumpctl start
  /boot/initramfs-3.16.0-rc7+kdump.img does not exist

  Usage: lsinitrd [options] [<initramfs file> [<filename> [<filename> [...] ]]]
  Usage: lsinitrd [options] -k <kernel version>

  -h, --help                  print a help message and exit.
  -s, --size                  sort the contents of the initramfs by size.
  -m, --mod                   list modules.
  -f, --file <filename>       print the contents of <filename>.
  -k, --kver <kernel version> inspect the initramfs of <kernel version>.

No kdump initial ramdisk found.
Rebuilding /boot/initramfs-3.16.0-rc7+kdump.img
[..]

In addition, lsinitrd is a slow operation. We only run it when it's
fadump mode, to speed up in kdump mode.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-08-06 12:02:59 +08:00
Hari Bathini
adb585a336 kdumpctl: fix error handling in fadump case
In fadump, in case of failure while rebuilding initrd, the error status
is not handled properly. See code snippet below:

    $MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver \
            -i /tmp/fadump.initramfs /etc/fadump.initramfs
    rm -f /tmp/fadump.initramfs
    if [ $? != 0 ]; then
        echo "mkdumprd: failed to rebuild initrd with fadump support" >&2
        return 1
    fi

This patch fixes this issue

Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-08-05 13:53:24 +08:00
Hari Bathini
78589a3207 kdump: Check whether or not to invoke capturing vmcore
The script dracut-kdump.sh is  responsible for capturing vmcore during
second kernel boot.  Currently this  script  gets installed into kdump
initrd as part of kdumpbase dracut module.

With fadump support, 'dracut-kdump.sh' script also gets installed into
default initrd to capture  vmcore generated by firmware assisted dump.
Thus in fadump case, the  same initrd is  going to be used for  normal
boot as well as boot after system crash. Hence a  check is required to
see if it is a normal boot or boot after crash.

A new node "ibm,kernel-dump" is added, to the device tree, by firmware
to notify kernel if it is booting after crash.  The below patch adds a
check for this node  before executing  steps to  capture vmcore.  This
check will help bypassing  the vmcore capture steps during normal boot
process.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-28 13:03:48 +08:00
Hari Bathini
5bb5be045c kdump: Rebuild default initrd for firmware assisted dump
The current kdump infrastructure builds a separate initrd which then
gets loaded into memory by kexec-tools for use by  kdump kernel. But
firmware  assisted dump (FADUMP) does not  use kexec-based approach.
After crash, firmware reboots  the  partition and  loads grub loader
like the normal  booting process does. Hence in the FADUMP approach,
the second kernel  (after crash) will always  use the default initrd
(OS built). So, to support FADUMP, change is required,  as in to add
dump capturing steps, in this initrd.

The  current kdumpctl script implementation  already has the code to
build initrd  using mkdumprd. This patch  uses  the new  '--rebuild'
option introduced, in  dracut, to incrementally build  the initramfs
image. Before rebuilding, we may need to  probe the initrd image for
fadump support, to avoid  rebuilding the initrd image multiple times
unnecessarily. This can be done using "lsinitrd" tool with the newly
proposed '--mod' option  & inspecting the presence of "kdumpbase" in
the list of modules of default initrd image. We rebuild the image if
only "kdumpbase" module is missing in the initrd image. Also, before
rebuilding, a backup of default initrd image is taken.

Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree
kdump  module for  dracut,  which is responsible for  adding  vmcore
capture  steps into initrd,  if dracut is  invoked  with  "IN_KDUMP"
environment variable set to 1.  mkdumprd script exports "IN_KDUMP=1"
environment variable before  invoking  dracut to build kdump initrd.
This patch relies on this current mechanism of kdump init script.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-28 13:03:44 +08:00
Hari Bathini
9f7b8b03b4 kdump: Modify kdump script to stop firmware assisted dump
During service kdump stop, if firmware assisted dump is enabled
and running,  then stop firmware assisted dump by echo'ing 0 to
'/sys/kernel/fadump_registered' file.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-28 13:03:41 +08:00
Hari Bathini
734790aa75 kdump: Modify kdump script to start the firmware assisted dump.
During service kdump start, if firmware assisted dump is not enabled then
fallback to starting of existing kexec based kdump.  If firmware assisted
is enabled but not running, then start firmware assisted dump by echo'ing
1 to '/sys/kernel/fadump_registered' file.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-28 13:03:38 +08:00
Hari Bathini
e0e70085e1 kdump: Modify status routine to check for firmware-assisted dump
This patch enables kdump script to  check if firmware-assisted dump is
enabled or not by reading value from '/sys/kernel/fadump_enabled'. The
determine_dump_mode() routine sets dump_mode to 'fadump', if fadump is
enabled. By default, dump_mode is set to 'kdump' mode.

Modify status routine to check if firmware assisted dump is registered
or not by  reading value from '/sys/kernel/fadump_registered' file. If
it is set to '1' then return status=0 else return status=1.

    0  <= Firmware assisted is enabled and running
    1  <= Firmware assisted is enabled but not running

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-28 13:02:28 +08:00
Hari Bathini
69986be99d cleanup: Remove "function" keyword from all functions and correct typos
This cleanup patch removes unnecessary keyword "function" at all places in
kdumpctl script. Also, corrects couple of typos in the script.

Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-21 17:47:21 +08:00
WANG Chao
463742ad95 kdumpctl: display message while waiting for the single instance lock
Vivek suggested we should display message while waiting for the lock,
because the waiting could be long and user will have no idea what's
going on.

So we will repeat the following message every 5 seconds while waiting:

"Another app is currently holding the kdump lock; waiting for it to exit..."

Thanks Vivek for providing a more comprehensive message.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-07-18 13:31:54 +08:00
Martin Perina
2066e5f792 Add fence_kdump support for generic clusters
Adds two new options to kdump.conf to be able to configure fence_kdump
support for generic clusters:

  fence_kdump_args <arg(s)>
    - Command line arguments for fence_kdump_send (it can contain all
      valid arguments except hosts to send notification to)

  fence_kdump_nodes <node(s)>
    - List of cluster node(s) separated by space to send fence_kdump
      notification to (this option is mandatory to enable fence_kdump)

Generic clusters fence_kdump configuration take precedence over older
method of fence_kdump configuration for Pacemaker clusters. It means
that if fence_kdump is configured using above options in kdump.conf, old
Pacemaker configuration is not used even if it exists.

Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-04-03 14:43:06 +08:00
Martin Perina
3e6e353bf7 Rename check_fence_kdump to check_pcs_fence_kdump
Renames check_fence_kdump to check_pcs_fence_kdump to clearly identify
that this method checks only Pacemaker configuration of fence_kdump.

Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-04-03 14:43:01 +08:00
Martin Perina
98f58cdc56 Rename is_fence_kdump to is_pcs_fence_kdump
Renames is_fence_kdump to is_pcs_fence_kdump to identify that this
method should be used to detect fence_kdump configuration only in
Pacemaker clusters.

Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-04-03 14:42:57 +08:00
Martin Perina
98d4be908a Rename FENCE_KDUMP_CONFIG to FENCE_KDUMP_CONFIG_FILE
Renames FENCE_KDUMP_CONFIG variable to FENCE_KDUMP_CONFIG_FILE to
distinguish it from values read from fence_kdump_args option in
kdump.conf (introduced in following patches).

Bug-Url: https://bugzilla.redhat.com/1078134
Signed-off-by: Martin Perina <mperina@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-04-03 14:42:13 +08:00
Jerry Hoemann
428a5e99ee kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel
== Version 2 ==

Addresses Vivek's review comments:

1. Don't force numeric in awk script snipet.

2. Command line processing is moved from load_kernel to new function
   "prepare_cmdline."   This new function is responsible for
   setting up the command line passed to KEXEC.

3. New function "append_cmdline" is added to append {argument,value}
   pair to command line if argument is not already present.

== Version 1 ==

A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple
processors in the crash kernel.

To do this safely the crash kernel needs to know which CPU was the 1st
kernel BSP (bootstrap processor) so that the crash kernel will NOT send
the BSP an INIT.  If the crash kernel sends an INIT to the 1st kernel
BSP, some systems may reset or hang.

The EFI spec doesn't require that any particular processor is chosen
as the BSP and the CPU (and its apic id) can change from one boot to
the next.  Hence automating the selection of CPU to disable if the
system would panic is desired.

This patch updates the kdumpctl script to get the "initial apicid"
of CPU 0 in the first kernel and will pass this as the
"disable_cpu_apicid=" arguement to kexec if it wasn't explicitly
set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND.

CPU 0 is chosen as it is the processor thats execute the OS
initialization
code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.)

See associated Red Hat Bugzilla(s) for additional background material:

        https://bugzilla.redhat.com/show_bug.cgi?id=1059031
        https://bugzilla.redhat.com/show_bug.cgi?id=980621

Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-28 14:55:16 +08:00
arthur
5dac95bbad remove the selinux filpping code in propagate_ssh_key
Description of problem:
Previously with selinux in enforcing mode, could prevent ssh-keygen from
generating keys. Support for selinux policy for allowing applications to
access ssh-keygen for generating ssh keys was added in
selinux-policy-3.7.19-126.el6_2.6.

Solutions:
Because of the context was added for ssh key generation, so the keys were
generated without fliping from enforcing mode to permissive mode for ssh
key generation. This patch removes selinux code which switches between
enforcing and permissive modes.

Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-19 12:58:52 +08:00
Dave Young
d802c3a1df kdumpctl: status function cleanup
Move the code to check /sys/kernel/kexec_crash_loaded to function
check_kdump_feasibility(). And rename status() to check_current_kdump_status()
so these two functions become clearer.

cleanup kdumpctl status path as well.

Tested with kernel without CONFIG_KEXEC
Tested with run kdumpctl start two times.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-17 12:50:02 +08:00
Dave Young
afff4dc8a3 kdumpctl: claim that kdump does not support secure boot when service start
Kdump does not support secure boot yet, so let's claim it is not supported
at the begginning of service start function.

In this patch for checking secure boot status I'm checking the efivars per
suggestion from pjones. see in code comments for the details.

Tested in Fedora 19 + qemu ovmf with secure boot enabled.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-02-17 12:50:00 +08:00
WANG Chao
590a0c21ab kdumpctl: rebuild kdump initramfs if cluster or fence_kdump config is changed.
If the system is configured fence kdump, we need to update kdump
initramfs if cluster or fence_kdump config is newer.

In RHEL7, cluster config is no longer keeping locally but stored
remotely. Fortunately we can use a pcs tool to retrieve the xml based
config and parse the last changed time from that.

/etc/sysconfig/fence_kdump is used to configure runtime arguments to
fence_kdump_send. So We have to pass the arguments to 2nd kernel.

When cluster config or /etc/sysconfig/fence_kdump is newer than local
kdump initramfs, we must rebuild initramfs to adapt changes in cluster.

For example:

Detected change(s) the following file(s):

  cluster-cib /etc/sysconfig/fence_kdump
Rebuilding /boot/initramfs-xxxkdump.img
[..]

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>
2014-01-29 16:20:06 +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
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
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
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
dyoung@redhat.com
aa15e6b6dc kdumpctl: add selinux relabel when service startup
Dracut root fs is always mounted, but it's not guaranteed to success
because we are in crash/kdump context. So selinux policy can not only
depends on chroot load_policy.

Per discussion with Vivek and Selinux people, relabel kdump files
when the service restart.

Currently only below cases are considerd:
1. target mounted in 1st kernel
2. target mounted as rw, if user mount it as 'ro' they will have to
   relabel the files by themselves.
3. save path is not masked, this means if /var/crash is mount to another
   disk which is different from dump target it will not visible to user
   so user need manually relabel them.
4. only local filesystem based targets.

Tested on F19 machine.
Tested local fs dump and network dump along with different save path
to address above mentioned cases.

Vivek: use function name is_dump_target_configured
       use getfattr -m "security.selinux" instead of ".*"
Daniel: use restorecon instead of chcon.
dyoung: keep minix in local fs list since it has not been deperacated yet.
Vivek: wrap is_dump_target_configured checking in function path_to_be_relabeled
dyoung: use awk instead of cut to print config value for different
        space delimeters
dyoung: mute df error message: `df $_mnt/$_path 2>/dev/null`

For nfs restorecon, since it will be in 3.11 kernel, we can add it when it's
ok in Fedora.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-06-13 11:28:25 +08:00
dyoung@redhat.com
fe96b47828 add dracut_args option to kdump.conf
mkdumprd call dracut to rebuilding kdump initrd, sometimes passing extra
dracut args is helpful. For example user can enable debug output with
--debug, --printsize to print roughly increased initramfs size by each module,
--omit-drivers to omit kernel modules, etc.

This patch enables dracut_args option for passing extra args to dracut.
Also it modifies add_dracut_arg() to treat a string with-in quote as single
string because for dracut options which has its own args, the args need to be
quoted and space seperated.

If add_dracut_arg() gets an string read from kdump.conf and if that string
contains double quotes, then while converting to positional parameters
those double quotes are not interpreted. Hence if /etc/kdump.conf contains
following.

dracut_args --add-drivers "driver1 driver2"

then add_dracut_args() sees following positional parameters

$1= --add-drivers
$2= "driver1
$3= driver2"

Notice, double quotes have been ignored and parameters have been broken
based on white space.

Modify add_dracut_arg() to look for parameters starting with " and
if one is found, it tries to merge all the next parameters till one
is found with ending double quote. Hence effectively simulating
following behavior.

$1= --add-drivers
$2= "driver1 driver2"

[v1->v2]: address quoted substring in dracut_args, also handle the leading
and ending spaces in substring.
[v2->v3]: fix dracut arguments seperator in kdump.conf.
[v3->v4]: improve changelog, thanks vivek.
[v4->v5]: make the manpage more verbose [vivek].

Tested with below dracut_args test cases:
1. dracut_args --add-drivers "pcspkr virtio_net" --omit-drivers "sdhci-pci hid-logitech-dj e1000"
2. dracut_args --add-drivers "   pcspkr virtio_net   " --omit-drivers "sdhci-pci hid-logitech-dj e1000"

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-04-27 10:44:48 +08:00
Dave Young
dc8e283ff5 Deprecate blacklist option
Current blacklist option is different from the option in rhel6. In current
implementation blacklist just means omit the driver, but it should really
be preventing it being loaded in initramfs.

To keep consistent, just make the option as deprecated. User is suggested
to user dracut kernel cmdline rd.driver.blacklist instead.

[v1->v2]: improve man page description, thanks Vivek.

Tested in kvm guest with rd.driver.blacklist in kdump sysconfig

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-04-02 10:26:39 +08:00