Resolves: https://issues.redhat.com/browse/RHEL-10484
Upstream: Fedora
Conflict: Missing upstream patch d4e8772("kdumpctl: make do_estimate more
robust")
commit 741861164e
Author: Lichen Liu <lichliu@redhat.com>
Date: Mon Oct 30 14:51:59 2023 +0800
kdumpctl: Only returns immediately after an error occurs in check_*_modified
Currently is_system_modified will return immediately when check_*_modified
return a non-zero value, and the remaining checks will not be executed.
For example, if there is a fs-related error exists, and someone changes the
kdump.conf, check_files_modified will return 1 and is_system_modified will
return 1 immediately. This will cause kdumpctl to skip check_fs/drivers_modified,
kdump.service will rebuild the initrd and start successfully, however, any
errors should prevent kdump.service from starting.
This patch will cause check_*_modifed to continue running until an error occurs
or all execution ends.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Acked-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-8727
Resolves: https://issues.redhat.com/browse/RHEL-8710
Upstream: Fedora
Conflict: The 1st hunk is merged manualy because of conflict caused
by context.
commit 4841bc6a6d
Author: Baoquan He <bhe@redhat.com>
Date: Thu Sep 21 18:01:02 2023 +0800
kdump-lib.sh: add extra 64M to default crashkernel if sme/sev is active
It's reported that kdump kernel failed to boot and can't dump vmcore
when crashkernel=192M and SME/SEV is active.
This is because swiotlb will be enabled and reserves 64M memory by
default on system with SME/SEV enabled. Then kdump kernel will be out of
memory after taking 64M away for swiotlb init.
So here add extra 64M memory to default crashkernel value so that kdump
kernel can function well as before. When doing that, search journalctl
for the "Memory Encryption Features active: AMD" to check if SME or SEV
is active. This line of log is printed out in kernel function as below
and the type SME is mutual exclusive with type SEV.
***:
arch/x86/mm/mem_encrypt.c:print_mem_encrypt_feature_info()
Note:
1) The conditional check is relying on journalctl log because I didn't
find available system interface to check if SEV is active. Even
though we can check if SME is active via /proc/cpuinfo. For
consistency, I take the same check for both SME and SEV by searching
journalctl.
2) The conditional check is relying on journalctl log, means it won't
work for crashkernel setting in anoconda because the installation
kernel doesn't have the SME/SEV setting. So customer need manually
run 'kdumpctl reset-crashkernel' to reset crashkernel to add the
extra 64M after OS installation.
3) We need watch the line of log printing in
print_mem_encrypt_feature_info() in kernel just in case people may
change it in the future.
Signed-off-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-8727
Resolves: https://issues.redhat.com/browse/RHEL-8710
Upstream: Fedora
Conflict: spec/kdump-lib_spec.sh doesn't exist in RHEL, so I remove
the hunk directly.
commit 64f2827a4b
Author: Philipp Rudo <prudo@redhat.com>
Date: Wed Sep 6 10:49:47 2023 +0200
kdump-lib: Harden _crashkernel_add
_crashkernel_add currently always assumes the good case, i.e. that the
value of the crashkernel parameter has the correct syntax and that the
delta added is a number. Both doesn't have to be true when the values
are provided by users. Thus add some additional checks.
Furthermore require the delta to have a explicit unit, i.e. no longer
assume that is in megabytes, i.e. 100 -> 100M.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-14003
Upstream: Fedora
Conflict: None
commit 4fa17b2ee4
Author: Nayna Jain <nayna@linux.ibm.com>
Date: Tue Oct 3 23:41:47 2023 -0400
powerpc: update kdumpctl to load kernel signing key for fadump
On secure boot enabled systems with static keys, kexec with kexec_file_load(-s)
fails as "Permission Denied" when fadump is enabled.
Similar to kdump, load kernel signing key for fadump as well.
Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-14003
Upstream: Fedora
Conflict: None
commit fe6eb30e67
Author: Nayna Jain <nayna@linux.ibm.com>
Date: Tue Oct 3 23:41:46 2023 -0400
powerpc: update kdumpctl to remove deletion of kernel signing key once loaded
Kernel signing key is deleted once kdump is loaded. This causes confusion in
debugging since key is no longer visible. Unless someone knows how
kdumpctl script works, it is difficult to find out how kdump could be
loaded when there is no key on .ima keyring.
Remove deletion of kernel signing key once loaded. And then to prevent
multiple loading of same key when kdump service is disabled/enabled, update
key description field as well.
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: RHEL-14000
Upstream: https://github.com/horms/kexec-tools
Conflict: None
commit bd0200c47c45dd420244b39ddabcecdab1fb9a8e
Author: Hari Bathini <hbathini@linux.ibm.com>
Date: Wed Sep 20 17:29:27 2023 +0530
kexec: update manpage with explicit mention of clean kexec
While the manpage does mention about kexec boot with a clean shutdown,
it is not explicit about it. Make it explicit.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: None
commit 4b7b7736ee
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Wed Aug 2 20:36:48 2023 +0530
Introduce a function to get reserved memory size
The size of the reserved memory in the functions show_reserved_mem,
check_crash_mem_reserved, and do_estimate are fetched from the sysfs
node `/sys/kernel/kexec_crash_size`. However, in the case of fadump,
the reserved area size is instead present in
/sys/kernel/fadump/mem_reserved.
For example:
$ kdumpctl showmem
kdump: Dump mode is fadump
kdump: Reserved 0MB memory for crash kernel
The above command showed 0MB for Reserved memory which is incorrect, the
actual reservation was 2048MB.
To resolve this issue a new helper function is introduced to fetch
reserved memory size based on the dump mode. For "fadump" mode,
it looks in `/sys/kernel/fadump/mem_reserved`, otherwise, it uses
`/sys/kernel/kexec_crash_size`. And all functions that previously
fetching reserved memory directly from `/sys/kernel/kexec_crash_size`
sysfs node are now updated to use this new function to get the reserved
memory size.
With the fix in place, the `kdumpctl showmem` command will now display
correct reserved memory size.
$ kdumpctl showmem
kdump: Dump mode is fadump
kdump: Reserved 2048MB memory for crash kernel
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: Some newer patches has been rebased, which caused git am to
encounter some problems.
commit fc7c65312a
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Thu Aug 17 16:38:35 2023 +0530
powerpc: update fadump sysfs node path
The fadump sysfs nodes /sys/kernel/fadump_[enabled|registered], have
been relocated to /sys/kernel/fadump/[enabled|registered] by kernel
commits d418b19f34ed ("powerpc/fadump: Reorganize /sys/kernel/fadump_*
sysfs files").
To ensure compatibility, symbolic links were added for each relocated
sysfs entry. Nonetheless, note that these symbolic links might be
removed later, as they have been deprecated by kernel commit
3f5f1f22ef10 ("Documentation/ABI: Mark /sys/kernel/fadump_* sysfs files
deprecated")
This patch updates the scripts to use the updated fadump sysfs files.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: Some newer patches has been rebased, which caused git am to
encounter some problems.
commit b9fd7a4076
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Jan 12 16:31:02 2023 +0100
kdumpctl: merge check_current_{kdump,fadump}_status
Both functions are almost identical. The only differences are (1) the
sysfs node the status is read from and (2) the fact the fadump version
doesn't verify if the file it's trying to read actually exists. Thus
merge the two functions and get rid of the check_current_status wrapper.
While at it rename the function to is_kernel_loaded which explains
better what the function does.
Finally, after moving FADUMP_REGISTER_SYS_NODE shellcheck can no longer
access the definition and starts complaining about it not being quoted.
Thus quote all uses of FADUMP_REGISTER_SYS_NODE.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz2165018
Upstream: Fedora Rawhide
Conflict: None
commit daa829f79e
Author: Lichen Liu <lichliu@redhat.com>
Date: Mon Jun 12 17:17:43 2023 +0800
spec: kdump/ppc64: make servicelog_notify silent when there are no errors
There is confusing message in /var/log/anaconda/packaging.log when installing
kexec-tools during the system installation on ppc64le:
Event Notification Registration successful (id: 1)
Make servicelog_notify slient when there are no erros.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2215606
Upstream: Fedora Rawhide
Conflict: None
commit dda81d72c2
Author: Philipp Rudo <prudo@redhat.com>
Date: Mon Jun 19 14:31:48 2023 +0200
kdumpctl: Fix temporary directory location
The temporary directory is currently created under the current working
directory. That alone isn't ideal but works most of the time. However,
it will fail when the current working directory is not writable. So make
sure the directory is created within TMPDIR.
Fixes: ea00b7d ("kdumpctl: Move temp file in get_kernel_size to global temp dir")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2165839
Upstream: Fedora
Conflict: None
commit f3139012f2
Author: Pingfan Liu <piliu@redhat.com>
Date: Tue Jun 20 08:50:31 2023 +0800
kdump-lib: Match 64k debug kernel in prepare_kdump_bootinfo()
For kernel 64k variant, it terminates with substring 64k-debug, e.g.
vmlinuz-5.14.0-327.el9.aarch64+64k-debug.
Providing an extra matching pattern to filter out it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None
commit 64d93c886f
Author: Pingfan Liu <piliu@redhat.com>
Date: Fri Jun 9 16:04:29 2023 +0800
kdumpctl: Fix the matching of plus symbol by grep's EREs
After introducing 64k variant kernel on aarch64, an example kernel name
looks like "vmlinuz-5.14.0-316.el9.aarch64+64k". To match the plus
symbol, it demands an escape charater.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None
commit 7a2c4cbc3b
Author: Pingfan Liu <piliu@redhat.com>
Date: Tue Jun 13 17:43:23 2023 +0800
kdump-lib: Evaluate the memory consumption by smmu and mlx5 separately
On 4k and 64k kernels, the typical consumption values for SMMU are 36MB
and 384MB, respectively. Hence for 64k kernel, the consumption by smmu
should be taken into account carefully.
To do it by adding the extra 384MB value if installing a 64k kernel.
The upper limit value 384MB is calculated according to the formula in
the kernel smmu driver.
As for mlx5 network cards, it is measured by a pratical test, 200M for
64k variant, 150M for 4k variant
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None
commit 05c4861443
Author: Pingfan Liu <piliu at redhat.com>
Date: Tue Jun 13 17:43:22 2023 +0800
kdump-lib: add support for 64K aarch64
On aarch64, both 4K and 64K kernel can be installed, while they demand
different size reserved memory for kdump kernel.
'get_conf PAGE_SIZE' can not work if installing a 64K kernel when
running a 4K kernel. Hence resorting to the kernel release naming rules.
At present, the 64K kernel has the keyword '64k' in its suffix.
The base line for 64K is decided based on 4K. The diff 100M is picked up
since on a high end machine without smmu enabled, the diff of MemFree is
82M.
As for the smmu case, a huge difference in the memory consumption lies
between 64k and 4k driver. And it should be calculated separatedly.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None
commit d8b961be37
Author: Pingfan Liu <piliu@redhat.com>
Date: Tue Jun 13 17:43:21 2023 +0800
kdump-lib: Introduce parse_kver_from_path() to get kernel version from its path name
kdump_get_arch_recommend_crashkernel() expects the kernel version info,
while _update_kernel() provides the absolute path, which contains the
kernel version info.
This patch introduce a dedicated function parse_kver_from_path() to
extract the kernel info from the path
Credit to Philipp, who contributes the original code.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: Drop shellspec test case
commit 51efbcf83e
Author: Pingfan Liu <piliu@redhat.com>
Date: Tue Jun 13 17:43:20 2023 +0800
kdump-lib: Introduce a help function _crashkernel_add()
This help function can manipulate the crashkernel cmdline by adding an
number for each item. Also a basic test case for _crashkernel_add() is
provided in this patch.
Credit to Philipp, who contributes the original code.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: applied manually due to slight difference in context
commit 5b31b099ae
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Apr 26 04:48:25 2023 +0800
Simplify the management of the kernel parameter crashkernel
Currently, kexec-tools only updates the crashkernel to a new default
value only when both two conditions are met,
- auto_reset_crashkernel=yes in kdump.conf
- existing kernels or current running kernel should use the old default
value.
To address seen corner cases, the logic to tell if the second condition
is met becomes quite complex. Instead of making the logic more complex
to support aarch64-64k, this patch drops the second condition to
simplify the management of the crashkernel kernel parameter.
Another change brought by this simplification is kexec-tools will also
set up the kernel crashkernel parameter for a fresh install (previously
it's limited to osbuild).
Note
1. This patch also stop trying to update /etc/default/grub because
a) it only affects the static file /boot/grub2/grub.cfg
b) grubby is recommended to change the kernel command-line parameters
for both Fedora [1] and RHEL9 [2][3]
c) For the cases of aarch64 and POWER, different kernels could have
different default crashkernel value.
2. Starting with Fedora 37, posttrans rpm scriplet distinguish between
package install and upgrade.
[1] https://fedoraproject.org/wiki/GRUB_2
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters
[3] https://access.redhat.com/solutions/1136173
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2165839
Upstream: Fedora
Conflict: None
commit 81d3cc344d
Author: Pingfan Liu <piliu@redhat.com>
Date: Thu Apr 20 11:26:34 2023 +0800
kdump-lib: fix the matching pattern for debug-kernel
On aarch64, a 64k kernel's name looks like:
vmlinuz-5.14.0-300.el9.aarch64+64k and the corresponding debug kernel's
name looks like: vmlinuz-5.14.0-300.el9.aarch64+64k-debug, which ends
with the suffix -debug instead of +debug.
Fix the matching pattern by [+|-]debug
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2165839
Upstream: Fedora
Conflict: None
commit 88919b73f0
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Jan 12 16:31:04 2023 +0100
kdump-lib: always specify version in is_squash_available
is_squash_available is only used in dracut-module-setup.sh and mkdumprd.
Neither of the two scripts calls prepare_kdump_bootinfo which determines
and sets KDUMP_KERNELVER. Thus KDUMP_KERNELVER is only non-zero if it
explicitly specified by the user in /etc/sysconfig/kdump (and the file
gets sourced, which is not the case for drachu-module-setup.sh).
In theory this can even lead to bugs. For example consider the case when
a debug kernel is running. In that case kdumpctl will try to use the
non-debug version of the kernel while is_squash_available will make its
decision based on the debug version. So in case the debug kernel has
squash available but the non-debug kernel doesn't mkdumprd will try to
add it nevertheless.
Thus factor out the kernel version detection from prepare_kdump_bootinfo
and make use of the new function when checking for the availability of
those kernel modules.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-518
Upstream: Fedora
Conflict: None
commit e42a823dae
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Jun 1 16:05:05 2023 +0800
mkdumprd: Use the correct syntax to redirect the stderr to null
A space was added by mistake and unfortunately fips-mode-setup refuses
an extra parameter,
# fips-mode-setup --is-enabled 2 > /dev/null
# echo $?
2
# fips-mode-setup --is-enabled 2
Check, enable, or disable the system FIPS mode.
usage: /usr/bin/fips-mode-setup --enable|--disable [--no-bootcfg]
usage: /usr/bin/fips-mode-setup --check
usage: /usr/bin/fips-mode-setup --is-enabled
So in this case mkdumprd can never detect if FIPS is enabled. Fix this
mistake.
Fixes: 443a43e0 ("mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: Small context difference in kexec-tools.spec
commit ea7be0608e
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri May 5 17:14:42 2023 +0200
kdumpctl: Add basic UKI support
A Unified Kernel Image (UKI) is a single EFI PE executable combining an
EFI stub, a kernel image, an initrd image, and the kernel command line.
They are defined in the Boot Loader Specification [1] as type #2
entries. UKIs have the advantage that all code as well as meta data that
is required to boot the system, not only the kernel image, is combined
in a single PE file and can be signed for EFI SecureBoot. This extends
the coverage of SecureBoot extensively.
For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e
("redhat: Add sub-RPM with a EFI unified kernel image for virtual
machines").
There are two problems with UKIs from the kdump point of view at the
moment. First, they cannot be directly loaded via kexec_file_load and
second, the initrd included isn't suitable for kdump. In order to enable
kdump on systems with UKIs build the kdump initrd as usual and extract
the kernel image before loading the crash kernel.
[1] https://uapi-group.org/specifications/specs/boot_loader_specification/
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None
commit ea00b7db43
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri May 5 17:14:41 2023 +0200
kdumpctl: Move temp file in get_kernel_size to global temp dir
Others will need to use a temporary files, too. In order to avoid
potential clashes of multiple trap handlers move the local temp file
into a global temp dir.
While at it make sure that the trap handler returns the correct exit
code.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None
commit 81d89c885f
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri May 5 17:14:40 2023 +0200
kdumpctl: Move get_kernel_size to kdumpctl
The function is only used in do_estimate. Move it to kdumpctl to
prevent confusion.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: drop removal of irqpoll in prepare_cmdline due to missing
d55a056 ("kdumpctl: move aws workaround to kdump-lib") and
d593bfa ("KDUMP_COMMANDLINE: remove irqpoll parameter on aws aarch64 platform")
commit 0f6ad91be8
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Jan 12 16:31:07 2023 +0100
kdump-lib: fix prepare_cmdline
A recently added unit test found that prepare_cmdline has several
problems. For example an empty remove list will remove all spaces or
when the cmdline contains a parameter with quoted values containing
spaces will only remove the beginning up to the first space. Furthermore
the old design requires lots of subshells and pipes.
This patch rewrites prepare_cmdline in a way that makes the unit test
happy and tries to use as many bash built-ins as possible.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-512
Upstream: Fedora
Conflict: None
commit 443a43e075
Author: Coiby Xu <coxu@redhat.com>
Date: Wed May 24 12:01:45 2023 +0800
mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS
Currently, kdump doesn't work on many FIPS-enabled systems including
Azure, ESXI, Hyper, POWER and etc. When FIPS is enabled, it needs to
access /boot//.vmlinuz-xxx.hmac to verify the integrity of the kernel.
However, on those systems, /boot fails to be mounted due to a lack of
fs and block device drivers and the system just halted after failing to
verify the integrity of the kernel. For example, on Hyper-V, sd_mod, sg,
scsi_transport_fc, hv_storvsc and hv_vmbus need to be installed in order
for /boot to be mounted.
mkdumprd calls dracut with the --no-hostonly-default-device. Following
the documentation (man dracut),
--no-hostonly-default-device
Do not generate implicit host devices like root, swap, fstab, etc.
Use "--mount" or "--add-device" to explicitly add devices as needed
this patch uses "--add-device" to explicitly add the device of /boot.
Note there is already an attempt to fix it in dracut's 01fips module
i.e. via the commit 83651776 ("fips: ensure fs module for /boot is
installed"). Unfortunately it only installs the file system driver e.g.
xfs.
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2078176
Upstream: Fedora
Conflict: None
commit d619b6dabe
Author: Lichen Liu <lichliu@redhat.com>
Date: Tue Apr 4 14:13:14 2023 +0800
kdumpctl: lower the log level in reset_crashkernel_for_installed_kernel
Although upgrading the kernel with `rpm -Uvh` is not recommended, the
kexec-tools plugin prints confusing error logs when a customer upgrades the
kernel through it.
```
kdump: kernel 5.14.0-80.el9.x86_64 doesn't exist
kdump: Couldn't find current running kernel
```
Not finding the currently running kernel will only make kdump unable to copy the
grub entry parameters to the newly installed kernel, so lower the log level.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Related: bz2151504
Upstream: Fedora
Conflict: None
commit 12d9eff9dc
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Mar 28 16:33:34 2023 +0800
Show how much time kdump has waited for the network to be ready
Relates: https://bugzilla.redhat.com/show_bug.cgi?id=2151504
Currently, when the network isn't ready, kdump would repeatedly print
the same info,
[ 29.537230] kdump[671]: Bad kdump network destination: 192.123.1.21
[ 30.559418] kdump[679]: Bad kdump network destination: 192.123.1.21
[ 31.580189] kdump[687]: Bad kdump network destination: 192.123.1.21
This is not user-friendly and users may think kdump has got stuck. So
also show much time has waited for the network to be ready,
[ 29.546258] kdump[673]: Waiting for network to be ready (50s / 10min)
...
[ 32.608967] kdump[697]: Waiting for network to be ready (56s / 10min)
Note kdump_get_ip_route no longer prints an error message and it's up to
the caller to determine the log level and print relevant messages. And
kdump_collect_netif_usage aborts when kdump_get_ip_route fails.
Reported-by: Martin Pitt <mpitt@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: bz2151504
Upstream: Fedora
Conflict: None
commit df6f25ff20
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Mar 27 13:17:32 2023 +0800
Tell nmcli to not escape colon when getting the path of connection profile
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151504
When a NetworManager connection profile contains a colon in the name,
"nmcli --get-values UUID,FILENAME" by default would escape the colon
because a colon is also used for separating the values. In this case,
99kdumpbase fails to get the correct connection profile path,
kdumpctl[5439]: cp: cannot stat '/run/NetworkManager/system-connections/static-52\\\:54\\\:01.nmconnection': No such file or directory
kdumpctl[5440]: sed: can't read /tmp/1977-DRACUT_KDUMP_NM/ifcfg-static-52-54-01: No such file or directory
kdumpctl[5449]: dracut-install: ERROR: installing '/tmp/1977-DRACUT_KDUMP_NM/ifcfg-static-52-54-01' to '/etc/NetworkManager/system-connections/ifcfg-static-52-54-01'
As a result, dumping vmcore to a remote nfs would fail.
In our case of getting connection profile path, there is no need to escape the
colon so pass "-escape no" to nmcli,
[root@localhost ~]# nmcli --get-values UUID,FILENAME c show
659e09c1-a6bd-3549-9be4-a07a1a9a8ffd:/etc/NetworkManager/system-connections/aa\:bb.nmconnection
[root@localhost ~]# nmcli -escape no --get-values UUID,FILENAME c show
659e09c1-a6bd-3549-9be4-a07a1a9a8ffd:/etc/NetworkManager/system-connections/aa:bb.nmconnection
Suggested-by: Beniamino Galvani <bgalvani@redhat.com>
Reported-by: Martin Pitt <mpitt@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: bz2140721
Upstream: Fedora
Conflict: None
commit 70c7598ef0
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Dec 23 16:03:38 2022 +0800
Install nfsv4-related drivers when users specify nfs dumping via dracut_args
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2140721
Currently, if users specify dumping to nfsv4 target via
dracut_args --mount "<NFS-server-ip>:/var/crash /mnt nfs defaults"
it fails with the following errors,
[ 5.159760] mount[446]: mount.nfs: Protocol not supported
[ 5.164502] systemd[1]: mnt.mount: Mount process exited, code=exited, status=32/n/a
[ 5.167616] systemd[1]: mnt.mount: Failed with result 'exit-code'.
[FAILED] Failed to mount /mnt.
This is because nfsv4-releted drivers are not installed to kdump initrd.
mkdumprd calls dracut with "--hostonly-mode strict". If nfsv4-related
drivers aren't loaded before calling dracut, they won't be installed.
When users specify nfs dumping via dracut_args, kexec-tools won't mount
the nfs fs beforehand hence nfsv4-related drivers won't be installed.
Note dracut only installs the nfs driver i.e. nfsv3 driver for "--mount
... nfs". So also install nfsv4-related drivers when users specify nfs
dumping via dracut_args. Since nfs_layout_nfsv41_files depends on nfsv4,
the nfsv4 driver will be installed automatically.
As for the reason why we support nfs dumping via dracut_args instead of
asking user to use the nfs directive, please refer to commit 74c6f464
("Support special mount information via 'dracut_args'").
Fixes: 4eedcae5 ("dracut-module-setup.sh: don't include multipath-hostonly")
Reported-by: rcheerla@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: bz2177574
Upstream: RHEL-only
This reverts commit 870ec2ec93.
Now the real fix has gone into the RHEL-9 kernel [1], the temporary
workaround can be removed.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2129726
Signed-off-by: Pingfan Liu <piliu@redhat.com>
