February 2014 - kexec - Fedora mailing-lists

[PATCH] Add some missing variables to default sysconfig and kdumpctl
by Dave Young 04 May '14

04 May '14

When I testing arm kdump, the kdump start failed with several missing variables Copy them from x86 sysconfig to general sysconfig so at least user can set the right value in sysconfig Also It's better to add them to the beggining of kdumpctl and initilize them as nul, later sourcing sysconfig will overwite them. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kdump.sysconfig | 9 +++++++++ kdumpctl | 3 +++ 2 files changed, 12 insertions(+) --- kexec-tools.orig/kdump.sysconfig +++ kexec-tools/kdump.sysconfig @@ -24,3 +24,12 @@ KDUMP_COMMANDLINE_APPEND="irqpoll maxcpu # Example: # KEXEC_ARGS="--elf32-core-headers" KEXEC_ARGS="" + +#Where to find the boot image +KDUMP_BOOTDIR="/boot" + +#What is the image type used for kdump +KDUMP_IMG="" + +#What is the images extension. Relocatable kernels don't have one +KDUMP_IMG_EXT="" --- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -9,6 +9,9 @@ MKDUMPRD="/sbin/mkdumprd -f" SAVE_PATH=/var/crash SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" DUMP_TARGET="" +KDUMP_BOOTDIR="" +KDUMP_IMG="" +KDUMP_IMG_EXT="" . /lib/kdump/kdump-lib.sh

2 1

[PATCH v3 0/8] kdump: Modify kdump init script to support firmware-assisted dump
by Hari Bathini 29 Apr '14

29 Apr '14

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 in v3: 1. Split few functions for readability. 2. Added a cleanup patch to remove unnecessay "function" keyword. --- Hari Bathini (8): 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: Take a backup of original default initrd before rebuilding. kdump: Rebuild default initrd for firmware assisted dump kdump: Get rid of "function" keyword from all functions kdump: Check for /proc/vmcore existence before capturing the vmcore. kdump: Add firmware-assisted dump howto document dracut-kdump.sh | 3 fadump-howto.txt | 428 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kdumpctl | 308 +++++++++++++++++++++++++++++++++------ 3 files changed, 691 insertions(+), 48 deletions(-) create mode 100644 fadump-howto.txt -- - Hari

4 18

[PATCH v2] kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel
by Jerry Hoemann 16 Mar '14

16 Mar '14

== Version 2 == Addresses Vivek's review comments: 1. Don't force numeric in awk script snipet. 2. Command line processing is moved from load_kernel to new function "prepare_cmdline." This new function is responsible for setting up the command line passed to KEXEC. 3. New function "append_cmdline" is added to append {argument,value} pair to command line if argument is not already present. == Version 1 == A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 --- kdumpctl | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 54 insertions(+), 7 deletions(-) diff --git a/kdumpctl b/kdumpctl index 46ae633..0a0bab1 100755 --- a/kdumpctl +++ b/kdumpctl @@ -41,6 +41,59 @@ function remove_cmdline_param() echo $cmdline } +# +# This function returns the "initial apicid" of the +# boot cpu (cpu 0) if present. +# +function get_bootcpu_initial_apicid() +{ + awk ' \ + BEGIN { CPU = "-1"; } \ + $1=="processor" && $2==":" { CPU = $NF; } \ + CPU=="0" && /initial apicid/ { print $NF; } \ + ' \ + /proc/cpuinfo +} + +# +# This function appends argument "$2=$3" to string ($1) if not already present. +# +function append_cmdline() +{ + local cmdline=$1 + local newstr=${cmdline/$2/""} + + # unchanged str implies argument wasn't there + if [ "$cmdline" == "$newstr" ]; then + cmdline="${cmdline} ${2}=${3}" + fi + + echo $cmdline +} + +# This function performs a series of edits on the command line +function prepare_cmdline() +{ + local cmdline; + if [ -z "$KDUMP_COMMANDLINE" ]; then + cmdline=`cat /proc/cmdline` + else + cmdline=${KDUMP_COMMANDLINE} + fi + cmdline=`remove_cmdline_param "$cmdline" crashkernel hugepages hugepagesz` + + + cmdline="${cmdline} ${KDUMP_COMMANDLINE_APPEND}" + + local id=`get_bootcpu_initial_apicid` + if [ ! -z ${id} ] ; then + cmdline=`append_cmdline "${cmdline}" disable_cpu_apicid ${id}` + fi + + echo $cmdline +} + + function save_core() { coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`" @@ -244,13 +297,7 @@ function load_kdump() fi fi - if [ -z "$KDUMP_COMMANDLINE" ] - then - KDUMP_COMMANDLINE=`cat /proc/cmdline` - fi - KDUMP_COMMANDLINE=`remove_cmdline_param "$KDUMP_COMMANDLINE" crashkernel hugepages hugepagesz` - - KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} ${KDUMP_COMMANDLINE_APPEND}" + KDUMP_COMMANDLINE=`prepare_cmdline` $KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \ -- 1.8.5.3

