kexec February 2014

kexec@lists.fedoraproject.org

12 participants
23 discussions

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 12 Feb '14

12 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec February 2014