Commit Graph

1164 Commits

Author SHA1 Message Date
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
Pingfan Liu
c755499fad dracut-module-setup.sh: check whether to include multipath-hostonly or not
Due to the following commit in dracut, which splits out hostonly modules
commit 5ce7cc7337a4c769b223152c083914f2052aa348
Author: Harald Hoyer <harald@redhat.com>
Date:   Mon Jul 10 13:28:40 2017 +0200

    add 90multipath-hostonly module

    hardcoding the wwid of the drives in the initramfs causes problems
    when the drives are cloned to a system with the same hardware, but
    different disk wwid's

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

So kdump should decide whether to include the hostonly module.
The multipath-hostonly can help kdump to include only the needed mpath device,
in order to use less memory by 2nd kernel.

---- The performance -----
before this patch
[root@localhost ~]# time kdumpctl start
Detected change(s) in the following file(s):

  /etc/kdump.conf
Rebuilding /boot/initramfs-4.13.9-300.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]

real    0m12.485s
user    0m10.096s
sys     0m1.887s

after this patch

root@localhost ~]# time kdumpctl start
Detected change(s) in the following file(s):

  /etc/kdump.conf
Rebuilding /boot/initramfs-4.13.9-300.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]

real    0m15.839s
user    0m13.015s
sys     0m1.853s

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-11-24 13:58:28 +08:00
Dave Young
bdd2ac6b93 Release 2.0.16-1
Signed-off-by: Dave Young <dyoung@redhat.com>
2017-11-21 12:54:35 +08:00
Dave Young
d3577e3394 Revert "Use absolute path /usr/bin/dracut in mkdumprd"
This reverts commit 8e3b6475c9.

After reading the background of bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1510922

It is not a problem actually, sorry for the noise.

Although root set different "PATH" can lead to wrong script, but it is
different with what the bug described "current working dir" and it is
not a problem worth an update
2017-11-09 15:29:22 +08:00
Dave Young
a2d284eea8 Release 2.0.15-15 2017-11-09 13:46:34 +08:00
Dave Young
8e3b6475c9 Use absolute path /usr/bin/dracut in mkdumprd
Since we call dracut directly on current working directory "." so it is
possible to trick root to call fake code.

Thus move to use absolute path instead.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
2017-11-09 13:46:13 +08:00
Dave Young
823c962ff1 Release 2.0.15-14 2017-10-11 09:59:00 +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
Dave Young
4594c9830d Release 2.0.15-13 2017-09-06 15:48:35 +08:00
Ziyue Yang
c05c898062 dracut-module-setup.sh: eliminate redundant kdump_get_mac_addr call
This commit eliminates a redundant kdump_get_mac_addr call in
kdump_setup_netdev.

Signed-off-by: Ziyue Yang <ziyang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:42:40 +08:00
Dave Young
69ba16a409 mkdumprd: use --quiet dracut argument to speedup initramfs build
Currently in Fedora/RedHat dracut installs its fedora.conf.example
as the default config file, in which sysloglvl is set 5. This leads
to maxloglvl=5 in dracut calls, making unnecessary lsinitrd calls
during initramfs builds by kdump.

This patch makes use of
https://github.com/dracutdevs/dracut/pull/272
and disables lsinitrd logging by giving "-q" option to dracut,
eliminating unnecessary lsinitrd calls in dracut.

1) Before this patch
$ kdumpctl stop; touch /etc/kdump.conf; time kdumpctl start
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Detected change(s) in the following file(s):
  /etc/kdump.conf
Rebuilding /boot/initramfs-4.13.0-0.rc1.git4.1.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]
real    0m26.824s
user    0m9.958s
sys     0m15.106s

2) After this patch
$ kdumpctl stop; touch /etc/kdump.conf; time kdumpctl start
kexec: unloaded kdump kernel
Stopping kdump: [OK]
Detected change(s) in the following file(s):
  /etc/kdump.conf
Rebuilding /boot/initramfs-4.13.0-0.rc1.git4.1.fc27.x86_64kdump.img
kexec: loaded kdump kernel
Starting kdump: [OK]
real    0m20.420s
user    0m8.385s
sys     0m10.468s

[dyoung]:
- rewrite patch subject

Signed-off-by: Ziyue Yang <ziyang@redhat.com>
Reviewed-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:42:31 +08:00
Dave Young
75ab9ee26a mkdumprd: fix patterns to modify mount options
mkdumprd removes "noauto" mount option, but it also mistakenly removes
"noauto" within a string. For example ext4 has mount option noauto_da_alloc
mkdumprd will replace it with _da_alloc.

Use '\b' to match a whole word of "noauto" to fix it.
Also do same for s/ro/rw for same reason.

Signed-off-by: Dave Young <dyoung@redhat.com>
Reveiwed-by: Xunlei Pang <xlpang@redhat.com>
2017-09-06 15:42:24 +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
3172bc0ef3 module-setup: remove software iscsi cmdline generated by dracut
After adding "--hostonly-cmdline", besides 99kdump, 95iscsi
also generates iscsi related cmdline. IOW, we have duplicate
software iscsi cmdlines.