4 9

[Patch v2] kdump fails loading if target is root fs by default while disk is mounted on save path
by Baoquan He 03 Mar '14

03 Mar '14

kdump now dumps vmcore to root partition by default in SAVE_PATCH directory, e.g /var/crash defaultly. This is problematic when another disk is mounted on /var or /var/crash, because the saved vmcore will he hidden after dump in 1st kernel. This also has the potential of blindly filling the root file system without a clue as to why. Now fix this by failing the loading of kdump kernel if dump target is root fs by default while different disk is mounted on save path. Signed-off-by: Baoquan He <bhe(a)redhat.com> --- mkdumprd | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/mkdumprd b/mkdumprd index bc002bc..d30b34c 100644 --- a/mkdumprd +++ b/mkdumprd @@ -453,6 +453,34 @@ check_resettable() return 1 } +check_block_dump_target() +{ + local _target + local _mntpoint + + if is_ssh_dump_target || is_nfs_dump_target; then + return + fi + + _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}') + [ -n "$_target" ] && return + + #get rootfs device name + _target=$(findmnt -k -f -n -o SOURCE /) + if [ -b "$_target" ]; then + mkdir -p $SAVE_PATH + _mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'` + _target=`df $SAVE_PATH | tail -1 | awk '{print $1}'` + if [ "$_mntpoint" != "/" ]; then + perror "Currently SAVE_PATH is $SAVE_PATH, $_target is mounted on $_mntpoint. While dump target is root filesystem by default." + perror_exit "Then vmcore will be hidden in 1st kernel after dump. Please check /etc/kdump.conf clearly to remove confusion!" + fi + fi + +} + +check_block_dump_target + if ! check_resettable; then exit 1 fi -- 1.8.3.1

2 5

[PATCH] s390x: do not install /etc/adjtime
by WANG Chao 28 Feb '14

28 Feb '14

On s390x, RTC or hardware clock doesn't exist. So we don't need /etc/adjtime to adjust time to UTC or localtime. AFAIK, s390 uses a more precise time source which is storing time in UTC. But we still need /etc/localtime to determine the system-wide time zone. Signed-off-by: WANG Chao <chaowang(a)redhat.com> --- dracut-module-setup.sh | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 4e7d5dc..37a5fa5 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -460,6 +460,16 @@ kdump_install_random_seed() { bs=$poolsize count=1 2> /dev/null } +# /etc/adjtime is used to determine RTC time format (UTC or localtime) +# /etc/localtime is used to set system timezone +kdump_install_time() { + # RTC doesn't exist on s390 + if [ `uname -m` != "s390x" ]; then + dracut_install -o /etc/adjtime + fi + dracut_install -o /etc/localtime +} + install() { kdump_install_conf >"$initdir/lib/dracut/no-emergency-shell" @@ -467,7 +477,7 @@ install() { if is_ssh_dump_target; then kdump_install_random_seed fi - dracut_install -o /etc/adjtime /etc/localtime + kdump_install_time inst "$moddir/monitor_dd_progress" "/kdumpscripts/monitor_dd_progress" chmod +x ${initdir}/kdumpscripts/monitor_dd_progress inst "/bin/dd" "/bin/dd" -- 1.8.5.3

3 6

[PATCH] adjust the installkernel function to make it return correct value
by Baoquan He 28 Feb '14

28 Feb '14

The old implementation in installkernel() will not return success when added wdt module is not iTCO_wdt. The returned value is related to the comparison. This is not correct and will cause kdump load failed. Now move the exact wdt module inserting to the right place, this can be fixed. Signed-off-by: Baoquan He <bhe(a)redhat.com> --- dracut-module-setup.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 4e7d5dc..bdadf7c 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -489,7 +489,7 @@ install() { installkernel() { wdt=$(lsmod|cut -f1 -d' '|grep "wdt$") if [ -n "$wdt" ]; then - instmods $wdt [ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich + instmods $wdt fi } -- 1.8.3.1

2 1

[PATCH] kdump fails loading if default action is dump_to_rootfs when disk is mounted on save path
by Baoquan He 24 Feb '14

24 Feb '14

kdump now defaults to only dump vmcore to the root partition in the /var/crash directory. This is problematic when /var is a separate file system because this makes saved vmcore hidden since one can not unmount /var even in single user mode. This also has the potential of blindly filling the root file system without out a clue as to why. Now fix this by failing the loading of kdump kernel if default action is dump_to_rootfs while different disk is mounted on save path. Signed-off-by: Baoquan He <bhe(a)redhat.com> --- kexec-kdump-howto.txt | 3 +++ mkdumprd | 20 ++++++++++++++++++++ 2 files changed, 23 insertions(+) diff --git a/kexec-kdump-howto.txt b/kexec-kdump-howto.txt index 7ffeab9..a43c225 100644 --- a/kexec-kdump-howto.txt +++ b/kexec-kdump-howto.txt @@ -430,6 +430,9 @@ There are other default actions available though. - poweroff Poweroff system after failure. +Note that if default action is set to dump_to_rootfs, kdump will fail +loading of kdump kernel when a different disk is mounted on 'save path'. + Compression and filtering The 'core_collector' parameter in kdump.conf allows you to specify a custom diff --git a/mkdumprd b/mkdumprd index bc002bc..a86f8bb 100644 --- a/mkdumprd +++ b/mkdumprd @@ -370,6 +370,24 @@ get_default_action_target() return } +check_default_action_target() +{ + local _target + local _mntpoint + local _action=$(grep "^default" /etc/kdump.conf 2>/dev/null | awk '{print $2}') + if [ -n "$_action" ] && [ "$_action" = "dump_to_rootfs" ]; then + #get rootfs device name + mkdir -p $SAVE_PATH + _mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'` + _target=`df $SAVE_PATH | tail -1 | awk '{print $1}'` + if [ "$_mntpoint" != "/" ]; then + perror_exit "$_target is mounted on $_mntpoint" + fi + fi + return +} + + get_override_resettable() { local override_resettable @@ -453,6 +471,8 @@ check_resettable() return 1 } +check_default_action_target + if ! check_resettable; then exit 1 fi -- 1.8.3.1

