kexec July 2017

kexec@lists.fedoraproject.org

9 participants
18 discussions

[RESEND PATCH v4 4/8] kdumpctl: use generated rd.lvm.lv=X
by Xunlei Pang 10 Jul '17

10 Jul '17

Resolves: bz1451717 https://bugzilla.redhat.com/1451717 When there is any "rd.lvm.lv=X", "lvm" dracut module will try to recognize all the lvm volumes which is unnecessary and probably cause trouble for us. See https://bugzilla.redhat.com/show_bug.cgi?id=1451717#c2 Remove all the rd.lvm.lv=X inherited from the kernel cmdline, and generate the corresponding cmdline as needed for kdump. Because prepare_cmdline() is only used by kdump, we don't need to add any fadump judgement(also remove the existing judgement in passing). Currently, we don't handle "rd.lvm.vg=X", we can add it in when there is some bug reported in the future. Signed-off-by: Xunlei Pang <xlpang(a)redhat.com> --- kdumpctl | 47 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 45 insertions(+), 2 deletions(-) diff --git a/kdumpctl b/kdumpctl index 8c40564..fbeb9fb 100755 --- a/kdumpctl +++ b/kdumpctl @@ -171,6 +171,45 @@ check_kdump_cpus() echo " try nr_cpus=$nr_min or larger instead" } +# Generate rd.lvm.lv=X for the kdump targets if any. +generate_lvm_cmdlines() +{ + local lvm_cmdlines="" + + generate_lvm_cmdline() { + local majmin=$1 dev + + [ -d "/sys/dev/block/$majmin/dm" ] || return 0 + dev=/dev/mapper/$(< "/sys/dev/block/$majmin/dm/name") + + vg=$(lvm lvs --rows $dev -o vg_name --separator=* 2>/dev/null | cut -d "*" -f 2) + lv=$(lvm lvs --rows $dev -o lv_name --separator=* 2>/dev/null | cut -d "*" -f 2) + if [ -n "$vg" -a -n "$lv" ]; then + lvm_cmdlines="rd.lvm.lv=$vg/$lv $lvm_cmdlines" + fi + + return 0 + } + + for_each_block_target_all generate_lvm_cmdline + + echo "$lvm_cmdlines" +} + +# $1: function name +for_each_block_target_all() +{ + local dev majmin + + for dev in $(get_kdump_targets); do + [ -b "$dev" ] || continue + majmin=$(get_maj_min $dev) + check_block_and_slaves_all $1 $majmin + done + + return 0 +} + # This function performs a series of edits on the command line. # Store the final result in global $KDUMP_COMMANDLINE. prepare_cmdline() @@ -190,15 +229,19 @@ prepare_cmdline() # Always remove "root=X", as we now explicitly generate all kinds # of dump target mount information including root fs. But we can - # not remove it in case of fadump or "default dump_to_rootfs". + # not remove it in case of "default dump_to_rootfs". # # We do this before KDUMP_COMMANDLINE_APPEND, if one really cares # about it(e.g. for debug purpose), then can pass "root=X" using # KDUMP_COMMANDLINE_APPEND. - if [ $DEFAULT_DUMP_MODE != "fadump" ] && ! is_dump_to_rootfs; then + if ! is_dump_to_rootfs; then cmdline=`remove_cmdline_param "$cmdline" root` fi + # Remove all the inherited rd.lvm.lv=X and generate those as needed. + cmdline=`remove_cmdline_param "$cmdline" rd.lvm.lv` + cmdline="${cmdline} $(generate_lvm_cmdlines)" + cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}" id=`get_bootcpu_initial_apicid` -- 1.8.3.1

1 0

[PATCH v3 0/8] collect kdump targets and improve kdump per those information
by Xunlei Pang 07 Jul '17

07 Jul '17

