Commit Graph

1022 Commits

Author SHA1 Message Date
Kairui Song
3a36568581 Make udev reload rules quiet during bootup
In commit 1c97aee and commit 227c185 udev rules was rewritten to use
systemd-run to run in a non-blocking mode. The problem is that it's a
bit noise, especially on machine bootup, systemd will always generate
extra logs for service start, you might see your journal full of lines
like these if you have many CPUs (each CPU generates a udev event on
boot):

...
Nov 22 22:23:05 localhost systemd[1]: Started /usr/lib/udev/kdump-udev-throttler.
Nov 22 22:23:05 localhost systemd[1]: Started /usr/lib/udev/kdump-udev-throttler.
Nov 22 22:23:05 localhost systemd[1]: Started /usr/lib/udev/kdump-udev-throttler.
Nov 22 22:23:05 localhost systemd[1]: Started /usr/lib/udev/kdump-udev-throttler.
...

While system is still booting up, kdump service is not started yet, so
systemd-run calls will end up doing nothing, the throttler being called
by systemd-run will just exit if kdump is not loaded.

This patch avoid systemd-run from being called at first place if kdump
service is not running by checking kdump.service status in udev rule,
so there won't be unnecessary logs.

Also remove the kdump service checking logic in kdump-udev-throttler as
udev is the only expected callee of this script, if it's not being
called at first place when kdump service is running, this checking will
be redundant. And even if any user called this script manually, it will
still work well as this script will call 'kdumpctl reload', it reload
the kdump resource only if kdump is loaded already.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-12-06 17:44:03 +08:00
Kairui Song
a0dc92f46c dracut-module-setup: Fix routing failure on multipath route
Currently we still don't support multipath route, when parsing multipath
route kdumpctl will wrongly consider 'nexthop' as the destination address,
and raise errors in second kernel.

When multipath route is in use, ip route output should be like this:
$ /sbin/ip route show
default via 192.168.122.1 dev ens1 proto dhcp metric 100
192.168.122.0/24 dev ens1 proto kernel scope link src 192.168.122.161 metric 100
192.168.122.8
	nexthop via 192.168.122.1 dev ens1 weight 50
	nexthop via 192.168.122.2 dev ens1 weight 5

As we don't care about HA/performance, simply use the rule with highest
weight and ignore the rest.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
2018-11-27 18:12:52 +08:00
Kairui Song
d4f04afa47 mkdumprd: drop some nfs mount options when reading from kernel
nfs service will append extra mount options to kernel mount options.
Those extra options represent current mounting details, but they may
not suitable for the second kernel. IP address may change, and we only
enable a single network stack (v4/v6), if nfs prefered another
network stack, inheriting the options will force nfs service to use
previous network stack and disable nfs's fallback mechanic and fail.

As nfs service have the capability to negotiate required protocols
and detect proper IP address, just drop those options and let nfs
automatically adapt the possible change in the second kernel.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-11-24 17:48:49 +08:00
Bhupesh Sharma
31222d611d doc/kdump.conf: Local dump path should be <mnt>/<path>/%HOST_IP-%DATE
Resolves: bz1561837
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1561837

Currently 'kdump.conf' and 'kdump.conf MAN page' entries state that the
local dump path should be:

<fs type> <partition>
	- Will mount -t <fs type> <partition> <mnt>, and copy
	  /proc/vmcore to <mnt>/<path>/%DATE/.

The correct vmcore path instead should be:
<mnt>/<path>/%HOST_IP-%DATE/

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2018-11-15 11:18:30 +08:00
Markus Linnala
65807d9855 As /etc/kdump.conf timestamp is updated do not compare it when doing rpm --verify 2018-11-13 16:23:57 +02: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
435cc06cee Release 2.0.18-1
(Also add missing change log for 2.0.17-12)

Signed-off-by: Kairui Song <kasong@redhat.com>
2018-11-06 00:33:29 +08:00
Kairui Song
0c609b0a37 Release 2.0.17-12
Signed-off-by: Kairui Song <kasong@redhat.com>
2018-11-01 22:55:02 +08:00
Kairui Song
1c97aee728 Throttle kdump reload request triggered by udev event
Previously, kdump will restart / reload for many times on hotplug
event, especially memory hotplug events. Hotplugged memory may
generate many udev event as memory are managed and hotplugged in
small chunks by the kernel.

This results in unnecessary system workload and an actually longer
delay of kdump reload and the hotplug event, as udev will either
get blocked or kdumpctl will be waiting for other triggered operation.