2 4

[PATCH v2 0/7] kdump: Modify kdump init script to support firmware-assisted dump
by Hari Bathini 24 Feb '14

24 Feb '14

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 in v2: 1. Added dump_mode variable to store dump type to use during checks. 2. Split start, stop and rebuild routines for kdump and fadump. 3. Rebased to kexec-tools version 2.0.4-24. 4. Added fadump howto document. --- 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: Take a backup of original default initrd before rebuilding. 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 dracut-kdump.sh | 3 fadump-howto.txt | 428 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kdumpctl | 263 +++++++++++++++++++++++++++++---- 3 files changed, 660 insertions(+), 34 deletions(-) create mode 100644 fadump-howto.txt -- - Hari

4 13

[PATCH v2] Relax restriction of dumping on encrypted target
by Arthur Zou 20 Feb '14

20 Feb '14

Resolve: bz1053045 Description: Currently kdumpctl will fail to create kdump initramfs and start kdump service while dump target is encrypted. This restriction is too strict. Resolution: Just warn user that encrypted device is in dump path and second kernel will wait on console for password to be entered. Signed-off-by: arthur <zzou(a)redhat.com> --- mkdumprd | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/mkdumprd b/mkdumprd index bc002bc..6797791 100644 --- a/mkdumprd +++ b/mkdumprd @@ -467,7 +467,7 @@ is_crypt() eval "$line" [[ "$ID_FS_TYPE" = "crypto_LUKS" ]] && { dev=$(udevadm info --query=all --path=/sys/dev/block/$majmin | awk -F= '/DEVNAME/{print $2}') - perror "Device $dev is encrypted, can not be used in kdump." + echo "Device $dev is encrypted." return 0 } return 1 @@ -482,18 +482,11 @@ check_crypt() [ $_ret -eq 0 ] && return - if [ $_ret -eq 1 ]; then - _target=$(get_block_dump_target) - perror "Can not save vmcore to target device $_target." - elif [ $_ret -eq 2 ]; then - perror "Default action is dump_to_rootfs but can not save vmcore to root device." - fi - return 1 } if ! check_crypt; then - exit 1 + echo "Warning: Encrypted device is in dump path. User will prompted for password during second kernel boot." fi # firstly get right SSH_KEY_LOCATION -- 1.8.4.2

