Query about package versioning
by Vivek Goyal
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_...
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
10 years, 2 months
[PATCH] Relax restriction of dumping on encrypted target
by Arthur Zou
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
10 years, 2 months
gitk --all on fedora kexec-tools tree
by Vivek Goyal
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
10 years, 2 months
[PATCH v2] remove the selinux filpping code in propagate_ssh_key
by Arthur Zou
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
10 years, 2 months
[PATCH] add fsck passno to dracut --mount args
by Dave Young
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)"
10 years, 2 months
[PATCH v2 0/2] Add Secure boot support warnings
by Dave Young
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
10 years, 2 months
[PATCH] insert wdt kernel modules when watchdog is active
by Baoquan He
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
10 years, 2 months
[PATCH 1/2] kdumpctl: claim that kdump does not support secure boot when service start
by Dave Young
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
10 years, 2 months
[PATCH 2/2] kdumpctl: status function cleanup
by Dave Young
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
10 years, 2 months
[PATCH v2] kdumpctl: claim that kdump does not support secure boot when service start
by Dave Young
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]"
10 years, 2 months
