kexec-tools/kdumpctl

1859 lines
48 KiB
Plaintext
Raw Permalink Normal View History

#!/bin/bash
KEXEC=/sbin/kexec
KDUMP_KERNELVER=""
KDUMP_KERNEL=""
KDUMP_COMMANDLINE=""
KEXEC_ARGS=""
KDUMP_LOG_PATH="/var/log"
MKDUMPRD="/sbin/mkdumprd -f"
2021-07-12 08:07:05 +00:00
MKFADUMPRD="/sbin/mkfadumprd"
DRACUT_MODULES_FILE="/usr/lib/dracut/modules.txt"
SAVE_PATH=/var/crash
SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
DUMP_TARGET=""
DEFAULT_INITRD=""
DEFAULT_INITRD_BAK=""
INITRD_CHECKSUM_LOCATION=""
KDUMP_INITRD=""
TARGET_INITRD=""
#kdump shall be the default dump mode
DEFAULT_DUMP_MODE="kdump"
image_time=0
standard_kexec_args="-d -p"
# Some default values in case /etc/sysconfig/kdump doesn't include
KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug"
if [[ -f /etc/sysconfig/kdump ]]; then
. /etc/sysconfig/kdump
fi
[[ $dracutbasedir ]] || dracutbasedir=/usr/lib/dracut
. $dracutbasedir/dracut-functions.sh
. /lib/kdump/kdump-lib.sh
. /lib/kdump/kdump-logger.sh
#initiate the kdump logger
if ! dlog_init; then
echo "failed to initiate the kdump logger."
exit 1
fi
KDUMP_TMPDIR=$(mktemp --tmpdir -d kdump.XXXX)
trap '
ret=$?;
rm -rf "$KDUMP_TMPDIR"
exit $ret;
' EXIT
single_instance_lock()
{
local rc timeout=5 lockfile
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
derror "Create file lock failed"
exit 1
fi
flock -n 9
rc=$?
while [[ $rc -ne 0 ]]; do
dinfo "Another app is currently holding the kdump lock; waiting for it to exit..."
flock -w $timeout 9
rc=$?
done
}
determine_dump_mode()
{
# Check if firmware-assisted dump is enabled
# if yes, set the dump mode as fadump
if is_fadump_capable; then
dinfo "Dump mode is fadump"
DEFAULT_DUMP_MODE="fadump"
fi
ddebug "DEFAULT_DUMP_MODE=$DEFAULT_DUMP_MODE"
}
save_core()
{
coredir="/var/crash/$(date +"%Y-%m-%d-%H:%M")"
mkdir -p "$coredir"
ddebug "cp --sparse=always /proc/vmcore $coredir/vmcore-incomplete"
if cp --sparse=always /proc/vmcore "$coredir/vmcore-incomplete"; then
mv "$coredir/vmcore-incomplete" "$coredir/vmcore"
dinfo "saved a vmcore to $coredir"
else
derror "failed to save a vmcore to $coredir"
fi
# pass the dmesg to Abrt tool if exists, in order
# to collect the kernel oops message.
# https://fedorahosted.org/abrt/
if [[ -x /usr/bin/dumpoops ]]; then
ddebug "makedumpfile --dump-dmesg $coredir/vmcore $coredir/dmesg"
makedumpfile --dump-dmesg "$coredir/vmcore" "$coredir/dmesg" > /dev/null 2>&1
ddebug "dumpoops -d $coredir/dmesg"
if dumpoops -d "$coredir/dmesg" > /dev/null 2>&1; then
dinfo "kernel oops has been collected by abrt tool"
fi
fi
}
rebuild_fadump_initrd()
{
2021-07-12 08:07:05 +00:00
if ! $MKFADUMPRD "$DEFAULT_INITRD_BAK" "$TARGET_INITRD" --kver "$KDUMP_KERNELVER"; then
derror "mkfadumprd: failed to make fadump initrd"
return 1
fi
return 0
}
check_earlykdump_is_enabled()
{
grep -q -w "rd.earlykdump" /proc/cmdline
}
rebuild_kdump_initrd()
{
ddebug "rebuild kdump initrd: $MKDUMPRD $TARGET_INITRD $KDUMP_KERNELVER"
if ! $MKDUMPRD "$TARGET_INITRD" "$KDUMP_KERNELVER"; then
derror "mkdumprd: failed to make kdump initrd"
return 1
fi
if check_earlykdump_is_enabled; then
dwarn "Tips: If early kdump is enabled, also require rebuilding the system initramfs to make the changes take effect for early kdump."
fi
return 0
}
rebuild_initrd()
{
if [[ ! -w $(dirname "$TARGET_INITRD") ]]; then
derror "$(dirname "$TARGET_INITRD") does not have write permission. Cannot rebuild $TARGET_INITRD"
return 1
fi
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
rebuild_fadump_initrd
else
rebuild_kdump_initrd
fi
}
#$1: the files to be checked with IFS=' '
check_exist()
{
for file in $1; do
if [[ ! -e $file ]]; then
derror "Error: $file not found."
return 1
fi
done
}
#$1: the files to be checked with IFS=' '
check_executable()
{
for file in $1; do
if [[ ! -x $file ]]; then
derror "Error: $file is not executable."
return 1
fi
done
}
backup_default_initrd()
{
ddebug "backup default initrd: $DEFAULT_INITRD"
if [[ ! -f $DEFAULT_INITRD ]]; then
return
fi
if [[ ! -e $DEFAULT_INITRD_BAK ]]; then
dinfo "Backing up $DEFAULT_INITRD before rebuild."
# save checksum to verify before restoring
sha1sum "$DEFAULT_INITRD" > "$INITRD_CHECKSUM_LOCATION"
if ! cp "$DEFAULT_INITRD" "$DEFAULT_INITRD_BAK"; then
dwarn "WARNING: failed to backup $DEFAULT_INITRD."
rm -f -- "$INITRD_CHECKSUM_LOCATION"
rm -f -- "$DEFAULT_INITRD_BAK"
fi
fi
}
restore_default_initrd()
{
ddebug "restore default initrd: $DEFAULT_INITRD"
if [[ ! -f $DEFAULT_INITRD ]]; then
return
fi
# If a backup initrd exists, we must be switching back from
# fadump to kdump. Restore the original default initrd.
if [[ -f $DEFAULT_INITRD_BAK ]] && [[ -f $INITRD_CHECKSUM_LOCATION ]]; then
# verify checksum before restoring
backup_checksum=$(sha1sum "$DEFAULT_INITRD_BAK" | awk '{ print $1 }')
default_checksum=$(awk '{ print $1 }' "$INITRD_CHECKSUM_LOCATION")
if [[ $default_checksum != "$backup_checksum" ]]; then
dwarn "WARNING: checksum mismatch! Can't restore original initrd.."
else
rm -f $INITRD_CHECKSUM_LOCATION
if mv "$DEFAULT_INITRD_BAK" "$DEFAULT_INITRD"; then
derror "Restoring original initrd as fadump mode is disabled."
sync
fi
fi
fi
}
check_config()
{
local -A _opt_rec
while read -r config_opt config_val; do
case "$config_opt" in
dracut_args)
if [[ $config_val == *--mount* ]]; then
if [[ $(echo "$config_val" | grep -o "\-\-mount" | wc -l) -ne 1 ]]; then
derror 'Multiple mount targets specified in one "dracut_args".'
return 1
fi
config_opt=_target
fi
;;
raw)
if [[ -d "/proc/device-tree/ibm,opal/dump" ]]; then
dwarn "WARNING: Won't capture opalcore when 'raw' dump target is used."
fi
config_opt=_target
;;
ext[234] | minix | btrfs | xfs | nfs | ssh | virtiofs)
config_opt=_target
;;
sshkey | 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) ;;
net | options | link_delay | disk_timeout | debug_mem_level | blacklist)
derror "Deprecated kdump config option: $config_opt. Refer to kdump.conf manpage for alternatives."
return 1
;;
'')
continue
;;
*)
derror "Invalid kdump config option $config_opt"
return 1
;;
esac
if [[ -z $config_val ]]; then
derror "Invalid kdump config value for option '$config_opt'"
return 1
fi
if [[ -n ${_opt_rec[$config_opt]} ]]; then
if [[ $config_opt == _target ]]; then
derror "More than one dump targets specified"
else
derror "Duplicated kdump config value of option $config_opt"
fi
return 1
fi
_opt_rec[$config_opt]="$config_val"
done <<< "$(kdump_read_conf)"
check_failure_action_config || return 1
check_final_action_config || return 1
check_fence_kdump_config || return 1
return 0
}
# get_pcs_cluster_modified_files <image timestamp>
# return list of modified file for fence_kdump modified in Pacemaker cluster
get_pcs_cluster_modified_files()
{
local time_stamp
local modified_files
is_generic_fence_kdump && return 1
is_pcs_fence_kdump || return 1
time_stamp=$(pcs cluster cib | xmllint --xpath 'string(/cib/@cib-last-written)' - | xargs -0 date +%s --date)
if [[ -n $time_stamp ]] && [[ $time_stamp -gt $image_time ]]; then
modified_files="cluster-cib"
fi
if [[ -f $FENCE_KDUMP_CONFIG_FILE ]]; then
time_stamp=$(stat -c "%Y" "$FENCE_KDUMP_CONFIG_FILE")
if [[ $time_stamp -gt $image_time ]]; then
modified_files="$modified_files $FENCE_KDUMP_CONFIG_FILE"
fi
fi
echo "$modified_files"
}
setup_initrd()
{
if ! prepare_kdump_bootinfo; then
derror "failed to prepare for kdump bootinfo."
return 1
fi
DEFAULT_INITRD_BAK="$KDUMP_BOOTDIR/.$(basename "$DEFAULT_INITRD").default"
INITRD_CHECKSUM_LOCATION="$DEFAULT_INITRD_BAK.checksum"
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
TARGET_INITRD="$DEFAULT_INITRD"
# backup initrd for reference before replacing it
# with fadump aware initrd
backup_default_initrd
else
TARGET_INITRD="$KDUMP_INITRD"
# 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
fi
}
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)
EXTRA_BINS=$(kdump_get_conf_val kdump_post)
CHECK_FILES=$(kdump_get_conf_val kdump_pre)
HOOKS="/etc/kdump/post.d/ /etc/kdump/pre.d/"
if [[ -d /etc/kdump/post.d ]]; then
for file in /etc/kdump/post.d/*; do
if [[ -x $file ]]; then
POST_FILES="$POST_FILES $file"
fi
done
fi
if [[ -d /etc/kdump/pre.d ]]; then
for file in /etc/kdump/pre.d/*; do
if [[ -x $file ]]; then
PRE_FILES="$PRE_FILES $file"
fi
done
fi
HOOKS="$HOOKS $POST_FILES $PRE_FILES"
CORE_COLLECTOR=$(kdump_get_conf_val core_collector | awk '{print $1}')
CORE_COLLECTOR=$(type -P "$CORE_COLLECTOR")
# POST_FILES and PRE_FILES are already checked against executable, need not to check again.
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
CHECK_FILES=$(kdump_get_conf_val extra_bins)
EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
files="$KDUMP_CONFIG_FILE $KDUMP_KERNEL $EXTRA_BINS $CORE_COLLECTOR"
[[ -e /etc/fstab ]] && files="$files /etc/fstab"
# Check for any updated extra module
EXTRA_MODULES="$(kdump_get_conf_val extra_modules)"
if [[ -n $EXTRA_MODULES ]]; then
if [[ -e /lib/modules/$KDUMP_KERNELVER/modules.dep ]]; then
files="$files /lib/modules/$KDUMP_KERNELVER/modules.dep"
fi
for _module in $EXTRA_MODULES; do
if _module_file="$(modinfo --set-version "$KDUMP_KERNELVER" --filename "$_module" 2> /dev/null)"; then
files="$files $_module_file"
for _dep_modules in $(modinfo -F depends "$_module" | tr ',' ' '); do
files="$files $(modinfo --set-version "$KDUMP_KERNELVER" --filename "$_dep_modules" 2> /dev/null)"
done
else
# If it's not a module nor builtin, give an error
if ! (modprobe --set-version "$KDUMP_KERNELVER" --dry-run "$_module" &> /dev/null); then
dwarn "Module $_module not found"
fi
fi
done
fi
# HOOKS is mandatory and need to check the modification time
files="$files $HOOKS"
is_lvm2_thinp_dump_target && files="$files $LVM_CONF"
check_exist "$files" && check_executable "$EXTRA_BINS" || return 2
for file in $files; do
if [[ -e $file ]]; then
time_stamp=$(stat -c "%Y" "$file")
if [[ $time_stamp -gt $image_time ]]; then
modified_files="$modified_files $file"
fi
if [[ -L $file ]]; then
file=$(readlink -m "$file")
time_stamp=$(stat -c "%Y" "$file")
if [[ $time_stamp -gt $image_time ]]; then
modified_files="$modified_files $file"
fi
fi
else
dwarn "$file doesn't exist"
fi
done
if [[ -n $modified_files ]]; then
dinfo "Detected change(s) in the following file(s): $modified_files"
return 1
fi
return 0
}
check_drivers_modified()
{
local _target _new_drivers _old_drivers _module_name _module_filename
# If it's dump target is on block device, detect the block driver
_target=$(get_block_dump_target)
if [[ -n $_target ]]; then
_record_block_drivers()
{
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
ddebug "MAJ:MIN=$1 drivers='$_drivers'"
}
check_block_and_slaves_all _record_block_drivers "$(get_maj_min "$_target")"
fi
# Include watchdog drivers if watchdog module is not omitted
is_dracut_mod_omitted watchdog || _new_drivers+=" $(get_watchdog_drvs)"
[[ -z $_new_drivers ]] && return 0
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
ddebug "Modules required for kdump: '$_new_drivers'"
ddebug "Modules included in old initramfs: '$_old_drivers'"
for _driver in $_new_drivers; do
# Skip deprecated/invalid driver name or built-in module
_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
continue
fi
if ! [[ " $_old_drivers " == *" $_module_name "* ]]; then
dinfo "Detected change in block device driver, new loaded module: $_module_name"
return 1
fi
done
}
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
# No need to check in case of raw target.
# 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
return 0
fi
_target=$(get_block_dump_target)
_new_fstype=$(get_fs_type_from_target "$_target")
if [[ -z $_target ]] || [[ -z $_new_fstype ]]; then
derror "Dump target is invalid"
return 2
fi
ddebug "_target=$_target _new_fstype=$_new_fstype"
_new_dev=$(kdump_get_persistent_dev "$_target")
if [[ -z $_new_dev ]]; then
perror "Get persistent device name failed"
return 2
fi
_new_mntpoint="$(get_kdump_mntpoint_from_target "$_target")"
_dracut_args=$(lsinitrd "$TARGET_INITRD" -f usr/lib/dracut/build-parameter.txt)
if [[ -z $_dracut_args ]]; then
dwarn "Warning: No dracut arguments found in initrd"
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
if echo "$_dracut_args" | grep -q "\-\-mount"; then
# shellcheck disable=SC2046
set -- $(echo "$_dracut_args" | awk -F "--mount '" '{print $2}' | cut -d' ' -f1,2,3)
_old_dev=$1
_old_mntpoint=$2
_old_fstype=$3
[[ $_new_dev == "$_old_dev" && $_new_mntpoint == "$_old_mntpoint" && $_new_fstype == "$_old_fstype" ]] && return 0
# otherwise rebuild if target device is not a root device
else
[[ $_target == "$(get_root_fs_device)" ]] && return 0
fi
dinfo "Detected change in File System"
return 1
}
# returns 0 if system is not modified
# returns 1 if system is modified
# returns 2 if system modification is invalid
check_system_modified()
{
local ret
local CONF_ERROR=2
local CONF_MODIFY=1
local CONF_NO_MODIFY=0
local conf_status=$CONF_NO_MODIFY
[[ -f $TARGET_INITRD ]] || return 1
for _func in check_files_modified check_fs_modified check_drivers_modified; do
$_func
ret=$?
# return immediately if an error occurred.
[[ $ret -eq "$CONF_ERROR" ]] && return "$ret"
[[ $ret -eq "$CONF_MODIFY" ]] && { conf_status="$CONF_MODIFY"; }
done
return $conf_status
}
check_rebuild()
{
local capture_capable_initrd="1"
local force_rebuild force_no_rebuild
local ret system_modified="0"
setup_initrd || return 1
force_no_rebuild=$(kdump_get_conf_val force_no_rebuild)
force_no_rebuild=${force_no_rebuild:-0}
if [[ $force_no_rebuild != "0" ]] && [[ $force_no_rebuild != "1" ]]; then
derror "Error: force_no_rebuild value is invalid"
return 1
fi
force_rebuild=$(kdump_get_conf_val force_rebuild)
force_rebuild=${force_rebuild:-0}
if [[ $force_rebuild != "0" ]] && [[ $force_rebuild != "1" ]]; then
derror "Error: force_rebuild value is invalid"
return 1
fi
if [[ $force_no_rebuild == "1" && $force_rebuild == "1" ]]; then
derror "Error: force_rebuild and force_no_rebuild are enabled simultaneously in kdump.conf"
return 1
fi
# Will not rebuild kdump initrd
if [[ $force_no_rebuild == "1" ]]; then
return 0
fi
#check to see if dependent files has been modified
#since last build of the image file
if [[ -f $TARGET_INITRD ]]; then
image_time=$(stat -c "%Y" "$TARGET_INITRD" 2> /dev/null)
#in case of fadump mode, check whether the default/target
#initrd is already built with dump capture capability
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
capture_capable_initrd=$(lsinitrd -f $DRACUT_MODULES_FILE "$TARGET_INITRD" | grep -c -e ^kdumpbase$ -e ^zz-fadumpinit$)
fi
fi
check_system_modified
ret=$?
if [[ $ret -eq 2 ]]; then
return 1
elif [[ $ret -eq 1 ]]; then
system_modified="1"
fi
if [[ $image_time -eq 0 ]]; then
dinfo "No kdump initial ramdisk found."
elif [[ $capture_capable_initrd == "0" ]]; then
dinfo "Rebuild $TARGET_INITRD with dump capture support"
elif [[ $force_rebuild != "0" ]]; then
dinfo "Force rebuild $TARGET_INITRD"
elif [[ $system_modified != "0" ]]; then
:
else
return 0
fi
dinfo "Rebuilding $TARGET_INITRD"
rebuild_initrd
}
# 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
# 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
keyctl padd asymmetric "" %:.ima < "/usr/share/doc/kernel-keys/$KDUMP_KERNELVER/kernel-signing-ppc.cer"
}
# Load the kdump kernel specified in /etc/sysconfig/kdump
# If none is specified, try to load a kdump kernel with the same version
# as the currently running kernel.
load_kdump()
{
kdumpctl: Add basic UKI support Resolves: bz2169720 Upstream: src.fedoraproject.org/rpms/kexec-tools.git Conflicts: Small context difference in kexec-tools.spec commit ea7be0608ed719cc1cb134ecf6ef51a4b7e9f104 Author: Philipp Rudo <prudo@redhat.com> Date: Fri May 5 17:14:42 2023 +0200 kdumpctl: Add basic UKI support A Unified Kernel Image (UKI) is a single EFI PE executable combining an EFI stub, a kernel image, an initrd image, and the kernel command line. They are defined in the Boot Loader Specification [1] as type #2 entries. UKIs have the advantage that all code as well as meta data that is required to boot the system, not only the kernel image, is combined in a single PE file and can be signed for EFI SecureBoot. This extends the coverage of SecureBoot extensively. For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e ("redhat: Add sub-RPM with a EFI unified kernel image for virtual machines"). There are two problems with UKIs from the kdump point of view at the moment. First, they cannot be directly loaded via kexec_file_load and second, the initrd included isn't suitable for kdump. In order to enable kdump on systems with UKIs build the kdump initrd as usual and extract the kernel image before loading the crash kernel. [1] https://uapi-group.org/specifications/specs/boot_loader_specification/ Signed-off-by: Philipp Rudo <prudo@redhat.com> Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 07:11:31 +00:00
local ret uki
KEXEC_ARGS=$(prepare_kexec_args "${KEXEC_ARGS}")
KDUMP_COMMANDLINE=$(prepare_cmdline "${KDUMP_COMMANDLINE}" "${KDUMP_COMMANDLINE_REMOVE}" "${KDUMP_COMMANDLINE_APPEND}")
kdumpctl: Add basic UKI support Resolves: bz2169720 Upstream: src.fedoraproject.org/rpms/kexec-tools.git Conflicts: Small context difference in kexec-tools.spec commit ea7be0608ed719cc1cb134ecf6ef51a4b7e9f104 Author: Philipp Rudo <prudo@redhat.com> Date: Fri May 5 17:14:42 2023 +0200 kdumpctl: Add basic UKI support A Unified Kernel Image (UKI) is a single EFI PE executable combining an EFI stub, a kernel image, an initrd image, and the kernel command line. They are defined in the Boot Loader Specification [1] as type #2 entries. UKIs have the advantage that all code as well as meta data that is required to boot the system, not only the kernel image, is combined in a single PE file and can be signed for EFI SecureBoot. This extends the coverage of SecureBoot extensively. For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e ("redhat: Add sub-RPM with a EFI unified kernel image for virtual machines"). There are two problems with UKIs from the kdump point of view at the moment. First, they cannot be directly loaded via kexec_file_load and second, the initrd included isn't suitable for kdump. In order to enable kdump on systems with UKIs build the kdump initrd as usual and extract the kernel image before loading the crash kernel. [1] https://uapi-group.org/specifications/specs/boot_loader_specification/ Signed-off-by: Philipp Rudo <prudo@redhat.com> Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 07:11:31 +00:00
if is_uki "$KDUMP_KERNEL"; then
uki=$KDUMP_KERNEL
KDUMP_KERNEL=$KDUMP_TMPDIR/vmlinuz
objcopy -O binary --only-section .linux "$uki" "$KDUMP_KERNEL"
sync -f "$KDUMP_KERNEL"
# Make sure the temp file has the correct SELinux label.
# Otherwise starting the kdump.service will fail.
chcon -t boot_t "$KDUMP_KERNEL"
fi
ddebug "$KEXEC $KEXEC_ARGS $standard_kexec_args --command-line=$KDUMP_COMMANDLINE --initrd=$TARGET_INITRD $KDUMP_KERNEL"
# 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.
exec 12>&2
exec 2>> $KDUMP_LOG_PATH/kdump.log
chmod 600 $KDUMP_LOG_PATH/kdump.log
PS4='+ $(date "+%Y-%m-%d %H:%M:%S") ${BASH_SOURCE}@${LINENO}: '
set -x
# shellcheck disable=SC2086
$KEXEC $KEXEC_ARGS $standard_kexec_args \
--command-line="$KDUMP_COMMANDLINE" \
--initrd="$TARGET_INITRD" "$KDUMP_KERNEL"
ret=$?
set +x
exec 2>&12 12>&-
if [[ $ret == 0 ]]; then
dinfo "kexec: loaded kdump kernel"
return 0
else
derror "kexec: failed to load kdump kernel"
return 1
fi
}
check_ssh_config()
{
local SSH_TARGET
while read -r config_opt config_val; do
case "$config_opt" in
sshkey)
# remove inline comments after the end of a directive.
if [[ -f $config_val ]]; then
# canonicalize the path
SSH_KEY_LOCATION=$(/usr/bin/readlink -m "$config_val")
else
dwarn "WARNING: '$config_val' doesn't exist, using default value '$SSH_KEY_LOCATION'"
fi
;;
path)
SAVE_PATH=$config_val
;;
ssh)
DUMP_TARGET=$config_val
;;
*) ;;
esac
done <<< "$(kdump_read_conf)"
#make sure they've configured kdump.conf for ssh dumps
SSH_TARGET=$(echo -n "$DUMP_TARGET" | sed -n '/.*@/p')
if [[ -z $SSH_TARGET ]]; then
return 1
fi
return 0
}
# 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()
{
local start_time
local warn_once=1
local cur
local diff
local retval
local errmsg
start_time=$(date +%s)
while true; do
errmsg=$(ssh -i "$SSH_KEY_LOCATION" -o BatchMode=yes "$DUMP_TARGET" mkdir -p "$SAVE_PATH" 2>&1)
retval=$?
# ssh exits with the exit status of the remote command or with 255 if an error occurred
if [[ $retval -eq 0 ]]; then
return 0
elif [[ $retval -ne 255 ]]; then
derror "Could not create $DUMP_TARGET:$SAVE_PATH, you should check the privilege on server side"
return 1
fi
# if server removes the authorized_keys or, no /root/.ssh/kdump_id_rsa
ddebug "$errmsg"
if echo "$errmsg" | grep -q "Permission denied\|No such file or directory\|Host key verification failed"; then
derror "Could not create $DUMP_TARGET:$SAVE_PATH, you probably need to run \"kdumpctl propagate\""
return 1
fi
if [[ $warn_once -eq 1 ]]; then
dwarn "Network dump target is not usable, waiting for it to be ready..."
warn_once=0
fi
cur=$(date +%s)
diff=$((cur - start_time))
# 60s time out
if [[ $diff -gt 180 ]]; then
break
fi
sleep 1
done
dinfo "Could not create $DUMP_TARGET:$SAVE_PATH, ipaddr is not ready yet. You should check network connection"
return 1
}
check_ssh_target()
{
check_and_wait_network_ready
}
propagate_ssh_key()
{
if ! check_ssh_config; then
derror "No ssh config specified in $KDUMP_CONFIG_FILE. Can't propagate"
exit 1
fi
local KEYFILE=$SSH_KEY_LOCATION
local errmsg="Failed to propagate ssh key"
#Check to see if we already created key, if not, create it.
if [[ -f $KEYFILE ]]; then
dinfo "Using existing keys..."
else
dinfo "Generating new ssh keys... "
/usr/bin/ssh-keygen -t rsa -f "$KEYFILE" -N "" 2>&1 > /dev/null
dinfo "done."
fi
#now find the target ssh user and server to contact.
SSH_USER=$(echo "$DUMP_TARGET" | cut -d@ -f1)
SSH_SERVER=$(echo "$DUMP_TARGET" | sed -e's/\(.*@\)\(.*$\)/\2/')
#now send the found key to the found server
ssh-copy-id -i "$KEYFILE" "$SSH_USER@$SSH_SERVER"
RET=$?
if [[ $RET == 0 ]]; then
dinfo "$KEYFILE has been added to ~$SSH_USER/.ssh/authorized_keys on $SSH_SERVER"
return 0
else
derror "$errmsg, $KEYFILE failed in transfer to $SSH_SERVER"
exit 1
fi
}
show_reserved_mem()
{
local mem
local mem_mb
Introduce a function to get reserved memory size Resolves: bz2232499 Upstream: Fedora Rawhide Conflict: None commit 4b7b7736eef8c682a8af07081d7f06eeb774172f Author: Sourabh Jain <sourabhjain@linux.ibm.com> Date: Wed Aug 2 20:36:48 2023 +0530 Introduce a function to get reserved memory size The size of the reserved memory in the functions show_reserved_mem, check_crash_mem_reserved, and do_estimate are fetched from the sysfs node `/sys/kernel/kexec_crash_size`. However, in the case of fadump, the reserved area size is instead present in /sys/kernel/fadump/mem_reserved. For example: $ kdumpctl showmem kdump: Dump mode is fadump kdump: Reserved 0MB memory for crash kernel The above command showed 0MB for Reserved memory which is incorrect, the actual reservation was 2048MB. To resolve this issue a new helper function is introduced to fetch reserved memory size based on the dump mode. For "fadump" mode, it looks in `/sys/kernel/fadump/mem_reserved`, otherwise, it uses `/sys/kernel/kexec_crash_size`. And all functions that previously fetching reserved memory directly from `/sys/kernel/kexec_crash_size` sysfs node are now updated to use this new function to get the reserved memory size. With the fix in place, the `kdumpctl showmem` command will now display correct reserved memory size. $ kdumpctl showmem kdump: Dump mode is fadump kdump: Reserved 2048MB memory for crash kernel Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com> Reviewed-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 08:24:28 +00:00
mem=$(get_reserved_mem_size)
mem_mb=$((mem / 1024 / 1024))
dinfo "Reserved ${mem_mb}MB memory for crash kernel"
}
save_raw()
{
local kdump_dir
local raw_target
raw_target=$(kdump_get_conf_val raw)
[[ -z $raw_target ]] && return 0
[[ -b $raw_target ]] || {
derror "raw partition $raw_target not found"
return 1
}
check_fs=$(lsblk --nodeps -npo FSTYPE "$raw_target")
if [[ $(echo "$check_fs" | wc -w) -ne 0 ]]; then
dwarn "Warning: Detected '$check_fs' signature on $raw_target, data loss is expected."
return 0
fi
kdump_dir=$(kdump_get_conf_val path)
if [[ -z ${kdump_dir} ]]; then
coredir="/var/crash/$(date +"%Y-%m-%d-%H:%M")"
else
coredir="${kdump_dir}/$(date +"%Y-%m-%d-%H:%M")"
fi
mkdir -p "$coredir"
[[ -d $coredir ]] || {
derror "failed to create $coredir"
return 1
}
if makedumpfile -R "$coredir/vmcore" < "$raw_target" > /dev/null 2>&1; then
# dump found
dinfo "Dump saved to $coredir/vmcore"
# wipe makedumpfile header
dd if=/dev/zero of="$raw_target" bs=1b count=1 2> /dev/null
else
rm -rf "$coredir"
fi
return 0
}
local_fs_dump_target()
{
local _target
if _target=$(grep -E "^ext[234]|^xfs|^btrfs|^minix" /etc/kdump.conf); then
echo "$_target" | awk '{print $2}'
fi
}
path_to_be_relabeled()
{
local _path _target _mnt="/" _rmnt
if is_user_configured_dump_target; then
if is_mount_in_dracut_args; then
return
fi
_target=$(local_fs_dump_target)
if [[ -n $_target ]]; then
_mnt=$(get_mntpoint_from_target "$_target")
if ! is_mounted "$_mnt"; then
return
fi
else
return
fi
fi
_path=$(get_save_path)
# if $_path is masked by other mount, we will not relabel it.
_rmnt=$(df "$_mnt/$_path" 2> /dev/null | tail -1 | awk '{ print $NF }')
if [[ $_rmnt == "$_mnt" ]]; then
echo "$_mnt/$_path"
fi
}
selinux_relabel()
{
local _path _i _attr
_path=$(path_to_be_relabeled)
if [[ -z $_path ]] || ! [[ -d $_path ]]; then
return
fi
while IFS= read -r -d '' _i; do
_attr=$(getfattr -m "security.selinux" "$_i" 2> /dev/null)
if [[ -z $_attr ]]; then
restorecon "$_i"
fi
done < <(find "$_path" -print0)
}
check_fence_kdump_config()
{
local hostname
local ipaddrs
local nodes
hostname=$(hostname)
ipaddrs=$(hostname -I)
nodes=$(kdump_get_conf_val "fence_kdump_nodes")
for node in $nodes; do
if [[ $node == "$hostname" ]]; then
derror "Option fence_kdump_nodes cannot contain $hostname"
return 1
fi
# node can be ipaddr
if echo "$ipaddrs " | grep -q "$node "; then
derror "Option fence_kdump_nodes cannot contain $node"
return 1
fi
done
return 0
}
check_dump_feasibility()
{
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
return 0
fi
check_kdump_feasibility
}
start_fadump()
{
echo 1 > "$FADUMP_REGISTER_SYS_NODE"
if ! is_kernel_loaded "fadump"; then
derror "fadump: failed to register"
return 1
fi
dinfo "fadump: registered successfully"
return 0
}
start_dump()
{
# On secure boot enabled Power systems, load kernel signing key on .ima for signature
# verification using kexec file based syscall.
if [[ "$(uname -m)" == ppc64le ]] && is_secure_boot_enforced; then
load_kdump_kernel_key
fi
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
start_fadump
else
load_kdump
fi
}
check_failure_action_config()
{
local default_option
local failure_action
local option="failure_action"
default_option=$(kdump_get_conf_val default)
failure_action=$(kdump_get_conf_val failure_action)
if [[ -z $failure_action ]] && [[ -z $default_option ]]; then
return 0
elif [[ -n $failure_action ]] && [[ -n $default_option ]]; then
derror "Cannot specify 'failure_action' and 'default' option together"
return 1
fi
if [[ -n $default_option ]]; then
option="default"
failure_action="$default_option"
fi
case "$failure_action" in
reboot | halt | poweroff | shell | dump_to_rootfs)
return 0
;;
*)
dinfo $"Usage kdump.conf: $option {reboot|halt|poweroff|shell|dump_to_rootfs}"
return 1
;;
esac
}
check_final_action_config()
{
local final_action
final_action=$(kdump_get_conf_val final_action)
if [[ -z $final_action ]]; then
return 0
else
case "$final_action" in
reboot | halt | poweroff)
return 0
;;
*)
dinfo $"Usage kdump.conf: final_action {reboot|halt|poweroff}"
return 1
;;
esac
fi
}
start()
{
if ! check_dump_feasibility; then
derror "Starting kdump: [FAILED]"
return 1
fi
if ! check_config; then
derror "Starting kdump: [FAILED]"
return 1
fi
if sestatus 2> /dev/null | grep -q "SELinux status.*enabled"; then
selinux_relabel
fi
if ! save_raw; then
derror "Starting kdump: [FAILED]"
return 1
fi
if [[ $DEFAULT_DUMP_MODE == "kdump" ]] && is_kernel_loaded "kdump"; then
dwarn "Kdump already running: [WARNING]"
return 0
fi
if check_ssh_config; then
if ! check_ssh_target; then
derror "Starting kdump: [FAILED]"
return 1
fi
fi
if ! check_rebuild; then
derror "Starting kdump: [FAILED]"
return 1
fi
if ! start_dump; then
derror "Starting kdump: [FAILED]"
return 1
fi
dinfo "Starting kdump: [OK]"
}
reload()
{
if ! is_kernel_loaded "$DEFAULT_DUMP_MODE"; then
dwarn "Kdump was not running: [WARNING]"
fi
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
reload_fadump
return
else
if ! stop_kdump; then
derror "Stopping kdump: [FAILED]"
return 1
fi
fi
dinfo "Stopping kdump: [OK]"
if ! setup_initrd; then
derror "Starting kdump: [FAILED]"
return 1
fi
if ! start_dump; then
derror "Starting kdump: [FAILED]"
return 1
fi
dinfo "Starting kdump: [OK]"
}
stop_fadump()
{
echo 0 > "$FADUMP_REGISTER_SYS_NODE"
if is_kernel_loaded "fadump"; then
derror "fadump: failed to unregister"
return 1
fi
dinfo "fadump: unregistered successfully"
return 0
}
stop_kdump()
{
if is_secure_boot_enforced; then
$KEXEC -s -p -u
else
$KEXEC -p -u
fi
# shellcheck disable=SC2181
if [[ $? != 0 ]]; then
derror "kexec: failed to unload kdump kernel"
return 1
fi
dinfo "kexec: unloaded kdump kernel"
return 0
}
reload_fadump()
{
if echo 1 > "$FADUMP_REGISTER_SYS_NODE"; then
dinfo "fadump: re-registered successfully"
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.
if stop_fadump; then
start_fadump
return
fi
fi
return 1
}
stop()
{
if [[ $DEFAULT_DUMP_MODE == "fadump" ]]; then
stop_fadump
else
stop_kdump
fi
# shellcheck disable=SC2181
if [[ $? != 0 ]]; then
derror "Stopping kdump: [FAILED]"
return 1
fi
dinfo "Stopping kdump: [OK]"
return 0
}
rebuild()
{
check_config || return 1
if check_ssh_config; then
if ! check_ssh_target; then
return 1
fi
fi
setup_initrd || return 1
dinfo "Rebuilding $TARGET_INITRD"
rebuild_initrd
}
check_vmlinux()
{
# Use readelf to check if it's a valid ELF
readelf -h "$1" &> /dev/null || return 1
}
get_vmlinux_size()
{
local size=0 _msize
while read -r _msize; do
size=$((size + _msize))
done <<< "$(readelf -l -W "$1" | awk '/^ LOAD/{print $6}' 2> /dev/stderr)"
echo $size
}
try_decompress()
{
# The obscure use of the "tr" filter is to work around older versions of
# "grep" that report the byte offset of the line instead of the pattern.
# Try to find the header ($1) and decompress from here
for pos in $(tr "$1\n$2" "\n$2=" < "$4" | grep -abo "^$2"); do
if ! type -P "$3" > /dev/null; then
ddebug "Signiature detected but '$3' is missing, skip this decompressor"
break
fi
pos=${pos%%:*}
tail "-c+$pos" "$img" | $3 > "$5" 2> /dev/null
if check_vmlinux "$5"; then
ddebug "Kernel is extracted with '$3'"
return 0
fi
done
return 1
}
# Borrowed from linux/scripts/extract-vmlinux
get_kernel_size()
{
# Prepare temp files:
local tmp img=$1
tmp="$KDUMP_TMPDIR/vmlinux"
# Try to check if it's a vmlinux already
check_vmlinux "$img" && get_vmlinux_size "$img" && return 0
# That didn't work, so retry after decompression.
try_decompress '\037\213\010' xy gunzip "$img" "$tmp" ||
try_decompress '\3757zXZ\000' abcde unxz "$img" "$tmp" ||
try_decompress 'BZh' xy bunzip2 "$img" "$tmp" ||
try_decompress '\135\0\0\0' xxx unlzma "$img" "$tmp" ||
try_decompress '\211\114\132' xy 'lzop -d' "$img" "$tmp" ||
try_decompress '\002!L\030' xxx 'lz4 -d' "$img" "$tmp" ||
try_decompress '(\265/\375' xxx unzstd "$img" "$tmp"
# Finally check for uncompressed images or objects:
[[ $? -eq 0 ]] && get_vmlinux_size "$tmp" && return 0
# Fallback to use iomem
local _size=0 _seg
while read -r _seg; do
_size=$((_size + 0x${_seg#*-} - 0x${_seg%-*}))
done <<< "$(grep -E "Kernel (code|rodata|data|bss)" /proc/iomem | cut -d ":" -f 1)"
echo $_size
}
do_estimate()
{
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
local kdump_mods
local -A large_mods
local baseline
Include the memory overhead cost of cryptsetup when estimating the memory requirement for LUKS-encrypted target Resolves: bz2076206 Upstream: Fedora Conflict: None commit 6ce4b85bb3ed6c97beda9ee4774e0924afbbf58a Author: Coiby Xu <coxu@redhat.com> Date: Mon Sep 5 18:08:44 2022 +0800 Include the memory overhead cost of cryptsetup when estimating the memory requirement for LUKS-encrypted target Currently, "kdumpctl estimate" neglects the memory overhead cost of cryptsetup itself. Unfortunately, there is no golden formula to calculate the overhead cost [1]. So estimate the overhead cost as 50M for aarch64 and 20M for other architectures based on the following empirical data, | Overhead (M) | OS | arch | | ------------ | ----------------------------------------- | ------- | | 14.1 | RHEL-9.2.0-20220829.d.1 | ppc64le | | 14 | Fedora-37-20220830.n.0 Everything ppc64le | ppc64le | | 17 | Fedora 36 | ppc64le | | 8.8 | Fedora 35 | s390x | | 10.1 | Fedora-Rawhide-20220829.n.0, fc38 | s390x | | 42 | Fedora-Rawhide-20220829.n.0, fc38 | arch64 | | 40 | F35 | arch64 | | 42 | F36 | arch64 | | 42 | Fedora-Rawhide-20220901.n.0 | arch64 | | 10 | F35 | x86_64 | | 10 | Fedora-Rawhide-20220901.n.0 | x86_64 | | 11 | Fedora-Rawhide-20220901.n.0 | x86_64 | [1] https://lore.kernel.org/cryptsetup/20220616044339.376qlipk5h2omhx2@Rk/T/#u Fixes: e9e6a2c ("kdumpctl: Add kdumpctl estimate") Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-26 07:39:30 +00:00
local kernel_size mod_size initrd_size baseline_size runtime_size reserved_size estimated_size recommended_size _cryptsetup_overhead
local size_mb=$((1024 * 1024))
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
setup_initrd
if [[ ! -f $TARGET_INITRD ]]; then
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
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)
if [[ ${baseline: -1} == "M" ]]; then
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
baseline=${baseline%M}
elif [[ ${baseline: -1} == "G" ]]; then
baseline=$((${baseline%G} * 1024))
elif [[ ${baseline: -1} == "T" ]]; then
baseline=$((${baseline%Y} * 1048576))
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
fi
# The default pre-reserved crashkernel value
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
baseline_size=$((baseline * size_mb))
# Current reserved crashkernel size
Introduce a function to get reserved memory size Resolves: bz2232499 Upstream: Fedora Rawhide Conflict: None commit 4b7b7736eef8c682a8af07081d7f06eeb774172f Author: Sourabh Jain <sourabhjain@linux.ibm.com> Date: Wed Aug 2 20:36:48 2023 +0530 Introduce a function to get reserved memory size The size of the reserved memory in the functions show_reserved_mem, check_crash_mem_reserved, and do_estimate are fetched from the sysfs node `/sys/kernel/kexec_crash_size`. However, in the case of fadump, the reserved area size is instead present in /sys/kernel/fadump/mem_reserved. For example: $ kdumpctl showmem kdump: Dump mode is fadump kdump: Reserved 0MB memory for crash kernel The above command showed 0MB for Reserved memory which is incorrect, the actual reservation was 2048MB. To resolve this issue a new helper function is introduced to fetch reserved memory size based on the dump mode. For "fadump" mode, it looks in `/sys/kernel/fadump/mem_reserved`, otherwise, it uses `/sys/kernel/kexec_crash_size`. And all functions that previously fetching reserved memory directly from `/sys/kernel/kexec_crash_size` sysfs node are now updated to use this new function to get the reserved memory size. With the fix in place, the `kdumpctl showmem` command will now display correct reserved memory size. $ kdumpctl showmem kdump: Dump mode is fadump kdump: Reserved 2048MB memory for crash kernel Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com> Reviewed-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 08:24:28 +00:00
reserved_size=$(get_reserved_mem_size)
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
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
if [[ " $kdump_mods " != *" $_name "* ]]; then
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
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")
[[ $(echo "$_crypt_info" | sed -n "s/^Version:\s*\(.*\)/\1/p") == "2" ]] || continue
for _mem in $(echo "$_crypt_info" | sed -n "s/\sMemory:\s*\(.*\)/\1/p" | sort -n -r); do
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
crypt_size=$((crypt_size + _mem * 1024))
break
done
done
Include the memory overhead cost of cryptsetup when estimating the memory requirement for LUKS-encrypted target Resolves: bz2076206 Upstream: Fedora Conflict: None commit 6ce4b85bb3ed6c97beda9ee4774e0924afbbf58a Author: Coiby Xu <coxu@redhat.com> Date: Mon Sep 5 18:08:44 2022 +0800 Include the memory overhead cost of cryptsetup when estimating the memory requirement for LUKS-encrypted target Currently, "kdumpctl estimate" neglects the memory overhead cost of cryptsetup itself. Unfortunately, there is no golden formula to calculate the overhead cost [1]. So estimate the overhead cost as 50M for aarch64 and 20M for other architectures based on the following empirical data, | Overhead (M) | OS | arch | | ------------ | ----------------------------------------- | ------- | | 14.1 | RHEL-9.2.0-20220829.d.1 | ppc64le | | 14 | Fedora-37-20220830.n.0 Everything ppc64le | ppc64le | | 17 | Fedora 36 | ppc64le | | 8.8 | Fedora 35 | s390x | | 10.1 | Fedora-Rawhide-20220829.n.0, fc38 | s390x | | 42 | Fedora-Rawhide-20220829.n.0, fc38 | arch64 | | 40 | F35 | arch64 | | 42 | F36 | arch64 | | 42 | Fedora-Rawhide-20220901.n.0 | arch64 | | 10 | F35 | x86_64 | | 10 | Fedora-Rawhide-20220901.n.0 | x86_64 | | 11 | Fedora-Rawhide-20220901.n.0 | x86_64 | [1] https://lore.kernel.org/cryptsetup/20220616044339.376qlipk5h2omhx2@Rk/T/#u Fixes: e9e6a2c ("kdumpctl: Add kdumpctl estimate") Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-10-26 07:39:30 +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
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
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
recommended_size=$baseline_size
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
else
recommended_size=$estimated_size
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
fi
echo "Reserved crashkernel: $((reserved_size / size_mb))M"
echo "Recommended crashkernel: $((recommended_size / size_mb))M"
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
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"
[[ $crypt_size -ne 0 ]] &&
echo "LUKS required size: $((crypt_size / size_mb))M"
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
echo -n "Large modules:"
if [[ ${#large_mods[@]} -eq 0 ]]; then
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
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
if [[ $reserved_size -lt $recommended_size ]]; then
echo "WARNING: Current crashkernel size is lower than recommended size $((recommended_size / size_mb))M."
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
fi
}
get_default_crashkernel()
{
local _dump_mode=$1
kdump_get_arch_recommend_crashkernel "$_dump_mode"
}
# 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}"
}
# 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
}
add helper functions to get kernel path by kernel release and the path of current running kernel Resolves: bz1895258 Upstream: Fedora Conflict: None commit 945cbbd59b34739c4a6b2f228c33f76e2981a18a Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 7 15:16:07 2021 +0800 add helper functions to get kernel path by kernel release and the path of current running kernel grubby --info=kernel-path or --add-kernel=kernel-path accepts a kernel path (e.g. /boot/vmlinuz-5.14.14-200.fc34.x86_64) instead of kernel release (e.g 5.14.14-200.fc34.x86_64). So we need to know the kernel path given a kernel release. Although for Fedora/RHEL, the kernel path is "/boot/vmlinuz-<KERNEL_RELEASE>", a path kernel could also be /boot/<machine-id>/<KERNEL_RELEASE>/vmlinuz. So the most reliable way to find the kernel path given a kernel release is to use "grubby --info". For osbuild, a kernel path may not yet exist but it's valid for "grubby --update-kernel=KERNEL_PATH". For example, "grubby -info" may output something as follows, index=0 kernel="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64" args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8" root="UUID=76a22bf4-f153-4541-b6c7-0332c0dfaeac" initrd="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/initramfs-5.15.10-100.fc34.x86_64.img" There is no need to check if path like /var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64 physically exists. Note these helper functions doesn't support CoreOS/Atomic/Silverblue since grubby isn't used by them. Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
# Insert '/' before '+' to cope with grep's EREs
_release=${_release//+/\\+}
_grubby_kernel_str=$(grubby --info ALL | grep -E "^kernel=.*$_release(\/\w+)?\"$")
add helper functions to get kernel path by kernel release and the path of current running kernel Resolves: bz1895258 Upstream: Fedora Conflict: None commit 945cbbd59b34739c4a6b2f228c33f76e2981a18a Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 7 15:16:07 2021 +0800 add helper functions to get kernel path by kernel release and the path of current running kernel grubby --info=kernel-path or --add-kernel=kernel-path accepts a kernel path (e.g. /boot/vmlinuz-5.14.14-200.fc34.x86_64) instead of kernel release (e.g 5.14.14-200.fc34.x86_64). So we need to know the kernel path given a kernel release. Although for Fedora/RHEL, the kernel path is "/boot/vmlinuz-<KERNEL_RELEASE>", a path kernel could also be /boot/<machine-id>/<KERNEL_RELEASE>/vmlinuz. So the most reliable way to find the kernel path given a kernel release is to use "grubby --info". For osbuild, a kernel path may not yet exist but it's valid for "grubby --update-kernel=KERNEL_PATH". For example, "grubby -info" may output something as follows, index=0 kernel="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64" args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8" root="UUID=76a22bf4-f153-4541-b6c7-0332c0dfaeac" initrd="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/initramfs-5.15.10-100.fc34.x86_64.img" There is no need to check if path like /var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64 physically exists. Note these helper functions doesn't support CoreOS/Atomic/Silverblue since grubby isn't used by them. Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
_kernel_path=$(_filter_grubby_kernel_str "$_grubby_kernel_str")
if [[ -z $_kernel_path ]]; then
ddebug "kernel $_release doesn't exist"
add helper functions to get kernel path by kernel release and the path of current running kernel Resolves: bz1895258 Upstream: Fedora Conflict: None commit 945cbbd59b34739c4a6b2f228c33f76e2981a18a Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 7 15:16:07 2021 +0800 add helper functions to get kernel path by kernel release and the path of current running kernel grubby --info=kernel-path or --add-kernel=kernel-path accepts a kernel path (e.g. /boot/vmlinuz-5.14.14-200.fc34.x86_64) instead of kernel release (e.g 5.14.14-200.fc34.x86_64). So we need to know the kernel path given a kernel release. Although for Fedora/RHEL, the kernel path is "/boot/vmlinuz-<KERNEL_RELEASE>", a path kernel could also be /boot/<machine-id>/<KERNEL_RELEASE>/vmlinuz. So the most reliable way to find the kernel path given a kernel release is to use "grubby --info". For osbuild, a kernel path may not yet exist but it's valid for "grubby --update-kernel=KERNEL_PATH". For example, "grubby -info" may output something as follows, index=0 kernel="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64" args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8" root="UUID=76a22bf4-f153-4541-b6c7-0332c0dfaeac" initrd="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/initramfs-5.15.10-100.fc34.x86_64.img" There is no need to check if path like /var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64 physically exists. Note these helper functions doesn't support CoreOS/Atomic/Silverblue since grubby isn't used by them. Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
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
}
_update_kernel_cmdline()
{
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
local _kernel_path=$1 _crashkernel=$2 _dump_mode=$3 _fadump_val=$4
if is_ostree; then
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
grubby --args "crashkernel=$_crashkernel" --update-kernel "$_kernel_path"
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
[[ -f /etc/zipl.conf ]] && zipl > /dev/null
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
}
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
_valid_grubby_kernel_path()
{
[[ -n "$1" ]] && grubby --info="$1" > /dev/null 2>&1
}
# 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
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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"
# 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
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
#
# $1: the name of the kernel command line parameter
# $2: new value. If empty, given parameter would be removed
_update_kernel_arg_in_grub_etc_default()
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
{
local _para=$1 _val=$2 _para_val
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
if [[ $(uname -m) == s390x ]]; then
return
fi
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
if [[ -n $_val ]]; then
_para_val="$_para=$_val"
fi
# 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"
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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"
}
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
# 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.
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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.
if is_ostree; then
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
_update_kernel_cmdline "" "$_new_crashkernel" "$_new_dump_mode" ""
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
if [[ $_reboot == yes ]]; then
systemctl reboot
fi
fi
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
_update_kernel_arg_in_grub_etc_default crashkernel "$_crashkernel"
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
# remove the fadump if fadump is disabled
if [[ $_fadump_val == off ]]; then
_fadump_val=""
fi
_update_kernel_arg_in_grub_etc_default fadump "$_fadump_val"
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
else
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
_kernels=$(_get_all_kernels_from_grubby "$_grubby_kernel_path")
fi
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
fi
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
_update_kernel_cmdline "$_kernel" "$_new_crashkernel" "$_new_dump_mode" "$_new_fadump_val"
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +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
fi
}
Don't try to update crashkernel when bootloader is not installed Resolves: bz2060319 Upstream: Fedora Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update during package install") hasn't been backported. Note it's now no longer needed. commit 5951b5e26823b6bedf3237bd169a781b03f25031 Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 20 13:59:18 2022 +0800 Don't try to update crashkernel when bootloader is not installed Currently when using anaconda to install the OS, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory ... INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory Or for s390, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ... 03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ... INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory This is because when anaconda installs the packages, bootloader hasn't been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist. So don't try to update crashkernel when bootloader isn't ready to avoid the above errors. Note this is the second attempt to fix this issue. Previously a file /tmp/kexec_tools_package_install was created to avoid running the related code thus to avoid the above errors but unfortunately that approach has two issues a) somehow osbuild doesn't delete it for RHEL b) this file could still exist if users manually remove kexec-tools. Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install") Reported-by: Jan Stodola <jstodola@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-20 05:59:18 +00:00
_is_bootloader_installed()
{
if [[ $(uname -m) == s390x ]]; then
Don't try to update crashkernel when bootloader is not installed Resolves: bz2060319 Upstream: Fedora Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update during package install") hasn't been backported. Note it's now no longer needed. commit 5951b5e26823b6bedf3237bd169a781b03f25031 Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 20 13:59:18 2022 +0800 Don't try to update crashkernel when bootloader is not installed Currently when using anaconda to install the OS, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory ... INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory Or for s390, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ... 03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ... INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory This is because when anaconda installs the packages, bootloader hasn't been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist. So don't try to update crashkernel when bootloader isn't ready to avoid the above errors. Note this is the second attempt to fix this issue. Previously a file /tmp/kexec_tools_package_install was created to avoid running the related code thus to avoid the above errors but unfortunately that approach has two issues a) somehow osbuild doesn't delete it for RHEL b) this file could still exist if users manually remove kexec-tools. Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install") Reported-by: Jan Stodola <jstodola@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-20 05:59:18 +00:00
test -f /etc/zipl.conf
else
test -f /boot/grub2/grub.cfg
fi
}
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
_update_crashkernel()
{
local _kernel _kver _dump_mode _old_default_crashkernel _new_default_crashkernel _fadump_val _msg
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
_kernel=$1
_dump_mode=$(get_dump_mode_by_kernel "$_kernel")
_old_default_crashkernel=$(get_grub_kernel_boot_parameter "$_kernel" crashkernel)
_kver=$(parse_kver_from_path "$_kernel")
# The second argument is for the case of aarch64, where installing a 64k variant on a 4k kernel, or vice versa
_new_default_crashkernel=$(kdump_get_arch_recommend_crashkernel "$_dump_mode" "$_kver")
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
if [[ $_old_default_crashkernel != "$_new_default_crashkernel" ]]; then
_fadump_val=$(get_grub_kernel_boot_parameter "$_kernel" fadump)
if _update_kernel_cmdline "$_kernel" "$_new_default_crashkernel" "$_dump_mode" "$_fadump_val"; then
_msg="For kernel=$_kernel, crashkernel=$_new_default_crashkernel now. Please reboot the system for the change to take effet."
_msg+=" Note if you don't want kexec-tools to manage the crashkernel kernel parameter, please set auto_reset_crashkernel=no in /etc/kdump.conf."
dinfo "$_msg"
fi
fi
}
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value Resolves: bz1895258 Upstream: Fedora Conflict: None commit 0adb0f4a8c4c69ba54171f0113a4fbfc1729900f Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 15:33:13 2021 +0800 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
# shellcheck disable=SC2154 # false positive when dereferencing an array
reset_crashkernel_after_update()
{
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
local _kernel
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value Resolves: bz1895258 Upstream: Fedora Conflict: None commit 0adb0f4a8c4c69ba54171f0113a4fbfc1729900f Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 15:33:13 2021 +0800 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
Don't try to update crashkernel when bootloader is not installed Resolves: bz2060319 Upstream: Fedora Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update during package install") hasn't been backported. Note it's now no longer needed. commit 5951b5e26823b6bedf3237bd169a781b03f25031 Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 20 13:59:18 2022 +0800 Don't try to update crashkernel when bootloader is not installed Currently when using anaconda to install the OS, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory ... INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory Or for s390, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ... 03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ... INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory This is because when anaconda installs the packages, bootloader hasn't been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist. So don't try to update crashkernel when bootloader isn't ready to avoid the above errors. Note this is the second attempt to fix this issue. Previously a file /tmp/kexec_tools_package_install was created to avoid running the related code thus to avoid the above errors but unfortunately that approach has two issues a) somehow osbuild doesn't delete it for RHEL b) this file could still exist if users manually remove kexec-tools. Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install") Reported-by: Jan Stodola <jstodola@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-20 05:59:18 +00:00
if ! _is_bootloader_installed; then
return
fi
for _kernel in $(_get_all_kernels_from_grubby ALL); do
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
_update_crashkernel "$_kernel"
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value Resolves: bz1895258 Upstream: Fedora Conflict: None commit 0adb0f4a8c4c69ba54171f0113a4fbfc1729900f Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 15:33:13 2021 +0800 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
done
}
# 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.
#
# $1: environment variable
# $2: environ file path
read_proc_environ_var()
{
local _var=$1 _environ_path=$2
sed -n -E "s/.*(^|\x00)${_var}=([^\x00]*).*/\2/p" < "$_environ_path"
}
_OSBUILD_ENVIRON_PATH='/proc/1/environ'
set up kernel crashkernel for osbuild in kernel hook Resolves: bz1895258 Resolves: bz2024976 Upstream: Fedora Conflict: None commit ddd428a1d0d72bee2a8459b1a81541bcd0676873 Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 15 21:45:18 2021 +0800 set up kernel crashkernel for osbuild in kernel hook osbuild is a tool to build OS images. It uses bwrap to install packages inside a sandbox/container. Since the kernel package recommends kexec-tools which in turn recommends grubby, the installation order would be grubby -> kexec-tools -> kernel. So we can use the kernel hook 92-crashkernel.install provided by kexec-tools to set up kernel crashkernel for the target OS image. But in osbuild's case, there is no current running kernel and running `uname -r` in the container/sandbox actually returns the host kernel release. To set up kernel crashkernel for the OS image built by osbuild, a different logic is needed. We will check if kernel hook is running inside the osbuild container then set up kernel crashkernel only if osbuild hasn't specified a custome value. osbuild exposes [1] the container=bwrap-osbuild environment variable. According to [2], the environment variable is not inherited down the process tree, so we need to check /proc/1/environ to detect this environment variable to tell if the kernel hook is running inside a bwrap-osbuild container. After that we need to know if osbuild wants to use custom crashkernel value. This is done by checking if /etc/kernel/cmdline has crashkernel set [3]. /etc/kernel/cmdline is written before packages are installed. [1] https://github.com/osbuild/osbuild/pull/926 [2] https://systemd.io/CONTAINER_INTERFACE/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2024976#c5 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
_is_osbuild()
{
[[ $(read_proc_environ_var container "$_OSBUILD_ENVIRON_PATH") == bwrap-osbuild ]]
set up kernel crashkernel for osbuild in kernel hook Resolves: bz1895258 Resolves: bz2024976 Upstream: Fedora Conflict: None commit ddd428a1d0d72bee2a8459b1a81541bcd0676873 Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 15 21:45:18 2021 +0800 set up kernel crashkernel for osbuild in kernel hook osbuild is a tool to build OS images. It uses bwrap to install packages inside a sandbox/container. Since the kernel package recommends kexec-tools which in turn recommends grubby, the installation order would be grubby -> kexec-tools -> kernel. So we can use the kernel hook 92-crashkernel.install provided by kexec-tools to set up kernel crashkernel for the target OS image. But in osbuild's case, there is no current running kernel and running `uname -r` in the container/sandbox actually returns the host kernel release. To set up kernel crashkernel for the OS image built by osbuild, a different logic is needed. We will check if kernel hook is running inside the osbuild container then set up kernel crashkernel only if osbuild hasn't specified a custome value. osbuild exposes [1] the container=bwrap-osbuild environment variable. According to [2], the environment variable is not inherited down the process tree, so we need to check /proc/1/environ to detect this environment variable to tell if the kernel hook is running inside a bwrap-osbuild container. After that we need to know if osbuild wants to use custom crashkernel value. This is done by checking if /etc/kernel/cmdline has crashkernel set [3]. /etc/kernel/cmdline is written before packages are installed. [1] https://github.com/osbuild/osbuild/pull/926 [2] https://systemd.io/CONTAINER_INTERFACE/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2024976#c5 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
}
reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools Resolves: bz1895258 Upstream: Fedora Conflict: None commit 5e8c751c39a5ec9d10009cba1c2bd554a5763b90 Author: Coiby Xu <coxu@redhat.com> Date: Thu Dec 2 17:19:50 2021 +0800 reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools When kexec-tools updates the default crashkernel value, it will try to reset the existing installed kernels including the currently running kernel. So the running kernel could have different kernel cmdline parameters from /proc/cmdline. When installing a kernel after updating kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called by kernel-install [1] which would use /proc/cmdline to set up new kernel's cmdline. To address this special case, reset the new kernel's crashkernel and fadump value to the value that would be used by running kernel after rebooting by the installation hook. One side effect of this commit is it would reset the installed kernel's crashkernel even currently running kernel don't use the default crashkernel value after rebooting. But I think this side effect is a benefit for the user. The implementation depends on kernel-install which run the scripts in /usr/lib/kernel/install.d passing the following arguments, add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] An concrete example is given as follows, add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz kernel-install could be started by the kernel package's RPM scriplet [2]. As mentioned in previous commit "try to reset kernel crashkernel when kexec-tools updates the default crashkernel value", kdumpctl has difficulty running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks, there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a collaboration between rpm-ostree and kexec-tools is needed [3] to take care of this special case. Note the crashkernel.default support is dropped. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html [2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680 [3] https://github.com/coreos/rpm-ostree/issues/2894 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
reset_crashkernel_for_installed_kernel()
{
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
local _installed_kernel
reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools Resolves: bz1895258 Upstream: Fedora Conflict: None commit 5e8c751c39a5ec9d10009cba1c2bd554a5763b90 Author: Coiby Xu <coxu@redhat.com> Date: Thu Dec 2 17:19:50 2021 +0800 reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools When kexec-tools updates the default crashkernel value, it will try to reset the existing installed kernels including the currently running kernel. So the running kernel could have different kernel cmdline parameters from /proc/cmdline. When installing a kernel after updating kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called by kernel-install [1] which would use /proc/cmdline to set up new kernel's cmdline. To address this special case, reset the new kernel's crashkernel and fadump value to the value that would be used by running kernel after rebooting by the installation hook. One side effect of this commit is it would reset the installed kernel's crashkernel even currently running kernel don't use the default crashkernel value after rebooting. But I think this side effect is a benefit for the user. The implementation depends on kernel-install which run the scripts in /usr/lib/kernel/install.d passing the following arguments, add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] An concrete example is given as follows, add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz kernel-install could be started by the kernel package's RPM scriplet [2]. As mentioned in previous commit "try to reset kernel crashkernel when kexec-tools updates the default crashkernel value", kdumpctl has difficulty running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks, there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a collaboration between rpm-ostree and kexec-tools is needed [3] to take care of this special case. Note the crashkernel.default support is dropped. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html [2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680 [3] https://github.com/coreos/rpm-ostree/issues/2894 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
# During package install, only try to reset crashkernel for osbuild
# thus to avoid calling grubby when installing os via anaconda
Don't try to update crashkernel when bootloader is not installed Resolves: bz2060319 Upstream: Fedora Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update during package install") hasn't been backported. Note it's now no longer needed. commit 5951b5e26823b6bedf3237bd169a781b03f25031 Author: Coiby Xu <coxu@redhat.com> Date: Tue Dec 20 13:59:18 2022 +0800 Don't try to update crashkernel when bootloader is not installed Currently when using anaconda to install the OS, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory ... INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ... INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory grep: /boot/grub2/grubenv: No such file or directory Or for s390, the following errors occur, INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ... 03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory grep: /etc/zipl.conf: No such file or directory INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ... INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory This is because when anaconda installs the packages, bootloader hasn't been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist. So don't try to update crashkernel when bootloader isn't ready to avoid the above errors. Note this is the second attempt to fix this issue. Previously a file /tmp/kexec_tools_package_install was created to avoid running the related code thus to avoid the above errors but unfortunately that approach has two issues a) somehow osbuild doesn't delete it for RHEL b) this file could still exist if users manually remove kexec-tools. Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install") Reported-by: Jan Stodola <jstodola@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-12-20 05:59:18 +00:00
if ! _is_bootloader_installed && ! _is_osbuild; then
return
fi
reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools Resolves: bz1895258 Upstream: Fedora Conflict: None commit 5e8c751c39a5ec9d10009cba1c2bd554a5763b90 Author: Coiby Xu <coxu@redhat.com> Date: Thu Dec 2 17:19:50 2021 +0800 reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools When kexec-tools updates the default crashkernel value, it will try to reset the existing installed kernels including the currently running kernel. So the running kernel could have different kernel cmdline parameters from /proc/cmdline. When installing a kernel after updating kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called by kernel-install [1] which would use /proc/cmdline to set up new kernel's cmdline. To address this special case, reset the new kernel's crashkernel and fadump value to the value that would be used by running kernel after rebooting by the installation hook. One side effect of this commit is it would reset the installed kernel's crashkernel even currently running kernel don't use the default crashkernel value after rebooting. But I think this side effect is a benefit for the user. The implementation depends on kernel-install which run the scripts in /usr/lib/kernel/install.d passing the following arguments, add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] An concrete example is given as follows, add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz kernel-install could be started by the kernel package's RPM scriplet [2]. As mentioned in previous commit "try to reset kernel crashkernel when kexec-tools updates the default crashkernel value", kdumpctl has difficulty running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks, there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a collaboration between rpm-ostree and kexec-tools is needed [3] to take care of this special case. Note the crashkernel.default support is dropped. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html [2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680 [3] https://github.com/coreos/rpm-ostree/issues/2894 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
if ! _installed_kernel=$(_find_kernel_path_by_release "$1"); then
exit 1
fi
if _is_osbuild; then
if ! grep -qs crashkernel= /etc/kernel/cmdline; then
reset_crashkernel "--kernel=$_installed_kernel"
fi
set up kernel crashkernel for osbuild in kernel hook Resolves: bz1895258 Resolves: bz2024976 Upstream: Fedora Conflict: None commit ddd428a1d0d72bee2a8459b1a81541bcd0676873 Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 15 21:45:18 2021 +0800 set up kernel crashkernel for osbuild in kernel hook osbuild is a tool to build OS images. It uses bwrap to install packages inside a sandbox/container. Since the kernel package recommends kexec-tools which in turn recommends grubby, the installation order would be grubby -> kexec-tools -> kernel. So we can use the kernel hook 92-crashkernel.install provided by kexec-tools to set up kernel crashkernel for the target OS image. But in osbuild's case, there is no current running kernel and running `uname -r` in the container/sandbox actually returns the host kernel release. To set up kernel crashkernel for the OS image built by osbuild, a different logic is needed. We will check if kernel hook is running inside the osbuild container then set up kernel crashkernel only if osbuild hasn't specified a custome value. osbuild exposes [1] the container=bwrap-osbuild environment variable. According to [2], the environment variable is not inherited down the process tree, so we need to check /proc/1/environ to detect this environment variable to tell if the kernel hook is running inside a bwrap-osbuild container. After that we need to know if osbuild wants to use custom crashkernel value. This is done by checking if /etc/kernel/cmdline has crashkernel set [3]. /etc/kernel/cmdline is written before packages are installed. [1] https://github.com/osbuild/osbuild/pull/926 [2] https://systemd.io/CONTAINER_INTERFACE/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2024976#c5 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
return
fi
Simplify the management of the kernel parameter crashkernel Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676 Upstream: Fedora rawhide Conflict: applied manually due to slight difference in context commit 5b31b099ae9b40a8f832b07e8364d7b08025fdd6 Author: Coiby Xu <coxu@redhat.com> Date: Wed Apr 26 04:48:25 2023 +0800 Simplify the management of the kernel parameter crashkernel Currently, kexec-tools only updates the crashkernel to a new default value only when both two conditions are met, - auto_reset_crashkernel=yes in kdump.conf - existing kernels or current running kernel should use the old default value. To address seen corner cases, the logic to tell if the second condition is met becomes quite complex. Instead of making the logic more complex to support aarch64-64k, this patch drops the second condition to simplify the management of the crashkernel kernel parameter. Another change brought by this simplification is kexec-tools will also set up the kernel crashkernel parameter for a fresh install (previously it's limited to osbuild). Note 1. This patch also stop trying to update /etc/default/grub because a) it only affects the static file /boot/grub2/grub.cfg b) grubby is recommended to change the kernel command-line parameters for both Fedora [1] and RHEL9 [2][3] c) For the cases of aarch64 and POWER, different kernels could have different default crashkernel value. 2. Starting with Fedora 37, posttrans rpm scriplet distinguish between package install and upgrade. [1] https://fedoraproject.org/wiki/GRUB_2 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters [3] https://access.redhat.com/solutions/1136173 Signed-off-by: Coiby Xu <coxu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 02:11:53 +00:00
_update_crashkernel "$_installed_kernel"
reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools Resolves: bz1895258 Upstream: Fedora Conflict: None commit 5e8c751c39a5ec9d10009cba1c2bd554a5763b90 Author: Coiby Xu <coxu@redhat.com> Date: Thu Dec 2 17:19:50 2021 +0800 reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools When kexec-tools updates the default crashkernel value, it will try to reset the existing installed kernels including the currently running kernel. So the running kernel could have different kernel cmdline parameters from /proc/cmdline. When installing a kernel after updating kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called by kernel-install [1] which would use /proc/cmdline to set up new kernel's cmdline. To address this special case, reset the new kernel's crashkernel and fadump value to the value that would be used by running kernel after rebooting by the installation hook. One side effect of this commit is it would reset the installed kernel's crashkernel even currently running kernel don't use the default crashkernel value after rebooting. But I think this side effect is a benefit for the user. The implementation depends on kernel-install which run the scripts in /usr/lib/kernel/install.d passing the following arguments, add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] An concrete example is given as follows, add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz kernel-install could be started by the kernel package's RPM scriplet [2]. As mentioned in previous commit "try to reset kernel crashkernel when kexec-tools updates the default crashkernel value", kdumpctl has difficulty running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks, there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a collaboration between rpm-ostree and kexec-tools is needed [3] to take care of this special case. Note the crashkernel.default support is dropped. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html [2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680 [3] https://github.com/coreos/rpm-ostree/issues/2894 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
}
if [[ ! -f $KDUMP_CONFIG_FILE ]]; then
derror "Error: No kdump config file found!"
exit 1
fi
main()
{
# Determine if the dump mode is kdump or fadump
determine_dump_mode
case "$1" in
start)
if [[ -s /proc/vmcore ]]; then
save_core
reboot
else
start
fi
;;
stop)
stop
;;
status)
EXIT_CODE=0
is_kernel_loaded "$DEFAULT_DUMP_MODE"
case "$?" in
0)
dinfo "Kdump is operational"
EXIT_CODE=0
;;
1)
dinfo "Kdump is not operational"
EXIT_CODE=3
;;
esac
exit $EXIT_CODE
;;
reload)
reload
;;
restart)
stop
start
;;
rebuild)
rebuild
;;
condrestart) ;;
propagate)
propagate_ssh_key
;;
showmem)
show_reserved_mem
;;
estimate)
kdumpctl: Add kdumpctl estimate Resolves: bz1951415 Upstream: fedora Conflict: none commit e9e6a2c745d41f5447c0062525c0e4f3f489b903 Author: Kairui Song <kasong@redhat.com> Date: Thu Apr 22 03:27:10 2021 +0800 kdumpctl: Add kdumpctl estimate Add a rough esitimation support, currently, following memory usage are checked by this sub command: - System RAM - Kdump Initramfs size - Kdump Kernel image size - Kdump Kernel module size - Kdump userspace user and other runtime allocated memory (currently simply using a fixed value: 64M) - LUKS encryption memory usage The output of kdumpctl estimate looks like this: # kdumpctl estimate Reserved crashkernel: 256M Recommanded crashkernel: 160M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M Large modules: xfs: 1892352 nouveau: 2318336 And if the kdump target is encrypted: # kdumpctl estimate Encrypted kdump target requires extra memory, assuming using the keyslot with minimun memory requirement Reserved crashkernel: 256M Recommanded crashkernel: 655M Kernel image size: 47M Kernel modules size: 12M Initramfs size: 19M Runtime reservation: 64M LUKS required size: 512M Large modules: xfs: 1892352 nouveau: 2318336 WARNING: Current crashkernel size is lower than recommanded size 655M. The "Recommanded" value is calculated based on memory usages mentioned above, and will be adjusted accodingly to be no less than the value provided by kdump_get_arch_recommend_size. Signed-off-by: Kairui Song <kasong@redhat.com> Acked-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com>
2021-04-21 19:27:10 +00:00
do_estimate
;;
get-default-crashkernel)
get_default_crashkernel "$2"
;;
reset-crashkernel)
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Resolves: bz1895258 Upstream: Fedora Conflict: None commit 140da74a340f872b2579fc75b50a36fe7015c0ba Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 13:39:40 2021 +0800 rewrite reset_crashkernel to support fadump and to used by RPM scriptlet Rewrite kdumpctl reset-crashkernel KERNEL_PATH as kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot] This interface would reset a specific kernel to the default crashkernel value given the kernel path. And it also supports grubby's syntax so there are the following special cases, - if --kernel not specified, - use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump - otherwise use current running kernel, i.e. `uname -r` - if --kernel=DEFAULT, the default boot kernel is chosen - if --kernel=ALL, all kernels would have its crashkernel reset to the default value and the /etc/default/grub is updated as well --fadump=[on|off|nocma] toggles fadump on/off for the kernel provided in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by parsing the kernel command line for the kernel(s) to update. CoreOS/Atomic/Silverblue needs to be treated as a special case because, - "rpm-ostree kargs" is used to manage kernel command line parameters so --kernel doesn't make sense and there is no need to find current running kernel - "rpm-ostree kargs" itself would prompt the user to reboot the system after modify the kernel command line parameter - POWER is not supported so we can assume the dump mode is always kdump This interface will also be called by kexec-tools RPM scriptlets [1] to reset crashkernel. Note the support of crashkenrel.default is dropped. [1] 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:09 +00:00
shift
reset_crashkernel "$@"
;;
_reset-crashkernel-after-update)
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value Resolves: bz1895258 Upstream: Fedora Conflict: None commit 0adb0f4a8c4c69ba54171f0113a4fbfc1729900f Author: Coiby Xu <coxu@redhat.com> Date: Wed Dec 1 15:33:13 2021 +0800 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> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
if [[ $(kdump_get_conf_val auto_reset_crashkernel) != no ]]; then
reset_crashkernel_after_update
fi
;;
_reset-crashkernel-for-installed_kernel)
reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools Resolves: bz1895258 Upstream: Fedora Conflict: None commit 5e8c751c39a5ec9d10009cba1c2bd554a5763b90 Author: Coiby Xu <coxu@redhat.com> Date: Thu Dec 2 17:19:50 2021 +0800 reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools When kexec-tools updates the default crashkernel value, it will try to reset the existing installed kernels including the currently running kernel. So the running kernel could have different kernel cmdline parameters from /proc/cmdline. When installing a kernel after updating kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called by kernel-install [1] which would use /proc/cmdline to set up new kernel's cmdline. To address this special case, reset the new kernel's crashkernel and fadump value to the value that would be used by running kernel after rebooting by the installation hook. One side effect of this commit is it would reset the installed kernel's crashkernel even currently running kernel don't use the default crashkernel value after rebooting. But I think this side effect is a benefit for the user. The implementation depends on kernel-install which run the scripts in /usr/lib/kernel/install.d passing the following arguments, add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] An concrete example is given as follows, add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz kernel-install could be started by the kernel package's RPM scriplet [2]. As mentioned in previous commit "try to reset kernel crashkernel when kexec-tools updates the default crashkernel value", kdumpctl has difficulty running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks, there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a collaboration between rpm-ostree and kexec-tools is needed [3] to take care of this special case. Note the crashkernel.default support is dropped. [1] https://www.freedesktop.org/software/systemd/man/kernel-install.html [2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680 [3] https://github.com/coreos/rpm-ostree/issues/2894 Reviewed-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Coiby Xu <coxu@redhat.com>
2022-01-05 03:53:22 +00:00
if [[ $(kdump_get_conf_val auto_reset_crashkernel) != no ]]; then
reset_crashkernel_for_installed_kernel "$2"
fi
;;
*)
dinfo $"Usage: $0 {estimate|start|stop|status|restart|reload|rebuild|reset-crashkernel|propagate|showmem}"
exit 1
;;
esac
}
# 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.
(
exec 9<&-
main "$@"
)