2 2

[PATCH] kdumpctl: Pass disable_cpu_apicid to kexec of capture kernel
by Jerry Hoemann 20 Feb '14

20 Feb '14

A recent patch (https://lkml.org/lkml/2014/1/15/42) enables multiple processors in the crash kernel. To do this safely the crash kernel needs to know which CPU was the 1st kernel BSP (bootstrap processor) so that the crash kernel will NOT send the BSP an INIT. If the crash kernel sends an INIT to the 1st kernel BSP, some systems may reset or hang. The EFI spec doesn't require that any particular processor is chosen as the BSP and the CPU (and its apic id) can change from one boot to the next. Hence automating the selection of CPU to disable if the system would panic is desired. This patch updates the kdumpctl script to get the "initial apicid" of CPU 0 in the first kernel and will pass this as the "disable_cpu_apicid=" arguement to kexec if it wasn't explicitly set in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND. CPU 0 is chosen as it is the processor thats execute the OS initialization code and hence was the BSP as per x86 SDM (Vol 3a Section 8.4.) See associated Red Hat Bugzilla(s) for additional background material: https://bugzilla.redhat.com/show_bug.cgi?id=1059031 https://bugzilla.redhat.com/show_bug.cgi?id=980621 --- kdumpctl | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/kdumpctl b/kdumpctl index 46ae633..0f6cd20 100755 --- a/kdumpctl +++ b/kdumpctl @@ -208,6 +208,26 @@ function need_64bit_headers() print (strtonum("0x" r[2]) > strtonum("0xffffffff")); }'` } +# This function supplies argument disable_cpu_apicid if +# not explicitly specified in KDUMP_COMMANDLINE_APPEND. +# It will be the "initial apicid" of CPU 0 if it exists. + +function disable_apicid() +{ + local cmdline=${KDUMP_COMMANDLINE_APPEND/"disable_cpu_apicid"/":"} + + if [ "$cmdline" != "$KDUMP_COMMANDLINE_APPEND" ] ; then + return 0 + fi + + awk ' \ + BEGIN { CPU = -1; } \ + $1=="processor" && $2==":" { CPU = 0+$NF; } \ + CPU==0 && /initial apicid/ {print "disable_cpu_apicid="$NF;} \ + ' \ + /proc/cpuinfo +} + # 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. @@ -251,6 +271,7 @@ function load_kdump() KDUMP_COMMANDLINE=`remove_cmdline_param "$KDUMP_COMMANDLINE" crashkernel hugepages hugepagesz` KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} ${KDUMP_COMMANDLINE_APPEND}" + KDUMP_COMMANDLINE="${KDUMP_COMMANDLINE} `disable_apicid`" $KEXEC $KEXEC_ARGS $standard_kexec_args \ --command-line="$KDUMP_COMMANDLINE" \ -- 1.8.5.3

2 1

Query about package versioning
by Vivek Goyal 20 Feb '14

20 Feb '14

Hi All, We are trying to sort out how to do kexec-tools package version, release number management in fedora across various branches, hence this query. I quickly went through following. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Naming_an… So far we do following. - In master branch keep on doing development and keep on bumping release at regular intervals. kexec-tools-2.0.4-1.fc21 kexec-tools-2.0.4-2.fc21 kexec-tools-2.0.4-3.fc21 ... ... kexec-tools-2.0.4-23.fc21 Lets say now FC21 forks off and a new branch is created. We keep on bumping release number in FC21 branch also. kexec-tools-2.0.4-24.fc21 kexec-tools-2.0.4-25.fc21 ... ... kexec-tools-2.0.4-30.fc21 And master will continue. kexec-tools-2.0.4-24.fc22 kexec-tools-2.0.4-25.fc22 ... ... kexec-tools-2.0.4-30.fc22 Are we doing the right thing here. I have few problems with above model. - By bumping release version, we kind of lose the information what was our base at the time of fork of branch. - Release numbers of released branch can get ahead of master branch depending on how many releases were done on master and how many releases were done on released branches. So instead of increasing release number on released branches, why don't we append additional number after dist and bump that up in released branch. So FC21 releases will look like. kexec-tools-2.0.4-24.fc21.1 kexec-tools-2.0.4-24.fc21.2 ... ... kexec-tools-2.0.4-23.fc21.10 That way we clearly know that FC21 was forked off master release .24. And upgradability of package will be maintained without any change of older release versions getting ahead of newer release versions. Thanks Vivek

1 0

[PATCH] Relax restriction of dumping on encrypted target
by Arthur Zou 18 Feb '14

18 Feb '14

Resolve: bz1053045 Description: Currently kdumpctl will fail to create kdump initramfs and start kdump service while dump target is encrypted. This restriction is too strict. Resolution: Just warn user that encrypted device is in dump path and second kernel will wait on console for password to be entered. Signed-off-by: arthur <zzou(a)redhat.com> --- mkdumprd | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/mkdumprd b/mkdumprd index bc002bc..c7dfa9c 100644 --- a/mkdumprd +++ b/mkdumprd @@ -467,7 +467,7 @@ is_crypt() eval "$line" [[ "$ID_FS_TYPE" = "crypto_LUKS" ]] && { dev=$(udevadm info --query=all --path=/sys/dev/block/$majmin | awk -F= '/DEVNAME/{print $2}') - perror "Device $dev is encrypted, can not be used in kdump." + echo "Warning: Target device $dev is encrypted." return 0 } return 1 @@ -482,18 +482,11 @@ check_crypt() [ $_ret -eq 0 ] && return - if [ $_ret -eq 1 ]; then - _target=$(get_block_dump_target) - perror "Can not save vmcore to target device $_target." - elif [ $_ret -eq 2 ]; then - perror "Default action is dump_to_rootfs but can not save vmcore to root device." - fi - return 1 } if ! check_crypt; then - exit 1 + echo "Warning: Encrypted device is in dump path and capture kernel will wait on console for password to be entered." fi # firstly get right SSH_KEY_LOCATION -- 1.8.4.2

