This patch set implements firmware-assisted dump support for kdump service. Firmware-assisted dump support depends on existing kdump infrastructure (kdump scripts) present in userland to save dump to the disk. Though existing kdump script will work seemlessly, it still needs to modified to make it aware of presense of firmware- assisted dump feature during service start and stop. These changes are tested successfully on a power box with fedora19.
Changes from v5 to v6: 1. Using common global variable TARGET_INITRD for both kdump and fadump modes 2. Reworked on determine_dump_mode routine 3. Using a temporary image for rebuilding
---
Hari Bathini (7): kdump: Modify status routine to check for firmware-assisted dump kdump: Modify kdump script to start the firmware assisted dump. kdump: Modify kdump script to stop firmware assisted dump kdump: Rebuild default initrd for firmware assisted dump kdump: Check for /proc/vmcore existence before capturing the vmcore. kdump: Add firmware-assisted dump howto document cleanup: Remove "function" keyword from all functions and correct typos
dracut-kdump.sh | 3 + fadump-howto.txt | 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kdumpctl | 242 ++++++++++++++++++++++++++++++++++++++++++++-------- 3 files changed, 456 insertions(+), 39 deletions(-) create mode 100644 fadump-howto.txt
This patch enables kdump script to check if firmware-assisted dump is enabled or not by reading value from '/sys/kernel/fadump_enabled'. The determine_dump_mode() routine sets dump_mode to 'fadump', if fadump is enabled. By default, dump_mode is set to 'kdump' mode.
Modify status routine to check if firmware assisted dump is registered or not by reading value from '/sys/kernel/fadump_registered' file. If it is set to '1' then return status=0 else return status=1.
0 <= Firmware assisted is enabled and running 1 <= Firmware assisted is enabled but not running
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- kdumpctl | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 60 insertions(+), 3 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 9cae0c4..d6deea7 100755 --- a/kdumpctl +++ b/kdumpctl @@ -9,6 +9,10 @@ MKDUMPRD="/sbin/mkdumprd -f" SAVE_PATH=/var/crash SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" DUMP_TARGET="" +FADUMP_ENABLED_SYS_NODE="/sys/kernel/fadump_enabled" +FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered" +#kdump shall be the default dump mode +DEFAULT_DUMP_MODE="kdump"
. /lib/kdump/kdump-lib.sh
@@ -24,6 +28,16 @@ single_instance_lock() flock 9 }
+determine_dump_mode() +{ + # Check if firmware-assisted dump is enabled + # if yes, set the dump mode as fadump + if is_fadump_capable; then + echo "Dump mode is fadump" + DEFAULT_DUMP_MODE="fadump" + fi +} + # remove_cmdline_param <kernel cmdline> <param1> [<param2>] ... [<paramN>] # Remove a list of kernel parameters from a given kernel cmdline and print the result. # For each "arg" in the removing params list, "arg" and "arg=xxx" will be removed if exists. @@ -427,6 +441,25 @@ function propagate_ssh_key() }
+is_fadump_capable() +{ + # Check if firmware-assisted dump is enabled + # if no, fallback to kdump check + if [ -f $FADUMP_ENABLED_SYS_NODE ]; then + rc=`cat $FADUMP_ENABLED_SYS_NODE` + [ $rc -eq 1 ] && return 0 + fi + return 1 +} + +check_current_fadump_status() +{ + # Check if firmware-assisted dump has been registered. + rc=`cat $FADUMP_REGISTER_SYS_NODE` + [ $rc -eq 1 ] && return 0 + return 1 +} + function check_current_kdump_status() { rc=`cat /sys/kernel/kexec_crash_loaded` @@ -437,6 +470,17 @@ function check_current_kdump_status() fi }
+check_current_status() +{ + if [ $DEFAULT_DUMP_MODE == "fadump" ]; then + check_current_fadump_status + else + check_current_kdump_status + fi + + return $? +} + function save_raw() { local kdump_dir @@ -596,6 +640,16 @@ function check_fence_kdump_config() return 0 }
+check_dump_feasibility() +{ + if [ $DEFAULT_DUMP_MODE != "kdump" ]; then + return 0 + fi + + check_kdump_feasibility + return $? +} + function start() { check_config @@ -613,13 +667,13 @@ function start() return 1 fi
- check_kdump_feasibility + check_dump_feasibility if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]" return 1 fi
- check_current_kdump_status + check_current_status if [ $? == 0 ]; then echo "Kdump already running: [WARNING]" return 0 @@ -667,6 +721,9 @@ fi
main () { + # Determine if the dump mode is kdump or fadump + determine_dump_mode + case "$1" in start) if [ -s /proc/vmcore ]; then @@ -681,7 +738,7 @@ main () ;; status) EXIT_CODE=0 - check_current_kdump_status + check_current_status case "$?" in 0) echo "Kdump is operational"
During service kdump start, if firmware assisted dump is not enabled then fallback to starting of existing kexec based kdump. If firmware assisted is enabled but not running, then start firmware assisted dump by echo'ing 1 to '/sys/kernel/fadump_registered' file.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com --- kdumpctl | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/kdumpctl b/kdumpctl index d6deea7..f319bd2 100755 --- a/kdumpctl +++ b/kdumpctl @@ -650,6 +650,29 @@ check_dump_feasibility() return $? }
+start_fadump() +{ + echo 1 > $FADUMP_REGISTER_SYS_NODE + if ! check_current_fadump_status; then + echo "fadump: failed to register" + return 1 + fi + + echo "fadump: registered successfully" + return 0 +} + +start_dump() +{ + if [ $DEFAULT_DUMP_MODE == "fadump" ]; then + start_fadump + else + load_kdump + fi + + return $? +} + function start() { check_config @@ -691,7 +714,8 @@ function start() echo "Starting kdump: [FAILED]" return 1 fi - load_kdump + + start_dump if [ $? != 0 ]; then echo "Starting kdump: [FAILED]" return 1
During service kdump stop, if firmware assisted dump is enabled and running, then stop firmware assisted dump by echo'ing 0 to '/sys/kernel/fadump_registered' file.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- kdumpctl | 39 +++++++++++++++++++++++++++++++++------ 1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/kdumpctl b/kdumpctl index f319bd2..4bc3952 100755 --- a/kdumpctl +++ b/kdumpctl @@ -724,18 +724,45 @@ function start() echo "Starting kdump: [OK]" }
-function stop() +stop_fadump() +{ + echo 0 > $FADUMP_REGISTER_SYS_NODE + if check_current_fadump_status; then + echo "fadump: failed to unregister" + return 1 + fi + + echo "fadump: unregistered successfully" + return 0 +} + +stop_kdump() { $KEXEC -p -u 2>/dev/null - if [ $? == 0 ]; then - echo "kexec: unloaded kdump kernel" - echo "Stopping kdump: [OK]" - return 0 - else + if [ $? != 0 ]; then echo "kexec: failed to unloaded kdump kernel" + return 1 + fi + + echo "kexec: unloaded kdump kernel" + return 0 +} + +function stop() +{ + if [ $DEFAULT_DUMP_MODE == "fadump" ]; then + stop_fadump + else + stop_kdump + fi + + if [ $? != 0 ]; then echo "Stopping kdump: [FAILED]" return 1 fi + + echo "Stopping kdump: [OK]" + return 0 }
if [ ! -f "$KDUMP_CONFIG_FILE" ]; then
The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd.
The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken.
Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script.
Patch that adds "--mod" option to lsinitrd tool is posted upstream, awaiting approval. Link for reference: http://www.spinics.net/lists/linux-initramfs/msg03670.html
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- kdumpctl | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 4bc3952..e86bee0 100755 --- a/kdumpctl +++ b/kdumpctl @@ -9,6 +9,7 @@ MKDUMPRD="/sbin/mkdumprd -f" SAVE_PATH=/var/crash SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" DUMP_TARGET="" +TARGET_INITRD="" FADUMP_ENABLED_SYS_NODE="/sys/kernel/fadump_enabled" FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered" #kdump shall be the default dump mode @@ -133,13 +134,45 @@ function save_core() fi }
-function rebuild_initrd() +rebuild_fadump_initrd() { - $MKDUMPRD $kdump_initrd $kdump_kver + # backup fadump initrd for reference before replacing it + backup_initrd + + target_initrd_tmp="$TARGET_INITRD.tmp" + $MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver + if [ $? != 0 ]; then + echo "mkdumprd: failed to rebuild initrd with fadump support" >&2 + return 1 + fi + + # updating fadump initrd + mv $target_initrd_tmp $TARGET_INITRD + sync + + return 0 +} + +rebuild_kdump_initrd() +{ + $MKDUMPRD $TARGET_INITRD $kdump_kver if [ $? != 0 ]; then echo "mkdumprd: failed to make kdump initrd" >&2 return 1 fi + + return 0 +} + +rebuild_initrd() +{ + if [ $DEFAULT_DUMP_MODE == "fadump" ]; then + rebuild_fadump_initrd + else + rebuild_kdump_initrd + fi + + return $? }
#$1: the files to be checked with IFS=' ' @@ -164,6 +197,17 @@ function check_executable() done }
+backup_initrd() +{ + target_initrd_bak="$TARGET_INITRD.default.bak" + + # Check if backup initrd is already present. + if [ ! -e $target_initrd_bak ];then + echo "Backing up $TARGET_INITRD" + cp $TARGET_INITRD $target_initrd_bak + fi +} + function check_config() { local nr @@ -242,7 +286,17 @@ function check_rebuild() fi
kdump_kernel="${KDUMP_BOOTDIR}/${KDUMP_IMG}-${kdump_kver}${KDUMP_IMG_EXT}" - kdump_initrd="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img" + if [ $DEFAULT_DUMP_MODE == "fadump" ]; then + TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}.img" + if [ ! -s "$TARGET_INITRD" ]; then + echo "Error: No initrd found to rebuild!" + return 1 + fi + fadump_support=`lsinitrd -m $TARGET_INITRD | grep ^kdumpbase$ | wc -l` + else + TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img" + fadump_support=-1 + fi
_force_rebuild=`grep ^force_rebuild $KDUMP_CONFIG_FILE 2>/dev/null` if [ $? -eq 0 ]; then @@ -259,8 +313,8 @@ function check_rebuild()
#check to see if dependent files has been modified #since last build of the image file - if [ -f $kdump_initrd ]; then - image_time=`stat -c "%Y" $kdump_initrd 2>/dev/null` + if [ -f $TARGET_INITRD ]; then + image_time=`stat -c "%Y" $TARGET_INITRD 2>/dev/null` else image_time=0 fi @@ -287,8 +341,10 @@ function check_rebuild()
if [ $image_time -eq 0 ]; then echo -n "No kdump initial ramdisk found."; echo + elif [ "$fadump_support" -eq "0" ]; then + echo "$TARGET_INITRD has no fadump support" elif [ "$force_rebuild" != "0" ]; then - echo -n "Force rebuild $kdump_initrd"; echo + echo -n "Force rebuild $TARGET_INITRD"; echo elif [ -n "$modified_files" ]; then echo "Detected change(s) the following file(s):" echo -n " "; echo "$modified_files" | sed 's/\s/\n /g' @@ -296,7 +352,7 @@ function check_rebuild() return 0 fi
- echo "Rebuilding $kdump_initrd" + echo "Rebuilding $TARGET_INITRD" rebuild_initrd return $? } @@ -349,7 +405,7 @@ function load_kdump()
$KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \ - --initrd=$kdump_initrd $kdump_kernel 2>/dev/null + --initrd=$TARGET_INITRD $kdump_kernel 2>/dev/null if [ $? == 0 ]; then echo "kexec: loaded kdump kernel" return 0
On Thu, Jun 12, 2014 at 08:26:15PM +0530, Hari Bathini wrote:
The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd.
The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken.
Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script.
Patch that adds "--mod" option to lsinitrd tool is posted upstream, awaiting approval. Link for reference: http://www.spinics.net/lists/linux-initramfs/msg03670.html
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
kdumpctl | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 4bc3952..e86bee0 100755 --- a/kdumpctl +++ b/kdumpctl @@ -9,6 +9,7 @@ MKDUMPRD="/sbin/mkdumprd -f" SAVE_PATH=/var/crash SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" DUMP_TARGET="" +TARGET_INITRD="" FADUMP_ENABLED_SYS_NODE="/sys/kernel/fadump_enabled" FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered" #kdump shall be the default dump mode @@ -133,13 +134,45 @@ function save_core() fi }
Hi Hari,
This patch is almost there. I have few more minor comments.
-function rebuild_initrd() +rebuild_fadump_initrd() {
- $MKDUMPRD $kdump_initrd $kdump_kver
- # backup fadump initrd for reference before replacing it
- backup_initrd
- target_initrd_tmp="$TARGET_INITRD.tmp"
All the local variables please define the at beginning of function, like.
local target_initrd_tmp
- $MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver
- if [ $? != 0 ]; then
echo "mkdumprd: failed to rebuild initrd with fadump support" >&2
return 1
- fi
- # updating fadump initrd
- mv $target_initrd_tmp $TARGET_INITRD
- sync
This system wide sync might harm us at some point of time. For the time being it is fine. But ideally send a patch to util-linux maintainer and write a small "fsync" utility and call "fsync $TARGET_INITRD". I heard that some unix variant had "fsync" as stand alone program.
- return 0
+}
+rebuild_kdump_initrd() +{
- $MKDUMPRD $TARGET_INITRD $kdump_kver if [ $? != 0 ]; then echo "mkdumprd: failed to make kdump initrd" >&2 return 1 fi
- return 0
+}
+rebuild_initrd() +{
- if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
rebuild_fadump_initrd
- else
rebuild_kdump_initrd
- fi
- return $?
}
#$1: the files to be checked with IFS=' ' @@ -164,6 +197,17 @@ function check_executable() done }
+backup_initrd() +{
- target_initrd_bak="$TARGET_INITRD.default.bak"
Why not just "$TARGET_INITRD.bak". I am wondering what's the purpose of "default" string.
- # Check if backup initrd is already present.
- if [ ! -e $target_initrd_bak ];then
echo "Backing up $TARGET_INITRD"
cp $TARGET_INITRD $target_initrd_bak
- fi
So this backup happens only if backup is not already present?
+}
function check_config() { local nr @@ -242,7 +286,17 @@ function check_rebuild() fi
kdump_kernel="${KDUMP_BOOTDIR}/${KDUMP_IMG}-${kdump_kver}${KDUMP_IMG_EXT}"
- kdump_initrd="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img"
- if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}.img"
if [ ! -s "$TARGET_INITRD" ]; then
echo "Error: No initrd found to rebuild!"
return 1
fi
fadump_support=`lsinitrd -m $TARGET_INITRD | grep ^kdumpbase$ | wc -l`
fadump_support name is little confusing. How about "initramfs_has_fadump". Also define this variable as "local" in the beginning of function.
- else
TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img"
fadump_support=-1
I don't think this is required. See below.
- fi
Can we move above logic in a separate function, say setup_target_initrd(). And in that function you can also do error handling if default intird is not found. In parent function check for return code and bail out.
_force_rebuild=`grep ^force_rebuild $KDUMP_CONFIG_FILE 2>/dev/null` if [ $? -eq 0 ]; then @@ -259,8 +313,8 @@ function check_rebuild()
#check to see if dependent files has been modified #since last build of the image file
- if [ -f $kdump_initrd ]; then
image_time=`stat -c "%Y" $kdump_initrd 2>/dev/null`
- if [ -f $TARGET_INITRD ]; then
else image_time=0 fiimage_time=`stat -c "%Y" $TARGET_INITRD 2>/dev/null`
@@ -287,8 +341,10 @@ function check_rebuild()
if [ $image_time -eq 0 ]; then echo -n "No kdump initial ramdisk found."; echo
- elif [ "$fadump_support" -eq "0" ]; then
This check could be combination of two checks. Something like.
elif [ DUMP_MODE == fadump && !initramfs_has_fadump ]
This is much more readable.
elif [ "$force_rebuild" != "0" ]; thenecho "$TARGET_INITRD has no fadump support"
echo -n "Force rebuild $kdump_initrd"; echo
elif [ -n "$modified_files" ]; then echo "Detected change(s) the following file(s):" echo -n " "; echo "$modified_files" | sed 's/\s/\n /g'echo -n "Force rebuild $TARGET_INITRD"; echo
@@ -296,7 +352,7 @@ function check_rebuild() return 0 fi
- echo "Rebuilding $kdump_initrd"
- echo "Rebuilding $TARGET_INITRD" rebuild_initrd return $?
} @@ -349,7 +405,7 @@ function load_kdump()
$KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \
--initrd=$kdump_initrd $kdump_kernel 2>/dev/null
if [ $? == 0 ]; then echo "kexec: loaded kdump kernel" return 0--initrd=$TARGET_INITRD $kdump_kernel 2>/dev/null
Thanks Vivek
On 07/11/2014 06:54 PM, Vivek Goyal wrote:
On Thu, Jun 12, 2014 at 08:26:15PM +0530, Hari Bathini wrote:
The current kdump infrastructure builds a separate initrd which then gets loaded into memory by kexec-tools for use by kdump kernel. But firmware assisted dump (FADUMP) does not use kexec-based approach. After crash, firmware reboots the partition and loads grub loader like the normal booting process does. Hence in the FADUMP approach, the second kernel (after crash) will always use the default initrd (OS built). So, to support FADUMP, change is required, as in to add dump capturing steps, in this initrd.
The current kdumpctl script implementation already has the code to build initrd using mkdumprd. This patch uses the new '--rebuild' option introduced, in dracut, to incrementally build the initramfs image. Before rebuilding, we may need to probe the initrd image for fadump support, to avoid rebuilding the initrd image multiple times unnecessarily. This can be done using "lsinitrd" tool with the newly proposed '--mod' option & inspecting the presence of "kdumpbase" in the list of modules of default initrd image. We rebuild the image if only "kdumpbase" module is missing in the initrd image. Also, before rebuilding, a backup of default initrd image is taken.
Kexec-tools package in rhel7 is now enhanced to insert a out-of-tree kdump module for dracut, which is responsible for adding vmcore capture steps into initrd, if dracut is invoked with "IN_KDUMP" environment variable set to 1. mkdumprd script exports "IN_KDUMP=1" environment variable before invoking dracut to build kdump initrd. This patch relies on this current mechanism of kdump init script.
Patch that adds "--mod" option to lsinitrd tool is posted upstream, awaiting approval. Link for reference: http://www.spinics.net/lists/linux-initramfs/msg03670.html
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
kdumpctl | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/kdumpctl b/kdumpctl index 4bc3952..e86bee0 100755 --- a/kdumpctl +++ b/kdumpctl @@ -9,6 +9,7 @@ MKDUMPRD="/sbin/mkdumprd -f" SAVE_PATH=/var/crash SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" DUMP_TARGET="" +TARGET_INITRD="" FADUMP_ENABLED_SYS_NODE="/sys/kernel/fadump_enabled" FADUMP_REGISTER_SYS_NODE="/sys/kernel/fadump_registered" #kdump shall be the default dump mode @@ -133,13 +134,45 @@ function save_core() fi }
Hi Hari,
This patch is almost there. I have few more minor comments.
-function rebuild_initrd() +rebuild_fadump_initrd() {
- $MKDUMPRD $kdump_initrd $kdump_kver
- # backup fadump initrd for reference before replacing it
- backup_initrd
- target_initrd_tmp="$TARGET_INITRD.tmp"
All the local variables please define the at beginning of function, like.
local target_initrd_tmp
- $MKDUMPRD $target_initrd_tmp --rebuild $TARGET_INITRD --kver $kdump_kver
- if [ $? != 0 ]; then
echo "mkdumprd: failed to rebuild initrd with fadump support" >&2
return 1
- fi
- # updating fadump initrd
- mv $target_initrd_tmp $TARGET_INITRD
- sync
This system wide sync might harm us at some point of time. For the time being it is fine. But ideally send a patch to util-linux maintainer and write a small "fsync" utility and call "fsync $TARGET_INITRD". I heard that some unix variant had "fsync" as stand alone program.
Will try to work on this. Adding a TODO for the time being..
- return 0
+}
+rebuild_kdump_initrd() +{
- $MKDUMPRD $TARGET_INITRD $kdump_kver if [ $? != 0 ]; then echo "mkdumprd: failed to make kdump initrd" >&2 return 1 fi
- return 0
+}
+rebuild_initrd() +{
if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
rebuild_fadump_initrd
else
rebuild_kdump_initrd
fi
return $? }
#$1: the files to be checked with IFS=' '
@@ -164,6 +197,17 @@ function check_executable() done }
+backup_initrd() +{
- target_initrd_bak="$TARGET_INITRD.default.bak"
Why not just "$TARGET_INITRD.bak". I am wondering what's the purpose of "default" string.
- # Check if backup initrd is already present.
- if [ ! -e $target_initrd_bak ];then
echo "Backing up $TARGET_INITRD"
cp $TARGET_INITRD $target_initrd_bak
- fi
So this backup happens only if backup is not already present?
Ideally, want to take a backup the first time fadump is used and be done with it..
+}
- function check_config() { local nr
@@ -242,7 +286,17 @@ function check_rebuild() fi
kdump_kernel="${KDUMP_BOOTDIR}/${KDUMP_IMG}-${kdump_kver}${KDUMP_IMG_EXT}"
- kdump_initrd="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img"
- if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}.img"
if [ ! -s "$TARGET_INITRD" ]; then
echo "Error: No initrd found to rebuild!"
return 1
fi
fadump_support=`lsinitrd -m $TARGET_INITRD | grep ^kdumpbase$ | wc -l`
fadump_support name is little confusing. How about "initramfs_has_fadump". Also define this variable as "local" in the beginning of function.
- else
TARGET_INITRD="${KDUMP_BOOTDIR}/initramfs-${kdump_kver}kdump.img"
fadump_support=-1
I don't think this is required. See below.
- fi
Can we move above logic in a separate function, say setup_target_initrd(). And in that function you can also do error handling if default intird is not found. In parent function check for return code and bail out.
_force_rebuild=`grep ^force_rebuild $KDUMP_CONFIG_FILE 2>/dev/null` if [ $? -eq 0 ]; then @@ -259,8 +313,8 @@ function check_rebuild()
#check to see if dependent files has been modified #since last build of the image file
- if [ -f $kdump_initrd ]; then
image_time=`stat -c "%Y" $kdump_initrd 2>/dev/null`
- if [ -f $TARGET_INITRD ]; then
else image_time=0 fiimage_time=`stat -c "%Y" $TARGET_INITRD 2>/dev/null`
@@ -287,8 +341,10 @@ function check_rebuild()
if [ $image_time -eq 0 ]; then echo -n "No kdump initial ramdisk found."; echo
- elif [ "$fadump_support" -eq "0" ]; then
This check could be combination of two checks. Something like.
elif [ DUMP_MODE == fadump && !initramfs_has_fadump ]
This is much more readable.
Sure. Will update accordingly..
elif [ "$force_rebuild" != "0" ]; thenecho "$TARGET_INITRD has no fadump support"
echo -n "Force rebuild $kdump_initrd"; echo
elif [ -n "$modified_files" ]; then echo "Detected change(s) the following file(s):" echo -n " "; echo "$modified_files" | sed 's/\s/\n /g'echo -n "Force rebuild $TARGET_INITRD"; echo
@@ -296,7 +352,7 @@ function check_rebuild() return 0 fi
- echo "Rebuilding $kdump_initrd"
- echo "Rebuilding $TARGET_INITRD" rebuild_initrd return $? }
@@ -349,7 +405,7 @@ function load_kdump()
$KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \
--initrd=$kdump_initrd $kdump_kernel 2>/dev/null
if [ $? == 0 ]; then echo "kexec: loaded kdump kernel" return 0--initrd=$TARGET_INITRD $kdump_kernel 2>/dev/null
Thanks Vivek
The script dracut-kdump.sh is responsible for capturing vmcore during second kernel boot. Currently this script gets installed into kdump initrd as part of kdumpbase dracut module. Since it's always installed into kdump initrd, this script assumes that '/proc/vmcore' will always be present when it is invoked.
With fadump support, 'dracut-kdump.sh' script also gets installed into default initrd to capture vmcore generated by firmware assisted dump. Thus in fadump case, the same initrd is going to be used for normal boot as well as boot after system crash. Hence a check is required to see if '/proc/vmcore' file exists before executing steps to capture vmcore. This check will help to bypass the vmcore capture steps during normal boot process.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com --- dracut-kdump.sh | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index cb13d92..55ac8bc 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -1,5 +1,8 @@ #!/bin/sh
+# continue only if /proc/vmcore is present. +[ ! -f /proc/vmcore ] && return + exec &> /dev/console . /lib/dracut-lib.sh . /lib/kdump-lib.sh
On Thu, Jun 12, 2014 at 08:26:22PM +0530, Hari Bathini wrote:
The script dracut-kdump.sh is responsible for capturing vmcore during second kernel boot. Currently this script gets installed into kdump initrd as part of kdumpbase dracut module. Since it's always installed into kdump initrd, this script assumes that '/proc/vmcore' will always be present when it is invoked.
With fadump support, 'dracut-kdump.sh' script also gets installed into default initrd to capture vmcore generated by firmware assisted dump. Thus in fadump case, the same initrd is going to be used for normal boot as well as boot after system crash. Hence a check is required to see if '/proc/vmcore' file exists before executing steps to capture vmcore. This check will help to bypass the vmcore capture steps during normal boot process.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com
dracut-kdump.sh | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index cb13d92..55ac8bc 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -1,5 +1,8 @@ #!/bin/sh
+# continue only if /proc/vmcore is present. +[ ! -f /proc/vmcore ] && return
How do we know if it is an error or it is fadump case. What if due to some bug /proc/vmcore is not present in case of kdump. We would like to detect that case and give proper error message.
I think you need to drop some kind of file in initramfs which tells you that you are running from an initramfs built for fadump. Say "fadump_initramfs". This can be done during initramfs build process.
And then check for presence of that file and return.
Thanks Vivek
On 07/11/2014 07:03 PM, Vivek Goyal wrote:
On Thu, Jun 12, 2014 at 08:26:22PM +0530, Hari Bathini wrote:
The script dracut-kdump.sh is responsible for capturing vmcore during second kernel boot. Currently this script gets installed into kdump initrd as part of kdumpbase dracut module. Since it's always installed into kdump initrd, this script assumes that '/proc/vmcore' will always be present when it is invoked.
With fadump support, 'dracut-kdump.sh' script also gets installed into default initrd to capture vmcore generated by firmware assisted dump. Thus in fadump case, the same initrd is going to be used for normal boot as well as boot after system crash. Hence a check is required to see if '/proc/vmcore' file exists before executing steps to capture vmcore. This check will help to bypass the vmcore capture steps during normal boot process.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com
dracut-kdump.sh | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index cb13d92..55ac8bc 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -1,5 +1,8 @@ #!/bin/sh
+# continue only if /proc/vmcore is present. +[ ! -f /proc/vmcore ] && return
How do we know if it is an error or it is fadump case. What if due to some bug /proc/vmcore is not present in case of kdump. We would like to detect that case and give proper error message.
I think you need to drop some kind of file in initramfs which tells you that you are running from an initramfs built for fadump. Say "fadump_initramfs". This can be done during initramfs build process.
A file inside initramfs may not work, as once the initramfs is built, it will be used for normal as well as kdump kernel. We may need to think of something else.. But looking at the code, the chances of /proc/vmcore not being present seem very slim..
Thanks Hari
And then check for presence of that file and return.
Thanks Vivek
On Mon, Jul 14, 2014 at 10:33:26PM +0530, Hari Bathini wrote:
On 07/11/2014 07:03 PM, Vivek Goyal wrote:
On Thu, Jun 12, 2014 at 08:26:22PM +0530, Hari Bathini wrote:
The script dracut-kdump.sh is responsible for capturing vmcore during second kernel boot. Currently this script gets installed into kdump initrd as part of kdumpbase dracut module. Since it's always installed into kdump initrd, this script assumes that '/proc/vmcore' will always be present when it is invoked.
With fadump support, 'dracut-kdump.sh' script also gets installed into default initrd to capture vmcore generated by firmware assisted dump. Thus in fadump case, the same initrd is going to be used for normal boot as well as boot after system crash. Hence a check is required to see if '/proc/vmcore' file exists before executing steps to capture vmcore. This check will help to bypass the vmcore capture steps during normal boot process.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com
dracut-kdump.sh | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index cb13d92..55ac8bc 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -1,5 +1,8 @@ #!/bin/sh +# continue only if /proc/vmcore is present. +[ ! -f /proc/vmcore ] && return
How do we know if it is an error or it is fadump case. What if due to some bug /proc/vmcore is not present in case of kdump. We would like to detect that case and give proper error message.
I think you need to drop some kind of file in initramfs which tells you that you are running from an initramfs built for fadump. Say "fadump_initramfs". This can be done during initramfs build process.
A file inside initramfs may not work, as once the initramfs is built, it will be used for normal as well as kdump kernel. We may need to think of something else..
Dropping a file in initramfs can atleast help you determine that this is fadump case. And in that case you can come up with special mechanism to figure out if /proc/vmcore was supposed to be there or not.
Given that powerpc firmware knows about it and boots kernel in restricted, memory, may be firmware can export that info to user space.
But looking at the code, the chances of /proc/vmcore not being present seem very slim..
There are error paths where vmcore initilization can fail and /proc/vmcore will not be present. So /proc/vmcore not being present does not necessarily mean that we are not booting after crash.
Thanks Vivek
On Thu, Jun 12, 2014 at 08:26:22PM +0530, Hari Bathini wrote:
The script dracut-kdump.sh is responsible for capturing vmcore during second kernel boot. Currently this script gets installed into kdump initrd as part of kdumpbase dracut module. Since it's always installed into kdump initrd, this script assumes that '/proc/vmcore' will always be present when it is invoked.
With fadump support, 'dracut-kdump.sh' script also gets installed into default initrd to capture vmcore generated by firmware assisted dump. Thus in fadump case, the same initrd is going to be used for normal boot as well as boot after system crash. Hence a check is required to see if '/proc/vmcore' file exists before executing steps to capture vmcore. This check will help to bypass the vmcore capture steps during normal boot process.
Hi Hari,
What happens if /proc/vmcore is present? So we use the existing logic to copy the vmcore to destination? But existing logic will reboot the machine after copying vmcore and I think that's not what you want.
Also existing logic will do error handling and try to dump somewhere else and reboot machine.
I don't think you want to reboot the machine. Have you taken care of all that and I missed it?
Thanks Vivek
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com
dracut-kdump.sh | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dracut-kdump.sh b/dracut-kdump.sh index cb13d92..55ac8bc 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -1,5 +1,8 @@ #!/bin/sh
+# continue only if /proc/vmcore is present. +[ ! -f /proc/vmcore ] && return
exec &> /dev/console . /lib/dracut-lib.sh . /lib/kdump-lib.sh
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
This patch adds fadump howto document to kexec-tools. The document is prepared in reference to kexec-kdump-howto.txt document.
Signed-off-by: Mahesh Salgaonkar mahesh@linux.vnet.ibm.com Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- fadump-howto.txt | 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 250 insertions(+) create mode 100644 fadump-howto.txt
diff --git a/fadump-howto.txt b/fadump-howto.txt new file mode 100644 index 0000000..e744b8c --- /dev/null +++ b/fadump-howto.txt @@ -0,0 +1,250 @@ +Firmware assisted dump (fadump) HOWTO + +Introduction + +Firmware assisted dump is a new feature in the 3.4 mainline kernel supported +only on powerpc architecture. The goal of firmware-assisted dump is to enable +the dump of a crashed system, and to do so from a fully-reset system, and to +minimize the total elapsed time until the system is back in production use. A +complete documentation on implementation can be found at +Documentation/powerpc/firmware-assisted-dump.txt in upstream linux kernel tree +from 3.4 version and above. + +Please note that the firmware-assisted dump feature is only available on Power6 +and above systems with recent firmware versions. + +Overview + +Fadump + +Fadump is a robust kernel crash dumping mechanism to get reliable kernel crash +dump with assistance from firmware. This approach does not use kexec, instead +firmware assists in booting the kdump kernel while preserving memory contents. +Unlike kdump, the system is fully reset, and loaded with a fresh copy of the +kernel. In particular, PCI and I/O devices are reinitialized and are in a +clean, consistent state. This second kernel, often called a capture kernel, +boots with very little memory and captures the dump image. + +The first kernel registers the sections of memory with the Power firmware for +dump preservation during OS initialization. These registered sections of memory +are reserved by the first kernel during early boot. When a system crashes, the +Power firmware fully resets the system, preserves all the system memory +contents, save the low memory (boot memory of size larger of 5% of system +RAM or 256MB) of RAM to the previous registered region. It will also save +system registers, and hardware PTE's. + +Fadump is supported only on ppc64 platform. The standard kernel and capture +kernel are one and the same on ppc64. + +If you're reading this document, you should already have kexec-tools +installed. If not, you install it via the following command: + + # yum install kexec-tools + +Fadump Operational Flow: + +Like kdump, fadump also exports the ELF formatted kernel crash dump through +/proc/vmcore. Hence existing kdump infrastructure can be used to capture fadump +vmcore. The idea is to keep the functionality transparent to end user. From +user perspective there is no change in the way kdump init script works. + +However, unlike kdump, fadump does not pre-load kdump kernel and initrd into +reserved memory, instead it always uses default OS initrd during second boot +after crash. Hence, for fadump, we rebuild the new kdump initrd and replace it +with default initrd. Before replacing existing default initrd we take a backup +of original default initrd for user's reference. The dracut package has been +enhanced to rebuild the default initrd with vmcore capture steps. The initrd +image is rebuilt as per the configuration in /etc/kdump.conf file. + +The control flow of fadump works as follows: +01. System panics. +02. At the crash, kernel informs power firmware that kernel has crashed. +03. Firmware takes the control and reboots the entire system preserving + only the memory (resets all other devices). +04. The reboot follows the normal booting process (non-kexec). +05. The boot loader loads the default kernel and initrd from /boot +06. The default initrd loads and runs /init +07. dracut-kdump.sh script present in fadump aware default initrd checks if + '/proc/vmcore' file exists before executing steps to capture vmcore. + (This check will help to bypass the vmcore capture steps during normal boot + process.) +09. Captures dump according to /etc/kdump.conf +10. Is dump capture successful (yes goto 12, no goto 11) +11. Perfom the default action specified in /etc/kdump.conf (Default action + is reboot, if unspecified) +12. Reboot + + +How to configure fadump: + +Again, we assume if you're reading this document, you should already have +kexec-tools installed. If not, you install it via the following command: + + # yum install kexec-tools + +To be able to do much of anything interesting in the way of debug analysis, +you'll also need to install the kernel-debuginfo package, of the same arch +as your running kernel, and the crash utility: + + # yum --enablerepo=*debuginfo install kernel-debuginfo.$(uname -m) crash + +Next up, we need to modify some boot parameters to enable firmware assisted +dump. With the help of grubby, it's very easy to append "fadump=on" to the end +of your kernel boot parameters. Optionally, user can also append +'fadump_reserve_mem=X' kernel cmdline to specify size of the memory to reserve +for boot memory dump preservation. + + # grubby --args="fadump=on" --update-kernel=/boot/vmlinuz-`uname -r` + +The term 'boot memory' means size of the low memory chunk that is required for +a kernel to boot successfully when booted with restricted memory. By default, +the boot memory size will be the larger of 5% of system RAM or 256MB. +Alternatively, user can also specify boot memory size through boot parameter +'fadump_reserve_mem=' which will override the default calculated size. Use this +option if default boot memory size is not sufficient for second kernel to boot +successfully. + +After making said changes, reboot your system, so that the specified memory is +reserved and left untouched by the normal system. Take note that the output of +'free -m' will show X MB less memory than without this parameter, which is +expected. If you see OOM (Out Of Memory) error messages while loading capture +kernel, then you should bump up the memory reservation size. + +Now that you've got that reserved memory region set up, you want to turn on +the kdump init script: + + # systemctl enable kdump.service + +Then, start up kdump as well: + + # systemctl start kdump.service + +This should turn on the firmware assisted functionality in kernel by +echo'ing 1 to /sys/kernel/fadump_registered, leaving the system ready +to capture a vmcore upon crashing. To test this out, you can force-crash +your system by echo'ing a c into /proc/sysrq-trigger: + + # echo c > /proc/sysrq-trigger + +You should see some panic output, followed by the system reset and booting into +fresh copy of kernel. When default initrd loads and runs /init, vmcore should +be copied out to disk (by default, in /var/crash/YYYY.MM.DD-HH:MM:SS/vmcore), +then the system rebooted back into your normal kernel. + +Once back to your normal kernel, you can use the previously installed crash +kernel in conjunction with the previously installed kernel-debuginfo to +perform postmortem analysis: + + # crash /usr/lib/debug/lib/modules/2.6.17-1.2621.el5/vmlinux + /var/crash/2006-08-23-15:34/vmcore + + crash> bt + +and so on... + +Saving vmcore-dmesg.txt +---------------------- +Kernel log bufferes are one of the most important information available +in vmcore. Now before saving vmcore, kernel log bufferes are extracted +from /proc/vmcore and saved into a file vmcore-dmesg.txt. After +vmcore-dmesg.txt, vmcore is saved. Destination disk and directory for +vmcore-dmesg.txt is same as vmcore. Note that kernel log buffers will +not be available if dump target is raw device. + +Dump Triggering methods: + +This section talks about the various ways, other than a Kernel Panic, in which +fadump can be triggered. The following methods assume that fadump is configured +on your system, with the scripts enabled as described in the section above. + +1) AltSysRq C + +FAdump can be triggered with the combination of the 'Alt','SysRq' and 'C' +keyboard keys. Please refer to the following link for more details: + +http://kbase.redhat.com/faq/FAQ_43_5559.shtm + +In addition, on PowerPC boxes, fadump can also be triggered via Hardware +Management Console(HMC) using 'Ctrl', 'O' and 'C' keyboard keys. + +2) Kernel OOPs + +If we want to generate a dump everytime the Kernel OOPses, we can achieve this +by setting the 'Panic On OOPs' option as follows: + + # echo 1 > /proc/sys/kernel/panic_on_oops + +3) PowerPC specific methods: + +On IBM PowerPC machines, issuing a soft reset invokes the XMON debugger(if +XMON is configured). To configure XMON one needs to compile the kernel with +the CONFIG_XMON and CONFIG_XMON_DEFAULT options, or by compiling with +CONFIG_XMON and booting the kernel with xmon=on option. + +Following are the ways to remotely issue a soft reset on PowerPC boxes, which +would drop you to XMON. Pressing a 'X' (capital alphabet X) followed by an +'Enter' here will trigger the dump. + +3.1) HMC + +Hardware Management Console(HMC) available on Power4 and Power5 machines allow +partitions to be reset remotely. This is specially useful in hang situations +where the system is not accepting any keyboard inputs. + +Once you have HMC configured, the following steps will enable you to trigger +fadump via a soft reset: + +On Power4 + Using GUI + + * In the right pane, right click on the partition you wish to dump. + * Select "Operating System->Reset". + * Select "Soft Reset". + * Select "Yes". + + Using HMC Commandline + + # reset_partition -m <machine> -p <partition> -t soft + +On Power5 + Using GUI + + * In the right pane, right click on the partition you wish to dump. + * Select "Restart Partition". + * Select "Dump". + * Select "OK". + + Using HMC Commandline + + # chsysstate -m <managed system name> -n <lpar name> -o dumprestart -r lpar + +3.2) Blade Management Console for Blade Center + +To initiate a dump operation, go to Power/Restart option under "Blade Tasks" in +the Blade Management Console. Select the corresponding blade for which you want +to initate the dump and then click "Restart blade with NMI". This issues a +system reset and invokes xmon debugger. + + +Advanced Setups & Default action: + +Kdump and fadump exhibit similar behavior in terms of setup & default action. +For fadump advanced setup related information see section "Advanced Setups" in +"kexec-kdump-howto.txt" document. Refer to "Default action" section in "kexec- +kdump-howto.txt" document for fadump default action related information. + +Compression and filtering + +Refer "Compression and filtering" section in "kexec-kdump-howto.txt" document. +Compression and filtering are same for kdump & fadump. + + +Notes on rootfs mount: +Dracut is designed to mount rootfs by default. If rootfs mounting fails it +will refuse to go on. So fadump leaves rootfs mounting to dracut currently. +We make the assumtion that proper root= cmdline is being passed to dracut +initramfs for the time being. If you need modify "KDUMP_COMMANDLINE=" in +/etc/sysconfig/kdump, you will need to make sure that appropriate root= +options are copied from /proc/cmdline. In general it is best to append +command line options using "KDUMP_COMMANDLINE_APPEND=" instead of replacing +the original command line completely.
This cleanup patch removes unnecessary keyword "function" at all places in kdumpctl script. Also, corrects couple of typos in the script.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com --- kdumpctl | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/kdumpctl b/kdumpctl index e86bee0..5c8796b 100755 --- a/kdumpctl +++ b/kdumpctl @@ -42,7 +42,7 @@ determine_dump_mode() # remove_cmdline_param <kernel cmdline> <param1> [<param2>] ... [<paramN>] # Remove a list of kernel parameters from a given kernel cmdline and print the result. # For each "arg" in the removing params list, "arg" and "arg=xxx" will be removed if exists. -function remove_cmdline_param() +remove_cmdline_param() { local cmdline=$1 shift @@ -60,7 +60,7 @@ function remove_cmdline_param() # This function returns the "initial apicid" of the # boot cpu (cpu 0) if present. # -function get_bootcpu_initial_apicid() +get_bootcpu_initial_apicid() { awk ' \ BEGIN { CPU = "-1"; } \ @@ -73,7 +73,7 @@ function get_bootcpu_initial_apicid() # # This function appends argument "$2=$3" to string ($1) if not already present. # -function append_cmdline() +append_cmdline() { local cmdline=$1 local newstr=${cmdline/$2/""} @@ -87,7 +87,7 @@ function append_cmdline() }
# This function performs a series of edits on the command line -function prepare_cmdline() +prepare_cmdline() { local cmdline; if [ -z "$KDUMP_COMMANDLINE" ]; then @@ -109,7 +109,7 @@ function prepare_cmdline() }
-function save_core() +save_core() { coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`"
@@ -176,7 +176,7 @@ rebuild_initrd() }
#$1: the files to be checked with IFS=' ' -function check_exist() +check_exist() { for file in $1; do if [ ! -f "$file" ]; then @@ -187,7 +187,7 @@ function check_exist() }
#$1: the files to be checked with IFS=' ' -function check_executable() +check_executable() { for file in $1; do if [ ! -x "$file" ]; then @@ -208,7 +208,7 @@ backup_initrd() fi }
-function check_config() +check_config() { local nr
@@ -274,7 +274,7 @@ get_pcs_cluster_modified_files() echo $modified_files }
-function check_rebuild() +check_rebuild() { local extra_modules modified_files="" local _force_rebuild force_rebuild="0" @@ -346,7 +346,7 @@ function check_rebuild() elif [ "$force_rebuild" != "0" ]; then echo -n "Force rebuild $TARGET_INITRD"; echo elif [ -n "$modified_files" ]; then - echo "Detected change(s) the following file(s):" + echo "Detected change(s) in the following file(s):" echo -n " "; echo "$modified_files" | sed 's/\s/\n /g' else return 0 @@ -359,7 +359,7 @@ function check_rebuild()
# This function check iomem and determines if we have more than # 4GB of ram available. Returns 1 if we do, 0 if we dont -function need_64bit_headers() +need_64bit_headers() { return `tail -n 1 /proc/iomem | awk '{ split ($1, r, "-"); \ print (strtonum("0x" r[2]) > strtonum("0xffffffff")); }'` @@ -368,7 +368,7 @@ function need_64bit_headers() # Load the kdump kerel specified in /etc/sysconfig/kdump # If none is specified, try to load a kdump kernel with the same version # as the currently running kernel. -function load_kdump() +load_kdump() { MEM_RESERVED=$(cat /sys/kernel/kexec_crash_size) if [ $MEM_RESERVED -eq 0 ] @@ -415,7 +415,7 @@ function load_kdump() fi }
-function check_ssh_config() +check_ssh_config() { while read config_opt config_val; do # remove inline comments after the end of a directive. @@ -448,7 +448,7 @@ function check_ssh_config() return 0 }
-function check_ssh_target() +check_ssh_target() { local _ret ssh -q -i $SSH_KEY_LOCATION -o BatchMode=yes $DUMP_TARGET mkdir -p $SAVE_PATH @@ -460,7 +460,7 @@ function check_ssh_target() return 0 }
-function propagate_ssh_key() +propagate_ssh_key() { check_ssh_config if [ $? -ne 0 ]; then @@ -516,7 +516,7 @@ check_current_fadump_status() return 1 }
-function check_current_kdump_status() +check_current_kdump_status() { rc=`cat /sys/kernel/kexec_crash_loaded` if [ $rc == 1 ]; then @@ -537,7 +537,7 @@ check_current_status() return $? }
-function save_raw() +save_raw() { local kdump_dir local raw_target @@ -648,7 +648,7 @@ selinux_relabel() # is 1 and SetupMode is 0, then secure boot is being enforced. # # Assume efivars is mounted at /sys/firmware/efi/efivars. -function is_secure_boot_enforced() +is_secure_boot_enforced() { local secure_boot_file setup_mode_file local secure_boot_byte setup_mode_byte @@ -668,7 +668,7 @@ function is_secure_boot_enforced() return 1 }
-function check_kdump_feasibility() +check_kdump_feasibility() { if is_secure_boot_enforced; then echo "Secure Boot is Enabled. Kdump service can't be started. Disable Secure Boot and retry" @@ -681,7 +681,7 @@ function check_kdump_feasibility() fi }
-function check_fence_kdump_config() +check_fence_kdump_config() { local hostname=`hostname` local nodes=$(get_option_value "fence_kdump_nodes") @@ -729,7 +729,7 @@ start_dump() return $? }
-function start() +start() { check_config if [ $? -ne 0 ]; then @@ -796,7 +796,7 @@ stop_kdump() { $KEXEC -p -u 2>/dev/null if [ $? != 0 ]; then - echo "kexec: failed to unloaded kdump kernel" + echo "kexec: failed to unload kdump kernel" return 1 fi
@@ -804,7 +804,7 @@ stop_kdump() return 0 }
-function stop() +stop() { if [ $DEFAULT_DUMP_MODE == "fadump" ]; then stop_fadump
On Thu, Jun 12, 2014 at 08:26:37PM +0530, Hari Bathini wrote:
This cleanup patch removes unnecessary keyword "function" at all places in kdumpctl script. Also, corrects couple of typos in the script.
Signed-off-by: Hari Bathini hbathini@linux.vnet.ibm.com
This can be first patch in the series. In fact post this patch separately and this can be applied first. And rebase your patch series on top of it.
Thanks Vivek