The package rpms/kexec-tools.git has added or updated architecture specific content in
its
spec file (ExclusiveArch/ExcludeArch or %ifarch/%ifnarch) in commit(s):
https://src.fedoraproject.org/cgit/rpms/kexec-tools.git/commit/?id=685e07....
Change:
+%ifarch ppc64 ppc64le
Thanks.
Full change:
============
commit 01a7da83f7a49579f77767bc3097b9bf31777738
Author: Coiby Xu <coxu(a)redhat.com>
Date: Sat Apr 2 12:19:35 2022 +0800
Release 2.0.23-6
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 819d68d..e0f5b5e 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -5,7 +5,7 @@
Name: kexec-tools
Version: 2.0.23
-Release: 5%{?dist}
+Release: 6%{?dist}
License: GPLv2
Summary: The kexec/kdump userspace component
@@ -412,6 +412,10 @@ fi
%endif
%changelog
+* Sat Apr 2 2022
+- arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela
+- purgatory: do not enable vectorization automatically for purgatory compiling
+
* Mon Feb 14 2022 Coiby <coxu(a)redhat.com> - 2.0.23-5
- fix incorrect usage of _get_all_kernels_from_grubby
- fix the mistake of swapping function parameters of read_proc_environ_var
commit 39789963fb3385d23500d9cfb6aceb1dac4e2271
Author: Coiby Xu <coxu(a)redhat.com>
Date: Sat Apr 2 12:06:42 2022 +0800
arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela
Resolves: bz2052949
Upstream: Fedora
Conflict: None
commit 8e3f663a4dfe39b303e25ea2b945a4fab9fef7ae
Author: Pingfan Liu <piliu(a)redhat.com>
Date: Thu Mar 31 11:38:05 2022 +0800
arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela
GCC 12 has some changes, which affects the generated AArch64 code of kexec-tools.
Accordingly, a new rel type R_AARCH64_LDST128_ABS_LO12_NC is confronted
by machine_apply_elf_rel() on AArch64. This fails the load of kernel
with the message "machine_apply_elf_rel: ERROR Unknown type: 299"
Citing from objdump -rDSl purgatory/purgatory.ro
0000000000000f80 <sha256_starts>:
sha256_starts():
f80: 90000001 adrp x1, 0 <verify_sha256_digest>
f80: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfa0
f84: a9007c1f stp xzr, xzr, [x0]
f88: 3dc00021 ldr q1, [x1]
f88: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfa0
f8c: 90000001 adrp x1, 0 <verify_sha256_digest>
f8c: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfb0
f90: 3dc00020 ldr q0, [x1]
f90: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfb0
f94: ad008001 stp q1, q0, [x0, #16]
f98: d65f03c0 ret
f9c: d503201f nop
fa0: 6a09e667 .inst 0x6a09e667 ; undefined
fa4: bb67ae85 .inst 0xbb67ae85 ; undefined
fa8: 3c6ef372 .inst 0x3c6ef372 ; undefined
fac: a54ff53a ld3w {z26.s-z28.s}, p5/z, [x9, #-3, mul vl]
fb0: 510e527f sub wsp, w19, #0x394
fb4: 9b05688c madd x12, x4, x5, x26
fb8: 1f83d9ab .inst 0x1f83d9ab ; undefined
fbc: 5be0cd19 .inst 0x5be0cd19 ; undefined
Here, gcc generates codes, which make loads and stores carried out using
the 128-bits floating-point registers. And a new rel type
R_AARCH64_LDST128_ABS_LO12_NC should be handled.
Make machine_apply_elf_rel() coped with this new reloc, so kexec-tools
can work smoothly.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
diff --git a/kexec-tools-2.0.23-arm64-kexec-arm64-add-support-for-R_AARCH64_LDST128_.patch
b/kexec-tools-2.0.23-arm64-kexec-arm64-add-support-for-R_AARCH64_LDST128_.patch
new file mode 100644
index 0000000..da5d8c9
--- /dev/null
+++ b/kexec-tools-2.0.23-arm64-kexec-arm64-add-support-for-R_AARCH64_LDST128_.patch
@@ -0,0 +1,94 @@
+From 8e3f663a4dfe39b303e25ea2b945a4fab9fef7ae Mon Sep 17 00:00:00 2001
+From: Pingfan Liu <piliu(a)redhat.com>
+Date: Thu, 31 Mar 2022 11:38:05 +0800
+Subject: [PATCH] arm64/kexec-arm64: add support for
+ R_AARCH64_LDST128_ABS_LO12_NC rela
+
+GCC 12 has some changes, which affects the generated AArch64 code of kexec-tools.
+Accordingly, a new rel type R_AARCH64_LDST128_ABS_LO12_NC is confronted
+by machine_apply_elf_rel() on AArch64. This fails the load of kernel
+with the message "machine_apply_elf_rel: ERROR Unknown type: 299"
+
+Citing from objdump -rDSl purgatory/purgatory.ro
+
+0000000000000f80 <sha256_starts>:
+sha256_starts():
+ f80: 90000001 adrp x1, 0 <verify_sha256_digest>
+ f80: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfa0
+ f84: a9007c1f stp xzr, xzr, [x0]
+ f88: 3dc00021 ldr q1, [x1]
+ f88: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfa0
+ f8c: 90000001 adrp x1, 0 <verify_sha256_digest>
+ f8c: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfb0
+ f90: 3dc00020 ldr q0, [x1]
+ f90: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfb0
+ f94: ad008001 stp q1, q0, [x0, #16]
+ f98: d65f03c0 ret
+ f9c: d503201f nop
+ fa0: 6a09e667 .inst 0x6a09e667 ; undefined
+ fa4: bb67ae85 .inst 0xbb67ae85 ; undefined
+ fa8: 3c6ef372 .inst 0x3c6ef372 ; undefined
+ fac: a54ff53a ld3w {z26.s-z28.s}, p5/z, [x9, #-3, mul vl]
+ fb0: 510e527f sub wsp, w19, #0x394
+ fb4: 9b05688c madd x12, x4, x5, x26
+ fb8: 1f83d9ab .inst 0x1f83d9ab ; undefined
+ fbc: 5be0cd19 .inst 0x5be0cd19 ; undefined
+
+Here, gcc generates codes, which make loads and stores carried out using
+the 128-bits floating-point registers. And a new rel type
+R_AARCH64_LDST128_ABS_LO12_NC should be handled.
+
+Make machine_apply_elf_rel() coped with this new reloc, so kexec-tools
+can work smoothly.
+
+Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
+Signed-off-by: Simon Horman <horms(a)verge.net.au>
+Signed-off-by: Coiby Xu <coiby.xu(a)gmail.com>
+---
+ kexec/arch/arm64/kexec-arm64.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
+index 9dd072c..e25f600 100644
+--- a/kexec/arch/arm64/kexec-arm64.c
++++ b/kexec/arch/arm64/kexec-arm64.c
+@@ -1248,6 +1248,10 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym
*UNUSED(sym),
+
+ #if !defined(R_AARCH64_LDST64_ABS_LO12_NC)
+ # define R_AARCH64_LDST64_ABS_LO12_NC 286
++#endif
++
++#if !defined(R_AARCH64_LDST128_ABS_LO12_NC)
++# define R_AARCH64_LDST128_ABS_LO12_NC 299
+ #endif
+
+ uint64_t *loc64;
+@@ -1309,6 +1313,7 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym
*UNUSED(sym),
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + (((value - address) >> 2) & 0x3ffffff));
+ break;
++ /* encode imm field with bits [11:3] of value */
+ case R_AARCH64_LDST64_ABS_LO12_NC:
+ if (value & 7)
+ die("%s: ERROR Unaligned value: %lx\n", __func__,
+@@ -1318,6 +1323,17 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym
*UNUSED(sym),
+ *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
+ + ((value & 0xff8) << (10 - 3)));
+ break;
++
++ /* encode imm field with bits [11:4] of value */
++ case R_AARCH64_LDST128_ABS_LO12_NC:
++ if (value & 15)
++ die("%s: ERROR Unaligned value: %lx\n", __func__,
++ value);
++ type = "LDST128_ABS_LO12_NC";
++ loc32 = ptr;
++ imm = value & 0xff0;
++ *loc32 = cpu_to_le32(le32_to_cpu(*loc32) + (imm << (10 - 4)));
++ break;
+ default:
+ die("%s: ERROR Unknown type: %lu\n", __func__, r_type);
+ break;
+--
+2.34.1
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 9ccb727..819d68d 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -108,6 +108,7 @@ Patch401:
./kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machi
#
# Patches 501 through 600 are meant for ARM kexec-tools enablement
#
+Patch501:
./kexec-tools-2.0.23-arm64-kexec-arm64-add-support-for-R_AARCH64_LDST128_.patch
#
# Patches 601 onward are generic patches
@@ -130,6 +131,7 @@ tar -z -x -v -f %{SOURCE9}
tar -z -x -v -f %{SOURCE19}
%patch401 -p1
+%patch501 -p1
%patch601 -p1
%ifarch ppc
commit c6b2a4b26ba75e14af39ce990a6f20d38edd0b60
Author: Coiby Xu <coxu(a)redhat.com>
Date: Sat Apr 2 12:00:46 2022 +0800
purgatory: do not enable vectorization automatically for purgatory compiling
Resolves: bz2057391
Upstream: Fedora
Conflict: None
commit 1b03cf7adc3c156ecab2618acb1ec585336a3f75
Author: Baoquan He <bhe(a)redhat.com>
Date: Tue Mar 29 18:12:28 2022 +0800
purgatory: do not enable vectorization automatically for purgatory compiling
Redhat CKI reported kdump kernel will hang a while very early after crash
triggered, then reset to firmware to reboot.
This failure can only be observed with kdump or kexec reboot via
kexec_load system call. With kexec_file_load interface, both kdump and
kexec reboot work very well. And further investigation shows that gcc
version 11 doesn't have this issue, while gcc version 12 does.
After checking the release notes of the latest gcc, Dave found out it's
because gcc 12 enables auto-vectorization for -O2 optimization level.
Please see below link for more information:
https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Auto-Vec-O2
Adding -fno-tree-vectorize to Makefile of purgatory can fix the issue.
Signed-off-by: Baoquan He <bhe(a)redhat.com>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
diff --git a/kexec-tools-2.0.23-purgatory-do-not-enable-vectorization-automatically-.patch
b/kexec-tools-2.0.23-purgatory-do-not-enable-vectorization-automatically-.patch
new file mode 100644
index 0000000..85ae7e6
--- /dev/null
+++ b/kexec-tools-2.0.23-purgatory-do-not-enable-vectorization-automatically-.patch
@@ -0,0 +1,44 @@
+From 1b03cf7adc3c156ecab2618acb1ec585336a3f75 Mon Sep 17 00:00:00 2001
+From: Baoquan He <bhe(a)redhat.com>
+Date: Tue, 29 Mar 2022 18:12:28 +0800
+Subject: [PATCH] purgatory: do not enable vectorization automatically for
+ purgatory compiling
+
+Redhat CKI reported kdump kernel will hang a while very early after crash
+triggered, then reset to firmware to reboot.
+
+This failure can only be observed with kdump or kexec reboot via
+kexec_load system call. With kexec_file_load interface, both kdump and
+kexec reboot work very well. And further investigation shows that gcc
+version 11 doesn't have this issue, while gcc version 12 does.
+
+After checking the release notes of the latest gcc, Dave found out it's
+because gcc 12 enables auto-vectorization for -O2 optimization level.
+Please see below link for more information:
+
+
https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Auto-Vec-O2
+
+Adding -fno-tree-vectorize to Makefile of purgatory can fix the issue.
+
+Signed-off-by: Baoquan He <bhe(a)redhat.com>
+Signed-off-by: Simon Horman <horms(a)verge.net.au>
+---
+ purgatory/Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/purgatory/Makefile b/purgatory/Makefile
+index 2dd6c47..15adb12 100644
+--- a/purgatory/Makefile
++++ b/purgatory/Makefile
+@@ -49,7 +49,7 @@ $(PURGATORY): CFLAGS=$(PURGATORY_EXTRA_CFLAGS) \
+ $($(ARCH)_PURGATORY_EXTRA_CFLAGS) \
+ -Os -fno-builtin -ffreestanding \
+ -fno-zero-initialized-in-bss \
+- -fno-PIC -fno-PIE -fno-stack-protector
++ -fno-PIC -fno-PIE -fno-stack-protector -fno-tree-vectorize
+
+ $(PURGATORY): CPPFLAGS=$($(ARCH)_PURGATORY_EXTRA_CFLAGS) \
+ -I$(srcdir)/purgatory/include \
+--
+2.34.1
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 6b7ef14..9ccb727 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -112,6 +112,8 @@ Patch401:
./kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machi
#
# Patches 601 onward are generic patches
#
+Patch601:
./kexec-tools-2.0.23-purgatory-do-not-enable-vectorization-automatically-.patch
+
%description
kexec-tools provides /sbin/kexec binary that facilitates a new
@@ -128,6 +130,7 @@ tar -z -x -v -f %{SOURCE9}
tar -z -x -v -f %{SOURCE19}
%patch401 -p1
+%patch601 -p1
%ifarch ppc
%define archdef ARCH=ppc
commit 85888c8d233c0d115fcb145c022065028b12e3af
Author: Lichen Liu <lichliu(a)redhat.com>
Date: Tue Mar 1 13:09:00 2022 +0800
kdumpctl: sync the $TARGET_INITRD after rebuild
There is a system-wide sync call at the end of mkdumprd, move it to
kdumpctl after rebuild initrd and add another one for mkfadumprd.
Sync only the $TARGET_INITRD to avoid a system-wide sync taking too
long on a system with high disk activity.
Also update the sync in kdumpctl:restore_default_initrd which will
mv the $DEFAULT_INITRD_BAK to $DEFAULT_INITRD.
Signed-off-by: Lichen Liu <lichliu(a)redhat.com>
Reviewed-by: Philipp Rudo <prudo(a)redhat.com>
diff --git a/kdumpctl b/kdumpctl
index ac6ffeb..1869753 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -79,6 +79,7 @@ rebuild_fadump_initrd()
return 1
fi
+ sync -f "$TARGET_INITRD"
return 0
}
@@ -100,6 +101,7 @@ rebuild_kdump_initrd()
dwarn "Tips: If early kdump is enabled, also require rebuilding the system
initramfs to make the changes take effect for early kdump."
fi
+ sync -f "$TARGET_INITRD"
return 0
}
@@ -180,7 +182,7 @@ restore_default_initrd()
rm -f $INITRD_CHECKSUM_LOCATION
if mv "$DEFAULT_INITRD_BAK" "$DEFAULT_INITRD"; then
derror "Restoring original initrd as fadump mode is disabled."
- sync
+ sync -f "$DEFAULT_INITRD"
fi
fi
fi
diff --git a/mkdumprd b/mkdumprd
index 593ec77..5996d50 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -458,7 +458,3 @@ if ! is_fadump_capable; then
fi
dracut "${dracut_args[@]}" "$@"
-
-_rc=$?
-sync
-exit $_rc
commit ee97b48d7b4bcfb628b0522022f2379f1d743e70
Author: Coiby Xu <coxu(a)redhat.com>
Date: Wed Feb 16 09:42:54 2022 +0800
try to update the crashkernel in GRUB_ETC_DEFAULT after kexec-tools updates the
default crashkernel value
If GRUB_ETC_DEFAULT use crashkernel=auto or
crashkernel=OLD_DEFAULT_CRASHKERNEL, it should be updated as well.
Add a helper function to read kernel cmdline parameter from
GRUB_ETC_DEFAULT. This function is used to read kernel cmdline
parameter like fadump or crashkernel.
Reviewed-by: Philipp Rudo <prudo(a)redhat.com>
diff --git a/kdumpctl b/kdumpctl
index 1c94405..ac6ffeb 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1444,6 +1444,16 @@ _update_kernel_arg_in_grub_etc_default()
}" "$GRUB_ETC_DEFAULT"
}
+# Read the kernel arg in default grub conf.
+
+# Note reading a kernel parameter that doesn't have a value isn't supported.
+#
+# $1: the name of the kernel command line parameter
+_read_kernel_arg_in_grub_etc_default()
+{
+ sed -n -E
"s/^GRUB_CMDLINE_LINUX=.*[[:space:]\"]${1}=([^[:space:]\"]*).*$/\1/p"
"$GRUB_ETC_DEFAULT"
+}
+
reset_crashkernel()
{
local _opt _val _dump_mode _fadump_val _reboot _grubby_kernel_path _kernel _kernels
@@ -1577,6 +1587,34 @@ reset_crashkernel()
fi
}
+# update the crashkernel value in GRUB_ETC_DEFAULT if necessary
+#
+# called by reset_crashkernel_after_update and inherit its array variable
+# _crashkernel_vals
+update_crashkernel_in_grub_etc_default_after_update()
+{
+ local _crashkernel _fadump_val
+ local _dump_mode _old_default_crashkernel _new_default_crashkernel
+
+ _crashkernel=$(_read_kernel_arg_in_grub_etc_default crashkernel)
+
+ if [[ -z $_crashkernel ]]; then
+ return
+ fi
+
+ _fadump_val=$(_read_kernel_arg_in_grub_etc_default fadump)
+ _dump_mode=$(get_dump_mode_by_fadump_val "$_fadump_val")
+
+ _old_default_crashkernel=${_crashkernel_vals[old_${_dump_mode}]}
+ _new_default_crashkernel=${_crashkernel_vals[new_${_dump_mode}]}
+
+ if [[ $_crashkernel == auto ]] ||
+ [[ $_crashkernel == "$_old_default_crashkernel" &&
+ $_new_default_crashkernel != "$_old_default_crashkernel" ]]; then
+ _update_kernel_arg_in_grub_etc_default crashkernel
"$_new_default_crashkernel"
+ fi
+}
+
# shellcheck disable=SC2154 # false positive when dereferencing an array
reset_crashkernel_after_update()
{
@@ -1605,6 +1643,8 @@ reset_crashkernel_after_update()
fi
fi
done
+
+ update_crashkernel_in_grub_etc_default_after_update
}
# read the value of an environ variable from given environ file path
commit 1f98ed97bd36d08215e345b0790f5a9dfdcf7444
Author: Coiby Xu <coxu(a)redhat.com>
Date: Tue Feb 15 13:24:19 2022 +0800
address the case where there are multiple values for the same kernel arg
There is the case where there are multiple entries of the same parameter on
the command line, e.g.
GRUB_CMDLINE_LINUX="crashkernel=110M crashkernel=220M fadump=on
crashkernel=330M".
In such an situation _update_kernel_cmdline_in_grub_etc_default only
updates/removes the last entry which is usually not what you want as the
kernel (for crashkernel) takes the last entry it can find.
Thus make sure the case with multiple entries of the same parameter is
handled properly by removing all occurrences of given parameter first.
Note
1. sed command group and conditional control has been used to get rid of
grep.
2. Fully supporting kernel cmdline as documented in
Documentation/admin-guide/kernel-parameters.rst is complex and in
foreseeable future a full implementation is not needed. So simply
document the unsupported cases instead.
Fixes: 140da74 ("rewrite reset_crashkernel to support fadump and to used by RPM
scriptlet")
Reported-by: Philipp Rudo <prudo(a)redhat.com>
Suggested-by: Philipp Rudo <prudo(a)redhat.com>
Reviewed-by: Philipp Rudo <prudo(a)redhat.com>
diff --git a/kdumpctl b/kdumpctl
index 9fd76ac..1c94405 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -1399,25 +1399,49 @@ _get_all_kernels_from_grubby()
}
GRUB_ETC_DEFAULT="/etc/default/grub"
-# modify the kernel command line parameter in default grub conf
+# Update a kernel parameter in default grub conf
+#
+# If a value is specified, it will be inserted in the end. Otherwise it
+# would remove given kernel parameter.
+#
+# Note this function doesn't address the following cases,
+# 1. The kernel ignores everything on the command line after a '--'. So
+# simply adding the new entry to the end will fail if the cmdline
+# contains a --.
+# 2. If the value for a parameter contains spaces it can be quoted using
+# double quotes, for example param="value with spaces". This will
+# break the [^[:space:]\"] regex for the value.
+# 3. Dashes and underscores in the parameter name are equivalent. So
+# some_parameter and some-parameter are identical.
+# 4. Some parameters, e.g. efivar_ssdt, can be given multiple times.
+# 5. Some kernel parameters, e.g. quiet, doesn't have value
#
# $1: the name of the kernel command line parameter
-# $2: new value. If empty, the parameter would be removed
-_update_kernel_cmdline_in_grub_etc_default()
+# $2: new value. If empty, given parameter would be removed
+_update_kernel_arg_in_grub_etc_default()
{
- local _para=$1 _val=$2 _para_val _regex
+ local _para=$1 _val=$2 _para_val
if [[ -n $_val ]]; then
_para_val="$_para=$_val"
fi
- _regex='^(GRUB_CMDLINE_LINUX=.*)([[:space:]"])'"$_para"'=[^[:space:]"]*(.*)$'
- if grep -q -E "$_regex" "$GRUB_ETC_DEFAULT"; then
- sed -i -E
's/'"$_regex"'/\1\2'"$_para_val"'\3/'
"$GRUB_ETC_DEFAULT"
- elif [[ -n $_para_val ]]; then
- # If the kernel parameter doesn't exist, put it in the first
- sed -i -E 's/^(GRUB_CMDLINE_LINUX=")/\1'"$_para_val"' /'
"$GRUB_ETC_DEFAULT"
- fi
+ # Update the command line /etc/default/grub, i.e.
+ # on the line that starts with 'GRUB_CMDLINE_LINUX=',
+ # 1) remove $para=$val if the it's the first arg
+ # 2) remove all occurences of $para=$val
+ # 3) insert $_para_val to end
+ # 4) remove duplicate spaces left over by 1) or 2) or 3)
+ # 5) remove space at the beginning of the string left over by 1) or 2) or 3)
+ # 6) remove space at the end of the string left over by 1) or 2) or 3)
+ sed -i -E "/^GRUB_CMDLINE_LINUX=/ {
+ s/\"${_para}=[^[:space:]\"]*/\"/g;
+ s/[[:space:]]+${_para}=[^[:space:]\"]*/ /g;
+ s/\"$/ ${_para_val}\"/
+ s/[[:space:]]+/ /g;
+ s/(\")[[:space:]]+/\1/g;
+ s/[[:space:]]+(\")/\1/g;
+ }" "$GRUB_ETC_DEFAULT"
}
reset_crashkernel()
@@ -1496,10 +1520,12 @@ reset_crashkernel()
# - set the dump mode as kdump for non-ppc64le cases
# - retrieved the default crashkernel value for given dump mode
if [[ $_grubby_kernel_path == ALL && -n $_dump_mode ]]; then
- _update_kernel_cmdline_in_grub_etc_default crashkernel "$_crashkernel"
+ _update_kernel_arg_in_grub_etc_default crashkernel "$_crashkernel"
# remove the fadump if fadump is disabled
- [[ $_fadump_val == off ]] && _fadump_val=""
- _update_kernel_cmdline_in_grub_etc_default fadump "$_fadump_val"
+ if [[ $_fadump_val == off ]]; then
+ _fadump_val=""
+ fi
+ _update_kernel_arg_in_grub_etc_default fadump "$_fadump_val"
fi
# If kernel-path not specified, either
commit 685e07eccdb5dcafed050a6411910c2336d36f80
Author: Coiby Xu <coxu(a)redhat.com>
Date: Fri Feb 11 13:11:17 2022 +0800
update kernel crashkernel in posttrans RPM scriptlet when updating kexec-tools
When doing in-place upgrading using leapp on x86_64, kdumpcl can't
acquire instance lock when running in %post RPM scriplet on x86_64,
localhost upgrade[1306]: /bin/kdumpctl: line 49: /var/lock/kdump: No such file or
directory
localhost upgrade[1306]: kdump: Create file lock failed
and running "touch /var/lock/dkump" also fails with
"No such file or directory". Thus kdumpctl can't be run in %post
scriptlet. But kdumpctl can be run in %posttrans RPM scriplet.
Besides, it's better to update crashkernel after the kernel has been
updated. So let's update kernel crashkernel in the %posttrans
scriptlet which will be run in the end of a transaction i.e. after
the kernel has been updated.
Note for %posttrans scriptlet, "$1 == 1" means both installing a new
package and upgrading a package.
[1]
https://github.com/apptainer/singularity/issues/2386#issuecomment-474747054
Reported-by: Jie Li <jieli(a)redhat.com>
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
Reviewed-by: Philipp Rudo <prudo(a)redhat.com>
diff --git a/kexec-tools.spec b/kexec-tools.spec
index ac134da..6b7ef14 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -305,19 +305,6 @@ then
mv /etc/sysconfig/kdump.new /etc/sysconfig/kdump
fi
-# try to reset kernel crashkernel value to new default value when upgrading
-# the package
-if ! grep -qs "ostree" /proc/cmdline && [ $1 == 2 ]; then
- kdumpctl reset-crashkernel-after-update
- rm /tmp/old_default_crashkernel 2>/dev/null
-%ifarch ppc64 ppc64le
- rm /tmp/old_default_crashkernel_fadump 2>/dev/null
-%endif
- # dnf would complain about the exit code not being 0. To keep it happy,
- # always return 0
- :
-fi
-
%postun
%systemd_postun_with_restart kdump.service
@@ -350,6 +337,21 @@ do
fi
done
+%posttrans
+# try to reset kernel crashkernel value to new default value when upgrading
+# the package
+if ! grep -qs "ostree" /proc/cmdline && [ $1 == 1 ]; then
+ kdumpctl reset-crashkernel-after-update
+ rm /tmp/old_default_crashkernel 2>/dev/null
+%ifarch ppc64 ppc64le
+ rm /tmp/old_default_crashkernel_fadump 2>/dev/null
+%endif
+ # dnf would complain about the exit code not being 0. To keep it happy,
+ # always return 0
+ :
+fi
+
+
%files
/usr/sbin/kexec
%ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64
commit d8968f43d9372357e9e3332185757fcf50f8a554
Author: Tao Liu <ltao(a)redhat.com>
Date: Wed Feb 16 14:26:38 2022 +0800
kdump-lib.sh: Check the output of blkid with sed instead of eval
Previously the output of blkid is not checked. If the output
is empty, the eval will report the following error message:
/lib/kdump/kdump-lib.sh: eval: line 925: syntax error near unexpected token
`;'
/lib/kdump/kdump-lib.sh: eval: line 925: `; echo $TYPE'
For example, we can observe such a failing when blkid is invoked
against a lvm thinpool block device:
$ blkid -u filesystem,crypto -o export -- "/dev/block/253\:2"
$ echo $?
2
$ udevadm info /dev/block/253\:2|grep S\:
S: mapper/vg00-thinpoll_tmeta
In this patch, we will use sed instead of eval, to output the
fstype of block device if any.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
Reviewed-by: Philipp Rudo <prudo(a)redhat.com>
diff --git a/kdump-lib.sh b/kdump-lib.sh
index 3e912cc..4ed5035 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -885,7 +885,8 @@ get_luks_crypt_dev()
[[ -b /dev/block/$1 ]] || return 1
- _type=$(eval "$(blkid -u filesystem,crypto -o export -- "/dev/block/$1");
echo \$TYPE")
+ _type=$(blkid -u filesystem,crypto -o export -- "/dev/block/$1" | \
+ sed -n -E "s/^TYPE=(.*)$/\1/p")
[[ $_type == "crypto_LUKS" ]] && echo "$1"
for _x in "/sys/dev/block/$1/slaves/"*; do