To fix this, introduce a kdump-udev-throttler as an agent which will
be called by udev and merge concurrent kdump restart requests. Tested
with a Hyper-V VM which is failing due to udev timeout previously,
no new issues found.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-11-01 22:33:17 +08:00
Kairui Song
227c18506c Rewrite kdump's udev rules
According to udev's man page, PROGRAM is either used to determine
device's name or whether the device matches the rule. So we should
use RUN insteand. Meanwhile, both RUN / PROGRAM only accepts very
short-running foreground tasks, but kdump restart may take a long
time if there are any device changes that will lead to image rebuild,
which may lead to buggy behavior.

On the other hand, memory / CPU hot plug should never trigger a
initramfs rebuild.

To solve this problem, we will use new introduced "kdumpctl reload"
instead, and use systemd-run to create a transient service unit for
the reload and run it in no-block mode, so udev won't be blocked by
anything.

We need to make systemd-run execute in non-blocking mode, and do not
synchronously wait for the operation to finish, because udev expect
the command line in RUN to be finished immediately, however, kdumpctl
reload may take 0.5-1s for an ordinary reload, or even slower on some
machines. So we give systemd-run an explicit --no-block option to run
in non-blocking mode. Without --no-blocking, systemd-run will verify,
enqueue and wait for the operation to finish. By using the --no-block
option, systemd-run will only verify and enqueue the unit then
return. In this way, we make sure the command is executed
asynchronously, and the status will be monitored and logged by
systemd, which is reliable and non-blocking.

Another thing to mention is that --no-block is only needed after
systemd-v220, before v220 systemd-run uses non-blocking mode by
default and --no-block option is not available on earlier systemd
versions.

Also reformat the udev rules to a more maintanceable format.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-11-01 22:33:11 +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
Kairui Song
80357ee9b4 Release 2.0.17-11
Signed-off-by: Kairui Song <kasong@redhat.com>
2018-10-15 15:29:01 +08:00
Kairui Song
9b6e312447 Enable dracut squash module
In dracut-049, a new squash module is introduced, it can reduce the
memory usage of kdump initramfs in the capture kernel, this helps a lot
on lowering the risk of OOM failure.

Tested with latest rawhide with NFS, SSH and local dump.

Signed-off-by: Kairui Song <kasong@redhat.com>
2018-10-15 15:01:31 +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
ac55095191 kdump-lib-initramfs.sh: Add check to remount to rw mode only if dump target is ro.
Currently the script does not check if the dump target is read-only and would
always mount to read-write mode. This caused an issue with nfs mount as the
fstab options would be reconsidered while remounting to read-write mode.
The remount would fail with the below error as all options cannot be changed
runtime.

mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified

Which in result would not save the vmcore on the dump target.

This patch addresses this issue by checking the dump target status for read-only.
If yes, remount to read-write mode without reconsidering the fstab options.

Signed-off-by: Kenneth D'souza <kdsouza@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2018-10-15 10:46:44 +08:00
Kairui Song
67e5c8d226 Release 2.0.17-10
Signed-off-by: Kairui Song <kasong@redhat.com>
2018-08-22 16:31:18 +08:00
Bhupesh Sharma
00da17176d kexec: fix for "Unhandled rela relocation: R_X86_64_PLT32" error
Resolves: bz1619122
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1619122

This patch fixes the "Unhandled rela relocation: R_X86_64_PLT32" error
that we are seeing with Fedora 29 (and newer kernels > 4.18) which
trying to run kexec/kdump on x86_64 machines.

