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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
== 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=1059031https://bugzilla.redhat.com/show_bug.cgi?id=980621
Signed-off-by: Jerry Hoemann <jerry.hoemann@hp.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
