If dracut watchdog module is enabled then, it includes kernel watchdog
module of active watchdog device in initramfs.
kdump.conf has an option to modify dracut_args. So, if an user passes "-a
watchdog" in dracut_args then dracut will add kernel watchdog module of
active watchdog device in initramfs.
Since, kexec-tools always requires to add kernel watchdog module of active
watchdog device in initramfs, therefore even when an user does not pass any
watchdog option and there exists at least one active watchdog device then
also kexec-tools adds "-a watchdog" in dracut args.
Therefore, if an user does not want to add kernel watchdog module in
initramfs then the person must pass "-o watchdog" in dracut_args.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Fix the typos and grammar problems in kdump.conf man page.
Reported-by: Donald Berry <dberry@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
The default action comment about "halt" is wrong, default action means
the action to perform after a vmcore saving failure.
Also there are lots of typos and incorrect expressions.
Fix them here as well.
[dyoung: fixed trailing whitespaces, drop unnecessary comments, change the
alignment.]
Reported-by: Donald Berry <dberry@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
There are several kinds of iSCSI mode rhel support currently.
- Pure hardware iSCSI
- iBFT iSCSI
- Pure software iSCSI
Except for the 1st one that firmware takes care of everything to
make it behave like a local disk, both iBFT and pure software iSCSI
mode need pass information to kdump kernel for configuring them
correctly.
Currently kdump takes iBFT mode as a software iSCSI and collects
the related information to set up software iSCSI in 2nd kernel,
though dracut can detect and collect information to set up iBFT
iSCSI of 2nd kernel. This brings up 2 problems:
1) Redundent information about the related iSCSI is collected. One
is done by kdump, the other is from dracut.
2) These 2 sessions of 2nd kernel for a certain session of 1st kernel
could contain two "ip=xxx" cmdline option. This will cause cmdline
handling error in dracut.
The 1st one is not critical while the 2nd is. In order to avoid above
2 problems, kdump need detect iBFT mode iSCSI and leave it to dracut.
This is what is done in this patch.
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Use our own code to get system total memory from /proc/meminfo because the
callback to pyanaconda sometimes cause installation hangs.
Signed-off-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>
The ifcfg file name of <netif> under "/etc/sysconfig/network-scripts/"
may not be "ifcfg-<netif>". For example, for "enp0s25" we are able to
generate its ifcfg like "/etc/sysconfig/network-scripts/ifcfg-enp0s25test"
via network-manager. If we alway assume "ifcfg-<netif>" is there, we will
got the wrong result in some cases.
The issue can be resolved by using the new get_ifcfg_filename() introduced
by PATCH "kdump-lib: Add get_ifcfg_filename() to get the proper ifcfg file",
so we hereby change all the "ifcfg-<netif>" users to use get_ifcfg_filename().
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Previously, we assumed the ifcfg file of a network "interface" is
"/etc/sysconfig/network-scripts/ifcfg-<interface>", but actually
it is not the case.
For example, for network interface "enp0s25", we are able to
generate like "/etc/sysconfig/network-scripts/ifcfg-enp0s25-test"
for it via network-manager.
The "suffix" in "ifcfg-<suffix>" is actually a "configuration"
name not "interface" name, though normally we use the "interface"
name as its "configuration" name. You can refer to "man ifup"
for some detail.
So, this patch adds some assistant helpers to acquire the right
ifcfg file for an interface. Borrow some logic from script below:
"/etc/sysconfig/network-scripts/network-functions"
Signed-off-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>
We do not have *.xz, *.gz as part of repositiry, so ignore them. They are
annoying during development period, specially when we want to modify all
changes using `git add -A`.
Also ignore *.swp, and *.rpm because many of such temporary files are
created during development and such files would not be the part of
repository.
Signed-off-by: Pratyush Anand <panand@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>
to_dev_name() and get_persistent_dev() can be used by function in kdumpctl.
Therefore moving them to kdump-lib.sh.
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>
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>
raw devices are not mounted and also does not need to contain any
filesystem. So they may have UUIDs(when formatted) and may not have UUIDs
when raw. Therefore, do not look for persistent names by-uuid for raw
devices.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Suggested-by: Dave Young <dyoung@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>
Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1310495
kexec kernel hangs in ppc64le test. It is caused by kexec does not support
abi v2 properly.
Backport upstream patches below fixes the issue:
There is no code conflicts.
commit 3debb8cf3272216119cb2e59a4963ce3c18fe8e3
Author: Alan Modra <amodra@gmail.com>
Date: Fri Feb 26 18:06:15 2016 +1100
Properly align powerpc64 .toc
gcc leaves .toc byte aligned, relying on the linker to align the section.
* kexec/arch/ppc64/kexec-elf-rel-ppc64.c (machine_verify_elf_rel):
Fudge alignment of .toc section.
Signed-off-by: Alan Modra <amodra@gmail.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Tested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
commit 1e423dc297d10eb7ff25c829d2856ef12fc81d77
Author: Anton Blanchard <anton@samba.org>
Date: Fri Feb 26 18:04:16 2016 +1100
ppc64: purgatory: Handle local symbols in ELF ABIv2
The PowerPC64 ELF ABIv2 has the concept of global and local symbols
and information on this is encoded in sym->st_other. When doing a
R_PPC64_REL24 branch we want to hit the local entry point, so adjust
it as necessary.
Signed-off-by: Anton Blanchard <anton@samba.org>
Tested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
commit 4a2ae3a39c64dc43e9d094be9541253234ff4822
Author: Anton Blanchard <anton@samba.org>
Date: Fri Feb 26 18:03:11 2016 +1100
Pass struct mem_sym into machine_apply_elf_rel()
On PowerPC64 ABIv2 we need to look at the symbol to determine
if it has a local entry point. Pass struct mem_sym into
machine_apply_elf_rel() so we can.
Signed-off-by: Anton Blanchard <anton@samba.org>
Tested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Xunlei Pang <xlpang@redhat.com>
In latest rawhide kdump kernel reboot hangs because systemd reports a
conflict when kdump calls reboot during booting. Need further investigation
about the new systemd behavior.
Here is the error message copied from kdump session:
[snip]
kdump: saving vmcore complete
Failed to start reboot.target: Transaction contains conflicting jobs 'stop' and 'start' for shutdown.target. Probably contradicting requirement dependencies configured.
Failed to talk to init daemon.
[FAILED] Failed to start Kdump Vmcore Save Service.
[snip]
We previouly use "reboot -f" but later we changed to reboot because we want
systemd to take care of the shutdown path, mainly for umount filesystems.
Change back to "reboot -f" works but we still need umount by ourselves.
During my tests with "reboot -f" I get below dirty ext2 filesystem:
[root@localhost ~]# fsck /dev/vdb
fsck from util-linux 2.27
e2fsck 1.42.13 (17-May-2015)
/dev/vdb was not cleanly unmounted, check forced.
Actually "reboot -f" equals to "systemctl reboot -f -f"
systemctl manpage says "-f" and "-f -f" means different behavior:
When use -f with reboot, will execute reboot without shutting down all units.
However all processes will be killed forcibly and all file systems are
unmounted or remounted read-only. If -f is specified twice, will reboot
immediately without terminating any processes or unmounting any file systems.
Thus change to use "systemctl reboot -f" for our reboot actions. It can fix
the problem and at the same time it can ensure filesystems are umounted before
rebooting.
OTOH, a systemd changes cause the breakage, it may be a system service new
design, Later I can dig into systemd changes see which commit cause the
breakage.
Signed-off-by: Dave Young <dyoung@redhat.com
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
"quiet" will disable most of log messages. For debugging kdump
kernel purpose it is better to remove quiet in 2nd kernel so that
we always see kernel messages.
Signed-off-by: Dangyi Liu <dliu@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>
For arches we do not exlictly support, kdumpctl will fail with errors because
kernel can not be found. It is caused by there's no proper KDUMP_IMG prefix
so kernel image can not be found.
Kexec/kdump functionality may simply work, so let's add those prefix in
default sysconfig file thus one can test and use kexec/kdump in Fedora.
Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Pratyush Anand <panand@redhat.com>
Add descriptions of parallel dumping and how to use it.
Signed-off-by: Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com>
Reviewed-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
dracut will place the config in the random path during generating the
initramfs. Remove the duplicate prefix path ${initdir}.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Pulled below commit from Martin Kolman:
commit 0c68135bd14788bc6b3f7f901eb2d2cb8ba76f79
Author: Martin Kolman <martin.kolman@gmail.com>
Date: Mon Sep 7 14:46:42 2015 +0200
Don't put options after the %end of the %addon section
Otherwise the installation describing kickstart will not be valid.
This can resulting in various issues such, as Initial Setup refusing
to run due to invalid kickstart file.
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>
kdumpctl is useful sometimes when users want to debug or setup ssh key
authentication. So add a man page for it.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Pratyush Anand <panand@redhat.com>
Ifcfg depends on network module, which is quite large and useless
when using a local dump target. Also we don't really need ifcfg to
setup network interfaces. So just remove it.
On fedora22, the uncompressed dumprd would decrease about 20MB when
using a local dump target. A regression testing is also conducted with
targets of nfs and ssh.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
The system may have multiple default route entry. Following is an
example to show the details.
# ip -6 route list dev eth0
2620:52:0:1040::/64 proto kernel metric 256 expires 2591978sec fe80::/64 proto kernel metric 256
default via fe80:52:0:1040::1 proto ra metric 1024 expires 1778sec hoplimit 64
default via fe80:52:0:1040::2 proto ra metric 1024 expires 1778sec hoplimit 64
Choose the first matched entry.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Dracut will die in the situation that dracut detects to use dhcp to
setup ip address, but kdump passes the ip address to it.
In commit 7ea50dc7a3, we start to use
option permanent to get the ip address in kdump_static_ip. If the
network is setuped by static, we will get the ip address, otherwise
getting none.
In commit c994a80698 which it used to
support ipv6 protocol, I miss the option permanent.
This patch is not a fixing patch, just pulls back something to make
kdump work as original.
Signed-off-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