95iscsi generated software iscsi cmdline doesn't work, so we
remove that of 95iscsi and use that of 99kdump which has been
well tested.

We can change to use 95iscsi when possible in the future.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:41:48 +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
e067d77dfc mkdumprd: apply dracut "--hostonly-cmdline" and "--no-hostonly-default-device"
Dracut has "--hostonly-cmdline" which can generate cmdlines(if any)
regarding the dump target, it's an existing way for us to use to
simplify the code. E.g. We already removed generate_lvm_cmdlines(),
to use "--hostonly-cmdline".

But "--hostonly-cmdline" has other issues(e.g. BZ1451717), it adds
needless devices for kdump like root device.

Now dracut supports "--no-hostonly-default-device" which enables
us to only add the kdump target, which can avoid needless devices
being recognized under kdump. Thus "--hostonly-cmdline" side effects
can be avoided with the help of "--no-hostonly-default-device".

This patch applies dracut's "--hostonly-cmdline" together with
"--no-hostonly-default-device" to achieve above-mentioned purpose.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-09-06 15:40:04 +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
dcffd4759e Revert "mkdumprd: omit dracut modules in case of no dm target"
This reverts commit 821d1af080.

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:37:45 +08:00
Xunlei Pang
2c9128a971 Revert "mkdumprd: omit dracut modules in case of network dumping"
This reverts commit fb522e972c.

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:37:15 +08:00
Dave Young
c8ab07e72b Release 2.0.15-12
btw, fixed the bogus date in rpm spec changelog
2017-08-17 16:58:06 +08:00
Dave Young
4384995b3d makedumpfile: fix 4.13 kernel larget vmcore bug
Added patch from panand which was accepted by upstream but not merged in upstream yet.
kexec-tools-2.0.15-makedumpfile-fix-SECTION_MAP_MASK-for-kernel-bigger-than-4.13.patch
2017-08-17 16:50:23 +08:00
Dave Young
fcaa683b01 Revert "Improve 'cpu add' udev rules"
This reverts commit 65d37d19c7.
Since we have no such bugs in Fedora and original rule works fine thus revert it.
2017-08-17 16:42:11 +08:00
Dave Young
238f7d836c Release 2.0.15-11
[From ville.skytta@iki.fi]
- Own the /usr/share/makedumpfile dir
- Mark COPYING as %%license
2017-08-15 09:50:35 +08:00
Dave Young
0ffa712fab Release 2.0.15-10 2017-08-08 10:10:50 +08:00
Pratyush Anand
65d37d19c7 Improve 'cpu add' udev rules
Currently kdump service is restarted even when any new file is added in cpu
subsystem. So, it can be restarted multiple times in the cases like loading
of acpi_cpufreq module or online/offline of any cpu.

However, we should see kdump service restart only once in case a new CPU
is added or removed. cpu crash notes buffer is created when a new CPU is
added. It's location does not change when a CPU is onlined/offlined or
acpi_cpufreq driver is loaded. Therefore, no need to restart kdump
service in such cases.

Thus, we need to introduce an extra filter for the kernel name of the
directory created by cpu_add which is KERNEL=="cpu[0-9]*". This will ensure
that kdump service is not restarted when any new file is added in /removed
from cpu subsystem.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-08-08 10:10:35 +08:00
Xunlei Pang
38e6b41c0c module-setup: suppress the early iscsi error messages
Currently, we throw the error message at the very beginning, as
a result on a pure-hardware(all-offload) iscsi machine with many
iscsi partitions, we suffered from too much noise as follows:
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.1/host0/session1
  iscsiadm: No records found
  Unable to find iscsi record for
  /sys/devices/pci0000:00/0000:00:06.0/0000:07:00.0/0000:08:01.3/host1/session2
  kexec: loaded kdump kernel
  Starting kdump: [OK]

There's no need to know the very early error messages, we can
remove the error output which is actually normal for the pure
hardware iscsi.

As for unexpected errors, we kept the error outputs in the
succeeding kdump_iscsi_get_rec_val() calls by not appending
"2>/dev/null".

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-08-08 10:10:19 +08:00
Xunlei Pang
2777a93a9c mkdumprd: use 300s as the default systemd unit timeout for kdump mount
Currently, systemd uses 90s as the default mount unit timeout
(see "man 5 systemd-system.conf " for "DefaultTimeoutStartSec"),
in some cases, although it works well in 1st kernel, it's not
enough under kdump and results in mount timeout, further results
in kdump dumping failure.

We've met several such issues, we decided to enlarge this default
value a little for kdump.

We know that dracut has a default initqueue timeout value of 180s
("rd.retry"), we finalized a little larger value 300s as kdump's
default timeout if there is no explicit "DefaultTimeoutStartSec=X,
specified by users.

"DefaultTimeoutStartSec=X" can be overridden by individual mount
option "x-systemd.device-timeout=X", users can specify their own
values as needed.