2 3

gitk --all on fedora kexec-tools tree
by Vivek Goyal 17 Feb '14

17 Feb '14

Hi Chao, I am running "gitk --all" on fedora kexec-tools tree. I kind of expected that master branch runs first and then rest of the branches fork off that. Something like as follows. -------------------------------------------------------> master | | | |--->f18 |----->f19 |---->f20 In my gitk view f20 seems to be on top and it looks as if master has been forked off the main trunk. I am not sure if this is gitk behavior and it is possible that it can show branches anyway, or it has something to do with we fork off branches. Anyway, this is not something very important. I noticed something and thought of bringing it to your notice. Thanks Vivek

3 3

[PATCH v2] remove the selinux filpping code in propagate_ssh_key
by Arthur Zou 17 Feb '14

17 Feb '14

Resolves bz971279 Description of problem: Previously with selinux in enforcing mode, could prevent ssh-keygen from generating keys. Support for selinux policy for allowing applications to access ssh-keygen for generating ssh keys was added in selinux-policy-3.7.19-126.el6_2.6. Solutions: Because of the context was added for ssh key generation, so the keys were generated without fliping from enforcing mode to permissive mode for ssh key generation. This patch removes selinux code which switches between enforcing and permissive modes. Signed-off-by: arthur <zzou(a)redhat.com> --- kdumpctl | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/kdumpctl b/kdumpctl index 46ae633..d27557a 100755 --- a/kdumpctl +++ b/kdumpctl @@ -317,13 +317,6 @@ function propagate_ssh_key() exit 1 fi - #Check if selinux is on... must flip to permissive mode - #for the moment to create key, then flip back... - se_enforce=`/usr/sbin/sestatus | grep -c "^Current mode.*enforcing"` - if [ "$se_enforce" -ge 1 ]; then - /usr/sbin/setenforce 0 2>&1 > /dev/null - fi - local KEYFILE=$SSH_KEY_LOCATION local errmsg="Failed to propagate ssh key" @@ -336,11 +329,6 @@ function propagate_ssh_key() echo "done." fi - #If necessary, flip selinux back to enforcing - if [ "$se_enforce" -ge 1 ]; then - /usr/sbin/setenforce 1 2>&1 > /dev/null - fi - #now find the target ssh user and server to contact. SSH_USER=`echo $DUMP_TARGET | cut -d\ -f2 | cut -d@ -f1` SSH_SERVER=`echo $DUMP_TARGET | sed -e's/$.*(a)$$.*$$/\2/'` -- 1.8.4.2