We collect all the kdump targets i.e. devices recognized under kdump, then improve kdump according to the type of the target. Currently we have two: dump target and root target in case of "dump_to_rootfs". E.g. If we know there is no crypt target, we can remove dracut "crypt" module, we only add rd.lvm.lv=X regarding the lvm target to kdump. E.g. If we know there is only network dumping(ssh/nfs), we can omit some non-network modules like dm/lvm/multipath/crypt/iscsi/fcoe/etc. This series does two major things: 1)Patch 1~5 solve https://bugzilla.redhat.com/1451717 2)Patch 6~8 reduce the initramfs size by omitting needless dracut modules. Xunlei Pang (8): kdump-lib.sh: fix improper get_block_dump_target() kdump-lib.sh: introduce get_kdump_targets() mkdumprd: change for_each_block_target() to use get_kdump_targets() kdumpctl: use generated rd.lvm.lv=X mkdumprd: omit crypt when there is no crypt kdump target mkdumprd: omit dracut modules in case of no dm target mkdumprd: omit dracut modules in case of network dumping module-setup: fix kdump network dependency dracut-module-setup.sh | 2 +- kdump-lib.sh | 111 +++++++++++++++++++++++++++++++++++++++++++------ kdumpctl | 66 ++++++++++++++++++----------- mkdumprd | 111 ++++++++++++++++++++++++++++--------------------- 4 files changed, 204 insertions(+), 86 deletions(-) -- 1.8.3.1

3 21

[PATCH v2] kdumpctl: fix infinite loop caused by running under bash
by Ziyue Yang 06 Jul '17

06 Jul '17