This patch achieves the purpose by creating a dedicated conf file
"/etc/systemd/system.conf.d/kdump.conf" which has the content of
"DefaultTimeoutStartSec=300s", this is based on the fact that all
the conf files will be parsed by systemd and the last parsed one
will be used if there are duplicate definitions.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-08-08 10:10:03 +08:00
Dave Young
00ceca7f99 Release 2.0.15-9
https://bugzilla.redhat.com/show_bug.cgi?id=1474706

Makedumpfile failed with below error messages, which is caused by kernel changes 65ade2f872b474fa8a04c2d397783350326634e6:

Buffer size for the cyclic mode: 95992
vtop4_x86_64: Can't get the symbol of init_level4_pgt.
readmem: Can't convert a virtual address(ffffffff8fe18284) to physical address.
readmem: type_addr: 0, addr:ffffffff8fe18284, size:390
check_release: Can't get the address of system_utsname.

Pull in Pratyush's fix in upstream makedumpfile (not merged yet but acked by
maintainer)

Signed-off-by: Dave Young <dyoung@redhat.com>
2017-08-07 09:44:42 +08:00
Fedora Release Engineering
1ad0c239a5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild 2017-08-03 00:20:54 +00:00
Florian Weimer
610f08562d Rebuild with fixed binutils for ppc64le (#1475636) 2017-07-30 18:12:58 +02:00
Dave Young
d968a68263 Release 2.0.15-6
Update makedumpfile to upstream 1.6.2

Signed-off-by: Dave Young <dyoung@redhat.com>
2017-07-28 14:42:15 +08:00
Fedora Release Engineering
ee882b26b7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild 2017-07-26 15:08:54 +00:00
Dave Young
06b35b224d Release 2.0.15-4 2017-07-19 09:56:07 +08:00
Xunlei Pang
8fd9f017b2 mkdumprd: remove useless "x-initrd.mount"
After the following systemd commit, "x-initrd.mount"
option became useless actually, we can safely remove
it now.

commit ce3f6d82b003f365f718f24e48f55b8a0372b924
Author: nmartensen <nis.martensen@web.de>
Date:   Fri Jan 15 07:55:25 2016 +0100

    fstab-generator: remove bogus condition

    The sysroot mount is already taken care of by the
    add_sysroot_mount function. With this condition
    left in, we can we can get something like this:

    initrd-root-fs.target.requires
    `-- usr.mount -> /run/systemd/generator/usr.mount

    in the main system (i.e., not in the initramfs). In
    the initramfs, the previous condition already kicks in.

[snip]

"mount_in_initrd(me)" is true with "x-initrd.mount" option,
the behaviour of systemd fstab generator changed after the
above-mentioned patch, it always generates local mount units
required by local-fs.target regardless of "x-initrd.mount".

After failure, it enters dracut emergency, further triggers
kdump emergency service, thus there is no problem.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-19 09:51:12 +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
Dave Young
06c776f36b Release 2.0.15-3 2017-07-14 16:07:11 +08:00
Xunlei Pang
a431a7e354 module-setup: fix 99kdumpbase network dependency
I noticed that network is still enabled for local dumping,
like the following kdump boot message on my test machine
using local disk as the dump target:
  tg3.c:v3.137 (May 11, 2014)
  tg3 0000:02:00.0 eth2: Tigon3 [partno(BCM95720) rev
  (PCI Express) MAC address c8:1f:66:c9:35:0d
  tg3 0000:02:00.0 eth2: attached PHY is 5720C

After some debugging, found it due to a misuse in code below:
  if [ is_generic_fence_kdump -o is_pcs_fence_kdump ]; then
      _dep="$_dep network"
  fi
The "if" condition always results in "true", and should be
changed as follows:
  if is_generic_fence_kdump -o is_pcs_fence_kdump; then
      _dep="$_dep network"
  fi

After this, network won't be involved in non-network dumping,
as for dumpings require network such as nfs/ssh/iscsi/fcoe/etc,
dracut will add network accordingly. And kdump initramfs size
can be reduced from 24MB to 17MB tested on some real hardware,
and from 19MB to 14MB on my kvm. Moreover, it could avoid the
network (driver) initialization thereby saving us more memory.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:59 +08:00
Xunlei Pang
fb522e972c mkdumprd: omit dracut modules in case of network dumping
In case of only network target, we can clearly and safely
remove more unnecessary modules to reduce initramfs size,
and to enhance stability.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:48 +08:00
Xunlei Pang
821d1af080 mkdumprd: omit dracut modules in case of no dm target
In case of on dm related target, we can clearly and safely
remove many unnecessary modules to reduce initramfs size,
and to enhance stability.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:40 +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
9e7b64dc90 mkdumprd: change for_each_block_target() to use get_kdump_targets()
Resolves: bz1451717
https://bugzilla.redhat.com/1451717

Now that we have get_kdump_targets(), use it to simplify the code.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-07-14 14:54:15 +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
Dave Young
151e0b5345 Release 2.0.15-2 2017-06-28 14:36:01 +08:00
Pratyush Anand
7845cdd89c aarch64: Add makedumpfile executable
Add makedumpfile executable for aarch64 as well.

Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-06-28 14:35:42 +08:00