Related: bz2060319
Upstream: Fedora
Conflict: None
commit 12e6cd2b76a10bb6b52c0cc28ad0e8c8f57a319a
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Feb 20 17:33:08 2023 +0800
Use the correct command to get architecture
`uname -r` was used by mistake. As a result, kexec-tools failed to
update crashkernel=auto during in-place upgrade from RHEL8 to RHEL9.
`uname -m` should be used to get architecture instead.
Fixes: 5951b5e2 ("Don't try to update crashkernel when bootloader is not installed")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2060319
Upstream: Fedora
Conflict: commit a3da46d6 ("Skip reset_crashkernel_after_update
during package install") hasn't been backported. Note it's now
no longer needed.
commit 5951b5e26823b6bedf3237bd169a781b03f25031
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Dec 20 13:59:18 2022 +0800
Don't try to update crashkernel when bootloader is not installed
Currently when using anaconda to install the OS, the following errors
occur,
INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 ...
INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
...
INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9.el9.x86_64 ...
INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
Or for s390, the following errors occur,
INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-71.el9.s390x ...
03:37:51,232 INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory
grep: /etc/zipl.conf: No such file or directory
grep: /etc/zipl.conf: No such file or directory
INF packaging: Configuring (running scriptlet for): kexec-tools-2.0.23-9_1.el9_0.s390x ...
INF dnf.rpm: grep: /etc/zipl.conf: No such file or directory
This is because when anaconda installs the packages, bootloader hasn't
been installed and /boot/grub2/grubenv or /etc/zipl.conf doesn't exist.
So don't try to update crashkernel when bootloader isn't ready to avoid
the above errors.
Note this is the second attempt to fix this issue. Previously a file
/tmp/kexec_tools_package_install was created to avoid running the
related code thus to avoid the above errors but unfortunately that
approach has two issues a) somehow osbuild doesn't delete it for RHEL b)
this file could still exist if users manually remove kexec-tools.
Fixes: e218128 ("Only try to reset crashkernel for osbuild during package install")
Reported-by: Jan Stodola <jstodola@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit 25411da9660e732a53e675936813aad924ba65df
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Fri Dec 2 18:46:50 2022 +0530
fadump: fix default initrd backup and restore logic
In case of fadump, default initrd is rebuilt with dump capturing
capability, as the same initrd is used for booting production kernel
as well as capture kernel.
The original initrd file is backed up with a checksum, to restore
it as the default initrd when fadump is disabled. As the checksum
file is not kernel version specific, switching between different
kernel versions and kdump/fadump dump mode breaks the default initrd
backup/restore logic. Fix this by having a kernel version specific
checksum file.
Also, if backing up initrd fails, retaining the checksum file isn't
useful. Remove it.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2139000
Upstream: Fedora
Conflict: None
commit a833624fe57a28a4ccb44f7f27f06a7e867e8755
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Mon Nov 21 18:56:08 2022 +0530
fadump: avoid status check while starting in fadump mode
With kernel commit 607451ce0aa9b ("powerpc/fadump: register for fadump
as early as possible"), 'kdumpctl start' prematurely returns with the
below message:
"Kdump already running: [WARNING]"
instead of setting default initrd with dump capture capability as
required for fadump. Skip status check in fadump mode to avoid this
problem.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2141536
Upstream: Fedora
Conflict: None
commit 5eb77ee3fa986f39bb74a5956910aed6f60b8008
Author: Lichen Liu <lichliu@redhat.com>
Date: Thu Nov 24 09:15:25 2022 +0800
kdumpctl: Optimize _find_kernel_path_by_release regex string
Currently _find_kernel_path_by_release uses grubby and grep to
find the kernel path, if both the normal kernel and it's debug
varient exist, the grep will give more than one kernel strings.
```
kernel="/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x+debug"
kernel="/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x"
```
This will cause an error when installing debug kernel.
```
The param "/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x+debug
/boot/vmlinuz-5.14.0-139.kpq0.el9.s390x" is incorrect
```
Fixes: 945cbbd ("add helper functions to get kernel path by kernel release and the path of current running kernel")
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
upstream: fedora
resolves: bz2083475
conflict: none
commit 3ae8cf8876edd6ca668890f55d4c006e28a41f90
Author: Tao Liu <ltao@redhat.com>
Date: Thu Nov 10 10:25:58 2022 +0800
Don't check fs modified when dump target is lvm2 thinp
When the dump target is lvm2 thinp, if we didn't mount
the dump target first, get_fs_type_from_target will get
empty output:
Before mount:
$ get_fs_type_from_target /dev/vg00/thinlv
After mount:
$ mount /dev/vg00/thinlv /mnt
$ get_fs_type_from_target /dev/vg00/thinlv
ext4
As a result, kdumpctl start will fail with:
$ kdumpctl start
kdump: Dump target is invalid
kdump: Starting kdump: [FAILED]
This patch fix the issue by bypassing check_fs_modified
when the dump target is lvm2 thinp.
Signed-off-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Coiby Xu <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
resolves: bz2083475
upstream: fedora
conflict: none
commit 10ca970940f0d8f4edc29737eba1968526182f1e
Author: Tao Liu <ltao@redhat.com>
Date: Sat Oct 8 15:41:40 2022 +0800
lvm.conf should be check modified if lvm2 thinp enabled
lvm2 relies on /etc/lvm/lvm.conf to determine its behaviour. The
important configs such as thin_pool_autoextend_threshold and
thin_pool_autoextend_percent will be used during kdump in 2nd
kernel. So if the file is modified, the initramfs should be
rebuild to include the latest.
Signed-off-by: Tao Liu <ltao@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Related: bz2076206
Upstream: Fedora
Conflict: None
commit 50a8461fc7cc70b57387baa58ff4db864ba36632
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Sep 5 17:49:18 2022 +0800
Choosing the most memory-consuming key slot when estimating the
memory requirement for LUKS-encrypted target
When there are multiple key slots, "kdumpctl estimate" uses the least
memory-consuming key slot. For example, when there are two memory slots
created with --pbkdf-memory=1048576 (1G) and --pbkdf-memory=524288 (512M),
"kdumpctl estimate" thinks the extra memory requirement is only 512M.
This will of course lead to OOM if the user uses the more
memory-consuming key slot. Fix it by sorting in reverse order.
Fixes: e9e6a2c ("kdumpctl: Add kdumpctl estimate")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2133129
Upstream: Fedora
Conflict: None
commit fdad7d9869a9637e6799cce222d386aed0b8781e
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Sep 29 12:35:00 2022 +0800
Skip reading /etc/defaut/grub for s390x
Currently, updating kexec-tools on s390x gives the warning
sed: can't read /etc/default/grub: No such file or directory
This happens because s390x doesn't use GRUB and /etc/default/grub
doesn't exist. We need to skip both reading and writing to
/etc/default/grub.
Reported-by: Jie Li <jieli@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2060319
Upstream: Fedora
Conflict: None
commit e218128e282066440a4a654707309d785066d79a
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Sep 8 14:30:02 2022 +0800
Only try to reset crashkernel for osbuild during package install
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2060319
Currently, kexec-tools tries to reset crashkernel when using anaconda to
install the system. But grubby isn't ready and complains that,
10:33:17,631 INF packaging: Configuring (running scriptlet for): kernel-core-5.14.0-70.el9.x86_64 1645746534 03dcd32db234b72440ee6764d59b32347c5f0cd98ac3fb55beb47214a76f33b4
10:34:16,696 INF dnf.rpm: grep: /boot/grub2/grubenv: No such file or directory
grep: /boot/grub2/grubenv: No such file or directory
We only need to try resetting crashkernel for osbuild. Skip it for other
cases. To tell if it's package install instead of package upgrade, make
use of %pre to write a file /tmp/kexec-tools-install when "$1 == 1" [1].
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax
Reported-by: Jan Stodola <jstodola@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Lichen Liu <lichenliu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
upstream: fedora
resolves: bz2085347
conflict: yes, small conflict due to patch
"kdumpctl: drop DUMP_TARGET variable" not
backported to rhel9.
commit c743881ae691c4e2bcf049cbf28abd2850b816e8
Author: Tao Liu <ltao@redhat.com>
Date: Fri Sep 23 18:13:11 2022 +0800
virtiofs support for kexec-tools
This patch add virtiofs support for kexec-tools by introducing a new option
for /etc/kdump.conf:
virtiofs myfs
Where myfs is a variable tag name specified in qemu cmdline
"-device vhost-user-fs-pci,tag=myfs".
The patch covers the following cases:
1) Dumping VM's vmcore to a virtiofs shared directory;
2) When the VM's rootfs is a virtiofs shared directory and dumping the
VM's vmcore to its subdirectory, such as /var/crash;
3) The combination of case 1 & 2: The VM's rootfs is a virtiofs shared
directory and dumping the VM's vmcore to another virtiofs shared
directory.
Case 2 & 3 need dracut >= 057, otherwise VM cannot boot from virtiofs
shared rootfs. But it is not the issue of kexec-tools.
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2089871
Upstream: Fedora
Conflict: None
commit da0ca0d205e7ac64426ad43540dae3d03cd4447a
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Jun 28 14:38:28 2022 +0800
Allow to update kexec-tools using virt-customize for cloud base image
Resolves: bz2089871
Currently, kexec-tools can't be updated using virt-customize because
older version of kdumpctl can't acquire instance lock for the
get-default-crashkernel subcommand. The reason is /var/lock is linked to
/run/lock which however doesn't exist in the case of virt-customize.
This patch fixes this problem by using /tmp/kdump.lock as the lock
file if /run/lock doesn't exist.
Note
1. The lock file is now created in /run/lock instead of /var/run/lock since
Fedora has adopted adopted /run [2] since F15.
2. %pre scriptlet now always return success since package update won't
be blocked
[1] https://fedoraproject.org/wiki/Features/var-run-tmpfs
Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")
Reported-by: Nicolas Hicher <nhicher@redhat.com>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Suggested-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2111857
Upstream: Fedora
Conflict: None
commit 4edcd9a4001f684d6c5b66afc2e164bdd6a296eb
Author: Lichen Liu <lichliu@redhat.com>
Date: Wed Aug 24 16:16:14 2022 +0800
kdumpctl: make the kdump.log root-readable-only
Decrease the risk that of leaking information that could potentially
be used to exploit the crash further (think location of keys).
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Acked-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Upstream: fedora
Conflict: none
Resolves: bz2060774
commit 6d4062a936694b7cab7e0c536414b4d5b6ab8668
Author: Coiby Xu <coxu@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@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2060774
Upstream: fedora
Conflict: none
commit 37f4f2c1f6f1304e1b58604a788c57c51508eead
Author: Coiby Xu <coxu@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@redhat.com>
Suggested-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Related: bz1895258
Upstream: Fedora
Conflict: None
commit 41b8f9528c8ed89c68ad59750c18f032b5675a06
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Feb 9 08:04:39 2022 +0800
fix incorrect usage of _get_all_kernels_from_grubby
It's found that the kernel cmdline crashkernel=auto doesn't get updated
when upgrading kexec-tools. This happens because _get_all_kernels_from_grubby
is called with no argument by reset_crashkernel_after_update. When retrieving
all kernel paths on the system, "grubby --info ALL" should be used. Fix this
error by passing "ALL" argument.
Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")
Reported-by: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2024976
Upstream: Fedora
Conflict: None
commit 5111c01334046dd4176d4446075b02106fb9db4a
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Feb 7 08:08:01 2022 +0800
fix the mistake of swapping function parameters of read_proc_environ_var
_is_osbuild fails because it expects the 1st and 2nd function parameter
to be the environment variable and environ file path respectively. Fix
it by swapping the parameters in read_proc_environ_var.
Note the osbuild environ file path is defined in _OSBUILD_ENVIRON_PATH
so _is_osbuild can be unit-tested by overwriting _OSBUILD_ENVIRON_PATH.
Fixes: 6a3ce83 ("fix the error of parsing the container environ variable for osbuild")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Resolves: bz2024976
Upstream: Fedora
Conflict: None
commit 6a3ce83a60c7107112d576223175410b180a41a0
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Jan 19 11:16:29 2022 +0800
fix the error of parsing the container environ variable for osbuild
The environment variable entries in /proc/[pid]/environ are separated by
null bytes instead of by spaces. Update the sed regex to fix this issue.
Note that,
1. this patch also fixes a issue which is kdumpctl would try to reset
crashkernel even osbuild has provided custom crashkernel value.
2. kernel hook 92-crashkernel.install installed by kexec-tools is
guaranteed to be ran by kernel-install. kexec-tools doesn't recommend
kernel so there is no guarantee kernel is installed after kexec-tools.
But dnf invokes kernel-install in the posttrans scriptlet (of kernel-core)
which is always ran after all packages including kexec-tools and kernel
in a dnf transaction.
3. To be able to do unit tests, the logic of reading environment variable
has been extracted as a separate function.
Fixes: ddd428a ("set up kernel crashkernel for osbuild in kernel hook")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit d5c31605f364e258fdef60e8482498941644ad6a
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Jan 6 09:48:17 2022 +0800
use grep -s to suppress error messages about nonexistent or unreadable files
When a file doesn't exist or isn't readable, grep complains as follows,
grep: /proc/cmdline: No such file or directory
grep: /etc/kernel/cmdline: No such file or directory
/proc/cmdline doesn't exist when installing package for an OS image and
/etc/kernel/cmdline may not exist if osbuild doesn't want set custom
kernel cmdline.
Use "-s" to suppress the error messages.
Fixes: 0adb0f4 ("try to reset kernel crashkernel when kexec-tools updates the default crashkernel value")
Fixes: ddd428a ("set up kernel crashkernel for osbuild in kernel hook")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Acked-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Resolves: bz2024976
Upstream: Fedora
Conflict: None
commit ddd428a1d0d72bee2a8459b1a81541bcd0676873
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 15 21:45:18 2021 +0800
set up kernel crashkernel for osbuild in kernel hook
osbuild is a tool to build OS images. It uses bwrap to install packages
inside a sandbox/container. Since the kernel package recommends
kexec-tools which in turn recommends grubby, the installation order would
be grubby -> kexec-tools -> kernel. So we can use the kernel hook
92-crashkernel.install provided by kexec-tools to set up kernel
crashkernel for the target OS image. But in osbuild's case, there is no
current running kernel and running `uname -r` in the container/sandbox
actually returns the host kernel release. To set up kernel crashkernel for
the OS image built by osbuild, a different logic is needed.
We will check if kernel hook is running inside the osbuild container
then set up kernel crashkernel only if osbuild hasn't specified a
custome value. osbuild exposes [1] the container=bwrap-osbuild environment
variable. According to [2], the environment variable is not inherited down
the process tree, so we need to check /proc/1/environ to detect this
environment variable to tell if the kernel hook is running inside a
bwrap-osbuild container. After that we need to know if osbuild wants to use
custom crashkernel value. This is done by checking if /etc/kernel/cmdline
has crashkernel set [3]. /etc/kernel/cmdline is written before packages
are installed.
[1] https://github.com/osbuild/osbuild/pull/926
[2] https://systemd.io/CONTAINER_INTERFACE/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2024976#c5
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit 5e8c751c39a5ec9d10009cba1c2bd554a5763b90
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Dec 2 17:19:50 2021 +0800
reset kernel crashkernel for the special case where the kernel is updated right after kexec-tools
When kexec-tools updates the default crashkernel value, it will try to
reset the existing installed kernels including the currently running
kernel. So the running kernel could have different kernel cmdline
parameters from /proc/cmdline. When installing a kernel after updating
kexec-tools, /usr/lib/kernel/install.d/20-grub.install would be called
by kernel-install [1] which would use /proc/cmdline to set up new kernel's
cmdline. To address this special case, reset the new kernel's crashkernel
and fadump value to the value that would be used by running kernel after
rebooting by the installation hook. One side effect of this commit is it
would reset the installed kernel's crashkernel even currently running kernel
don't use the default crashkernel value after rebooting. But I think this
side effect is a benefit for the user.
The implementation depends on kernel-install which run the scripts in
/usr/lib/kernel/install.d passing the following arguments,
add KERNEL-VERSION $BOOT/MACHINE-ID/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...]
An concrete example is given as follows,
add 5.11.12-300.fc34.x86_64 /boot/e986846f63134c7295458cf36300ba5b/5.11.12-300.fc34.x86_64 /lib/modules/5.11.12-300.fc34.x86_64/vmlinuz
kernel-install could be started by the kernel package's RPM scriplet [2].
As mentioned in previous commit "try to reset kernel crashkernel when
kexec-tools updates the default crashkernel value", kdumpctl has difficulty
running in RPM scriptlet fore CoreOS. But rpm-ostree ignores all kernel hooks,
there is no need to disable the kernel hook for CoreOS/Atomic/Silverblue. But a
collaboration between rpm-ostree and kexec-tools is needed [3] to take care
of this special case.
Note the crashkernel.default support is dropped.
[1] https://www.freedesktop.org/software/systemd/man/kernel-install.html
[2] https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_2680
[3] https://github.com/coreos/rpm-ostree/issues/2894
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit 0adb0f4a8c4c69ba54171f0113a4fbfc1729900f
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 1 15:33:13 2021 +0800
try to reset kernel crashkernel when kexec-tools updates the default crashkernel value
kexec-tools could update the default crashkernel value.
When auto_reset_crashkernel=yes, reset kernel to new crashkernel
value in the following two cases,
- crashkernel=auto is found in the kernel cmdline
- the kernel crashkernel was previously set by kexec-tools i.e.
the kernel is using old default crashkernel value
To tell if the user is using a custom value for the kernel crashkernel
or not, we assume the user would never use the default crashkernel value
as custom value. When kexec-tools gets updated,
1. save the default crashkernel value of the older package to
/tmp/crashkernel (for POWER system, /tmp/crashkernel_fadump is saved
as well).
2. If auto_reset_crashkernel=yes, iterate all installed kernels.
For each kernel, compare its crashkernel value with the old
default crashkernel and reset it if yes
The implementation makes use of two RPM scriptlets [2],
- %pre is run before a package is installed so we can use it to save
old default crashkernel value
- %post is run after a package installed so we can use it to try to reset
kernel crashkernel
There are several problems when running kdumpctl in the RPM scripts
for CoreOS/Atomic/Silverblue, for example, the lock can't be acquired by
kdumpctl, "rpm-ostree kargs" can't be run and etc.. So don't enable this
feature for CoreOS/Atomic/Silverblue.
Note latest shellcheck (0.8.0) gives false positives about the
associative array as of this commit. And Fedora's shellcheck is 0.7.2
and can't even correctly parse the shell code because of the associative
array.
[1] https://github.com/koalaman/shellcheck/issues/2399
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit 140da74a340f872b2579fc75b50a36fe7015c0ba
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 1 13:39:40 2021 +0800
rewrite reset_crashkernel to support fadump and to used by RPM scriptlet
Rewrite kdumpctl reset-crashkernel KERNEL_PATH as
kdumpctl reset-crashkernel [--fadump=[on|off|nocma]] [--kernel=path_to_kernel] [--reboot]
This interface would reset a specific kernel to the default crashkernel value
given the kernel path. And it also supports grubby's syntax so there are the
following special cases,
- if --kernel not specified,
- use KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
- otherwise use current running kernel, i.e. `uname -r`
- if --kernel=DEFAULT, the default boot kernel is chosen
- if --kernel=ALL, all kernels would have its crashkernel reset to the
default value and the /etc/default/grub is updated as well
--fadump=[on|off|nocma] toggles fadump on/off for the kernel provided
in KERNEL_PATH. If --fadump is omitted, the dump mode is determined by
parsing the kernel command line for the kernel(s) to update.
CoreOS/Atomic/Silverblue needs to be treated as a special case because,
- "rpm-ostree kargs" is used to manage kernel command line parameters
so --kernel doesn't make sense and there is no need to find current
running kernel
- "rpm-ostree kargs" itself would prompt the user to reboot the system
after modify the kernel command line parameter
- POWER is not supported so we can assume the dump mode is always kdump
This interface will also be called by kexec-tools RPM scriptlets [1]
to reset crashkernel.
Note the support of crashkenrel.default is dropped.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit 945cbbd59b34739c4a6b2f228c33f76e2981a18a
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Dec 7 15:16:07 2021 +0800
add helper functions to get kernel path by kernel release and the path of current running kernel
grubby --info=kernel-path or --add-kernel=kernel-path accepts a kernel
path (e.g. /boot/vmlinuz-5.14.14-200.fc34.x86_64) instead of kernel release
(e.g 5.14.14-200.fc34.x86_64). So we need to know the kernel path given
a kernel release. Although for Fedora/RHEL, the kernel path is
"/boot/vmlinuz-<KERNEL_RELEASE>", a path kernel could also be
/boot/<machine-id>/<KERNEL_RELEASE>/vmlinuz. So the most reliable way to
find the kernel path given a kernel release is to use "grubby --info".
For osbuild, a kernel path may not yet exist but it's valid for
"grubby --update-kernel=KERNEL_PATH". For example, "grubby -info" may
output something as follows,
index=0
kernel="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64"
args="ro no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8"
root="UUID=76a22bf4-f153-4541-b6c7-0332c0dfaeac"
initrd="/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/initramfs-5.15.10-100.fc34.x86_64.img"
There is no need to check if path like
/var/cache/osbuild-worker/osbuild-store/tmp/tmp2prywdy5object/tree/boot/vmlinuz-5.15.10-100.fc34.x86_64
physically exists.
Note these helper functions doesn't support CoreOS/Atomic/Silverblue
since grubby isn't used by them.
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit 3d2079c31cd80741ea6d44eb7f13d7f08be74a94
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 1 16:57:15 2021 +0800
add helper functions to get dump mode
Add a helper function to get dump mode. The dump mode would be
- fadump if fadump=on or fadump=nocma
- kdump if fadump=off or empty fadump
Otherwise return 1.
Also add another helper function to return a kernel's dump mode.
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit fb9e6838abef1e3a2ba43966f58a1f146989b148
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Nov 16 06:48:40 2021 +0800
add a helper function to read kernel cmdline parameter from grubby --info
This helper function will be used to retrieve the value of kernel
cmdline parameters including crashkernel, fadump, swiotlb and etc.
Suggested-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1895258
Upstream: Fedora
Conflict: None
commit 796d0f6fd2932fd7c009f4517133b1a9c39501e5
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Nov 16 12:23:02 2021 +0800
provide kdumpctl get-default-crashkernel for kdump_anaconda_addon and RPM scriptlet
Provide "kdumpctl get-default-crashkernel" for kdump_anaconda_addon
so crashkernel.default isn't needed.
When fadump is on, kdump_anaconda_addon would need to specify the dump
mode, i.e. "kdumpctl get-default-crashkernel fadump".
This interface would also be used by RPM scriptlet [1] to fetch default
crashkernel value.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1931802
Upstream: Fedora
Conflict: The upstream commit was submitted before shfmt and .editorconfig.
So there are issues like 4 spaces verse tab indentation, double
brackets verse single bracket and etc.
commit 596fa0a07f089a9dd54cf631124d88653b4d77ec
Author: Pingfan Liu <piliu@redhat.com>
Date: Thu Feb 18 14:01:18 2021 +0800
kdumpctl: enable secure boot on ppc64le LPARs
On ppc64le LPAR, secure-boot is a little different from bare metal,
Where
host secure boot: /ibm,secure-boot/os-secureboot-enforcing DT property exists
while
guest secure boot: /ibm,secure-boot >= 2
Make kexec-tools adapt to LPAR
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
upstream: fedora
resolves: bz2003832
conflict:
function load_kdump_kernel_key() not exist in rhel9,
so related patch hunk is removed.
commit 0e4b66b1ab4d90bea8f3021a46660f5a253eb110
Author: Kairui Song <kasong@redhat.com>
Date: Tue Sep 14 02:25:40 2021 +0800
bash scripts: reformat with shfmt
This is a batch update done with:
shfmt -s -w mkfadumprd mkdumprd kdumpctl *-module-setup.sh
Clean up code style and reduce code base size, no behaviour change.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict:
function remove_kdump_kernel_key() not presented in rhel9,
so related patch hunk are removed.
commit 86538ca6e2e555caa8cdd2bcfcc3c5e94ac6bf58
Author: Kairui Song <kasong@redhat.com>
Date: Wed Sep 8 17:21:41 2021 +0800
bash scripts: fix variable quoting issue
Fixed quoting issues found by shellcheck, no feature
change. This should fix many errors when there is space
in any shell variables, eg. dump target's name/path/id.
False positives are marked with "# shellcheck disable=SCXXXX", for
example, args are expected to split so it should not be quoted.
And replaced some `cut -d ' ' -fX` with `awk '{print $X}'` since cut
is fragile, and doesn't work well with any quoted strings that have
redundant space.
Following quoting related issues are fixed (check the link
for example code and what could go wrong):
https://github.com/koalaman/shellcheck/wiki/SC2046https://github.com/koalaman/shellcheck/wiki/SC2053https://github.com/koalaman/shellcheck/wiki/SC2068https://github.com/koalaman/shellcheck/wiki/SC2086https://github.com/koalaman/shellcheck/wiki/SC2206
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict:
function load_kdump_kernel_key() not presented in rhel9,
so related patch hunk are removed.
commit 70978c00e5a573f0901ac404067eaea2c6536370
Author: Kairui Song <kasong@redhat.com>
Date: Wed Sep 8 17:20:51 2021 +0800
bash scripts: replace '[ ]' with '[[ ]]' for bash scripts
kdumpctl, mkdumprd, *-module-setup.sh only target bash, since they
only run in first kernel and depend on dracut, and dracut depends
on bash. So use '[[ ]]' to replace '[ ]'.
This is a batch update done with following command:
`sed -i -e 's/\(\s\)\[\s\([^]]*\)\s\]/\1\[\[\ \2 \]\]/g' kdumpctl, mkdumprd, *-module-setup.sh`
and replaced [ ... -a ... ] with [[ ... ]] && [[ ... ]] manually.
See https://tldp.org/LDP/abs/html/testconstructs.html for more details
on '[[ ]]', it's more versatile, safer, and slightly faster than '[ ]'.
This will also help shfmt to clean up the code in later commits.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit 54cc5c44befa308e122d93221c65486164ffb3e5
Author: Kairui Song <kasong@redhat.com>
Date: Wed Sep 8 01:48:52 2021 +0800
bash scripts: use $(...) notation instead of legacy `...`
This is a batch update done with following command:
`sed -i -e 's/`\([^`]*\)`/\$(\1)/g' mkfadumprd mkdumprd \
kdumpctl dracut-module-setup.sh dracut-fadump-module-setup.sh \
dracut-early-kdump-module-setup.sh`
And manually converted some corner cases. This fixes
all related issues detected by shellcheck.
Make it easier to do clean up in later commits.
Check following link for reasons to switch to the new syntax:
https://github.com/koalaman/shellcheck/wiki/SC2006
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit a416930706944828ae9bd8daf49be8ca998d3fcc
Author: Kairui Song <kasong@redhat.com>
Date: Wed Aug 4 15:50:30 2021 +0800
bash scripts: always use "read -r"
This helps to strip spaces and avoid mangling backslashes:
https://github.com/koalaman/shellcheck/wiki/SC2162
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit c4d85142be300814b8818fe8aad65eaa042e01c8
Author: Kairui Song <kasong@redhat.com>
Date: Wed Aug 4 15:18:59 2021 +0800
bash scripts: get rid of expr and let
As suggested by:
https://github.com/koalaman/shellcheck/wiki/SC2219
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict:
load_kdump_kernel_key() didn't present in rhel9,
so removed the patch for it.
commit 6d45257cc15b3a5b28ed3bfdacb06af065aaecb7
Author: Kairui Song <kasong@redhat.com>
Date: Wed Aug 4 15:14:00 2021 +0800
bash scripts: remove useless cat
Some `cat` calls are useless, remove them to make it cleaner.
See: https://github.com/koalaman/shellcheck/wiki/SC2002
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit 80525afaceac3fa6bdf6e57686f66ab497d2f153
Author: Kairui Song <kasong@redhat.com>
Date: Wed Aug 4 15:44:02 2021 +0800
kdumpctl: refine grep usage
Use `grep -q` instead of redirect to /dev/null.
Use `grep -c` instead, as suggested in:
https://github.com/koalaman/shellcheck/wiki/SC2126
Use `grep -E` instead of `egrep`.
https://github.com/koalaman/shellcheck/wiki/SC2196
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit dfb76467c9d9462e91e4dd8838f461fb7ab2538f
Author: Kairui Song <kasong@redhat.com>
Date: Wed Aug 4 16:22:17 2021 +0800
kdumpctl: fix fragile loops over find output
For loops over find output are fragile, use a while read loop:
https://github.com/koalaman/shellcheck/wiki/SC2044
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit 01613b7211a3de096a889000817ebb9da513f4af
Author: Kairui Song <kasong@redhat.com>
Date: Tue Aug 3 22:50:02 2021 +0800
kdumpctl: use kdump_get_conf_val to read config values
Also fixed kdumpctl, use `awk` instead of `cut` to read
core_collector's executable name correctly when its arguments
are not seperated by space.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit 09ccf88405793220af640c5317cbadb71cf03d36
Author: Kairui Song <kasong@redhat.com>
Date: Mon Aug 16 23:25:14 2021 +0800
kdump-lib.sh: add a config value retrive helper
Add a helper kdump_get_conf_val to replace get_option_value.
It can help cover more corner cases in the code, like when there are
multiple spaces in config file, config value separated by a tab,
heading spaces, or trailing comments.
And this uses "sed group command" and "sed hold buffer", make it much
faster than previous `grep <config> | tail -1`.
This helper is supposed to provide a universal way for kexec-tools
scripts to read in config value. Currently, different scripts are
reading the config in many different fragile ways.
For example, following codes are found in kexec-tools script code base:
1. grep ^force_rebuild $KDUMP_CONFIG_FILE
echo $_force_rebuild | cut -d' ' -f2
2. grep ^kdump_post $KDUMP_CONFIG_FILE | cut -d\ -f2
3. awk '/^sshkey/ {print $2}' $conf_file
4. grep ^path $KDUMP_CONFIG_FILE | cut -d' ' -f2-
1, 2, and 4 will fail if the space is replaced by, e.g. a tab
1 and 2 might fail if there are multiple spaces between config name
and config value:
"kdump_post /var/crash/scripts/kdump-post.sh"
A space will be read instead of config value.
1, 2, 3 will fail if there are space in file path, like:
"kdump_post /var/crash/scripts dir/kdump-post.sh"
4 will fail if there are trailing comments:
"path /var/crash # some comment here"
And all will fail if there are heading space,
" path /var/crash"
And all will most likely cause problems if the config file contains
the same option more than once.
And all of them are slower than the new sed call. Old get_option_value
is also very slow and doesn't handle heading space.
Although we never claim to support heading space or tailing comments
before, it's harmless to be more robust on config reading, and many
conf files in /etc support heading spaces. And have a faster and
safer config reading helper makes it easier to clean up the code.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
upstream: fedora
resolves: bz2003832
conflict: none
commit a0282ab22c4e61294346c8ab9c42ab87b8bdfbb0
Author: Kairui Song <kasong@redhat.com>
Date: Tue Aug 3 19:49:51 2021 +0800
kdump-lib.sh: add a config format and read helper
Add a helper `kdump_read_conf` to replace read_strip_comments.
`kdump_read_conf` does a few more things:
- remove trailing spaces.
- format the content, remove duplicated spaces between name and value.
- read from KDUMP_CONFIG_FILE (/etc/kdump.conf) directly, avoid pasting
"/etc/kdump.conf" path everywhere in the code.
- check if config file exists, just in case.
Also unify the environmental variable, now KDUMP_CONFIG_FILE stands for
the default config location.
This helps avoid some shell pitfalls about spaces when reading config.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Coiby Xu
Lichen Liu
Tao Liu
Kairui Song