2 1

[PATCH] add fsck passno to dracut --mount args
by Dave Young 14 Feb '14

14 Feb '14

We are using dracut --mount to pass fstab lines for mounting filesystems other than rootfs. But we did not provide passno for filesystem checking. Add passno '2' for all the --mount targets. Tested in F19 guest. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- mkdumprd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- kexec-tools.orig/mkdumprd +++ kexec-tools/mkdumprd @@ -104,7 +104,7 @@ to_mount() { _o=$(findmnt -k -f -n -r -o OPTIONS $_dev) _o=${_o/#ro/rw} #mount fs target as rw in 2nd kernel _o="${_o},nofail" #with nofail set, systemd won't block for mount failure - _mntopts="$_t $_o" + _mntopts="$_t $_o 0 2" #for non-nfs _dev converting to use udev persistent name if [ -b "$_s" ]; then _pdev="$(get_persistent_dev $_s)"

4 13

[PATCH v2 0/2] Add Secure boot support warnings
by Dave Young 14 Feb '14

14 Feb '14

Changes from v1: Use the error message from Vivek. echo detail error in check_kdump_feasibility Dave Young (2): kdumpctl: claim that kdump does not support secure boot when service start kdumpctl: status function cleanup kdumpctl | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 53 insertions(+), 15 deletions(-) -- 1.8.3.1

2 8

[PATCH] insert wdt kernel modules when watchdog is active
by Baoquan He 13 Feb '14

13 Feb '14

When watchdog is enabled in 1st kernel, then crash dump in kdump kernel will be interrupted if watchdog is timeout. Since some wdt drivers can stop the watchdog when its driver is loaded, e.g iTCO_wdt, this can benefit crash dump. Add watchdog driver which is active in system to initramfs, its loading can stop watchdog. For now, put this adding in 99kdumpbase. Signed-off-by: Baoquan He <bhe(a)redhat.com> --- dracut-module-setup.sh | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index c013430..d1ba83e 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -418,3 +418,11 @@ install() { # at some point of time. kdump_check_iscsi_targets } + +installkernel() { + wdt=$(lsmod|cut -f1 -d' '|grep "wdt$") + if [ -n "$wdt" ]; then + instmods $wdt + [ "$wdt" = "iTCO_wdt" ] && instmods lpc_ich + fi +} -- 1.8.3.1

3 8

[PATCH 1/2] kdumpctl: claim that kdump does not support secure boot when service start
by Dave Young 12 Feb '14

12 Feb '14

Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function. In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details. Tested in Fedora 19 + qemu ovmf with secure boot enabled. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kdumpctl | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) --- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,46 @@ selinux_relabel() done } +# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# 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() +{ + local secure_boot_file setup_mode_file + local secure_boot_byte setup_mode_byte + + secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null) + setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null) + + if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then + secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5) + setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5) + + if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then + return 0 + fi + fi + + return 1 +} + +function check_kdump_feasibility() +{ + if is_secure_boot_enforced; then + return 1; + fi +} + function start() { + local rc + check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]" @@ -517,6 +555,13 @@ function start() return 1 fi + check_kdump_feasibility + rc=$? + if [ $rc == 1 ]; then + echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry. [WARNING]" + return 1 + fi + status rc=$? if [ $rc == 2 ]; then

2 4

[PATCH 2/2] kdumpctl: status function cleanup
by Dave Young 11 Feb '14

11 Feb '14

Move the code to check /sys/kernel/kexec_crash_loaded to function check_kdump_feasibility(). And rename status() to check_current_kdump_status() so these two functions become clearer. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kdumpctl | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) --- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -384,12 +384,8 @@ function propagate_ssh_key() } -function status() +function check_current_kdump_status() { - if [ ! -e /sys/kernel/kexec_crash_loaded ] - then - return 2 - fi rc=`cat /sys/kernel/kexec_crash_loaded` if [ $rc == 1 ]; then return 0 @@ -534,6 +530,10 @@ function check_kdump_feasibility() if is_secure_boot_enforced; then return 1; fi + + if [ ! -e /sys/kernel/kexec_crash_loaded ]; then + return 2 + fi } function start() @@ -560,18 +560,15 @@ function start() if [ $rc == 1 ]; then echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry. [WARNING]" return 1 - fi - - status - rc=$? - if [ $rc == 2 ]; then + elif [ $rc == 2 ]; then echo "Kdump is not supported on this kernel: [WARNING]" return 1; - else - if [ $rc == 0 ]; then - echo "Kdump already running: [WARNING]" - return 0 - fi + fi + + check_current_kdump_status + if [ $? == 0 ]; then + echo "Kdump already running: [WARNING]" + return 0 fi if check_ssh_config; then