The patch is being discussed upstream and has been ACK'ed by Baoquan and
myself (see <https://www.spinics.net/lists/kexec/msg21255.html>) and I
have also tested the same on Fedora 29/rawhide x86_64 machine as well:

Before the patch:
----------------
[root@hp-bl480c-01 ~]# kdumpctl restart
  kexec: unloaded kdump kernel
  Stopping kdump: [OK]
  Unhandled rela relocation: R_X86_64_PLT32
  kexec: failed to load kdump kernel
  Starting kdump: [FAILED]

After the patch:
---------------
[root@hp-bl480c-01 ~]# kdumpctl restart
  kexec: unloaded kdump kernel
  Stopping kdump: [OK]
  kexec: loaded kdump kernel
  Starting kdump: [OK]

Suggested Upstream Fix:

    In response to a change in binutils, commit b21ebf2fb4c
    (x86: Treat R_X86_64_PLT32 as R_X86_64_PC32) was applied to
    the linux kernel during the 4.16 development cycle and has
    since been backported to earlier stable kernel series. The
    change results in the failure message in $SUBJECT when
    rebooting via kexec.

    Fix this by replicating the change in kexec.

    Signed-off-by: Chris Clayton <chris2553@googlemail.com>

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2018-08-22 15:48:43 +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
94a7b43407 Always drop nofail or nobootwait options
If nofail or nobootwait option is used, systemd's local-fs.target won't
wait for the mounting to complete, and kdump might start before the
required mount point is ready and then fail.

The host might use nofail for reasons like the device may get unpluged,
and if the device is not mounted and it is set as kdump target as the same
time then kdump service won't start, we will never enter the capture
kernel. By the time we have entered the capture kernel, the target device
must exist and ready to use, or else kdump would fail anyway. So force
remove nofail and nobootwait option.

Also drop rootflags=nofail option, as we don't depend on rootfs anymore
if the dump target don't required it. So the nofail option is no longer
needed.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-08-14 10:34:45 +08:00
Kairui Song
e9f3823082 Release 2.0.17-9 2018-08-07 17:35:38 +08:00
Kairui Song
f07d16814d Remove redundant kdump-anaconda-addon source codes
Signed-off-by: Kairui Song <kasong@redhat.com>
2018-08-07 17:28:12 +08:00
Kairui Song
f6770b30c3 dracut-module-setup: Fix DRM module inclusion test for hyper-v
We test if to include the drm module or not by testing if there are any
drm entry in sysfs. But there is an exception for hyper-v, DRM module
take care of hyperv's framebuffer driver as well but hyperv_fb will
not create any drm entry. So currently we got black screen on
hyperv guest.

Fix by detect hyperv's special entry as well.

Signed-off-by: Kairui Song <kasong@redhat.com>
2018-08-07 17:22:05 +08:00
Kairui Song
25b19d3627 Remove kdump-anaconda subpackage
Kdump anaconda has been included as a subpackage for a long time, which
is not a good practice, as the anaconda plugin should be built as
noarch and it does not belong to kexec-tools. We have created a new
package 'kdump-anaconda-addon', so remove it here.

The release version should be bumped later so that kdump-anaconda-addon
could mark previous versions as obsoleted.

Signed-off-by: Kairui Song <kasong@redhat.com>
2018-08-07 17:22:01 +08:00
Dave Young
3b8642c280 Release 2.0.17-8 2018-07-26 20:31:44 +08:00
Dave Young
9c7fea7ff7 Fix armv7hl build failure
armv7hl build failed because no makedumpfile* built but the latest commit
tries to install them.

Exclude armv7hl in the code chunk.

Signed-off-by: Dave Young <dyoung@redhat.com>
2018-07-26 20:19:08 +08:00
Dave Young
d319cbbb6d Release 2.0.17-7
Signed-off-by: Dave Young <dyoung@redhat.com>
2018-07-26 19:54:11 +08:00
Dave Young
3e065ac92e Remove koji build workaround patch since koji build works without the patch now
Signed-off-by: Dave Young <dyoung@redhat.com>
2018-07-26 19:51:25 +08:00
Bhupesh Sharma
bb6dd93d7a kexec-tools.spec: Drop kexec-tools-2.0.3-disable-kexec-test.patch
kexec_test seems to be no longer used upstream, so we had introduced
the 'kexec-tools-2.0.3-disable-kexec-test.patch' earlier to disable the
same from fedora kexec-tools as well.

However an earlier patch "Remove obsolete kdump tool" now explicitly
installs needed files via appropriate logic in .spec file, so we can
drop this patch now to reduce the maintenance burden.

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
2018-07-26 19:51:25 +08:00
Bhupesh Sharma
0b9095c11b Remove obsolete kdump tool
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441677
Testing: On x86_64 Fedora machine. After this patch kdump utility and related
        man page cannot be found on this machine:

        [root@tyan-gt24-09 ~]# which kdump
        /usr/bin/which: no kdump in
        (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

	[root@tyan-gt24-09 ~]# man kdump
        No manual entry for kdump

Update the fedora 'kexec-tools.spec' to not install the obsolete
kdump tool.

I have submitted an upstream patch to obsolete the kdump tool from
upstream kexec-tools (which has been accepted), but after an internal
discussion we decided not to backport the upstream 'kexec-tools' patch
(which does the same) for fedora, as we would prefer to manage the
changes directly in the .spec file itself.

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
2018-07-26 19:51:04 +08:00
Kairui Song
4eedcae5e1 dracut-module-setup.sh: don't include multipath-hostonly
This commit basically reverts commit c755499fad,
and make use of new introduced tri-state hostonly mode.

Following dracut commits merged multipath-hostonly into multipath
module, and introduced a tri-state hostonly mode.

    commit 35e86ac117acbfd699f371f163cdda9db0ebc047
    Author: Kairui Song <kasong@redhat.com>
    Date:   Thu Jul 5 16:20:04 2018 +0800

        Merge 90-multipath-hostonly and 90-multipath

    commit a695250ec7db21359689e50733c6581a8d211215
    Author: Kairui Song <kasong@redhat.com>
    Date:   Wed Jul 4 17:21:37 2018 +0800

        Introduce tri-state hostonly mode

multipath-hostonly module was introduced only for kdump, because kdump
need a more strict hostonly policy for multipath device to save memory.

Now multipath module will provide the behave we wanted by setting
hostonly mode to strict.
2018-07-26 19:25:09 +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
Fedora Release Engineering
3de202cfdb - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
Signed-off-by: Fedora Release Engineering <releng@fedoraproject.org>
2018-07-13 07:00:01 +00:00
Dave Young
5350d31f56 Release 2.0.17-5 2018-07-09 12:48:20 +08:00
Dave Young
9913d44d9e Update makedumpfile 1.6.4 2018-07-09 12:45:31 +08:00
Pingfan Liu
6832be14f2 dracut-module-setup.sh: pass ip=either6 param for ipv6
Kdump always use _proto=dhcp for both ipv4 and ipv6.  But for ipv6
the dhcp address assignment is not like ipv4, there are different ways
for it, stateless and stateful, see below document:
https://fedoraproject.org/wiki/IPv6Guide

In case stateless, kernel can do the address assignment, dracut use
_proto=auto6;  for stateful case, dracut use _proto=dhcp6.
But it is hard to decide whether stateless or stateful takes effect,
hence, dracut introduces ip=either6 option, which can try both of these
method automatically for us. For detail, refer to dracut:
commit 67354ee 40network: introduce ip=either6 option

We do not see bug reports before because for the most auto6 cases
kernel assign ip address before dhclient, kdump just happened to work.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2018-07-09 12:43:28 +08:00
Pingfan Liu
92db9cb9f2 dracut-module-setup.sh: install /etc/hosts when using fence_kdump
When using fence_kdump, module-setup will create a kdump.conf with
fence_kdump_nodes. The node name comes from the cluster xml, which may
use the hostname alias. Later in kdump stage, "fence_kdump_send alias_1
alias_2" sends out notification to peers. Hence it requires /etc/hosts
and nsswitch.conf to make alias work.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2018-07-09 12:43:19 +08:00
Dave Young
e4a27dde51 Resolves: bz1594827
Fix installation error for kdump anaconda addon.
2018-06-27 15:09:58 +08:00
Dave Young
0dad02e4bb Release 2.0.17-3 2018-05-30 10:50:36 +08:00
Lianbo Jiang
1704064885 Add early kdump support in initramfs.
Kdump service starts too late, so early crashes will have no chance
to get kdump kernel booting, this will cause crash information to be
lost. It is necessary to add a dracut module in order to load crash
kernel and initramfs as early as possible. You can provide "rd.early
kdump" in grub commandline to enable, then the early kdump will load
those files like the normal kdump, which is disabled by default.

For the normal kdump service, it can check whether the early kdump
has loaded the crash kernel and initramfs. It has no conflict with
the early kdump.

If you rebuild the new initramfs for early kdump, the new initramfs
size will become large, because it will put the vmlinuz and kdump
initramfs into the new initramfs.

In addition, early kdump doesn't support fadump.

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:19:19 +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
Dave Young
2884fed616 Revert "dracut-module-setup.sh: pass correct ip= param for ipv6"
This reverts commit 2f4149f276.

It is not proved to be right to get auto6 or dhcpv6 in 1st kernel,
pingfan is working on a dracut fix to do some fallback in 2nd kernel initramfs.
So revert this commit
2018-05-09 14:21:51 +08:00
Dave Young
a95fcea412 Release 2.0.17-2
Pull in makedumpfile 1.6.3
2018-04-28 14:41:25 +08:00
Dave Young
62999dab42 Add missing changelog in spec 2018-04-28 14:30:58 +08:00
Dave Young
6e25286a97 Release 2.0.17-1
Pull upstream 2.0.17
2018-04-26 13:19:12 +08:00
Dave Young
98cc66a34d Release 2.0.16-6 2018-04-08 17:03:04 +08:00
Pingfan Liu
c14ebf2676 kdump.sysconfig.ppc64(le): remove "root=" param from ppc64(le) 2nd kernel's command line
For ppc64(le), the default behavior of kexec always copy "root=" param,
but if dump target is ssh, there will no tools installed in kdump
rd, which help to mount root. As a result, kdump service will fail to
start. So explicitly disable the default behavior with --dt_no_old_root
option.

Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-03-22 16:15:08 +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