Resolves: RHEL-49401
commit 9ade09f00f4e65a4a40686cf77f003f8f8d7ecdf
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Jul 9 16:58:46 2024 +0800
Add build dependencies on needed libraries
Resolves: https://github.com/rhkdump/kdump-utils/issues/22
As found by Dave, built kexec-tools wasn't linked to libraries like
libz.so.1,
# ldd /sbin/kexec
linux-vdso.so.1 (0x0000ffff8cfa1000)
libc.so.6 => /lib64/libc.so.6 (0x0000ffff8cd10000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff8cf54000)
As a consequence, kexec fails to load the aarch64 kernel.
Previous version of /sbin/kexec is linked to liblzma.so and
libz.so,
# ldd /sbin/kexec
linux-vdso.so.1 (0x00007f28d392c000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f28d37e7000)
libz.so.1 => /lib64/libz.so.1 (0x00007f28d37c6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f28d35d4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f28d392e000)
So add build dependencies on those needed libraries.
Fixes: 28ced79 ("Split out kdump-utils and makedumpfile")
Reported-by: Jean Baptiste Trystram <jbtrystram@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-46776
commit 2f21fa2acfac9f6e19e071330f917e60aafc4600
Author: Philipp Rudo <prudo@redhat.com>
Date: Mon Jun 24 17:34:35 2024 +0200
kdump-lib: Drop 'file' dependency in is_uki
The 'file' utility is no longer installed per default. In addition there
was an update to it so it now reports the file type as
application/vnd.microsoft.portable-executable. Thus fall back to use
objdump to avoid adding yet an other dependency for kdump-utils and deal
with different versions of 'file'.
Note: This has the small drawback that objdump is arch specific. I.e.
examining a aarch64 UKI on a x86_64 machine will return an 'file format
not recognized' error.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-40956
commit 5109f119b643a416f24938774c02e39bb5d30467
Author: Philipp Rudo <prudo@redhat.com>
Date: Mon Jun 24 13:44:22 2024 +0200
Makefile: Fix early-kdump file names
When creating the kdump-utils subpackage the files for earlykdump were
incorrectly renamed to kdump.sh and kdump-module-setup.sh rather than
the expected early-kdump.sh and module-setup.sh. These incorrect file
names then got transferred to the newly created Makefile with fe372af
("Upstream kdump-utils").
With those incorrect file names dracut fails when trying to add the
earlykdump module with
# dracut --add earlykdump kdump.img
dracut[E]: Module 'earlykdump' cannot be installed.
Fix the file names to allow installing the earlykdump module.
Fixes: 372b4c6 ("Add kdump-utils subpackage")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-40817
commit 08649f2487300a077ee5a45ef045dc277c21484d
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Jun 20 13:19:30 2024 +0200
dracut-kdump.sh: Save kexec-dmesg.log after failure_action
The kexec-dmesg.log is only saved after the initial dump attempt but not
for the failure_action. So in case the initial dump attempt failed and
the failure_action is dump_to_rootfs the kexec-dmesg.log is missing. Fix
that by calling save_log also after executing the failure_action.
Fixes: 3d70f8b ("logger: save log after all kdump progress finished")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-31422
Resolves: RHEL-42413
commit 574f8f588b5257d410c01de076644d398e1fc9e6
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Jun 1 17:04:13 2023 +0200
kdumpctl: Simplify fadump handling in reset_crashkernel
When handling fadump there are three cases we need to consider
1) When running on non-ppc64le systems
In this case _dump_mode=kdump and _new_fadump='' always. In other
words we don't need to care updating the fadump parameter on the
kernel command line. We could always remove it like the code did so
far. But should we remove it when we never set it? In particular as
that might overwrite a change explicitly made by the user (for
whatever reason)
2) When running on ppc64le and the user provided --fadump option
In this case _new_fadump and _dump_mode are set accordingly to what
the user provided. Thus we need to update both the crashkernel (in
case fadump was turned on/off) and the fadump (in case the fadump
mode changed) parameters.
3) When running on ppc64le but the user did not provide --fadump option
In this case both _new_fadump='' and _dump_mode=''. In this case we
take over the previously set fadump parameter. Which means that we
don't need to update the fadump parameter at all. We do need to check
whether the _new_dump_mode is fadump or kdump though so we use the
correct (new) default crashkernel value.
In the three cases only the second one needs to update the fadump
parameter. Reflect this discussion in code.
This also fixes a bug that always prints
kdump: Updated fadump= for kernel=$kernel. Please reboot the
system for the change to take effect.
when the crashkernel= parameter is unchanged as well as reboots the
system, if --reboot is provided. Even for non-ppc architectures.
Fixes: 140da74 ("rewrite reset_crashkernel to support fadump and to used by RPM scriptlet")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-40745
commit f3669ac67a8c4a05ba7a9c9b62ae8756e50a186b
Author: Philipp Rudo <prudo@redhat.com>
Date: Tue Jun 18 14:57:16 2024 +0200
kdump-lib: fix sed expression in prepare_cmdline on aarch64
The sed expression misses a 's' for search and replace...
Fixes: 0f6ad91 ("kdump-lib: fix prepare_cmdline")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-46773
commit 3028529915d3026e62b59d8f3faadddd410baa75
Author: Philipp Rudo <prudo@redhat.com>
Date: Fri Jun 14 11:48:24 2024 +0200
kdumpctl: Drop default kexec '-d' option
Kernel commits cbc2fe9d9cb2 ("kexec_file: add kexec_file flag to control
debug printing") and a85ee18c7900 ("kexec_file: print out debugging
message if required") added debug messages to the kexec_file_load system
call when option -d is provided to the kexec user space tool. As
kexec_file_load is the default and option -d is set by default these
messages are always printed when a crash kernel is loaded. This not only
clutters the kernel log but also potentially leaks confidential kernel
information to users. As the messages are printed to the kernel log, not
stderr, the redirection to /var/log/kdump.log won't catch them. This
will become even more problematic as for RHEL10 the kernel will be built
without support for the kexec_load system call. So kexec_file_load will
be the only choice in the future.
The redirection also caused confusion in a recent bug report. There a
user moved a working /etc/sysconfig/kdump from ppc to s390 with
KEXEC_ARGS containing the --dt-no-old-root option. This option is arch
specific and does not exist on s390. Thus the kexec-tools failed with an
'unrecognized option' error followed by the usage(). The problem was
that the 'unrecognized option' error is printed to stderr, which got
redirected to /var/log/kdump.log, while the usage() is printed to
stdout, which ended up in the systemd journal. This caused confusion as
the user only checked the journal and found the usage() without any
error message.
Thus remove the default -d option and the redirection of stderr to
/var/log/kdump.log for the kexec-tools user space tool.
This commit ultimately reverts 88a8b94 ("kdumpctl: add the '-d' option to
enable the kexec loading debugging messages").
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-40948
Conflict: Yes, commented the diff code within the patch's commit log,
otherwise the patch command will regard the diff code as regular
patch hunk and fail.
Upstream: fedora
commit 98087d78eda2ca58a3b55ee5dd9e0e7bad8467ef
Author: Tao Liu <ltao@redhat.com>
Date: Tue Jun 25 16:35:16 2024 +1200
Use "grep -q <<< $(cmd)" instead of "cmd | grep -q"
The following line of code's exit value should be the exit value of
grep by default:
cmd | grep -q
However it will not always work as expected, a 141 exit code may be
returned, see the following debug info:
--- a/usr/lib/dracut/modules.d/99kdumpbase/module-setup.sh
+++ b/usr/lib/dracut/modules.d/99kdumpbase/module-setup.sh
@@ -55,6 +55,11 @@ depends() {
_dep="$_dep ssh-client"
fi
+ dracut --list-modules 1>&2
+ echo $? 1>&2
+ dracut --list-modules | grep -q lvmthinpool-monitor
+ echo $? ${PIPESTATUS[0]} ${PIPESTATUS[1]} 1>&2
+
if is_lvm2_thinp_dump_target; then
if dracut --list-modules | grep -q lvmthinpool-monitor; then
add_opt_module lvmthinpool-monitor
$ kdumpctl rebuild
kdump: Rebuilding /boot/initramfs-6.10.0-0.rc4.11.el10.x86_64kdump.img
...snip...
lvmmerge
lvmthinpool-monitor
..snip...
uefi-lib
0
141 141 0
The reason is, grep exits immediately when there is a match but the
first cmd still keep writing to the pipe. Since there is no reader,
a SIGPIPE signal is generated. As a result, a 141 exit code will be
returned.
Let's use the following line of code instead, which have the same effect
but works as expected:
grep -q <<< $(cmd)
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
We should use PatchXX to apply upstream kdump-utils
patches instead of directly merge them into git.
Resolves: RHEL-36415
Resolves: RHEL-37670
Upstream: https://github.com/rhkdump/kdump-utils/
Conflict: None
Signed-off-by: Lichen Liu <lichliu@redhat.com>
With the introduction of kernel commit c6c5b14dac0d ("powerpc: make fadump
resilient with memory add/remove events") linux kernel now internally manages
the update of elfcorehdr during memory add/remove events. So no need to
re-register fadump if the /sys/kernel/fadump/hotplug_ready is set to 1.
No impact for kernels that do not have /sys/kernel/fadump/hotplug_ready
sysfs.
Relevant kernel commit links:
1. https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com
2. https://msgid.link/20240422195932.1583833-3-sourabhjain@linux.ibm.com
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
There have been some of failing cases of kdump in 2nd kernel, where
ususally only one cpu is enabled by "nr_cpus=1", but with a large
number of devices, which may easily exceed the maximum IRQ resources of
one cpu can handle. As a result, the 2nd kernel will hang and kdump
fails. This issue is often observed on machines with many cpus and many
devices.
On those systems, pcieports consume quite proportion of IRQ resources,
many following message can be seen in dmesg log:
pcieport 0000:18:01.0: PME: Signaling with IRQ 109
According to kernel doc[1], when "pcie_ports=compat" applied, it will disable
native PCIe services (PME, AER, DPC, PCIe hotplug). Those functions are
power management events, error reporting, performance, hotplug related,
which are not the must-have functions for kdump. In addition, after
testing, no side effects such as cannot writing vmcore into sdx, nvme
etc been noticed.
This patch will disable native PCIe services for 2nd kernel, to saving the
scarce IRQ resources and increase the kdump success.
Attach Prarit's comments:
This makes sense to me. The only concern anyone should have is that a PCIE
error could have been responsible for taking down the kernel in the first
place, and booting into the second kernel could then also have a fatal
problem. I'm not sure we can ever fix that type of cascade of panics :)
so it makes sense to disable these features.
[1]: https://www.kernel.org/doc/html/v6.9-rc1/admin-guide/kernel-parameters.html
Signed-off-by: Tao Liu <ltao@redhat.com>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Currently, network dumping failed over a NIC that is a Single Root I/O
Virtualization (SR-IOV) virtual device. Usually the driver of the
virtual device won't specify the dependency on the driver of the
physical device. So to fix this issue, the driver of the physical device
needs to be found and installed as well.
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-7028
Currently, nfs dumping fails on some machines that has a dedicated PHY
driver (dealing with the physical layer) or MDIO bus (connecting the MAC
to PHY devices) driver. This is because kexec-tools doesn't install
dedicated PHY or MDIO driver explicitly. Usually a NIC driver shouldn't
specify the dependency on the needed PHY or MDIO driver because it
shouldn't a NIC (medium access control, MAC) driver is for dealing with
the Data link layer and a PHY driver is for physical layer. So as long
as a MAC driver can talk to the PHY layer via APIs, it shouldn't care
which PHY driver or device it's talking to. So when the
dependency on a PHY driver or MDIO driver is not found by dracut's
instmods, the PHY or MDIO driver won't be installed.
This patch passes =drivers/net/phy and =drivers/net/mdio to dracut's
instmods which will only install in-use PHY or MDIO driver(s).
Note ideally we should find out which PHY driver is used by a NIC but
unfortunately currently no universal way can be found
(/sys/class/net/NIC_NAME/phydev/driver/module can be used to find the
name of the PHY driver for some NICs but it doesn't exist for some NICs
like Qualcomm Atheros AR8031). So is it for a MDIO bus driver.
Fortunately currently no huge memory consumption is found for a PHY or
MDIO driver.
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Reported-by: Doreen Alongi <dalongi@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
If only "makedumpfile" is written in "core_collector" of /etc/kdump.conf
and try to run makedumpfile without options,
"makedumpfile --check-params" fails and terminates abnormally.
# grep ^core_collector /etc/kdump.conf
core_collector makedumpfile
# /usr/bin/kdumpctl start
:
Commandline parameter is invalid.
Try `makedumpfile --help' for more information.
kdump: makedumpfile parameter check failed.
kdump: mkdumprd: failed to make kdump initrd
kdump: Starting kdump: [FAILED]
On the other hand, "makedumpfile --check-params" works fine without any options.
# makedumpfile --check-params vmcore dumpfile
# echo $?
0
In addition, before verify_core_collector() was implemented,
initial RAM for kdump was successfully created using only "core_collector makedumpfile".
I consider it a regression.
This is due to a parameter extraction error in verify_core_collector().
Fix it to correctly extract only the options as follows.
Fixes: a1c28126 ("mkdumprd: Use makedumpfile --check-params option")
Signed-off-by: Mamoru Nishibe <nishibe.mamoru@fujitsu.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
There is a bug report for RHEL10 about a grep error reading
grep: /var/tmp/dracut.DiZuKp/initramfs/etc/systemd/system.conf*: No such file or directory
that shows up when rebuilding the initrd. This is caused by systemd
v255 that allows installing the default systemd config files to
/usr/lib/systemd instead of /etc/systemd [1][2] which is done for RHEL.
So unless a user manually adds /etc/systemd/system.conf the file no
longer exists.
However the test that requires the call to grep is somewhat wonky. IIUC
the test is there so we don't overwrite a setting the user might have
made. In my opinion this only makes sense as long as the timeout set is
larger than what we would set. But this part of the logic is missing.
So fix the error message by removing the test and add our config
unconditionally.
While at it rename the created drop-ins to 99-kdump.conf to follow
the recommended naming convention and to make sure that our value takes
precedence.
Note: In case the test is still needed we can fall back to use
'systemd-analyse cat-config' that automatically considers all potential
locations for the config and its drop-ins.
[1] 6495361c7d ("meson: add build option for install path of main config files")
[2] 6378f257e7 ("various: use new config loader instead of config_parse_config_file()")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Fix the following error found by rpmlint,
makedumpfile.x86_64: E: explicit-lib-dependency zlib
You must let rpm find the library dependencies by itself. Do not put unneeded
explicit Requires: tags.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
man files doesn't preserve line breaks. Construct a list to list the
cases where additional memory will be reserved.
Fixes: c752cbb2 ("Explain the auto_reset_crashkernel option in more details")
Reported-by: Jie Li <jieli@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Currently, the other options like "raw <partition>" become child items
of the auto_reset_crashkernel option,
auto_reset_crashkernel <yes|no>
...
raw <partition>
...
nfs <nfs mount>
...
...
Fix it by ending the auto_reset_crashkernel with ".RE".
Fixes: 73ced7f4 ("introduce the auto_reset_crashkernel option to kdump.conf")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit b3620b0dbc3e0fb9a92ab5faf34ac3b4e7bb7bd9
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Apr 9 09:25:48 2024 +0800
makedumpfile: remove explicit-lib-dependency zlib
Fix the following error found by rpmlint,
makedumpfile.x86_64: E: explicit-lib-dependency zlib
You must let rpm find the library dependencies by itself. Do not put unneeded
explicit Requires: tags.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit 2ed88633ade0f1e5523d8097d96df3fde1287ea7
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Apr 9 09:04:11 2024 +0800
kexec-tools: use make_install
use consistent build flags %make_install to have the benefits like
enabling parallel building automatically.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit a5c17afe7e871f7a2593d04b97e8e77fb434642c
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Jan 12 20:00:53 2024 +0800
Fix potential-bashisms in monitor_dd_progress
As suggested by Carl [1],
> /usr/lib/dracut/modules.d/99kdumpbase/monitor_dd_progress has some
> inconsistencies with other scripts in that directory. It is missing the
> .sh extension and is not executable. The latter is resulting in an
> rpmlint error.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239566#c2
Suggested-by: Carl George <carl@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit fe372afddde500249cd02fc3f152a164cfed321f
Author: Coiby Xu <coxu@redhat.com>
Date: Fri Mar 1 17:37:24 2024 +0800
Upstream kdump-utils
This patch upstreams the to-be-split-out kdump-utils to
https://github.com/rhkdump/kdump-utils. And it also simplify the .spec
file by putting the installation logic into a Makefile.
Cc: Philipp Rudo <prudo@redhat.com>
Cc: Carl George <carl@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit d2b6547f55ca960463de6dca6791db3c7d10ec06
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Feb 8 17:06:12 2024 +0100
Supported targets: Merge hypervisor sections
The supported targets list has two separate hypervisor sections. Merge
them into one.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit b6a066db5368d53a5e460ca1c948c0b43d66b1ef
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Feb 8 17:06:11 2024 +0100
Supported targets: Import from CentOS Stream 9
In CentOS Stream a list of supported targets is maintained. Where
"supported" means that these targets are tested regularly. Even though
there are some small differences between CentOS Stream and Fedora when
it comes to provided/supported packages and kernel configs, having this
list in Fedora as well makes sense. As it provides a entry point for
users to find out if a given setup is meant to work or not. Thus include
the supported-kdump-targets.txt from CentOS Stream 9 [1] into Fedora.
[1] 0a09d12d89/supported-kdump-targets.txt
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit c7683d8aabdbbbaaefdeee4a3e6c35482dca48c7
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Feb 29 11:18:00 2024 +0800
Don't disrupt current kdump users
Majority of current kexec-tools users have installed kexec-tools out of
the need for the kdump feature. To ensure a smooth transition, add
kdump-utils as weak dependency. If users only want to use kexec-tools,
they can uninstall kdump-utils.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Carl George <carl@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-29044
Upstream: Fedora
Conflict: None
commit 5fe098fec8eb19a942a608f19324601066c0467d
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Feb 29 11:05:14 2024 +0800
Don't systemctl preset kdump when updating kexec-tools to kdump-utils
When an old version of kexec-tools gets replaced by kdump-utils,
"%systemd_post" will be executed in the post scriptlet which has the
purpose to "systemctl preset kdump" for freshly installed kexec-tools.
But in the case of kdump-utils replacing kexec-tools, it is not needed
so skip this case.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Currently kdump-dep-generator will source kdump-lib.sh. Notice
kdump-dep-generator have #!/bin/sh so it should be POSIX, but
kdump-lib.sh is a non-POSIX bash script. When Bash is configured to run
in POSIX mode for #!/bin/sh scripts, it will fail with:
/usr/lib/kdump/kdump-lib.sh: line 1042: syntax error near unexpected token `<'
/usr/lib/kdump/kdump-lib.sh: line 1042: ` done < <( _crashkernel_parse "$ck")'
This subshell call is easy to convert into a pipe but we should just
source kdump-lib-initramfs.sh here, the only thing kdump-dep-generator
needs is is_ssh_dump_target which is in kdump-lib-initramfs.sh, also
prevents further POSIX violations.
Signed-off-by: Kairui Song <kasong@tencent.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2242185
grep (3.8) warnings when running the unit tests or running
"kdumpctl reset-crashkernel" on >= F39,
# unit tests
Examples:
1) kdumpctl _find_kernel_path_by_release() returns the kernel path for the given release
When call _find_kernel_path_by_release vmlinuz-6.2.11-200.fc37.x86_64
1.1) WARNING: There was output to stderr but not found expectation
stderr: grep: warning: stray \ before /
# spec/kdumpctl_general_spec.sh:169-172
# kdumpctl reset-crashkernel
grep: warning: stray \ before /
kdump: Updated crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-6.6.8-200.fc39.x86_64. Please reboot the system for the change to take effect.
This warning can be reproduced by
echo 'kernel="/boot/vmlinuz-6.4.6-200.fc38.x86_64"' | grep -E "^kernel=.*$_release(\/\w+)?\"$"
This patch removes unneeded backslash. It also adds a test for
systemd-boot path. And for simplification, Parameters:dynamic is now
used to generate test data dynamically.
Fixes: 8af05dc4 ("kdumpctl: Add support for systemd-boot paths")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
