2017-05-09 09:30:30 +00:00
|
|
|
#!/bin/bash
|
2011-07-06 19:25:34 +00:00
|
|
|
KEXEC=/sbin/kexec
|
|
|
|
|
|
|
|
KDUMP_KERNELVER=""
|
2020-07-27 18:40:20 +00:00
|
|
|
KDUMP_KERNEL=""
|
2011-07-06 19:25:34 +00:00
|
|
|
KDUMP_COMMANDLINE=""
|
|
|
|
KEXEC_ARGS=""
|
2020-10-27 09:04:24 +00:00
|
|
|
KDUMP_LOG_PATH="/var/log"
|
2012-06-06 08:24:23 +00:00
|
|
|
MKDUMPRD="/sbin/mkdumprd -f"
|
2021-06-23 14:36:48 +00:00
|
|
|
MKFADUMPRD="/sbin/mkfadumprd"
|
2017-08-31 06:27:00 +00:00
|
|
|
DRACUT_MODULES_FILE="/usr/lib/dracut/modules.txt"
|
2016-11-03 18:46:31 +00:00
|
|
|
DEFAULT_INITRD=""
|
|
|
|
DEFAULT_INITRD_BAK=""
|
2022-12-02 13:16:50 +00:00
|
|
|
INITRD_CHECKSUM_LOCATION=""
|
2020-07-27 18:40:20 +00:00
|
|
|
KDUMP_INITRD=""
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
TARGET_INITRD=""
|
2014-07-24 18:38:36 +00:00
|
|
|
FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered"
|
|
|
|
#kdump shall be the default dump mode
|
|
|
|
DEFAULT_DUMP_MODE="kdump"
|
2016-05-09 08:17:53 +00:00
|
|
|
image_time=0
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2020-10-27 09:04:24 +00:00
|
|
|
standard_kexec_args="-d -p"
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2015-11-18 08:00:22 +00:00
|
|
|
# Some default values in case /etc/sysconfig/kdump doesn't include
|
|
|
|
KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug"
|
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
declare -A OPT
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -f /etc/sysconfig/kdump ]]; then
|
2011-07-06 19:25:34 +00:00
|
|
|
. /etc/sysconfig/kdump
|
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
[[ $dracutbasedir ]] || dracutbasedir=/usr/lib/dracut
|
|
|
|
. $dracutbasedir/dracut-functions.sh
|
2022-01-04 06:04:38 +00:00
|
|
|
|
|
|
|
if [[ ${__SOURCED__:+x} ]]; then
|
|
|
|
KDUMP_LIB_PATH=.
|
|
|
|
else
|
|
|
|
KDUMP_LIB_PATH=/lib/kdump
|
|
|
|
fi
|
|
|
|
. $KDUMP_LIB_PATH/kdump-lib.sh
|
|
|
|
. $KDUMP_LIB_PATH/kdump-logger.sh
|
2020-10-27 09:04:22 +00:00
|
|
|
|
|
|
|
#initiate the kdump logger
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! dlog_init; then
|
2020-10-27 09:04:22 +00:00
|
|
|
echo "failed to initiate the kdump logger."
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2013-08-30 09:21:56 +00:00
|
|
|
single_instance_lock()
|
|
|
|
{
|
2022-06-28 06:38:28 +00:00
|
|
|
local rc timeout=5 lockfile
|
2014-07-16 12:09:48 +00:00
|
|
|
|
2022-06-28 06:38:28 +00:00
|
|
|
if [[ -d /run/lock ]]; then
|
|
|
|
lockfile=/run/lock/kdump
|
|
|
|
else
|
|
|
|
# when updating package using virt-customize, /run/lock doesn't exist
|
|
|
|
lockfile=/tmp/kdump.lock
|
|
|
|
fi
|
|
|
|
|
|
|
|
if ! exec 9> $lockfile; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Create file lock failed"
|
2017-07-12 02:59:55 +00:00
|
|
|
exit 1
|
|
|
|
fi
|
2014-07-16 12:09:48 +00:00
|
|
|
|
|
|
|
flock -n 9
|
|
|
|
rc=$?
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
while [[ $rc -ne 0 ]]; do
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Another app is currently holding the kdump lock; waiting for it to exit..."
|
2014-07-16 12:09:48 +00:00
|
|
|
flock -w $timeout 9
|
|
|
|
rc=$?
|
|
|
|
done
|
2013-08-30 09:21:56 +00:00
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
determine_dump_mode()
|
|
|
|
{
|
|
|
|
# Check if firmware-assisted dump is enabled
|
|
|
|
# if yes, set the dump mode as fadump
|
|
|
|
if is_fadump_capable; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Dump mode is fadump"
|
2014-07-24 18:38:36 +00:00
|
|
|
DEFAULT_DUMP_MODE="fadump"
|
|
|
|
fi
|
2020-10-27 09:04:22 +00:00
|
|
|
ddebug "DEFAULT_DUMP_MODE=$DEFAULT_DUMP_MODE"
|
2014-07-24 18:38:36 +00:00
|
|
|
}
|
|
|
|
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
rebuild_fadump_initrd()
|
2012-06-14 01:57:27 +00:00
|
|
|
{
|
2021-06-23 14:36:48 +00:00
|
|
|
if ! $MKFADUMPRD "$DEFAULT_INITRD_BAK" "$TARGET_INITRD" --kver "$KDUMP_KERNELVER"; then
|
|
|
|
derror "mkfadumprd: failed to make fadump initrd"
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2022-03-01 05:09:00 +00:00
|
|
|
sync -f "$TARGET_INITRD"
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2019-05-16 05:09:21 +00:00
|
|
|
check_earlykdump_is_enabled()
|
|
|
|
{
|
|
|
|
grep -q -w "rd.earlykdump" /proc/cmdline
|
|
|
|
}
|
|
|
|
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
rebuild_kdump_initrd()
|
|
|
|
{
|
2020-10-27 09:04:22 +00:00
|
|
|
ddebug "rebuild kdump initrd: $MKDUMPRD $TARGET_INITRD $KDUMP_KERNELVER"
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! $MKDUMPRD "$TARGET_INITRD" "$KDUMP_KERNELVER"; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "mkdumprd: failed to make kdump initrd"
|
2012-06-14 01:57:27 +00:00
|
|
|
return 1
|
|
|
|
fi
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
|
2019-05-16 05:09:21 +00:00
|
|
|
if check_earlykdump_is_enabled; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Tips: If early kdump is enabled, also require rebuilding the system initramfs to make the changes take effect for early kdump."
|
2019-05-16 05:09:21 +00:00
|
|
|
fi
|
|
|
|
|
2022-03-01 05:09:00 +00:00
|
|
|
sync -f "$TARGET_INITRD"
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
rebuild_initrd()
|
|
|
|
{
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ! -w $(dirname "$TARGET_INITRD") ]]; then
|
2021-09-08 09:21:41 +00:00
|
|
|
derror "$(dirname "$TARGET_INITRD") does not have write permission. Cannot rebuild $TARGET_INITRD"
|
2019-03-29 03:29:30 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
rebuild_fadump_initrd
|
|
|
|
else
|
|
|
|
rebuild_kdump_initrd
|
|
|
|
fi
|
2012-06-14 01:57:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#$1: the files to be checked with IFS=' '
|
2014-07-15 06:41:54 +00:00
|
|
|
check_exist()
|
2012-06-14 01:57:27 +00:00
|
|
|
{
|
|
|
|
for file in $1; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ! -e $file ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Error: $file not found."
|
2012-06-14 01:57:27 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
#$1: the files to be checked with IFS=' '
|
2014-07-15 06:41:54 +00:00
|
|
|
check_executable()
|
2012-06-14 01:57:27 +00:00
|
|
|
{
|
|
|
|
for file in $1; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ! -x $file ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Error: $file is not executable."
|
2012-06-14 01:57:27 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
backup_default_initrd()
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
{
|
2020-10-27 09:04:22 +00:00
|
|
|
ddebug "backup default initrd: $DEFAULT_INITRD"
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ! -f $DEFAULT_INITRD ]]; then
|
2017-05-04 06:56:54 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ ! -e $DEFAULT_INITRD_BAK ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Backing up $DEFAULT_INITRD before rebuild."
|
2016-11-03 18:46:31 +00:00
|
|
|
# save checksum to verify before restoring
|
2021-09-08 09:21:41 +00:00
|
|
|
sha1sum "$DEFAULT_INITRD" > "$INITRD_CHECKSUM_LOCATION"
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! cp "$DEFAULT_INITRD" "$DEFAULT_INITRD_BAK"; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "WARNING: failed to backup $DEFAULT_INITRD."
|
2022-12-02 13:16:50 +00:00
|
|
|
rm -f -- "$INITRD_CHECKSUM_LOCATION"
|
|
|
|
rm -f -- "$DEFAULT_INITRD_BAK"
|
2016-11-03 18:46:31 +00:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
}
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
restore_default_initrd()
|
|
|
|
{
|
2020-10-27 09:04:22 +00:00
|
|
|
ddebug "restore default initrd: $DEFAULT_INITRD"
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ! -f $DEFAULT_INITRD ]]; then
|
2020-07-27 18:40:20 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
# If a backup initrd exists, we must be switching back from
|
|
|
|
# fadump to kdump. Restore the original default initrd.
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -f $DEFAULT_INITRD_BAK ]] && [[ -f $INITRD_CHECKSUM_LOCATION ]]; then
|
2016-11-03 18:46:31 +00:00
|
|
|
# verify checksum before restoring
|
2021-08-04 07:14:00 +00:00
|
|
|
backup_checksum=$(sha1sum "$DEFAULT_INITRD_BAK" | awk '{ print $1 }')
|
|
|
|
default_checksum=$(awk '{ print $1 }' "$INITRD_CHECKSUM_LOCATION")
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $default_checksum != "$backup_checksum" ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "WARNING: checksum mismatch! Can't restore original initrd.."
|
2016-11-03 18:46:31 +00:00
|
|
|
else
|
|
|
|
rm -f $INITRD_CHECKSUM_LOCATION
|
2021-09-08 09:23:16 +00:00
|
|
|
if mv "$DEFAULT_INITRD_BAK" "$DEFAULT_INITRD"; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Restoring original initrd as fadump mode is disabled."
|
2022-03-01 05:09:00 +00:00
|
|
|
sync -f "$DEFAULT_INITRD"
|
2016-11-03 18:46:31 +00:00
|
|
|
fi
|
|
|
|
fi
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
_set_config()
|
|
|
|
{
|
|
|
|
local opt=$1
|
|
|
|
local val=$2
|
|
|
|
|
|
|
|
if [[ -z $val ]]; then
|
|
|
|
derror "Invalid kdump config value for option '$opt'"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [[ -n ${OPT[$opt]} ]]; then
|
2022-03-25 14:47:09 +00:00
|
|
|
if [[ $opt == _target ]] || [[ $opt == _fstype ]]; then
|
2022-03-25 14:47:06 +00:00
|
|
|
derror "More than one dump targets specified"
|
|
|
|
else
|
|
|
|
derror "Duplicated kdump config value of option $opt"
|
|
|
|
fi
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
OPT[$opt]="$val"
|
|
|
|
}
|
|
|
|
|
|
|
|
parse_config()
|
2013-03-11 09:31:25 +00:00
|
|
|
{
|
2021-04-14 05:41:19 +00:00
|
|
|
while read -r config_opt config_val; do
|
2013-03-11 09:31:25 +00:00
|
|
|
case "$config_opt" in
|
2020-08-20 17:35:20 +00:00
|
|
|
dracut_args)
|
|
|
|
if [[ $config_val == *--mount* ]]; then
|
2022-09-20 09:09:44 +00:00
|
|
|
if [[ $(echo "$config_val" | grep -o -- "--mount" | wc -l) -ne 1 ]]; then
|
2021-09-13 18:25:40 +00:00
|
|
|
derror 'Multiple mount targets specified in one "dracut_args".'
|
2020-08-20 17:35:20 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2022-03-25 14:47:09 +00:00
|
|
|
_set_config _fstype "$(get_dracut_args_fstype "$config_val")" || return 1
|
2022-03-25 14:47:06 +00:00
|
|
|
_set_config _target "$(get_dracut_args_target "$config_val")" || return 1
|
2020-08-20 17:35:20 +00:00
|
|
|
fi
|
2013-03-11 09:31:25 +00:00
|
|
|
;;
|
2020-08-20 17:35:20 +00:00
|
|
|
raw)
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -d "/proc/device-tree/ibm,opal/dump" ]]; then
|
2020-10-27 09:34:48 +00:00
|
|
|
dwarn "WARNING: Won't capture opalcore when 'raw' dump target is used."
|
2020-01-28 19:34:48 +00:00
|
|
|
fi
|
2022-03-25 14:47:09 +00:00
|
|
|
_set_config _fstype "$config_opt" || return 1
|
2020-08-20 17:35:20 +00:00
|
|
|
config_opt=_target
|
|
|
|
;;
|
2022-09-23 10:13:11 +00:00
|
|
|
ext[234] | minix | btrfs | xfs | nfs | ssh | virtiofs)
|
2022-03-25 14:47:09 +00:00
|
|
|
_set_config _fstype "$config_opt" || return 1
|
2020-08-20 17:35:20 +00:00
|
|
|
config_opt=_target
|
|
|
|
;;
|
2022-03-25 14:47:05 +00:00
|
|
|
sshkey)
|
|
|
|
if [[ -z $config_val ]]; then
|
|
|
|
derror "Invalid kdump config value for option '$config_opt'"
|
|
|
|
return 1
|
|
|
|
elif [[ -f $config_val ]]; then
|
2022-03-25 14:47:08 +00:00
|
|
|
config_val=$(/usr/bin/readlink -m "$config_val")
|
2022-03-25 14:47:05 +00:00
|
|
|
else
|
2022-03-25 14:47:08 +00:00
|
|
|
dwarn "WARNING: '$config_val' doesn't exist, using default value '$DEFAULT_SSHKEY'"
|
|
|
|
config_val=$DEFAULT_SSHKEY
|
2022-03-25 14:47:05 +00:00
|
|
|
fi
|
|
|
|
;;
|
2022-03-25 14:47:07 +00:00
|
|
|
path | core_collector | kdump_post | kdump_pre | extra_bins | extra_modules | failure_action | default | final_action | force_rebuild | force_no_rebuild | fence_kdump_args | fence_kdump_nodes | auto_reset_crashkernel) ;;
|
2021-09-13 18:25:40 +00:00
|
|
|
|
|
|
|
net | options | link_delay | disk_timeout | debug_mem_level | blacklist)
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Deprecated kdump config option: $config_opt. Refer to kdump.conf manpage for alternatives."
|
2013-03-11 09:31:25 +00:00
|
|
|
return 1
|
|
|
|
;;
|
2021-04-14 05:41:19 +00:00
|
|
|
'')
|
|
|
|
continue
|
|
|
|
;;
|
2013-03-11 09:31:25 +00:00
|
|
|
*)
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Invalid kdump config option $config_opt"
|
2020-08-20 17:35:20 +00:00
|
|
|
return 1
|
2013-03-11 09:31:25 +00:00
|
|
|
;;
|
|
|
|
esac
|
2020-08-20 17:35:20 +00:00
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
_set_config "$config_opt" "$config_val" || return 1
|
2021-08-03 11:49:51 +00:00
|
|
|
done <<< "$(kdump_read_conf)"
|
2014-07-15 06:41:54 +00:00
|
|
|
|
2022-03-25 14:47:07 +00:00
|
|
|
OPT[path]=${OPT[path]:-$DEFAULT_PATH}
|
2022-03-25 14:47:08 +00:00
|
|
|
OPT[sshkey]=${OPT[sshkey]:-$DEFAULT_SSHKEY}
|
2022-03-25 14:47:07 +00:00
|
|
|
|
2019-01-17 20:31:23 +00:00
|
|
|
check_failure_action_config || return 1
|
2019-01-17 20:31:24 +00:00
|
|
|
check_final_action_config || return 1
|
2014-04-02 08:33:47 +00:00
|
|
|
check_fence_kdump_config || return 1
|
2022-03-25 14:47:05 +00:00
|
|
|
check_ssh_config || return 1
|
2014-04-02 08:33:47 +00:00
|
|
|
|
2013-03-11 09:31:25 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
# get_pcs_cluster_modified_files <image timestamp>
|
|
|
|
# return list of modified file for fence_kdump modified in Pacemaker cluster
|
|
|
|
get_pcs_cluster_modified_files()
|
2013-12-17 07:00:33 +00:00
|
|
|
{
|
2014-04-02 08:33:47 +00:00
|
|
|
local time_stamp
|
|
|
|
local modified_files
|
2013-12-17 07:00:33 +00:00
|
|
|
|
2014-04-02 08:33:47 +00:00
|
|
|
is_generic_fence_kdump && return 1
|
2014-04-02 08:33:43 +00:00
|
|
|
is_pcs_fence_kdump || return 1
|
2013-12-17 07:00:33 +00:00
|
|
|
|
2021-09-07 17:48:52 +00:00
|
|
|
time_stamp=$(pcs cluster cib | xmllint --xpath 'string(/cib/@cib-last-written)' - | xargs -0 date +%s --date)
|
2013-12-17 07:00:33 +00:00
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -n $time_stamp ]] && [[ $time_stamp -gt $image_time ]]; then
|
2014-04-02 08:33:47 +00:00
|
|
|
modified_files="cluster-cib"
|
2013-12-17 07:00:33 +00:00
|
|
|
fi
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -f $FENCE_KDUMP_CONFIG_FILE ]]; then
|
2021-09-08 09:21:41 +00:00
|
|
|
time_stamp=$(stat -c "%Y" "$FENCE_KDUMP_CONFIG_FILE")
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $time_stamp -gt $image_time ]]; then
|
2014-04-02 08:33:47 +00:00
|
|
|
modified_files="$modified_files $FENCE_KDUMP_CONFIG_FILE"
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:21:41 +00:00
|
|
|
echo "$modified_files"
|
2013-12-17 07:00:33 +00:00
|
|
|
}
|
|
|
|
|
2016-11-03 18:46:31 +00:00
|
|
|
setup_initrd()
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
{
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! prepare_kdump_bootinfo; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "failed to prepare for kdump bootinfo."
|
2020-07-27 18:40:20 +00:00
|
|
|
return 1
|
2018-10-23 14:13:28 +00:00
|
|
|
fi
|
|
|
|
|
2021-09-08 09:21:41 +00:00
|
|
|
DEFAULT_INITRD_BAK="$KDUMP_BOOTDIR/.$(basename "$DEFAULT_INITRD").default"
|
2022-12-02 13:16:50 +00:00
|
|
|
INITRD_CHECKSUM_LOCATION="$DEFAULT_INITRD_BAK.checksum"
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2016-11-03 18:46:31 +00:00
|
|
|
TARGET_INITRD="$DEFAULT_INITRD"
|
2019-03-29 03:29:30 +00:00
|
|
|
|
|
|
|
# backup initrd for reference before replacing it
|
|
|
|
# with fadump aware initrd
|
|
|
|
backup_default_initrd
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
else
|
2020-07-27 18:40:20 +00:00
|
|
|
TARGET_INITRD="$KDUMP_INITRD"
|
2019-03-29 03:29:30 +00:00
|
|
|
|
|
|
|
# check if a backup of default initrd exists. If yes,
|
|
|
|
# it signifies a switch from fadump mode. So, restore
|
|
|
|
# the backed up default initrd.
|
|
|
|
restore_default_initrd
|
kdump: Rebuild default initrd for firmware assisted dump
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>
2014-07-24 18:39:07 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2016-05-09 08:17:53 +00:00
|
|
|
check_files_modified()
|
|
|
|
{
|
|
|
|
local modified_files=""
|
|
|
|
|
|
|
|
#also rebuild when Pacemaker cluster conf is changed and fence kdump is enabled.
|
|
|
|
modified_files=$(get_pcs_cluster_modified_files)
|
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
EXTRA_BINS=${OPT[kdump_post]}
|
|
|
|
CHECK_FILES=${OPT[kdump_pre]}
|
2020-07-16 08:50:15 +00:00
|
|
|
HOOKS="/etc/kdump/post.d/ /etc/kdump/pre.d/"
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -d /etc/kdump/post.d ]]; then
|
2020-06-05 02:24:07 +00:00
|
|
|
for file in /etc/kdump/post.d/*; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -x $file ]]; then
|
2020-06-05 02:24:07 +00:00
|
|
|
POST_FILES="$POST_FILES $file"
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
fi
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -d /etc/kdump/pre.d ]]; then
|
2020-06-05 02:24:07 +00:00
|
|
|
for file in /etc/kdump/pre.d/*; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -x $file ]]; then
|
2020-06-05 02:24:07 +00:00
|
|
|
PRE_FILES="$PRE_FILES $file"
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
fi
|
2020-07-16 08:50:15 +00:00
|
|
|
HOOKS="$HOOKS $POST_FILES $PRE_FILES"
|
2022-03-25 14:47:06 +00:00
|
|
|
CORE_COLLECTOR=$(echo "${OPT[core_collector]}" | awk '{print $1}')
|
2021-09-08 09:21:41 +00:00
|
|
|
CORE_COLLECTOR=$(type -P "$CORE_COLLECTOR")
|
2020-07-16 08:50:15 +00:00
|
|
|
# POST_FILES and PRE_FILES are already checked against executable, need not to check again.
|
|
|
|
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
|
2022-03-25 14:47:06 +00:00
|
|
|
CHECK_FILES=${OPT[extra_bins]}
|
2016-05-09 08:17:53 +00:00
|
|
|
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
|
2020-07-27 18:40:20 +00:00
|
|
|
files="$KDUMP_CONFIG_FILE $KDUMP_KERNEL $EXTRA_BINS $CORE_COLLECTOR"
|
2016-09-14 14:42:17 +00:00
|
|
|
[[ -e /etc/fstab ]] && files="$files /etc/fstab"
|
2016-05-09 08:17:53 +00:00
|
|
|
|
2019-05-13 06:20:25 +00:00
|
|
|
# Check for any updated extra module
|
2022-03-25 14:47:06 +00:00
|
|
|
EXTRA_MODULES="${OPT[extra_modules]}"
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -n $EXTRA_MODULES ]]; then
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -e /lib/modules/$KDUMP_KERNELVER/modules.dep ]]; then
|
2020-07-27 18:40:20 +00:00
|
|
|
files="$files /lib/modules/$KDUMP_KERNELVER/modules.dep"
|
2019-05-13 06:20:25 +00:00
|
|
|
fi
|
|
|
|
for _module in $EXTRA_MODULES; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if _module_file="$(modinfo --set-version "$KDUMP_KERNELVER" --filename "$_module" 2> /dev/null)"; then
|
2019-05-13 06:20:25 +00:00
|
|
|
files="$files $_module_file"
|
2021-09-08 09:21:41 +00:00
|
|
|
for _dep_modules in $(modinfo -F depends "$_module" | tr ',' ' '); do
|
2021-09-13 18:25:40 +00:00
|
|
|
files="$files $(modinfo --set-version "$KDUMP_KERNELVER" --filename "$_dep_modules" 2> /dev/null)"
|
2019-05-13 06:20:25 +00:00
|
|
|
done
|
|
|
|
else
|
|
|
|
# If it's not a module nor builtin, give an error
|
2021-09-13 18:25:40 +00:00
|
|
|
if ! (modprobe --set-version "$KDUMP_KERNELVER" --dry-run "$_module" &> /dev/null); then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Module $_module not found"
|
2019-05-13 06:20:25 +00:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
|
2020-07-29 07:52:21 +00:00
|
|
|
# HOOKS is mandatory and need to check the modification time
|
|
|
|
files="$files $HOOKS"
|
2022-10-08 07:41:40 +00:00
|
|
|
is_lvm2_thinp_dump_target && files="$files $LVM_CONF"
|
2021-09-08 09:23:16 +00:00
|
|
|
check_exist "$files" && check_executable "$EXTRA_BINS" || return 2
|
2016-05-09 08:17:53 +00:00
|
|
|
|
|
|
|
for file in $files; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -e $file ]]; then
|
2021-09-08 09:21:41 +00:00
|
|
|
time_stamp=$(stat -c "%Y" "$file")
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $time_stamp -gt $image_time ]]; then
|
2019-05-13 06:20:24 +00:00
|
|
|
modified_files="$modified_files $file"
|
|
|
|
fi
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -L $file ]]; then
|
2021-09-08 09:21:41 +00:00
|
|
|
file=$(readlink -m "$file")
|
|
|
|
time_stamp=$(stat -c "%Y" "$file")
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $time_stamp -gt $image_time ]]; then
|
2019-05-13 06:20:24 +00:00
|
|
|
modified_files="$modified_files $file"
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
else
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "$file doesn't exist"
|
2016-05-09 08:17:53 +00:00
|
|
|
fi
|
|
|
|
done
|
2019-05-13 06:20:24 +00:00
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -n $modified_files ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Detected change(s) in the following file(s): $modified_files"
|
2016-05-09 08:17:53 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2020-10-15 10:22:12 +00:00
|
|
|
check_drivers_modified()
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
{
|
2020-10-15 10:22:12 +00:00
|
|
|
local _target _new_drivers _old_drivers _module_name _module_filename
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
|
2020-10-15 10:22:12 +00:00
|
|
|
# If it's dump target is on block device, detect the block driver
|
|
|
|
_target=$(get_block_dump_target)
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -n $_target ]]; then
|
|
|
|
_record_block_drivers()
|
|
|
|
{
|
2020-10-15 10:22:12 +00:00
|
|
|
local _drivers
|
|
|
|
_drivers=$(udevadm info -a "/dev/block/$1" | sed -n 's/\s*DRIVERS=="\(\S\+\)"/\1/p')
|
|
|
|
for _driver in $_drivers; do
|
|
|
|
if ! [[ " $_new_drivers " == *" $_driver "* ]]; then
|
|
|
|
_new_drivers="$_new_drivers $_driver"
|
|
|
|
fi
|
|
|
|
done
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
|
2020-10-15 10:22:12 +00:00
|
|
|
ddebug "MAJ:MIN=$1 drivers='$_drivers'"
|
|
|
|
}
|
|
|
|
check_block_and_slaves_all _record_block_drivers "$(get_maj_min "$_target")"
|
|
|
|
fi
|
2020-10-27 09:04:22 +00:00
|
|
|
|
2020-10-15 10:22:14 +00:00
|
|
|
# Include watchdog drivers if watchdog module is not omitted
|
2020-10-15 10:22:15 +00:00
|
|
|
is_dracut_mod_omitted watchdog || _new_drivers+=" $(get_watchdog_drvs)"
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ -z $_new_drivers ]] && return 0
|
2021-06-25 06:44:45 +00:00
|
|
|
|
|
|
|
if is_fadump_capable; then
|
|
|
|
_old_drivers="$(lsinitrd "$TARGET_INITRD" -f /usr/lib/dracut/fadump-kernel-modules.txt | tr '\n' ' ')"
|
|
|
|
else
|
|
|
|
_old_drivers="$(lsinitrd "$TARGET_INITRD" -f /usr/lib/dracut/hostonly-kernel-modules.txt | tr '\n' ' ')"
|
|
|
|
fi
|
2020-10-27 09:04:22 +00:00
|
|
|
|
2020-10-15 10:22:14 +00:00
|
|
|
ddebug "Modules required for kdump: '$_new_drivers'"
|
2020-10-15 10:22:12 +00:00
|
|
|
ddebug "Modules included in old initramfs: '$_old_drivers'"
|
|
|
|
for _driver in $_new_drivers; do
|
2020-03-18 07:51:21 +00:00
|
|
|
# Skip deprecated/invalid driver name or built-in module
|
2021-09-13 18:25:40 +00:00
|
|
|
_module_name=$(modinfo --set-version "$KDUMP_KERNELVER" -F name "$_driver" 2> /dev/null)
|
|
|
|
_module_filename=$(modinfo --set-version "$KDUMP_KERNELVER" -n "$_driver" 2> /dev/null)
|
|
|
|
if [[ -z $_module_name ]] || [[ -z $_module_filename ]] || [[ $_module_filename == *"(builtin)"* ]]; then
|
kdumpctl: Detect block device driver change for initramfs rebuild
Previous we rebuild the initramfs when kenrel load module list changed,
but this is not very stable as some async services may load/unload
kernel modules, and cause unnecessary initramfs rebuild.
Instead, it's better to just check if the module required to dump to
the dump target is loaded or not, and rebuild if not loaded. This
avoids most false-positives, and ensure local target change is always
covered.
Currently only local fs dump target is covered, because this check
requires the dump target to be mounted when building the initramfs,
this guarantee that the module is in the loaded kernel module list,
else we may still get some false positive.
dracut-install could be leveraged to combine the modalias list with
kernel loaded module list as a more stable module list in the initramfs,
but upstream dracut change need to be done first.
Passed test on a KVM VM, changing the storage between SATA/USB/VirtIO
will trigger initramfs rebuild and didn't notice any false-positive.
Also passed test on my laptop with no false-positive.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-07 06:19:18 +00:00
|
|
|
continue
|
|
|
|
fi
|
|
|
|
if ! [[ " $_old_drivers " == *" $_module_name "* ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Detected change in block device driver, new loaded module: $_module_name"
|
kdumpctl: Detect block device driver change for initramfs rebuild
Previous we rebuild the initramfs when kenrel load module list changed,
but this is not very stable as some async services may load/unload
kernel modules, and cause unnecessary initramfs rebuild.
Instead, it's better to just check if the module required to dump to
the dump target is loaded or not, and rebuild if not loaded. This
avoids most false-positives, and ensure local target change is always
covered.
Currently only local fs dump target is covered, because this check
requires the dump target to be mounted when building the initramfs,
this guarantee that the module is in the loaded kernel module list,
else we may still get some false positive.
dracut-install could be leveraged to combine the modalias list with
kernel loaded module list as a more stable module list in the initramfs,
but upstream dracut change need to be done first.
Passed test on a KVM VM, changing the storage between SATA/USB/VirtIO
will trigger initramfs rebuild and didn't notice any false-positive.
Also passed test on my laptop with no false-positive.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-07 06:19:18 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
done
|
2020-10-15 10:22:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
check_fs_modified()
|
|
|
|
{
|
|
|
|
local _old_dev _old_mntpoint _old_fstype
|
|
|
|
local _new_dev _new_mntpoint _new_fstype
|
|
|
|
local _target _dracut_args
|
|
|
|
|
|
|
|
# No need to check in case of mount target specified via "dracut_args".
|
|
|
|
if is_mount_in_dracut_args; then
|
|
|
|
return 0
|
|
|
|
fi
|
kdumpctl: Detect block device driver change for initramfs rebuild
Previous we rebuild the initramfs when kenrel load module list changed,
but this is not very stable as some async services may load/unload
kernel modules, and cause unnecessary initramfs rebuild.
Instead, it's better to just check if the module required to dump to
the dump target is loaded or not, and rebuild if not loaded. This
avoids most false-positives, and ensure local target change is always
covered.
Currently only local fs dump target is covered, because this check
requires the dump target to be mounted when building the initramfs,
this guarantee that the module is in the loaded kernel module list,
else we may still get some false positive.
dracut-install could be leveraged to combine the modalias list with
kernel loaded module list as a more stable module list in the initramfs,
but upstream dracut change need to be done first.
Passed test on a KVM VM, changing the storage between SATA/USB/VirtIO
will trigger initramfs rebuild and didn't notice any false-positive.
Also passed test on my laptop with no false-positive.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-05-07 06:19:18 +00:00
|
|
|
|
2020-10-15 10:22:12 +00:00
|
|
|
# No need to check in case of raw target.
|
2022-11-10 02:25:58 +00:00
|
|
|
# Currently we do not check also if ssh/nfs/virtiofs/thinp target is specified
|
|
|
|
if is_ssh_dump_target || is_nfs_dump_target || is_raw_dump_target ||
|
|
|
|
is_virtiofs_dump_target || is_lvm2_thinp_dump_target; then
|
2020-10-15 10:22:12 +00:00
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
_target=$(get_block_dump_target)
|
2021-09-08 09:21:41 +00:00
|
|
|
_new_fstype=$(get_fs_type_from_target "$_target")
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $_target ]] || [[ -z $_new_fstype ]]; then
|
2020-10-15 10:22:12 +00:00
|
|
|
derror "Dump target is invalid"
|
|
|
|
return 2
|
|
|
|
fi
|
|
|
|
|
|
|
|
ddebug "_target=$_target _new_fstype=$_new_fstype"
|
2021-09-08 09:21:41 +00:00
|
|
|
_new_dev=$(kdump_get_persistent_dev "$_target")
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $_new_dev ]]; then
|
2020-11-30 07:16:57 +00:00
|
|
|
perror "Get persistent device name failed"
|
|
|
|
return 2
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
fi
|
|
|
|
|
2021-09-08 09:21:41 +00:00
|
|
|
_new_mntpoint="$(get_kdump_mntpoint_from_target "$_target")"
|
|
|
|
_dracut_args=$(lsinitrd "$TARGET_INITRD" -f usr/lib/dracut/build-parameter.txt)
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $_dracut_args ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Warning: No dracut arguments found in initrd"
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
# if --mount argument present then match old and new target, mount
|
|
|
|
# point and file system. If any of them mismatches then rebuild
|
2022-09-20 09:09:44 +00:00
|
|
|
if echo "$_dracut_args" | grep -q -- "--mount"; then
|
2021-09-08 09:21:41 +00:00
|
|
|
# shellcheck disable=SC2046
|
|
|
|
set -- $(echo "$_dracut_args" | awk -F "--mount '" '{print $2}' | cut -d' ' -f1,2,3)
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
_old_dev=$1
|
|
|
|
_old_mntpoint=$2
|
|
|
|
_old_fstype=$3
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ $_new_dev == "$_old_dev" && $_new_mntpoint == "$_old_mntpoint" && $_new_fstype == "$_old_fstype" ]] && return 0
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
# otherwise rebuild if target device is not a root device
|
|
|
|
else
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ $_target == "$(get_root_fs_device)" ]] && return 0
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Detected change in File System"
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
# returns 0 if system is not modified
|
|
|
|
# returns 1 if system is modified
|
|
|
|
# returns 2 if system modification is invalid
|
|
|
|
check_system_modified()
|
|
|
|
{
|
2016-05-09 08:17:53 +00:00
|
|
|
local ret
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
[[ -f $TARGET_INITRD ]] || return 1
|
|
|
|
|
2016-05-09 08:17:53 +00:00
|
|
|
check_files_modified
|
|
|
|
ret=$?
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $ret -ne 0 ]]; then
|
2016-05-09 08:17:53 +00:00
|
|
|
return $ret
|
|
|
|
fi
|
|
|
|
|
2020-10-15 10:22:12 +00:00
|
|
|
check_fs_modified
|
|
|
|
ret=$?
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $ret -ne 0 ]]; then
|
2020-10-15 10:22:12 +00:00
|
|
|
return $ret
|
|
|
|
fi
|
|
|
|
|
|
|
|
check_drivers_modified
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
ret=$?
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $ret -ne 0 ]]; then
|
kdumpctl: force rebuild in case of file system is modified
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>
2016-05-09 08:17:55 +00:00
|
|
|
return $ret
|
|
|
|
fi
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_rebuild()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2017-08-31 06:27:00 +00:00
|
|
|
local capture_capable_initrd="1"
|
2021-08-03 14:50:02 +00:00
|
|
|
local force_rebuild force_no_rebuild
|
2016-05-09 08:17:52 +00:00
|
|
|
local ret system_modified="0"
|
2012-06-14 01:57:27 +00:00
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
setup_initrd || return 1
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
force_no_rebuild=${OPT[force_no_rebuild]}
|
2021-08-03 14:50:02 +00:00
|
|
|
force_no_rebuild=${force_no_rebuild:-0}
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $force_no_rebuild != "0" ]] && [[ $force_no_rebuild != "1" ]]; then
|
2021-08-03 14:50:02 +00:00
|
|
|
derror "Error: force_no_rebuild value is invalid"
|
|
|
|
return 1
|
2017-04-12 05:44:18 +00:00
|
|
|
fi
|
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
force_rebuild=${OPT[force_rebuild]}
|
2021-08-03 14:50:02 +00:00
|
|
|
force_rebuild=${force_rebuild:-0}
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $force_rebuild != "0" ]] && [[ $force_rebuild != "1" ]]; then
|
2021-08-03 14:50:02 +00:00
|
|
|
derror "Error: force_rebuild value is invalid"
|
|
|
|
return 1
|
2012-08-06 14:01:29 +00:00
|
|
|
fi
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $force_no_rebuild == "1" && $force_rebuild == "1" ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Error: force_rebuild and force_no_rebuild are enabled simultaneously in kdump.conf"
|
2017-04-12 05:44:18 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Will not rebuild kdump initrd
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $force_no_rebuild == "1" ]]; then
|
2017-04-12 05:44:18 +00:00
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
2012-06-14 01:57:27 +00:00
|
|
|
#check to see if dependent files has been modified
|
|
|
|
#since last build of the image file
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -f $TARGET_INITRD ]]; then
|
2021-09-13 18:25:40 +00:00
|
|
|
image_time=$(stat -c "%Y" "$TARGET_INITRD" 2> /dev/null)
|
2017-08-31 06:27:00 +00:00
|
|
|
|
|
|
|
#in case of fadump mode, check whether the default/target
|
|
|
|
#initrd is already built with dump capture capability
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2021-08-04 07:44:02 +00:00
|
|
|
capture_capable_initrd=$(lsinitrd -f $DRACUT_MODULES_FILE "$TARGET_INITRD" | grep -c -e ^kdumpbase$ -e ^zz-fadumpinit$)
|
2017-08-31 06:27:00 +00:00
|
|
|
fi
|
2011-07-06 19:25:34 +00:00
|
|
|
fi
|
|
|
|
|
2016-05-09 08:17:52 +00:00
|
|
|
check_system_modified
|
|
|
|
ret=$?
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $ret -eq 2 ]]; then
|
2016-05-09 08:17:52 +00:00
|
|
|
return 1
|
2021-09-13 18:25:40 +00:00
|
|
|
elif [[ $ret -eq 1 ]]; then
|
2016-05-09 08:17:52 +00:00
|
|
|
system_modified="1"
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $image_time -eq 0 ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "No kdump initial ramdisk found."
|
2021-09-13 18:25:40 +00:00
|
|
|
elif [[ $capture_capable_initrd == "0" ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Rebuild $TARGET_INITRD with dump capture support"
|
2021-09-13 18:25:40 +00:00
|
|
|
elif [[ $force_rebuild != "0" ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Force rebuild $TARGET_INITRD"
|
2021-09-13 18:25:40 +00:00
|
|
|
elif [[ $system_modified != "0" ]]; then
|
2016-05-09 08:17:52 +00:00
|
|
|
:
|
2012-06-14 01:57:27 +00:00
|
|
|
else
|
|
|
|
return 0
|
2011-07-06 19:25:34 +00:00
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Rebuilding $TARGET_INITRD"
|
2012-06-14 01:57:27 +00:00
|
|
|
rebuild_initrd
|
2011-07-06 19:25:34 +00:00
|
|
|
}
|
|
|
|
|
2021-02-18 06:01:18 +00:00
|
|
|
# On ppc64le LPARs, the keys trusted by firmware do not end up in
|
|
|
|
# .builtin_trusted_keys. So instead, add the key to the .ima keyring
|
|
|
|
function load_kdump_kernel_key()
|
|
|
|
{
|
|
|
|
# this is only called inside is_secure_boot_enforced,
|
|
|
|
# no need to retest
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
# this is only required if DT /ibm,secure-boot is a file.
|
|
|
|
# if it is a dir, we are on OpenPower and don't need this.
|
|
|
|
if ! [[ -f /proc/device-tree/ibm,secure-boot ]]; then
|
|
|
|
return
|
|
|
|
fi
|
2021-02-18 06:01:18 +00:00
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
KDUMP_KEY_ID=$(keyctl padd asymmetric kernelkey-$RANDOM %:.ima < "/usr/share/doc/kernel-keys/$KDUMP_KERNELVER/kernel-signing-ppc.cer")
|
2021-02-18 06:01:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# remove a previously loaded key. There's no real security implication
|
|
|
|
# to leaving it around, we choose to do this because it makes it easier
|
|
|
|
# to be idempotent and so as to reduce the potential for confusion.
|
|
|
|
function remove_kdump_kernel_key()
|
|
|
|
{
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $KDUMP_KEY_ID ]]; then
|
2021-02-18 06:01:18 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:21:41 +00:00
|
|
|
keyctl unlink "$KDUMP_KEY_ID" %:.ima
|
2021-02-18 06:01:18 +00:00
|
|
|
}
|
|
|
|
|
KDUMP_COMMANDLINE: remove irqpoll parameter on aws aarch64 platform
Currently, kdump may experience failure on some aws aarch64 platform.
The final scenario is:
[ 79.145089] printk: console [ttyS0] disabled
Then the system has no response any more. And after reboot, there is no
vmcore generated under /var/crash/. More detail [1].
In a short word, it is caused by the irqpoll policy and some unknown
acpi issue. The serial device is hot-removed as a pci device.
More detailed, the irqpoll policy demands to iterate over all interrupt
handler, if the interrupt line is shared, then the handler is
dispatched. And acpi handler acpi_irq() is on a shared interrupt line,
so it is called. But for some unknown reason, the acpi hardware regs
hold wrong state, and the acpi driver decides that a hot-removed event
happens on a pci slot, which finally removes the pci serial device.
To tackle this issue by removing the irqpoll parameter on aws aarch64
platform, until the real root cause in acpi is found and resolved.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2080468#c0
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
2022-07-21 11:00:19 +00:00
|
|
|
function is_aws_aarch64()
|
|
|
|
{
|
|
|
|
local _bios_model
|
|
|
|
|
|
|
|
_bios_model=$(lscpu | grep "BIOS Model name")
|
|
|
|
if [[ "${_bios_model}" =~ "AWS Graviton" ]]; then
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2016-11-15 09:07:59 +00:00
|
|
|
# Load the kdump kernel specified in /etc/sysconfig/kdump
|
2011-07-06 19:25:34 +00:00
|
|
|
# If none is specified, try to load a kdump kernel with the same version
|
|
|
|
# as the currently running kernel.
|
2014-07-15 06:41:54 +00:00
|
|
|
load_kdump()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2020-10-27 09:04:24 +00:00
|
|
|
local ret
|
|
|
|
|
2018-05-22 10:15:07 +00:00
|
|
|
KEXEC_ARGS=$(prepare_kexec_args "${KEXEC_ARGS}")
|
|
|
|
KDUMP_COMMANDLINE=$(prepare_cmdline "${KDUMP_COMMANDLINE}" "${KDUMP_COMMANDLINE_REMOVE}" "${KDUMP_COMMANDLINE_APPEND}")
|
KDUMP_COMMANDLINE: remove irqpoll parameter on aws aarch64 platform
Currently, kdump may experience failure on some aws aarch64 platform.
The final scenario is:
[ 79.145089] printk: console [ttyS0] disabled
Then the system has no response any more. And after reboot, there is no
vmcore generated under /var/crash/. More detail [1].
In a short word, it is caused by the irqpoll policy and some unknown
acpi issue. The serial device is hot-removed as a pci device.
More detailed, the irqpoll policy demands to iterate over all interrupt
handler, if the interrupt line is shared, then the handler is
dispatched. And acpi handler acpi_irq() is on a shared interrupt line,
so it is called. But for some unknown reason, the acpi hardware regs
hold wrong state, and the acpi driver decides that a hot-removed event
happens on a pci slot, which finally removes the pci serial device.
To tackle this issue by removing the irqpoll parameter on aws aarch64
platform, until the real root cause in acpi is found and resolved.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2080468#c0
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
2022-07-21 11:00:19 +00:00
|
|
|
# This is a workaround on AWS platform, since irqpoll may cause the hot-remove of some pci hotplug device
|
|
|
|
if is_aws_aarch64; then
|
|
|
|
KDUMP_COMMANDLINE=$(remove_cmdline_param "${KDUMP_COMMANDLINE}" irqpoll)
|
|
|
|
fi
|
2011-07-06 19:25:34 +00:00
|
|
|
|
2020-06-29 13:13:54 +00:00
|
|
|
# For secureboot enabled machines, use new kexec file based syscall.
|
|
|
|
# Old syscall will always fail as it does not have capability to
|
|
|
|
# to kernel signature verification.
|
|
|
|
if is_secure_boot_enforced; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Secure Boot is enabled. Using kexec file based syscall."
|
2014-09-08 15:35:22 +00:00
|
|
|
KEXEC_ARGS="$KEXEC_ARGS -s"
|
2021-02-18 06:01:18 +00:00
|
|
|
load_kdump_kernel_key
|
2014-09-08 15:35:22 +00:00
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
ddebug "$KEXEC $KEXEC_ARGS $standard_kexec_args --command-line=$KDUMP_COMMANDLINE --initrd=$TARGET_INITRD $KDUMP_KERNEL"
|
|
|
|
|
2020-10-29 02:21:09 +00:00
|
|
|
# The '12' represents an intermediate temporary file descriptor
|
|
|
|
# to store the standard error file descriptor '2', and later
|
|
|
|
# restore the error file descriptor with the file descriptor '12'
|
|
|
|
# and release it.
|
2020-10-27 09:04:24 +00:00
|
|
|
exec 12>&2
|
|
|
|
exec 2>> $KDUMP_LOG_PATH/kdump.log
|
2022-08-24 08:16:14 +00:00
|
|
|
chmod 600 $KDUMP_LOG_PATH/kdump.log
|
2020-10-27 09:04:24 +00:00
|
|
|
PS4='+ $(date "+%Y-%m-%d %H:%M:%S") ${BASH_SOURCE}@${LINENO}: '
|
|
|
|
set -x
|
|
|
|
|
2021-09-08 09:21:41 +00:00
|
|
|
# shellcheck disable=SC2086
|
2011-07-06 19:25:34 +00:00
|
|
|
$KEXEC $KEXEC_ARGS $standard_kexec_args \
|
|
|
|
--command-line="$KDUMP_COMMANDLINE" \
|
2021-09-08 09:21:41 +00:00
|
|
|
--initrd="$TARGET_INITRD" "$KDUMP_KERNEL"
|
2020-10-27 09:04:24 +00:00
|
|
|
|
|
|
|
ret=$?
|
|
|
|
set +x
|
|
|
|
exec 2>&12 12>&-
|
|
|
|
|
2021-02-18 06:01:18 +00:00
|
|
|
remove_kdump_kernel_key
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $ret == 0 ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "kexec: loaded kdump kernel"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 0
|
|
|
|
else
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "kexec: failed to load kdump kernel"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_ssh_config()
|
2012-02-22 03:16:09 +00:00
|
|
|
{
|
2022-03-25 14:47:03 +00:00
|
|
|
local target
|
2021-08-17 18:04:45 +00:00
|
|
|
|
2022-03-25 14:47:09 +00:00
|
|
|
[[ "${OPT[_fstype]}" == ssh ]] || return 0
|
2012-02-22 03:16:09 +00:00
|
|
|
|
2022-03-25 14:47:09 +00:00
|
|
|
target=$(ssh -G "${OPT[_target]}" | sed -n -e "s/^hostname[[:space:]]\+\([^[:space:]]*\).*$/\1/p")
|
|
|
|
[[ ${OPT[_target]} =~ .*@.* ]] || return 1
|
|
|
|
if [[ ${OPT[_target]#*@} != "$target" ]]; then
|
|
|
|
derror "Invalid ssh destination ${OPT[_target]} provided."
|
2012-02-22 03:16:09 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2022-03-25 14:47:03 +00:00
|
|
|
|
2012-02-22 03:16:09 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2019-08-12 08:07:39 +00:00
|
|
|
# ipv6 host address may takes a long time to be ready.
|
|
|
|
# Instead of checking against ipv6 address, we just check the network reachable
|
|
|
|
# by the return val of 'ssh'
|
|
|
|
check_and_wait_network_ready()
|
|
|
|
{
|
2021-08-17 18:04:45 +00:00
|
|
|
local start_time
|
2019-09-24 03:19:12 +00:00
|
|
|
local warn_once=1
|
2019-08-12 08:07:39 +00:00
|
|
|
local cur
|
|
|
|
local diff
|
2019-08-28 07:22:22 +00:00
|
|
|
local retval
|
|
|
|
local errmsg
|
2019-08-12 08:07:39 +00:00
|
|
|
|
2022-03-25 14:47:09 +00:00
|
|
|
[[ "${OPT[_fstype]}" == ssh ]] || return 0
|
2022-03-25 14:47:05 +00:00
|
|
|
|
2021-08-17 18:04:45 +00:00
|
|
|
start_time=$(date +%s)
|
2019-08-12 08:07:39 +00:00
|
|
|
while true; do
|
2022-03-25 14:47:09 +00:00
|
|
|
errmsg=$(ssh -i "${OPT[sshkey]}" -o BatchMode=yes "${OPT[_target]}" mkdir -p "${OPT[path]}" 2>&1)
|
2019-08-28 07:22:22 +00:00
|
|
|
retval=$?
|
|
|
|
|
2019-08-12 08:07:39 +00:00
|
|
|
# ssh exits with the exit status of the remote command or with 255 if an error occurred
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $retval -eq 0 ]]; then
|
2019-08-12 08:07:39 +00:00
|
|
|
return 0
|
2021-09-08 09:20:51 +00:00
|
|
|
elif [[ $retval -ne 255 ]]; then
|
2022-03-25 14:47:09 +00:00
|
|
|
derror "Could not create ${OPT[_target]}:${OPT[path]}, you should check the privilege on server side"
|
2019-08-12 08:07:39 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2019-08-28 07:22:22 +00:00
|
|
|
|
|
|
|
# if server removes the authorized_keys or, no /root/.ssh/kdump_id_rsa
|
2020-10-27 09:04:22 +00:00
|
|
|
ddebug "$errmsg"
|
2021-09-08 09:23:16 +00:00
|
|
|
if echo "$errmsg" | grep -q "Permission denied\|No such file or directory\|Host key verification failed"; then
|
2022-03-25 14:47:09 +00:00
|
|
|
derror "Could not create ${OPT[_target]}:${OPT[path]}, you probably need to run \"kdumpctl propagate\""
|
2019-08-28 07:22:22 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $warn_once -eq 1 ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Network dump target is not usable, waiting for it to be ready..."
|
2019-09-24 03:19:12 +00:00
|
|
|
warn_once=0
|
|
|
|
fi
|
|
|
|
|
2019-08-12 08:07:39 +00:00
|
|
|
cur=$(date +%s)
|
2021-08-04 07:18:59 +00:00
|
|
|
diff=$((cur - start_time))
|
2022-03-25 14:47:02 +00:00
|
|
|
# time out after 180s
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $diff -gt 180 ]]; then
|
2021-09-13 18:25:40 +00:00
|
|
|
break
|
2019-08-12 08:07:39 +00:00
|
|
|
fi
|
|
|
|
sleep 1
|
|
|
|
done
|
|
|
|
|
2022-03-25 14:47:09 +00:00
|
|
|
dinfo "Could not create ${OPT[_target]}:${OPT[path]}, ipaddr is not ready yet. You should check network connection"
|
2019-08-12 08:07:39 +00:00
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
propagate_ssh_key()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2022-03-25 14:47:04 +00:00
|
|
|
local SSH_USER SSH_SERVER
|
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
parse_config || return 1
|
2022-03-25 14:47:05 +00:00
|
|
|
|
2022-03-25 14:47:09 +00:00
|
|
|
if [[ ${OPT[_fstype]} != ssh ]] ; then
|
2022-03-25 14:47:04 +00:00
|
|
|
derror "No ssh destination defined in $KDUMP_CONFIG_FILE."
|
|
|
|
derror "Please verify that $KDUMP_CONFIG_FILE contains 'ssh <user>@<host>' and that it is properly formatted."
|
2012-02-22 03:16:09 +00:00
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2022-03-25 14:47:08 +00:00
|
|
|
local KEYFILE=${OPT[sshkey]}
|
2011-07-06 19:25:34 +00:00
|
|
|
|
|
|
|
#Check to see if we already created key, if not, create it.
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ -f $KEYFILE ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Using existing keys..."
|
2011-07-06 19:25:34 +00:00
|
|
|
else
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Generating new ssh keys... "
|
2022-03-25 14:47:04 +00:00
|
|
|
/usr/bin/ssh-keygen -t rsa -f "$KEYFILE" -N "" &> /dev/null
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "done."
|
2011-07-06 19:25:34 +00:00
|
|
|
fi
|
|
|
|
|
2022-03-25 14:47:09 +00:00
|
|
|
SSH_USER=${OPT[_target]%@*}
|
|
|
|
SSH_SERVER=${OPT[_target]#*@}
|
|
|
|
if ssh-copy-id -i "$KEYFILE" "${OPT[_target]}"; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "$KEYFILE has been added to ~$SSH_USER/.ssh/authorized_keys on $SSH_SERVER"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 0
|
|
|
|
else
|
2022-03-25 14:47:04 +00:00
|
|
|
derror "Failed to propagate ssh key, could not transfer $KEYFILE to $SSH_SERVER"
|
2011-07-06 19:25:34 +00:00
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2018-05-11 02:02:39 +00:00
|
|
|
show_reserved_mem()
|
|
|
|
{
|
2021-09-13 18:25:40 +00:00
|
|
|
local mem
|
|
|
|
local mem_mb
|
2021-08-04 07:14:00 +00:00
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
mem=$(< /sys/kernel/kexec_crash_size)
|
|
|
|
mem_mb=$((mem / 1024 / 1024))
|
2018-05-11 02:02:39 +00:00
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
dinfo "Reserved ${mem_mb}MB memory for crash kernel"
|
2018-05-11 02:02:39 +00:00
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
check_current_fadump_status()
|
|
|
|
{
|
|
|
|
# Check if firmware-assisted dump has been registered.
|
2021-09-13 18:25:40 +00:00
|
|
|
rc=$(< $FADUMP_REGISTER_SYS_NODE)
|
2021-09-08 09:20:51 +00:00
|
|
|
[[ $rc -eq 1 ]] && return 0
|
2014-07-24 18:38:36 +00:00
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
|
|
|
check_current_status()
|
|
|
|
{
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2014-07-24 18:38:36 +00:00
|
|
|
check_current_fadump_status
|
|
|
|
else
|
|
|
|
check_current_kdump_status
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
save_raw()
|
2012-04-28 10:01:18 +00:00
|
|
|
{
|
|
|
|
local raw_target
|
|
|
|
|
2022-03-25 14:47:10 +00:00
|
|
|
[[ ${OPT[_fstype]} == raw ]] || return 0
|
|
|
|
|
|
|
|
raw_target=${OPT[_target]}
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ -b $raw_target ]] || {
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "raw partition $raw_target not found"
|
2012-04-28 10:01:18 +00:00
|
|
|
return 1
|
|
|
|
}
|
2021-09-08 09:21:41 +00:00
|
|
|
check_fs=$(lsblk --nodeps -npo FSTYPE "$raw_target")
|
|
|
|
if [[ $(echo "$check_fs" | wc -w) -ne 0 ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Warning: Detected '$check_fs' signature on $raw_target, data loss is expected."
|
2018-08-15 13:14:15 +00:00
|
|
|
return 0
|
|
|
|
fi
|
2012-04-28 10:01:18 +00:00
|
|
|
|
2022-03-25 14:47:07 +00:00
|
|
|
coredir="${OPT[path]}/$(date +"%Y-%m-%d-%H:%M")"
|
2012-04-28 10:01:18 +00:00
|
|
|
mkdir -p "$coredir"
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ -d $coredir ]] || {
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "failed to create $coredir"
|
2012-04-28 10:01:18 +00:00
|
|
|
return 1
|
|
|
|
}
|
2021-09-13 18:25:40 +00:00
|
|
|
if makedumpfile -R "$coredir/vmcore" < "$raw_target" > /dev/null 2>&1; then
|
2012-04-28 10:01:18 +00:00
|
|
|
# dump found
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Dump saved to $coredir/vmcore"
|
2012-04-28 10:01:18 +00:00
|
|
|
# wipe makedumpfile header
|
2021-09-13 18:25:40 +00:00
|
|
|
dd if=/dev/zero of="$raw_target" bs=1b count=1 2> /dev/null
|
2012-04-28 10:01:18 +00:00
|
|
|
else
|
|
|
|
rm -rf "$coredir"
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2022-03-25 14:47:11 +00:00
|
|
|
is_local_target()
|
2013-06-08 06:22:31 +00:00
|
|
|
{
|
2022-03-25 14:47:11 +00:00
|
|
|
[[ ${OPT[_fstype]} =~ ^ext[234]|^xfs|^btrfs|^minix ]]
|
2013-06-08 06:22:31 +00:00
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
path_to_be_relabeled()
|
|
|
|
{
|
2022-03-25 14:47:11 +00:00
|
|
|
local _path _mnt="/" _rmnt
|
2013-06-08 06:22:31 +00:00
|
|
|
|
2020-03-05 07:34:06 +00:00
|
|
|
if is_user_configured_dump_target; then
|
|
|
|
if is_mount_in_dracut_args; then
|
2021-09-13 18:25:40 +00:00
|
|
|
return
|
2020-03-05 07:34:06 +00:00
|
|
|
fi
|
|
|
|
|
2022-03-25 14:47:11 +00:00
|
|
|
if is_local_target; then
|
|
|
|
_mnt=$(get_mntpoint_from_target "${OPT[_target]}")
|
2020-03-12 12:57:08 +00:00
|
|
|
if ! is_mounted "$_mnt"; then
|
2013-06-08 06:22:31 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
else
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
_path=$(get_save_path)
|
|
|
|
# if $_path is masked by other mount, we will not relabel it.
|
2021-09-13 18:25:40 +00:00
|
|
|
_rmnt=$(df "$_mnt/$_path" 2> /dev/null | tail -1 | awk '{ print $NF }')
|
|
|
|
if [[ $_rmnt == "$_mnt" ]]; then
|
2021-09-08 09:21:41 +00:00
|
|
|
echo "$_mnt/$_path"
|
2013-06-08 06:22:31 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
selinux_relabel()
|
|
|
|
{
|
|
|
|
local _path _i _attr
|
|
|
|
|
|
|
|
_path=$(path_to_be_relabeled)
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $_path ]] || ! [[ -d $_path ]]; then
|
2013-06-08 06:22:31 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2021-08-04 08:22:17 +00:00
|
|
|
while IFS= read -r -d '' _i; do
|
2021-09-13 18:25:40 +00:00
|
|
|
_attr=$(getfattr -m "security.selinux" "$_i" 2> /dev/null)
|
|
|
|
if [[ -z $_attr ]]; then
|
|
|
|
restorecon "$_i"
|
2013-06-08 06:22:31 +00:00
|
|
|
fi
|
2021-08-04 08:22:17 +00:00
|
|
|
done < <(find "$_path" -print0)
|
2013-06-08 06:22:31 +00:00
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
check_fence_kdump_config()
|
2014-04-02 08:33:47 +00:00
|
|
|
{
|
2021-08-17 18:04:45 +00:00
|
|
|
local hostname
|
|
|
|
local ipaddrs
|
|
|
|
local nodes
|
|
|
|
|
|
|
|
hostname=$(hostname)
|
|
|
|
ipaddrs=$(hostname -I)
|
2022-03-25 14:47:06 +00:00
|
|
|
nodes=${OPT[fence_kdump_nodes]}
|
2014-04-02 08:33:47 +00:00
|
|
|
|
|
|
|
for node in $nodes; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ $node == "$hostname" ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Option fence_kdump_nodes cannot contain $hostname"
|
2014-04-02 08:33:47 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2017-05-17 03:16:22 +00:00
|
|
|
# node can be ipaddr
|
2021-09-08 09:23:16 +00:00
|
|
|
if echo "$ipaddrs " | grep -q "$node "; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Option fence_kdump_nodes cannot contain $node"
|
2017-05-17 03:16:22 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2014-04-02 08:33:47 +00:00
|
|
|
done
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:36 +00:00
|
|
|
check_dump_feasibility()
|
|
|
|
{
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2014-07-24 18:38:36 +00:00
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
check_kdump_feasibility
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:38:53 +00:00
|
|
|
start_fadump()
|
|
|
|
{
|
|
|
|
echo 1 > $FADUMP_REGISTER_SYS_NODE
|
|
|
|
if ! check_current_fadump_status; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "fadump: failed to register"
|
2014-07-24 18:38:53 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "fadump: registered successfully"
|
2014-07-24 18:38:53 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
start_dump()
|
|
|
|
{
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2014-07-24 18:38:53 +00:00
|
|
|
start_fadump
|
|
|
|
else
|
|
|
|
load_kdump
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2019-01-17 20:31:23 +00:00
|
|
|
check_failure_action_config()
|
2015-06-11 08:22:11 +00:00
|
|
|
{
|
|
|
|
local default_option
|
2019-01-17 20:31:23 +00:00
|
|
|
local failure_action
|
|
|
|
local option="failure_action"
|
2015-06-11 08:22:11 +00:00
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
default_option=${OPT[default]}
|
|
|
|
failure_action=${OPT[failure_action]}
|
2019-01-17 20:31:23 +00:00
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $failure_action ]] && [[ -z $default_option ]]; then
|
2015-06-11 08:22:11 +00:00
|
|
|
return 0
|
2021-09-13 18:25:40 +00:00
|
|
|
elif [[ -n $failure_action ]] && [[ -n $default_option ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Cannot specify 'failure_action' and 'default' option together"
|
2019-01-17 20:31:23 +00:00
|
|
|
return 1
|
2015-06-11 08:22:11 +00:00
|
|
|
fi
|
2019-01-17 20:31:23 +00:00
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -n $default_option ]]; then
|
2019-01-17 20:31:23 +00:00
|
|
|
option="default"
|
|
|
|
failure_action="$default_option"
|
|
|
|
fi
|
|
|
|
|
|
|
|
case "$failure_action" in
|
2021-09-13 18:25:40 +00:00
|
|
|
reboot | halt | poweroff | shell | dump_to_rootfs)
|
2019-01-17 20:31:23 +00:00
|
|
|
return 0
|
2021-09-13 18:25:40 +00:00
|
|
|
;;
|
|
|
|
*)
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo $"Usage kdump.conf: $option {reboot|halt|poweroff|shell|dump_to_rootfs}"
|
2019-01-17 20:31:23 +00:00
|
|
|
return 1
|
2021-09-13 18:25:40 +00:00
|
|
|
;;
|
2019-01-17 20:31:23 +00:00
|
|
|
esac
|
2015-06-11 08:22:11 +00:00
|
|
|
}
|
|
|
|
|
2019-01-17 20:31:24 +00:00
|
|
|
check_final_action_config()
|
|
|
|
{
|
|
|
|
local final_action
|
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
final_action=${OPT[final_action]}
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ -z $final_action ]]; then
|
2019-01-17 20:31:24 +00:00
|
|
|
return 0
|
|
|
|
else
|
|
|
|
case "$final_action" in
|
2021-09-13 18:25:40 +00:00
|
|
|
reboot | halt | poweroff)
|
2019-01-17 20:31:24 +00:00
|
|
|
return 0
|
2021-09-13 18:25:40 +00:00
|
|
|
;;
|
|
|
|
*)
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo $"Usage kdump.conf: final_action {reboot|halt|poweroff}"
|
2019-01-17 20:31:24 +00:00
|
|
|
return 1
|
2021-09-13 18:25:40 +00:00
|
|
|
;;
|
2019-01-17 20:31:24 +00:00
|
|
|
esac
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2014-07-15 06:41:54 +00:00
|
|
|
start()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! check_dump_feasibility; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2012-04-28 07:17:13 +00:00
|
|
|
return 1
|
2013-03-11 09:31:25 +00:00
|
|
|
fi
|
2012-04-28 07:17:13 +00:00
|
|
|
|
2022-03-25 14:47:06 +00:00
|
|
|
if ! parse_config; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2012-04-28 10:01:18 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
if sestatus 2> /dev/null | grep -q "SELinux status.*enabled"; then
|
2017-04-29 01:15:00 +00:00
|
|
|
selinux_relabel
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! save_raw; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2014-02-12 02:31:41 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2022-11-21 13:26:08 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "kdump" ]] && check_current_kdump_status; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Kdump already running: [WARNING]"
|
2014-02-13 03:23:58 +00:00
|
|
|
return 0
|
2011-07-06 19:25:34 +00:00
|
|
|
fi
|
2012-02-22 03:16:09 +00:00
|
|
|
|
2022-03-25 14:47:05 +00:00
|
|
|
if ! check_and_wait_network_ready; then
|
|
|
|
derror "Starting kdump: [FAILED]"
|
|
|
|
return 1
|
2013-02-18 09:05:43 +00:00
|
|
|
fi
|
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! check_rebuild; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2014-07-24 18:38:53 +00:00
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! start_dump; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Starting kdump: [OK]"
|
2011-07-06 19:25:34 +00:00
|
|
|
}
|
|
|
|
|
2018-10-23 14:13:28 +00:00
|
|
|
reload()
|
|
|
|
{
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! check_current_status; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dwarn "Kdump was not running: [WARNING]"
|
2018-10-23 14:13:28 +00:00
|
|
|
fi
|
|
|
|
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2019-02-28 04:50:29 +00:00
|
|
|
reload_fadump
|
2022-03-25 14:47:00 +00:00
|
|
|
return
|
2018-10-23 14:13:28 +00:00
|
|
|
else
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! stop_kdump; then
|
|
|
|
derror "Stopping kdump: [FAILED]"
|
|
|
|
return 1
|
|
|
|
fi
|
2018-10-23 14:13:28 +00:00
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Stopping kdump: [OK]"
|
2018-10-23 14:13:28 +00:00
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! setup_initrd; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2018-10-23 14:13:28 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
if ! start_dump; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Starting kdump: [FAILED]"
|
2018-10-23 14:13:28 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Starting kdump: [OK]"
|
2018-10-23 14:13:28 +00:00
|
|
|
}
|
|
|
|
|
2014-07-24 18:39:00 +00:00
|
|
|
stop_fadump()
|
|
|
|
{
|
|
|
|
echo 0 > $FADUMP_REGISTER_SYS_NODE
|
|
|
|
if check_current_fadump_status; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "fadump: failed to unregister"
|
2014-07-24 18:39:00 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "fadump: unregistered successfully"
|
2014-07-24 18:39:00 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
stop_kdump()
|
2011-07-06 19:25:34 +00:00
|
|
|
{
|
2020-06-29 13:13:54 +00:00
|
|
|
if is_secure_boot_enforced; then
|
2014-09-08 15:35:21 +00:00
|
|
|
$KEXEC -s -p -u
|
|
|
|
else
|
|
|
|
$KEXEC -p -u
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
# shellcheck disable=SC2181
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $? != 0 ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "kexec: failed to unload kdump kernel"
|
2014-07-24 18:39:00 +00:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "kexec: unloaded kdump kernel"
|
2014-07-24 18:39:00 +00:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2019-02-28 04:50:29 +00:00
|
|
|
reload_fadump()
|
|
|
|
{
|
2021-09-08 09:23:16 +00:00
|
|
|
if echo 1 > $FADUMP_REGISTER_SYS_NODE; then
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "fadump: re-registered successfully"
|
2019-02-28 04:50:29 +00:00
|
|
|
return 0
|
|
|
|
else
|
|
|
|
# FADump could fail on older kernel where re-register
|
|
|
|
# support is not enabled. Try stop/start from userspace
|
|
|
|
# to handle such scenario.
|
2021-09-08 09:23:16 +00:00
|
|
|
if stop_fadump; then
|
2019-02-28 04:50:29 +00:00
|
|
|
start_fadump
|
2022-03-25 14:47:00 +00:00
|
|
|
return
|
2019-02-28 04:50:29 +00:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2014-07-24 18:39:00 +00:00
|
|
|
stop()
|
|
|
|
{
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
|
2014-07-24 18:39:00 +00:00
|
|
|
stop_fadump
|
|
|
|
else
|
|
|
|
stop_kdump
|
|
|
|
fi
|
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
# shellcheck disable=SC2181
|
2021-09-08 09:20:51 +00:00
|
|
|
if [[ $? != 0 ]]; then
|
2020-10-27 09:04:22 +00:00
|
|
|
derror "Stopping kdump: [FAILED]"
|
2011-07-06 19:25:34 +00:00
|
|
|
return 1
|
|
|
|
fi
|
2014-07-24 18:39:00 +00:00
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Stopping kdump: [OK]"
|
2014-07-24 18:39:00 +00:00
|
|
|
return 0
|
2011-07-06 19:25:34 +00:00
|
|
|
}
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
rebuild()
|
|
|
|
{
|
2022-03-25 14:47:06 +00:00
|
|
|
parse_config || return 1
|
2022-03-25 14:47:05 +00:00
|
|
|
check_and_wait_network_ready || return 1
|
2019-05-27 06:46:49 +00:00
|
|
|
|
2021-09-08 09:23:16 +00:00
|
|
|
setup_initrd || return 1
|
2019-03-29 03:29:30 +00:00
|
|
|
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Rebuilding $TARGET_INITRD"
|
2019-03-29 03:29:30 +00:00
|
|
|
rebuild_initrd
|
|
|
|
}
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
do_estimate()
|
|
|
|
{
|
2021-04-21 19:27:10 +00:00
|
|
|
local kdump_mods
|
|
|
|
local -A large_mods
|
|
|
|
local baseline
|
2022-09-05 10:08:44 +00:00
|
|
|
local kernel_size mod_size initrd_size baseline_size runtime_size reserved_size estimated_size recommended_size _cryptsetup_overhead
|
2021-09-13 18:25:40 +00:00
|
|
|
local size_mb=$((1024 * 1024))
|
2021-04-21 19:27:10 +00:00
|
|
|
|
|
|
|
setup_initrd
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ! -f $TARGET_INITRD ]]; then
|
2021-04-21 19:27:10 +00:00
|
|
|
derror "kdumpctl estimate: kdump initramfs is not built yet."
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
kdump_mods="$(lsinitrd "$TARGET_INITRD" -f /usr/lib/dracut/hostonly-kernel-modules.txt | tr '\n' ' ')"
|
|
|
|
baseline=$(kdump_get_arch_recommend_size)
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ${baseline: -1} == "M" ]]; then
|
2021-04-21 19:27:10 +00:00
|
|
|
baseline=${baseline%M}
|
2021-09-13 18:25:40 +00:00
|
|
|
elif [[ ${baseline: -1} == "G" ]]; then
|
|
|
|
baseline=$((${baseline%G} * 1024))
|
|
|
|
elif [[ ${baseline: -1} == "T" ]]; then
|
|
|
|
baseline=$((${baseline%Y} * 1048576))
|
2021-04-21 19:27:10 +00:00
|
|
|
fi
|
|
|
|
|
2021-07-30 06:40:45 +00:00
|
|
|
# The default pre-reserved crashkernel value
|
2021-04-21 19:27:10 +00:00
|
|
|
baseline_size=$((baseline * size_mb))
|
|
|
|
# Current reserved crashkernel size
|
2021-09-13 18:25:40 +00:00
|
|
|
reserved_size=$(< /sys/kernel/kexec_crash_size)
|
2021-04-21 19:27:10 +00:00
|
|
|
# A pre-estimated value for userspace usage and kernel
|
|
|
|
# runtime allocation, 64M should good for most cases
|
|
|
|
runtime_size=$((64 * size_mb))
|
|
|
|
# Kernel image size
|
|
|
|
kernel_size=$(get_kernel_size "$KDUMP_KERNEL")
|
|
|
|
# Kdump initramfs size
|
|
|
|
initrd_size=$(du -b "$TARGET_INITRD" | awk '{print $1}')
|
|
|
|
# Kernel modules static size after loaded
|
|
|
|
mod_size=0
|
|
|
|
while read -r _name _size _; do
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ " $kdump_mods " != *" $_name "* ]]; then
|
2021-04-21 19:27:10 +00:00
|
|
|
continue
|
|
|
|
fi
|
|
|
|
mod_size=$((mod_size + _size))
|
|
|
|
|
|
|
|
# Mark module with static size larger than 2M as large module
|
|
|
|
if [[ $((_size / size_mb)) -ge 1 ]]; then
|
|
|
|
large_mods[$_name]=$_size
|
|
|
|
fi
|
|
|
|
done <<< "$(< /proc/modules)"
|
|
|
|
|
|
|
|
# Extra memory usage required for LUKS2 decryption
|
|
|
|
crypt_size=0
|
|
|
|
for _dev in $(get_all_kdump_crypt_dev); do
|
|
|
|
_crypt_info=$(cryptsetup luksDump "/dev/block/$_dev")
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ $(echo "$_crypt_info" | sed -n "s/^Version:\s*\(.*\)/\1/p") == "2" ]] || continue
|
2022-09-05 09:49:18 +00:00
|
|
|
for _mem in $(echo "$_crypt_info" | sed -n "s/\sMemory:\s*\(.*\)/\1/p" | sort -n -r); do
|
2021-04-21 19:27:10 +00:00
|
|
|
crypt_size=$((crypt_size + _mem * 1024))
|
|
|
|
break
|
|
|
|
done
|
|
|
|
done
|
2022-09-05 10:08:44 +00:00
|
|
|
|
|
|
|
if [[ $crypt_size -ne 0 ]]; then
|
|
|
|
if [[ $(uname -m) == aarch64 ]]; then
|
|
|
|
_cryptsetup_overhead=50
|
|
|
|
else
|
|
|
|
_cryptsetup_overhead=20
|
|
|
|
fi
|
|
|
|
|
|
|
|
crypt_size=$((crypt_size + _cryptsetup_overhead * size_mb))
|
|
|
|
echo -e "Encrypted kdump target requires extra memory, assuming using the keyslot with maximum memory requirement\n"
|
|
|
|
fi
|
2021-04-21 19:27:10 +00:00
|
|
|
|
|
|
|
estimated_size=$((kernel_size + mod_size + initrd_size + runtime_size + crypt_size))
|
|
|
|
if [[ $baseline_size -gt $estimated_size ]]; then
|
2021-07-14 19:08:28 +00:00
|
|
|
recommended_size=$baseline_size
|
2021-04-21 19:27:10 +00:00
|
|
|
else
|
2021-07-14 19:08:28 +00:00
|
|
|
recommended_size=$estimated_size
|
2021-04-21 19:27:10 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
echo "Reserved crashkernel: $((reserved_size / size_mb))M"
|
2021-07-14 19:08:28 +00:00
|
|
|
echo "Recommended crashkernel: $((recommended_size / size_mb))M"
|
2021-04-21 19:27:10 +00:00
|
|
|
echo
|
|
|
|
echo "Kernel image size: $((kernel_size / size_mb))M"
|
|
|
|
echo "Kernel modules size: $((mod_size / size_mb))M"
|
|
|
|
echo "Initramfs size: $((initrd_size / size_mb))M"
|
|
|
|
echo "Runtime reservation: $((runtime_size / size_mb))M"
|
2021-09-13 18:25:40 +00:00
|
|
|
[[ $crypt_size -ne 0 ]] &&
|
|
|
|
echo "LUKS required size: $((crypt_size / size_mb))M"
|
2021-04-21 19:27:10 +00:00
|
|
|
echo -n "Large modules:"
|
2021-09-13 18:25:40 +00:00
|
|
|
if [[ ${#large_mods[@]} -eq 0 ]]; then
|
2021-04-21 19:27:10 +00:00
|
|
|
echo " <none>"
|
|
|
|
else
|
|
|
|
echo ""
|
|
|
|
for _mod in "${!large_mods[@]}"; do
|
|
|
|
echo " $_mod: ${large_mods[$_mod]}"
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
|
2022-03-25 15:19:40 +00:00
|
|
|
if [[ $reserved_size -lt $recommended_size ]]; then
|
2021-07-14 19:08:28 +00:00
|
|
|
echo "WARNING: Current crashkernel size is lower than recommended size $((recommended_size / size_mb))M."
|
2021-04-21 19:27:10 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2021-11-16 04:23:02 +00:00
|
|
|
get_default_crashkernel()
|
|
|
|
{
|
|
|
|
local _dump_mode=$1
|
|
|
|
|
|
|
|
kdump_get_arch_recommend_crashkernel "$_dump_mode"
|
|
|
|
}
|
|
|
|
|
2021-11-15 22:48:40 +00:00
|
|
|
# Read kernel cmdline parameter for a specific kernel
|
|
|
|
# $1: kernel path, DEFAULT or kernel path, ALL not accepted
|
|
|
|
# $2: kernel cmldine parameter
|
|
|
|
get_grub_kernel_boot_parameter()
|
|
|
|
{
|
|
|
|
local _kernel_path=$1 _para=$2
|
|
|
|
|
|
|
|
[[ $_kernel_path == ALL ]] && derror "kernel_path=ALL invalid for get_grub_kernel_boot_parameter" && return 1
|
|
|
|
grubby --info="$_kernel_path" | sed -En -e "/^args=.*$/{s/^.*(\s|\")${_para}=(\S*).*\"$/\2/p;q}"
|
|
|
|
}
|
|
|
|
|
2021-12-01 08:57:15 +00:00
|
|
|
# get dump mode by fadump value
|
|
|
|
# return
|
|
|
|
# - fadump, if fadump=on or fadump=nocma
|
|
|
|
# - kdump, if fadump=off or empty fadump, return kdump
|
|
|
|
# - error if otherwise
|
|
|
|
get_dump_mode_by_fadump_val()
|
|
|
|
{
|
|
|
|
local _fadump_val=$1
|
|
|
|
|
|
|
|
if [[ -z $_fadump_val ]] || [[ $_fadump_val == off ]]; then
|
|
|
|
echo -n kdump
|
|
|
|
elif [[ $_fadump_val == on ]] || [[ $_fadump_val == nocma ]]; then
|
|
|
|
echo -n fadump
|
|
|
|
else
|
|
|
|
derror "invalid fadump=$_fadump_val"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# get dump mode of a specific kernel
|
|
|
|
# based on its fadump kernel cmdline parameter
|
|
|
|
get_dump_mode_by_kernel()
|
|
|
|
{
|
|
|
|
local _kernel_path=$1 _fadump_val _dump_mode
|
|
|
|
|
|
|
|
_fadump_val=$(get_grub_kernel_boot_parameter "$_kernel_path" fadump)
|
|
|
|
if _dump_mode=$(get_dump_mode_by_fadump_val "$_fadump_val"); then
|
|
|
|
echo -n "$_dump_mode"
|
|
|
|
else
|
|
|
|
derror "failed to get dump mode for kernel $_kernel_path"
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2021-12-07 07:16:07 +00:00
|
|
|
_filter_grubby_kernel_str()
|
|
|
|
{
|
|
|
|
local _grubby_kernel_str=$1
|
|
|
|
echo -n "$_grubby_kernel_str" | sed -n -e 's/^kernel="\(.*\)"/\1/p'
|
|
|
|
}
|
|
|
|
|
|
|
|
_find_kernel_path_by_release()
|
|
|
|
{
|
|
|
|
local _release="$1" _grubby_kernel_str _kernel_path
|
2022-11-24 01:15:25 +00:00
|
|
|
_grubby_kernel_str=$(grubby --info ALL | grep "^kernel=.*$_release\"$")
|
2021-12-07 07:16:07 +00:00
|
|
|
_kernel_path=$(_filter_grubby_kernel_str "$_grubby_kernel_str")
|
|
|
|
if [[ -z $_kernel_path ]]; then
|
|
|
|
derror "kernel $_release doesn't exist"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
echo -n "$_kernel_path"
|
|
|
|
}
|
|
|
|
|
|
|
|
_get_current_running_kernel_path()
|
|
|
|
{
|
|
|
|
local _release _path
|
|
|
|
|
|
|
|
_release=$(uname -r)
|
|
|
|
if _path=$(_find_kernel_path_by_release "$_release"); then
|
|
|
|
echo -n "$_path"
|
|
|
|
else
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2022-07-12 08:07:37 +00:00
|
|
|
_update_kernel_cmdline()
|
2021-09-13 18:25:40 +00:00
|
|
|
{
|
2021-12-01 05:39:40 +00:00
|
|
|
local _kernel_path=$1 _crashkernel=$2 _dump_mode=$3 _fadump_val=$4
|
2021-06-10 05:06:22 +00:00
|
|
|
|
2022-06-22 15:58:31 +00:00
|
|
|
if is_ostree; then
|
2021-12-01 05:39:40 +00:00
|
|
|
if rpm-ostree kargs | grep -q "crashkernel="; then
|
|
|
|
rpm-ostree kargs --replace="crashkernel=$_crashkernel"
|
|
|
|
else
|
|
|
|
rpm-ostree kargs --append="crashkernel=$_crashkernel"
|
|
|
|
fi
|
|
|
|
else
|
2022-07-12 08:07:37 +00:00
|
|
|
grubby --args "crashkernel=$_crashkernel" --update-kernel "$_kernel_path"
|
2021-12-01 05:39:40 +00:00
|
|
|
if [[ $_dump_mode == kdump ]]; then
|
|
|
|
grubby --remove-args="fadump" --update-kernel "$_kernel_path"
|
|
|
|
else
|
|
|
|
grubby --args="fadump=$_fadump_val" --update-kernel "$_kernel_path"
|
|
|
|
fi
|
|
|
|
fi
|
2022-07-12 08:07:37 +00:00
|
|
|
[[ -f /etc/zipl.conf ]] && zipl > /dev/null
|
2021-12-01 05:39:40 +00:00
|
|
|
}
|
2021-06-10 05:06:22 +00:00
|
|
|
|
2021-12-01 05:39:40 +00:00
|
|
|
_valid_grubby_kernel_path()
|
|
|
|
{
|
|
|
|
[[ -n "$1" ]] && grubby --info="$1" > /dev/null 2>&1
|
|
|
|
}
|
|
|
|
|
2022-02-09 00:04:39 +00:00
|
|
|
# return all the kernel paths given a grubby kernel-path
|
|
|
|
#
|
|
|
|
# $1: kernel path accepted by grubby, e.g. DEFAULT, ALL,
|
|
|
|
# /boot/vmlinuz-`uname -r`
|
|
|
|
# return: kernel paths separated by space
|
2021-12-01 05:39:40 +00:00
|
|
|
_get_all_kernels_from_grubby()
|
|
|
|
{
|
|
|
|
local _kernels _line _kernel_path _grubby_kernel_path=$1
|
|
|
|
|
|
|
|
for _line in $(grubby --info "$_grubby_kernel_path" | grep "^kernel="); do
|
|
|
|
_kernel_path=$(_filter_grubby_kernel_str "$_line")
|
|
|
|
_kernels="$_kernels $_kernel_path"
|
|
|
|
done
|
|
|
|
echo -n "$_kernels"
|
|
|
|
}
|
|
|
|
|
|
|
|
GRUB_ETC_DEFAULT="/etc/default/grub"
|
2022-02-15 05:24:19 +00:00
|
|
|
# Update a kernel parameter in default grub conf
|
|
|
|
#
|
|
|
|
# If a value is specified, it will be inserted in the end. Otherwise it
|
|
|
|
# would remove given kernel parameter.
|
|
|
|
#
|
|
|
|
# Note this function doesn't address the following cases,
|
|
|
|
# 1. The kernel ignores everything on the command line after a '--'. So
|
|
|
|
# simply adding the new entry to the end will fail if the cmdline
|
|
|
|
# contains a --.
|
|
|
|
# 2. If the value for a parameter contains spaces it can be quoted using
|
|
|
|
# double quotes, for example param="value with spaces". This will
|
|
|
|
# break the [^[:space:]\"] regex for the value.
|
|
|
|
# 3. Dashes and underscores in the parameter name are equivalent. So
|
|
|
|
# some_parameter and some-parameter are identical.
|
|
|
|
# 4. Some parameters, e.g. efivar_ssdt, can be given multiple times.
|
|
|
|
# 5. Some kernel parameters, e.g. quiet, doesn't have value
|
2021-12-01 05:39:40 +00:00
|
|
|
#
|
|
|
|
# $1: the name of the kernel command line parameter
|
2022-02-15 05:24:19 +00:00
|
|
|
# $2: new value. If empty, given parameter would be removed
|
|
|
|
_update_kernel_arg_in_grub_etc_default()
|
2021-12-01 05:39:40 +00:00
|
|
|
{
|
2022-02-15 05:24:19 +00:00
|
|
|
local _para=$1 _val=$2 _para_val
|
2021-12-01 05:39:40 +00:00
|
|
|
|
2022-07-12 06:06:25 +00:00
|
|
|
if [[ $(uname -m) == s390x ]]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2021-12-01 05:39:40 +00:00
|
|
|
if [[ -n $_val ]]; then
|
|
|
|
_para_val="$_para=$_val"
|
2021-06-10 05:06:22 +00:00
|
|
|
fi
|
|
|
|
|
2022-02-15 05:24:19 +00:00
|
|
|
# Update the command line /etc/default/grub, i.e.
|
|
|
|
# on the line that starts with 'GRUB_CMDLINE_LINUX=',
|
|
|
|
# 1) remove $para=$val if the it's the first arg
|
|
|
|
# 2) remove all occurences of $para=$val
|
|
|
|
# 3) insert $_para_val to end
|
|
|
|
# 4) remove duplicate spaces left over by 1) or 2) or 3)
|
|
|
|
# 5) remove space at the beginning of the string left over by 1) or 2) or 3)
|
|
|
|
# 6) remove space at the end of the string left over by 1) or 2) or 3)
|
|
|
|
sed -i -E "/^GRUB_CMDLINE_LINUX=/ {
|
|
|
|
s/\"${_para}=[^[:space:]\"]*/\"/g;
|
|
|
|
s/[[:space:]]+${_para}=[^[:space:]\"]*/ /g;
|
|
|
|
s/\"$/ ${_para_val}\"/
|
|
|
|
s/[[:space:]]+/ /g;
|
|
|
|
s/(\")[[:space:]]+/\1/g;
|
|
|
|
s/[[:space:]]+(\")/\1/g;
|
|
|
|
}" "$GRUB_ETC_DEFAULT"
|
2021-12-01 05:39:40 +00:00
|
|
|
}
|
|
|
|
|
2022-02-16 01:42:54 +00:00
|
|
|
# Read the kernel arg in default grub conf.
|
|
|
|
|
|
|
|
# Note reading a kernel parameter that doesn't have a value isn't supported.
|
|
|
|
#
|
|
|
|
# $1: the name of the kernel command line parameter
|
|
|
|
_read_kernel_arg_in_grub_etc_default()
|
|
|
|
{
|
|
|
|
sed -n -E "s/^GRUB_CMDLINE_LINUX=.*[[:space:]\"]${1}=([^[:space:]\"]*).*$/\1/p" "$GRUB_ETC_DEFAULT"
|
|
|
|
}
|
|
|
|
|
2021-12-01 05:39:40 +00:00
|
|
|
reset_crashkernel()
|
|
|
|
{
|
|
|
|
local _opt _val _dump_mode _fadump_val _reboot _grubby_kernel_path _kernel _kernels
|
|
|
|
local _old_crashkernel _new_crashkernel _new_dump_mode _crashkernel_changed
|
|
|
|
local _new_fadump_val _old_fadump_val _what_is_updated
|
|
|
|
|
|
|
|
for _opt in "$@"; do
|
|
|
|
case "$_opt" in
|
|
|
|
--fadump=*)
|
|
|
|
_val=${_opt#*=}
|
|
|
|
if _dump_mode=$(get_dump_mode_by_fadump_val $_val); then
|
|
|
|
_fadump_val=$_val
|
|
|
|
else
|
|
|
|
derror "failed to determine dump mode"
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
--kernel=*)
|
|
|
|
_val=${_opt#*=}
|
|
|
|
if ! _valid_grubby_kernel_path $_val; then
|
|
|
|
derror "Invalid $_opt, please specify a valid kernel path, ALL or DEFAULT"
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
_grubby_kernel_path=$_val
|
|
|
|
;;
|
|
|
|
--reboot)
|
|
|
|
_reboot=yes
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
derror "$_opt not recognized"
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
2022-06-22 15:58:31 +00:00
|
|
|
# 1. OSTree systems use "rpm-ostree kargs" instead of grubby to manage kernel command
|
|
|
|
# line. --kernel=ALL doesn't make sense for OStree.
|
|
|
|
# 2. We don't have any OSTree POWER systems so the dump mode is always kdump.
|
2021-12-01 05:39:40 +00:00
|
|
|
# 3. "rpm-ostree kargs" would prompt the user to reboot the system after
|
|
|
|
# modifying the kernel command line so there is no need for kexec-tools
|
|
|
|
# to repeat it.
|
2022-06-22 15:58:31 +00:00
|
|
|
if is_ostree; then
|
2021-12-01 05:39:40 +00:00
|
|
|
_old_crashkernel=$(rpm-ostree kargs | sed -n -E 's/.*(^|\s)crashkernel=(\S*).*/\2/p')
|
|
|
|
_new_dump_mode=kdump
|
|
|
|
_new_crashkernel=$(kdump_get_arch_recommend_crashkernel "$_new_dump_mode")
|
|
|
|
if [[ $_old_crashkernel != "$_new_crashkernel" ]]; then
|
2022-07-12 08:07:37 +00:00
|
|
|
_update_kernel_cmdline "" "$_new_crashkernel" "$_new_dump_mode" ""
|
2021-12-01 05:39:40 +00:00
|
|
|
if [[ $_reboot == yes ]]; then
|
|
|
|
systemctl reboot
|
|
|
|
fi
|
2021-06-10 05:06:22 +00:00
|
|
|
fi
|
2021-12-01 05:39:40 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
# For non-ppc64le systems, the dump mode is always kdump since only ppc64le
|
|
|
|
# has FADump.
|
|
|
|
if [[ -z $_dump_mode && $(uname -m) != ppc64le ]]; then
|
|
|
|
_dump_mode=kdump
|
|
|
|
_fadump_val=off
|
|
|
|
fi
|
|
|
|
|
|
|
|
# If the dump mode is determined, we can also know the default crashkernel value
|
|
|
|
if [[ -n $_dump_mode ]]; then
|
|
|
|
_crashkernel=$(kdump_get_arch_recommend_crashkernel "$_dump_mode")
|
|
|
|
fi
|
|
|
|
|
|
|
|
# If --kernel-path=ALL, update GRUB_CMDLINE_LINUX in /etc/default/grub.
|
|
|
|
#
|
|
|
|
# An exception case is when the ppc64le user doesn't specify the fadump value.
|
|
|
|
# In this case, the dump mode would be determined by parsing the kernel
|
|
|
|
# command line of the kernel(s) to be updated thus don't update GRUB_CMDLINE_LINUX.
|
|
|
|
#
|
|
|
|
# The following code has been simplified because of what has been done early,
|
|
|
|
# - set the dump mode as kdump for non-ppc64le cases
|
|
|
|
# - retrieved the default crashkernel value for given dump mode
|
|
|
|
if [[ $_grubby_kernel_path == ALL && -n $_dump_mode ]]; then
|
2022-02-15 05:24:19 +00:00
|
|
|
_update_kernel_arg_in_grub_etc_default crashkernel "$_crashkernel"
|
2021-12-01 05:39:40 +00:00
|
|
|
# remove the fadump if fadump is disabled
|
2022-02-15 05:24:19 +00:00
|
|
|
if [[ $_fadump_val == off ]]; then
|
|
|
|
_fadump_val=""
|
|
|
|
fi
|
|
|
|
_update_kernel_arg_in_grub_etc_default fadump "$_fadump_val"
|
2021-12-01 05:39:40 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
# If kernel-path not specified, either
|
|
|
|
# - use KDUMP_KERNELVER if it's defined
|
|
|
|
# - use current running kernel
|
|
|
|
if [[ -z $_grubby_kernel_path ]]; then
|
|
|
|
if [[ -z $KDUMP_KERNELVER ]] ||
|
|
|
|
! _kernel_path=$(_find_kernel_path_by_release "$KDUMP_KERNELVER"); then
|
|
|
|
if ! _kernel_path=$(_get_current_running_kernel_path); then
|
|
|
|
derror "no running kernel found"
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
_kernels=$_kernel_path
|
2021-06-10 05:06:22 +00:00
|
|
|
else
|
2021-12-01 05:39:40 +00:00
|
|
|
_kernels=$(_get_all_kernels_from_grubby "$_grubby_kernel_path")
|
|
|
|
fi
|
2021-06-10 05:06:22 +00:00
|
|
|
|
2021-12-01 05:39:40 +00:00
|
|
|
for _kernel in $_kernels; do
|
|
|
|
if [[ -z $_dump_mode ]]; then
|
|
|
|
_new_dump_mode=$(get_dump_mode_by_kernel "$_kernel")
|
|
|
|
_new_crashkernel=$(kdump_get_arch_recommend_crashkernel "$_new_dump_mode")
|
|
|
|
_new_fadump_val=$(get_grub_kernel_boot_parameter "$_kernel" fadump)
|
|
|
|
else
|
|
|
|
_new_dump_mode=$_dump_mode
|
|
|
|
_new_crashkernel=$_crashkernel
|
|
|
|
_new_fadump_val=$_fadump_val
|
2021-06-10 05:06:22 +00:00
|
|
|
fi
|
|
|
|
|
2021-12-01 05:39:40 +00:00
|
|
|
_old_crashkernel=$(get_grub_kernel_boot_parameter "$_kernel" crashkernel)
|
|
|
|
_old_fadump_val=$(get_grub_kernel_boot_parameter "$_kernel" fadump)
|
|
|
|
if [[ $_old_crashkernel != "$_new_crashkernel" || $_old_fadump_val != "$_new_fadump_val" ]]; then
|
2022-07-12 08:07:37 +00:00
|
|
|
_update_kernel_cmdline "$_kernel" "$_new_crashkernel" "$_new_dump_mode" "$_new_fadump_val"
|
2021-12-01 05:39:40 +00:00
|
|
|
if [[ $_reboot != yes ]]; then
|
|
|
|
if [[ $_old_crashkernel != "$_new_crashkernel" ]]; then
|
|
|
|
_what_is_updated="Updated crashkernel=$_new_crashkernel"
|
|
|
|
else
|
|
|
|
# This case happens only when switching between fadump=on and fadump=nocma
|
|
|
|
_what_is_updated="Updated fadump=$_new_fadump_val"
|
|
|
|
fi
|
|
|
|
dwarn "$_what_is_updated for kernel=$_kernel. Please reboot the system for the change to take effect."
|
|
|
|
fi
|
|
|
|
_crashkernel_changed=yes
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
|
|
|
|
if [[ $_reboot == yes && $_crashkernel_changed == yes ]]; then
|
|
|
|
reboot
|
2021-06-10 05:06:22 +00:00
|
|
|
fi
|
2021-08-03 11:49:51 +00:00
|
|
|
}
|
2021-06-10 05:06:22 +00:00
|
|
|
|
2022-12-20 05:59:18 +00:00
|
|
|
_is_bootloader_installed()
|
2022-09-08 06:30:02 +00:00
|
|
|
{
|
2022-12-20 05:59:18 +00:00
|
|
|
if [[ $(uname -r) == s390x ]]; then
|
|
|
|
test -f /etc/zipl.conf
|
|
|
|
else
|
|
|
|
test -f /boot/grub2/grub.cfg
|
|
|
|
fi
|
2022-09-08 06:30:02 +00:00
|
|
|
}
|
|
|
|
|
2022-02-16 01:42:54 +00:00
|
|
|
# update the crashkernel value in GRUB_ETC_DEFAULT if necessary
|
|
|
|
#
|
|
|
|
# called by reset_crashkernel_after_update and inherit its array variable
|
|
|
|
# _crashkernel_vals
|
|
|
|
update_crashkernel_in_grub_etc_default_after_update()
|
|
|
|
{
|
|
|
|
local _crashkernel _fadump_val
|
|
|
|
local _dump_mode _old_default_crashkernel _new_default_crashkernel
|
|
|
|
|
2022-09-29 04:35:00 +00:00
|
|
|
if [[ $(uname -m) == s390x ]]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2022-02-16 01:42:54 +00:00
|
|
|
_crashkernel=$(_read_kernel_arg_in_grub_etc_default crashkernel)
|
|
|
|
|
|
|
|
if [[ -z $_crashkernel ]]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
_fadump_val=$(_read_kernel_arg_in_grub_etc_default fadump)
|
|
|
|
_dump_mode=$(get_dump_mode_by_fadump_val "$_fadump_val")
|
|
|
|
|
|
|
|
_old_default_crashkernel=${_crashkernel_vals[old_${_dump_mode}]}
|
|
|
|
_new_default_crashkernel=${_crashkernel_vals[new_${_dump_mode}]}
|
|
|
|
|
|
|
|
if [[ $_crashkernel == auto ]] ||
|
|
|
|
[[ $_crashkernel == "$_old_default_crashkernel" &&
|
|
|
|
$_new_default_crashkernel != "$_old_default_crashkernel" ]]; then
|
|
|
|
_update_kernel_arg_in_grub_etc_default crashkernel "$_new_default_crashkernel"
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-01 07:33:13 +00:00
|
|
|
# shellcheck disable=SC2154 # false positive when dereferencing an array
|
|
|
|
reset_crashkernel_after_update()
|
|
|
|
{
|
|
|
|
local _kernel _crashkernel _dump_mode _fadump_val _old_default_crashkernel _new_default_crashkernel
|
|
|
|
declare -A _crashkernel_vals
|
|
|
|
|
2022-12-20 05:59:18 +00:00
|
|
|
if ! _is_bootloader_installed; then
|
2022-11-18 09:11:25 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-01 07:33:13 +00:00
|
|
|
_crashkernel_vals[old_kdump]=$(cat /tmp/old_default_crashkernel 2> /dev/null)
|
|
|
|
_crashkernel_vals[old_fadump]=$(cat /tmp/old_default_crashkernel_fadump 2> /dev/null)
|
|
|
|
_crashkernel_vals[new_kdump]=$(get_default_crashkernel kdump)
|
|
|
|
_crashkernel_vals[new_fadump]=$(get_default_crashkernel fadump)
|
|
|
|
|
2022-02-09 00:04:39 +00:00
|
|
|
for _kernel in $(_get_all_kernels_from_grubby ALL); do
|
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-01 07:33:13 +00:00
|
|
|
_crashkernel=$(get_grub_kernel_boot_parameter "$_kernel" crashkernel)
|
|
|
|
if [[ $_crashkernel == auto ]]; then
|
|
|
|
reset_crashkernel "--kernel=$_kernel"
|
|
|
|
elif [[ -n $_crashkernel ]]; then
|
|
|
|
_dump_mode=$(get_dump_mode_by_kernel "$_kernel")
|
|
|
|
_old_default_crashkernel=${_crashkernel_vals[old_${_dump_mode}]}
|
|
|
|
_new_default_crashkernel=${_crashkernel_vals[new_${_dump_mode}]}
|
|
|
|
if [[ $_crashkernel == "$_old_default_crashkernel" ]] &&
|
|
|
|
[[ $_new_default_crashkernel != "$_old_default_crashkernel" ]]; then
|
|
|
|
_fadump_val=$(get_grub_kernel_boot_parameter "$_kernel" fadump)
|
2022-07-12 08:07:37 +00:00
|
|
|
if _update_kernel_cmdline "$_kernel" "$_new_default_crashkernel" "$_dump_mode" "$_fadump_val"; then
|
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-01 07:33:13 +00:00
|
|
|
echo "For kernel=$_kernel, crashkernel=$_new_default_crashkernel now."
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
done
|
2022-02-16 01:42:54 +00:00
|
|
|
|
|
|
|
update_crashkernel_in_grub_etc_default_after_update
|
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-01 07:33:13 +00:00
|
|
|
}
|
|
|
|
|
2022-01-19 03:16:29 +00:00
|
|
|
# read the value of an environ variable from given environ file path
|
|
|
|
#
|
|
|
|
# The environment variable entries in /proc/[pid]/environ are separated
|
|
|
|
# by null bytes instead of by spaces.
|
2022-02-07 00:08:01 +00:00
|
|
|
#
|
|
|
|
# $1: environment variable
|
|
|
|
# $2: environ file path
|
2022-01-19 03:16:29 +00:00
|
|
|
read_proc_environ_var()
|
|
|
|
{
|
2022-02-07 00:08:01 +00:00
|
|
|
local _var=$1 _environ_path=$2
|
2022-01-19 03:16:29 +00:00
|
|
|
sed -n -E "s/.*(^|\x00)${_var}=([^\x00]*).*/\2/p" < "$_environ_path"
|
|
|
|
}
|
|
|
|
|
2022-02-07 00:08:01 +00:00
|
|
|
_OSBUILD_ENVIRON_PATH='/proc/1/environ'
|
2021-12-15 13:45:18 +00:00
|
|
|
_is_osbuild()
|
|
|
|
{
|
2022-02-07 00:08:01 +00:00
|
|
|
[[ $(read_proc_environ_var container "$_OSBUILD_ENVIRON_PATH") == bwrap-osbuild ]]
|
2021-12-15 13:45:18 +00:00
|
|
|
}
|
|
|
|
|
2021-12-02 09:19:50 +00:00
|
|
|
reset_crashkernel_for_installed_kernel()
|
|
|
|
{
|
|
|
|
local _installed_kernel _running_kernel _crashkernel _crashkernel_running
|
|
|
|
local _dump_mode_running _fadump_val_running
|
|
|
|
|
2022-09-08 06:30:02 +00:00
|
|
|
# During package install, only try to reset crashkernel for osbuild
|
|
|
|
# thus to avoid calling grubby when installing os via anaconda
|
2022-12-20 05:59:18 +00:00
|
|
|
if ! _is_bootloader_installed && ! _is_osbuild; then
|
2022-09-08 06:30:02 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2021-12-02 09:19:50 +00:00
|
|
|
if ! _installed_kernel=$(_find_kernel_path_by_release "$1"); then
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2022-01-19 03:16:29 +00:00
|
|
|
if _is_osbuild; then
|
|
|
|
if ! grep -qs crashkernel= /etc/kernel/cmdline; then
|
|
|
|
reset_crashkernel "--kernel=$_installed_kernel"
|
|
|
|
fi
|
2021-12-15 13:45:18 +00:00
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
2021-12-02 09:19:50 +00:00
|
|
|
if ! _running_kernel=$(_get_current_running_kernel_path); then
|
|
|
|
derror "Couldn't find current running kernel"
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
|
|
|
|
_crashkernel=$(get_grub_kernel_boot_parameter "$_installed_kernel" crashkernel)
|
|
|
|
_crashkernel_running=$(get_grub_kernel_boot_parameter "$_running_kernel" crashkernel)
|
|
|
|
_dump_mode_running=$(get_dump_mode_by_kernel "$_running_kernel")
|
|
|
|
_fadump_val_running=$(get_grub_kernel_boot_parameter "$_kernel" fadump)
|
|
|
|
|
|
|
|
if [[ $_crashkernel != "$_crashkernel_running" ]]; then
|
2022-07-12 08:07:37 +00:00
|
|
|
if _update_kernel_cmdline "$_installed_kernel" "$_crashkernel_running" "$_dump_mode_running" "$_fadump_val_running"; then
|
2021-12-02 09:19:50 +00:00
|
|
|
echo "kexec-tools has reset $_installed_kernel to use the new default crashkernel value $_crashkernel_running"
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2021-09-13 18:25:40 +00:00
|
|
|
main()
|
2013-11-25 16:23:11 +00:00
|
|
|
{
|
2014-07-24 18:38:36 +00:00
|
|
|
# Determine if the dump mode is kdump or fadump
|
|
|
|
determine_dump_mode
|
|
|
|
|
2013-11-25 16:23:11 +00:00
|
|
|
case "$1" in
|
2021-09-13 18:25:40 +00:00
|
|
|
start)
|
2021-12-28 06:47:46 +00:00
|
|
|
start
|
2013-11-25 16:23:11 +00:00
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
stop)
|
2013-11-25 16:23:11 +00:00
|
|
|
stop
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
status)
|
2011-07-06 19:25:34 +00:00
|
|
|
EXIT_CODE=0
|
2014-07-24 18:38:36 +00:00
|
|
|
check_current_status
|
2013-11-25 16:23:11 +00:00
|
|
|
case "$?" in
|
2021-09-13 18:25:40 +00:00
|
|
|
0)
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Kdump is operational"
|
2013-11-25 16:23:11 +00:00
|
|
|
EXIT_CODE=0
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
1)
|
2020-10-27 09:04:22 +00:00
|
|
|
dinfo "Kdump is not operational"
|
2013-11-25 16:23:11 +00:00
|
|
|
EXIT_CODE=3
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
exit $EXIT_CODE
|
2011-07-06 19:25:34 +00:00
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
reload)
|
2018-10-23 14:13:28 +00:00
|
|
|
reload
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
restart)
|
2013-11-25 16:23:11 +00:00
|
|
|
stop
|
|
|
|
start
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
rebuild)
|
2019-03-29 03:29:30 +00:00
|
|
|
rebuild
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
condrestart) ;;
|
|
|
|
|
|
|
|
propagate)
|
2013-11-25 16:23:11 +00:00
|
|
|
propagate_ssh_key
|
2011-07-06 19:25:34 +00:00
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
showmem)
|
2018-05-11 02:02:39 +00:00
|
|
|
show_reserved_mem
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
estimate)
|
2021-04-21 19:27:10 +00:00
|
|
|
do_estimate
|
|
|
|
;;
|
2021-11-16 04:23:02 +00:00
|
|
|
get-default-crashkernel)
|
|
|
|
get_default_crashkernel "$2"
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
reset-crashkernel)
|
2021-12-01 05:39:40 +00:00
|
|
|
shift
|
|
|
|
reset_crashkernel "$@"
|
2021-06-10 05:06:22 +00:00
|
|
|
;;
|
2022-09-08 06:08:42 +00:00
|
|
|
_reset-crashkernel-after-update)
|
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2021-12-01 07:33:13 +00:00
|
|
|
if [[ $(kdump_get_conf_val auto_reset_crashkernel) != no ]]; then
|
|
|
|
reset_crashkernel_after_update
|
|
|
|
fi
|
|
|
|
;;
|
2022-09-08 06:08:42 +00:00
|
|
|
_reset-crashkernel-for-installed_kernel)
|
2021-12-02 09:19:50 +00:00
|
|
|
if [[ $(kdump_get_conf_val auto_reset_crashkernel) != no ]]; then
|
|
|
|
reset_crashkernel_for_installed_kernel "$2"
|
|
|
|
fi
|
|
|
|
;;
|
2021-09-13 18:25:40 +00:00
|
|
|
*)
|
2021-06-10 05:06:22 +00:00
|
|
|
dinfo $"Usage: $0 {estimate|start|stop|status|restart|reload|rebuild|reset-crashkernel|propagate|showmem}"
|
2013-11-25 16:23:11 +00:00
|
|
|
exit 1
|
2021-09-13 18:25:40 +00:00
|
|
|
;;
|
2011-07-06 19:25:34 +00:00
|
|
|
esac
|
2013-11-25 16:23:11 +00:00
|
|
|
}
|
|
|
|
|
2022-01-04 06:04:38 +00:00
|
|
|
if [[ ${__SOURCED__:+x} ]]; then
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [[ ! -f $KDUMP_CONFIG_FILE ]]; then
|
|
|
|
derror "Error: No kdump config file found!"
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2013-11-25 16:23:11 +00:00
|
|
|
# Other kdumpctl instances will block in queue, until this one exits
|
|
|
|
single_instance_lock
|
|
|
|
|
|
|
|
# To avoid fd 9 leaking, we invoke a subshell, close fd 9 and call main.
|
|
|
|
# So that fd isn't leaking when main is invoking a subshell.
|
2021-09-13 18:25:40 +00:00
|
|
|
(
|
|
|
|
exec 9<&-
|
|
|
|
main "$@"
|
|
|
|
)
|