Description of problem (https://bugzilla.redhat.com/show_bug.cgi?id=1465735): Run `kdumpctl status` as normal user, get below error messages: Another app is currently holding the kdump lock; waiting for it to exit... flock: 9: Bad file descriptor Another app is currently holding the kdump lock; waiting for it to exit... flock: 9: Bad file descriptor ... The bug is caused by behavior difference between bash and sh (bash in posix). In the function single_instance_lock in kdumpctl script, there is exec 9>/var/lock/kdump which will fail in user mode. However, this fail will cause script exiting under bash but not exiting under sh, causing infinite loop because the flock will always fail. According to the 16th item in ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html If a POSIX.2 special builtin returns an error status, a non- interactive shell exits. And according to https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html exec is one of the POSIX.2 special builtin's. This patch fixes the bug by checking exec return value. Signed-off-by: Ziyue Yang <ziyang(a)redhat.com> --- kdumpctl | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kdumpctl b/kdumpctl index e440bbb..a517925 100755 --- a/kdumpctl +++ b/kdumpctl @@ -37,6 +37,10 @@ single_instance_lock() local rc timeout=5 exec 9>/var/lock/kdump + if [ $? -ne 0 ]; then + echo "Creating file lock failed" + exit 1 + fi flock -n 9 rc=$? -- 2.9.3

2 1

[PATCH v2 0/7] collect kdump targets and improve kdump per those information
by Xunlei Pang 06 Jul '17

06 Jul '17

This patch series mainly solves https://bugzilla.redhat.com/1451717 We collect all the kdump targets i.e. devices recognized under kdump, then improve kdump according to the type of the target. E.g. If we know there is no crypt target, we can remove dracut "crypt" module, we only add rd.lvm.lv=X regarding the lvm target to kdump. Xunlei Pang (7): kdump-lib.sh: fix improper get_block_dump_target() kdump-lib.sh: introduce get_kdump_targets() mkdumprd: change for_each_block_target() to use get_kdump_targets() kdumpctl: use generated rd.lvm.lv=X mkdumprd: omit crypt when there is no crypt kdump target mkdumprd: omit dracut modules in case of no lvm target mkdumprd: omit dracut modules in case of network dumping kdump-lib.sh | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---- kdumpctl | 52 ++++++++++++----------- mkdumprd | 106 +++++++++++++++++++++++---------------------- 3 files changed, 212 insertions(+), 83 deletions(-) -- 1.8.3.1

5 23

[PATCH] kdumpctl: fix infinite loop caused by running under bash
by Ziyue Yang 03 Jul '17

03 Jul '17

The bug (https://bugzilla.redhat.com/show_bug.cgi?id=1465735) is caused by behavior difference between bash and sh (bash in posix). In the function single_instance_lock in kdumpctl script, there is exec 9>/var/lock/kdump which will fail in user mode. However, this fail will cause script exit under bash and non-exit under sh, causing infinite loop because the flock will always fail. According to the 16th item in ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html If a POSIX.2 special builtin returns an error status, a non- interactive shell exits. And according to https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html exec is one of the POSIX.2 special builtin's. This patch fixes the bug by checking exec return value. Signed-off-by: Ziyue Yang <ziyang(a)redhat.com> --- kdumpctl | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kdumpctl b/kdumpctl index e440bbb..a517925 100755 --- a/kdumpctl +++ b/kdumpctl @@ -37,6 +37,10 @@ single_instance_lock() local rc timeout=5 exec 9>/var/lock/kdump + if [ $? -ne 0 ]; then + echo "Creating file lock failed" + exit 1 + fi flock -n 9 rc=$? -- 2.9.3

2 2

[PATCH] kdumpctl: fix infinite loop caused by running under bash
by Ziyue Yang 03 Jul '17

03 Jul '17

Description of problem (https://bugzilla.redhat.com/show_bug.cgi?id=1465735): Run `kdumpctl status` as normal user, get below error messages: Another app is currently holding the kdump lock; waiting for it to exit... flock: 9: Bad file descriptor Another app is currently holding the kdump lock; waiting for it to exit... flock: 9: Bad file descriptor ... The bug is caused by behavior difference between bash and sh (bash in posix). In the function single_instance_lock in kdumpctl script, there is exec 9>/var/lock/kdump which will fail in user mode. However, this fail will cause script exit under bash and non-exit under sh, causing infinite loop because the flock will always fail. According to the 16th item in ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html If a POSIX.2 special builtin returns an error status, a non- interactive shell exits. And according to https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html exec is one of the POSIX.2 special builtin's. This patch fixes the bug by checking exec return value. Signed-off-by: Ziyue Yang <ziyang(a)redhat.com> --- kdumpctl | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kdumpctl b/kdumpctl index e440bbb..a517925 100755 --- a/kdumpctl +++ b/kdumpctl @@ -37,6 +37,10 @@ single_instance_lock() local rc timeout=5 exec 9>/var/lock/kdump + if [ $? -ne 0 ]; then + echo "Creating file lock failed" + exit 1 + fi flock -n 9 rc=$? -- 2.9.3

1 0

[PATCH] kdumpctl: fix infinite loop caused by running under bash
by Ziyue Yang 03 Jul '17

03 Jul '17

Description of problem (https://bugzilla.redhat.com/show_bug.cgi?id=1465735): Run `kdumpctl status` as normal user, get below error messages: Another app is currently holding the kdump lock; waiting for it to exit... flock: 9: Bad file descriptor Another app is currently holding the kdump lock; waiting for it to exit... flock: 9: Bad file descriptor ... The bug is caused by behavior difference between bash and sh (bash in posix). In the function single_instance_lock in kdumpctl script, there is exec 9>/var/lock/kdump which will fail in user mode. However, this fail will cause script exit under bash and non-exit under sh, causing infinite loop because the flock will always fail. According to the 16th item in ftp://ftp.gnu.org/old-gnu/Manuals/bash-2.02/html_node/bashref_66.html If a POSIX.2 special builtin returns an error status, a non- interactive shell exits. And according to https://www.gnu.org/software/bash/manual/html_node/Special-Builtins.html exec is one of the POSIX.2 special builtin's. This patch fixes the bug by checking exec return value. Signed-off-by: Ziyue Yang <ziyang(a)redhat.com> --- kdumpctl | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kdumpctl b/kdumpctl index e440bbb..a517925 100755 --- a/kdumpctl +++ b/kdumpctl @@ -37,6 +37,10 @@ single_instance_lock() local rc timeout=5 exec 9>/var/lock/kdump + if [ $? -ne 0 ]; then + echo "Creating file lock failed" + exit 1 + fi flock -n 9 rc=$? -- 2.9.3

1 0

[PATCH 0/4] collect kdump targets and improve kdump per those information
by Xunlei Pang 03 Jul '17

03 Jul '17

This patch series solves https://bugzilla.redhat.com/1451717 We collect all the kdump targets i.e. devices recognized under kdump, then improve kdump according to the type of the target. If we know there is no crypt target, we can remove dracut "crypt" module, we only add rd.lvm.lv=X regarding the lvm target to kdump. Xunlei Pang (4): kdump-lib.sh: fix inproper get_block_dump_target() kdumpctl: collect all the kdump targets kdumpctl: use generated rd.lvm.lv=X mkdumprd: omit crypt when there is no crypt kdump target kdump-lib.sh | 44 ++++++++++++++++++++----- kdumpctl | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++------ mkdumprd | 39 ++++++++++++++-------- 3 files changed, 158 insertions(+), 31 deletions(-) -- 1.8.3.1

3 20

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec July 2017