2 2

[PATCH v2] kdumpctl: claim that kdump does not support secure boot when service start
by Dave Young 11 Feb '14

11 Feb '14

Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function. In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details. Tested in Fedora 19 + qemu ovmf with secure boot enabled. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kdumpctl | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) --- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,44 @@ selinux_relabel() done } +# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# is 1 and SetupMode is 0, then secure boot is being enforced. +# +# Assume efivars is mounted at /sys/firmware/efi/efivars. +function check_secure_boot() +{ + local secure_boot_file setup_mode_file + local secure_boot_byte setup_mode_byte + + secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null) + setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null) + + if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then + secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5) + setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5) + + if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then + return 0 + fi + fi + + return 1 +} + function start() { + check_secure_boot + if [ $? -eq 0 ]; then + echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry." + echo "Starting kdump: [FAILED]" + return 1 + fi + check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]"

4 10

[PATCH resend] kdumpctl: claim that kdump does not support secure boot when service start
by Dave Young 07 Feb '14

07 Feb '14

Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function. In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details. Tested in Fedora 19 + qemu ovmf with secure boot enabled. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kdumpctl | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) --- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,44 @@ selinux_relabel() done } +# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# is 1 and SetupMode is 0, then secure boot is being enforced. +# +# Assume efivars is mounted at /sys/firmware/efi/efivars. +function check_secure_boot() +{ + local secure_boot_file setup_mode_file + local secure_boot_byte setup_mode_byte + + secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null) + setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null) + + if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then + secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5) + setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5) + + if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then + return 0 + fi +fi + + return 1 +} + function start() { + check_secure_boot + if [ $? -eq 0 ]; then + echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry." + echo "Starting kdump: [FAILED]" + return 1 + fi + check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]"

1 0

[PATCH] kdumpctl: claim that kdump does not support secure boot when service start
by Dave Young 07 Feb '14

07 Feb '14

Kdump does not support secure boot yet, so let's claim it is not supported at the begginning of service start function. In this patch for checking secure boot status I'm checking the efivars per suggestion from pjones. see in code comments for the details. Tested in Fedora 19 + qemu ovmf with secure boot enabled. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kdumpctl | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) --- kexec-tools.orig/kdumpctl +++ kexec-tools/kdumpctl @@ -500,8 +500,43 @@ selinux_relabel() done } +# Check if secure boot is being enforced. +# +# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and +# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four +# bytes are the attributes associated with the variable and can safely be +# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot +# is 1 and SetupMode is 0, then secure boot is being enforced. +# +# Assume efivars is mounted at /sys/firmware/efi/efivars. +function check_secure_boot() +{ + local secure_boot_file setup_mode_file + local secure_boot_byte setup_mode_byte + + secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null) + setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null) + + if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then + secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5) + setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5) + + if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then + return 0 + fi +fi + + return 1 +} + function start() { + check_secure_boot + if [ $? -eq 0 ]; then + echo "Secure boot is not supported in kdump yet. Please disable secure boot and retry." + echo "Starting kdump: [FAILED]" + fi + check_config if [ $? -ne 0 ]; then echo "Starting kdump: [FAILED]"

1 1

[PATCH 0/6] kdump: Modify kdump init script to support firmware-assisted dump
by Hari Bathini 05 Feb '14

05 Feb '14

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. --- Hari Bathini (6): 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: Take a backup of original default initrd before rebuilding. kdump: Rebuild default initrd for firmware assisted dump kdump: Check for /proc/vmcore existence before capturing the vmcore. dracut-kdump.sh | 3 + kdumpctl | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 169 insertions(+), 15 deletions(-) -- - Hari

2 11

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec February 2014