User complains that kdump_post script doesn't execute after mount
failed. This happened since mount failure will trigger
kdump-error-handler.service, and then start kdump-error-handler.sh.
However in kdump-error-handler.sh it doesn't execute kdump_post.
Hence add it in this patch.
Surely the function do_kdump_post need be moved into kdump-lib-initramfs.sh
to be a common function.
v1->v2:
Add a return value to do_kdump_post when invoked in kdump_error-handler.sh.
And call do_kdump_post earlier than do_default_action, otherwise
it may not execute if reboot/poweroff/halt.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Meifei Huang <mhuang@redhat.com>
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>
Steve found a bug. When mount a disk in /var and not specify path
in /etc/kdump.conf, the vmcore will be dumped into /var/crash of
that disk, but not /crash on that disk.
This is because when write the parsed path into /tmp/$$-kdump.conf
in default_dump_target_install_conf() of mkdumprd, it uses below
sed command. So if no path specified at all, this sed command won't
add it to /tmp/$$-kdump.conf. Then in 2nd kernel it will take default
path, namely "/var/crash" as path if no path in /etc/kdump.conf in
2nd kernel.
sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf
According to Dave Young's suggestion, erase the old path line and then
insert the parsed path. This can fix it.
v2->v3:
erase the old path line and then insert the parsed path.
sed -i -e "s#^path[[:space:]]\+$_save_path##" /tmp/$$-kdump.conf
echo "path $_path" >> /tmp/$$-kdump.conf
v3->v4:
Change the sed pattern, erase lines starting with "path" and then
insert the parsed path.
sed -i -e "s#^path.*##" /tmp/$$-kdump.conf
echo "path $_path" >> /tmp/$$-kdump.conf
v4->v5:
Chaowang suggested using sed command d to remove the whole line
like below:
sed -i "/^path/d" /tmp/$$-kdump.conf
echo "path $_path" >> /tmp/$$-kdump.conf
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Chao pointed out that it's better to use get_option_value to get
get a specific config_val.
And also there's a potential risk when use below sed command to
do the replacement.
sed -i -e "s#$_save_path#$_path#" /tmp/$$-kdump.conf
Say user configure kdump.conf like the following. Then sed may
replace "/var/crash/post.sh" with something else, depanding on
mount point.
kdump_post /var/crash/post.sh
path /var/crash
So in this patch clean them up.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
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>
Jerry Hoemann reported a bug that a mount will fail when he installed
a system with separate "/" "/var" and "/var/crash". That means root
disk /dev/a mounted on /, and another disk /dev/b is mounted on /var,
then the 3rd disk /dev/c mounted on /var/crash. Then kdump will fail
since mount will fail.
This is because the mount information will be written into
/$mntimage/etc/fstab like below. And the dump target is /dev/c. However
/dev/b is not related in kdump, its mount info is not necessary and not
saved. So when go into kdump kernel, it will find there's not a crash
dir under /sysroot/var. And in current implementation, if not a root
disk dump, sysroot is a read-only mount, no dir can be created in this
situation.
/dev/disk/by-uuid/cdcf007a-b623-45ee-8d73-a8be0d372440 /sysroot/var/crash xfs rw,relatime,...,x-initrd.mount 0 2
So in this patch, change the mount behavior to fix this bug. If dump
target is a root disk, mount point is /sysroot. If dump target is not
root, just mount it to /kdumproot/$_target. Now it works.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Tested-by: Jerry Hoemann <jerry.hoemann@hp.com>
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>
Certain kernel parameters like min_free_kbytes can be configured at runtime
using sysctl. While this is useful in first kernel, it can lead to unnecessary
failures like OOM in kdump kernel. This patch enforces default vaules for all
sysctl parameters, in kdump kernel, by removing sysctl.conf & sysctl.d/* files.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Once login using ssh, the ssh will store the known hosts entry to the
local ~/.ssh/known_hosts. From now, we can login using ssh automaticly.
The ssh will check the ~/ssh/.known_hosts entry, if set the option
StrictHostKeyChecking=yes/ask in the config or command line, when you
want to login the target. the default value of StrictHostKeyChecking is
ask.
And the kdump using the ssh will append the option
StrictHostKeyChecking=yes in the command line.
We can using following ip to connect peer machine, if enable the ipv6.
fe80::5054:ff:fe48:ca80%eth0
Obviously, above ip contains the ethX.
Kdump will add the prefix "kdump-" before ethX to avoid flowing
netdevice name in case netdevice names ethX in the 2nd kernel. So the
ip address will change to fe80::5054:ff:fe48:ca80%kdump-eth0.
Kdump will login the target manully in the 2nd kernel, because of the
option StrictHostKeyChecking=yes and inexistence known hosts entry
in the local ~/.ssh/known_hosts. Hence dumping core will fail.
In order to login automaticly using ssh, we should add the prefix
"kdump-" before ethX in the local ~/.ssh/known_hosts.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
For ethX, it may fail to setup the network in the 2nd kernel due to the
mapping of ethernet device name and MAC changes.
The commit(ba7660f37e) has fixed this
issue by add the prefix "kdump-" before ethX. But the network will fail
to work in the static route mode because of this commit.
Here is the config which is used to setup the static route:
rd.route=192.168.201.215:192.168.200.137:eth1
Obviously, the static route config comtains the ethX. But the network
device names kdump-ethX in the 2nd kernel, so the static route config
will fail to execute. To fix it, we should identify the network device.
Add the prefix "kdump-" before the ethX in the static route config to
setup it successfully in the 2nd kernel.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
It is boring that internal result is shown in the terminal. Do not print
anything to standard output by using the command "grep -q".
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
In ssh or raw dump case, if user do not specify "core_collector" in
kdump.conf, kdump will fail. Because global DEFAULT_CORE_COLLECTOR
variable isn't applied to CORE_COLLECTOR. Now fix it and clean up the
duplicate code in kdump.sh.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
I forgot to add kdump.sysconfig.ppc64le to "Source" directive to
kexec-tools.spec. And on ppc64le, the default kdump.sysconfig will be
installed to /etc/sysconfig/kdump. Now fix it.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
get_option_value() is used to get the value of $1 configured in
/etc/kdump.conf. But when we use "get_option_value ssh", it can get the
value of "sshkey" instead of "ssh".
Fix the regexp pattern to get an exact match.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Previously for solving static route issues, all routes which go
through a specific dev will be saved in 1st kernel, and then added
in 2nd kernel. Because we use below search pattern, an exception
will happen:
/sbin/ip route show | grep -v default | grep "^[[:digit:]].*via.* $_netdev"
That exception is a corner case which happened when 2 machines connected
directly by cable and the 2 network interfaces are configured in
different network subnets. E.g there are 2 machines A and B:
A:ens10 < ------ > B:ens9
A:ens10 inet 192.168.100.111/24 scope global ens10
route need be added in A:
192.168.110.0/24 dev ens10
B:ens9 inet 192.168.110.222/24 scope global ens9
route need be added in B
192.168.100.0/24 dev ens9
Now if A want to dump to B, the route "192.168.110.0/24 dev ens10"
has to be saved and added in 2nd kernel.
So in this patch "ip route get to $target" command is executed, then
an exact route can be got for going to that target. By this, static
route works and the corner case can be fixed too.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Marc Milgram <mmilgram@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
With fadump support, dracut-kdump.sh script is installed into default
initrd to capture vmcore generated by firmware assisted dump. Thus in
fadump case, the same initrd is being used for normal boot as well as
boot after system crash. Hence a device node, added by firmware while
system crashes, is checked to identify if it is a normal boot or boot
after crash to determine whether or not capture vmcore. While testing
fadump in fedora21 alpha, observed that vmcore capture is initiated
even during normal boot, inspite of this check, with the below error:
"kdump.sh[451]: /bin/kdump.sh: line 5: return: can only `return'
from a function or sourced script"
The below patch tries to fix this issue.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Remove this package and put eppic_makedumpfile.so and its sample
scripts in kexec-tools package.
makedumpfile does dlopen() on eppic_makedumpfile.so and that does not
enforce any choice. One could either ship it in kexec-tools package or
in a subpackage. Both will work.
The real reason was that code for eppic_makedumpfile.so
(extension_eppic.c) and some eppic scripts are in upstream makedumpfile
project. And that project is distributed as part of kexec-tools package.
Now breaking down that makedumpfile in two parts and shipping all
eppic specific bits in a separate subpackage was creating confusion
everytime we did some changes.
So to avoid that confusion and to keep all of the makedumpfile related
bits in a single package, this change is being done.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
By default on powerpc platform, kvm will reserve a relatively large CMA
(128M aligned) at early boot. In kdump kernel, even KVM sounds useless
but still it reserves 128M and makes kdump kernel fail to boot.
Now fix this by adding the following to kernel command line:
"kvm_cma_resv_ratio=0"
which disable the CMA reservation.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
In case of iscsi boot, kernel cmdline will contain ip=xxx kernel
parameter for dracut setting up iscsi root in initramfs. For example:
"root=xxx ip=192.168.3.26:::255.255.255.0:localhost.localdomain:eno19:none ..."
dracut doesn't allow duplicate ip conf for the same network card. dracut
will not ignore the either of the duplicate. Instead, it refuses to
continue:
[ 15.876306] dracut: FATAL: For argument 'ip=192.168.3.26:::255.255.255.0:localhost.localdomain:eno19:none'\n
Duplication configurations for 'eno19'
[ 16.055513] dracut: Refusing to continue ev argument for multiple ip= lines
That's why in our code we don't add a duplicate ip conf when handling
the same network card the second time. But we never consider the case
that ip conf is already added in kernel cmdline for some special
purpose, for example, iscsi boot.
Now we also look up /proc/cmdline for ip conf. If it exists, we use the
existing one. The existing one should work out of box because dracut
will handle it in second kernel like it does for first kernel. That
said, the network card will be brought up and root disk will be mounted
under /sysroot.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
kexec-tools expects "powerpc64le" to pass to configure.ac, while we
passed ppc64le. Otherwise the build fails. Now fix it like we did for
ppc64.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
kdump.sysconfig.ppc64le is copied from kdump.sysconfig.ppc64. The
default sysconfig won't work for ppc64le.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Previously if a target need mount info, the relevant mount options
are got from /proc/mounts by below command:
findmnt -k -f -n -r -o OPTIONS $_dev
This will bring problems. Since /proc/mounts will give out a set
which contains each option. Some options have value specified by
user, some options just have default value if user doesn't specify.
If some mount options are not supported very well, bugs occured.
The more options, the worse.
So in this patch, we try to check fstab to get mount options firstly,
this give user a chance to decide which options they really want.
If they don't give a fstab entry, then we trust all options in
/proc/mounts.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Upstream makedumpfile contains some sample eppic scripts for reference.
Now pull the whole scripts directory into kexec-tools-eppic package.
Signed-off-by: WANG Chao <chaowang@redhat.com>
This patch changes restart of kdump service from cpu online/offline events
to cpu add/remove events.
Some people have complained that they are running cpu online/offline tests
at high frequency and kdump restarts at high frequency and systemd disables
the service. As a temporary fix, we committed a patch to never disable
kdump service.
In general it probably is a good idea to restart kdump service on cpu
add/remove events.
Toshi Kani confirmed following.
- File for /sys/devices/system/cpu/cpuX/crash_notes will be created first
before ADD event goes out. That means we can not miss creating EFL notes
for newly created cpu.
- For REMOVE event files under /sys/devices/system/cpu/cpuX/ are removed
first and then REMOVE event goes out. That means we will remove the elf
note header for removed cpu.
- There are some race conditions like a cpu is removed but system crashes
before kdump service restarts. In that case vmcore.c has to be more robust
to be able to inspect elf notes and discard empty ones.
Also it is possible that after cpu remove, crash notes memory got reused
for something else and after crash vmcore.c might see some random data.
It does basic size checks and discards elf notes if checks don't pass.
Above rance conditions can happen even with OFFLINE event and there is
no good way to remove these altogether. So making vmcore.c more robust
is the right solution here.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Backport the following commit from kexec-tools upstream:
commit 45b33eb
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date: Fri Jul 25 17:07:49 2014 +0200
ppc64/kdump: Fix ELF header endianess
The ELF header created among the loading of the kdump kernel should be
flagged using the current endianess and not always as big endian.
Without this patch the data exposed in /proc/vmcore are not readable when
running in LE mode.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
This is part of the work to enable ppc64le.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Backport the following commit from upstream kexec-tools:
commit 335bad7
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date: Tue Jul 22 18:22:28 2014 +0200
kexec/ppc64: disabling exception handling when building the purgatory
Some Linux distributions would like to turn on the GCC exception handling
by default. As this option introduces symbols in the built code that are
defined in a separate shared library, this is not a good idea to have such
an option activated when building the purgatory.
This patch forces the exception handling to be turned off when building the
purgatory on ppc64 BE and LE.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
This is part of the work to enable ppc64le.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Backport the following commit from upstream kexec-tools:
commit 2ca2203
Author: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Date: Mon Jun 16 14:42:43 2014 +0200
kexec/ppc64: move to device tree version 17
Kernel commit e6a6928c3ea1d0195ed75a091e345696b916c09b changed the way the
device tree is processed in the kernel. Now version 2 is no more supported.
This patch move the version of the device tree generated in ppc64
environment from 2 to 17, allowing to kexec kernel 3.16.
In addition, automates the define of NEED_STRUCTURE_BLOCK_EXTRA_PAD which
should not be set for DT version 16 and above.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
This is part of the work to enable ppc64le.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
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>
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>
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>
This is a back port from upstream.
commit 046d1755d2bd723a11a180c265e61a884990712e
Author: Vivek Goyal <vgoyal@redhat.com>
Date: Mon Aug 18 11:22:32 2014 -0400
kexec: Provide an option to use new kexec system call
Hi,
This is v2 of the patch. Since v1, I moved syscall implemented check littler
earlier in the function as per the feedback.
Now a new kexec syscall (kexec_file_load()) has been merged in upstream
kernel. This system call takes file descriptors of kernel and initramfs
as input (as opposed to list of segments to be loaded). This new system
call allows for signature verification of the kernel being loaded.
One use of signature verification of kernel is secureboot systems where
we want to allow kexec into a kernel only if it is validly signed by
a key system trusts.
This patch provides and option --kexec-file-syscall (-s), to force use of
new system call for kexec. Default is to continue to use old syscall.
Currently only bzImage64 on x86_64 can be loaded using this system call.
As kernel adds support for more arches and for more image types, kexec-tools
can be modified accordingly.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
