Fedora dracut-network version >= 044-117 must be installed to work with
this set of kexec-tools patches. Therefore adding dependency for them.
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Kdump explicitly adds "nfs" dracut module in case of nfs dumping,
actually in case of nfs dump, nfs is a mount target, and will be
added into host_fs_types[], thus dracut will add it automatically,
according to 95nfs/module-setup.sh check().
So, we can safely remove all the add_dracut_module "nfs".
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Update "kexec-kdump-howto" to illustrate the usage of special mount
information via "dracut_args".
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>
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>
Fedora dracut version >= 044-75 must be installed to work with this set of
kexec-tools patches. Therefore adding dependency for them.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Now dracut takes care to add module for active watchdog. Therefore we do
not need to pass iTCO_wdt and lpc_ich module in rd.driver.pre specifically
here.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Update howto with notes on dracut and kernel watchdog module handling.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Dave Young <dyoung@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>
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>
