Resolves: https://issues.redhat.com/browse/RHEL-138697
Conflict: None
commit 48dd252bf8cc75c696d5d7e9a07efc838e3aad66
Author: Philipp Rudo <prudo@redhat.com>
Date: Tue Sep 2 13:28:32 2025 +0200
spec: drop dependency for binutils
The binutils were added as dependency to support UKIs. With the main
part of the UKI support been moved to kexec-tools only one spot remains
in prepare_kdump_bootinfo where they are used. Refractor
prepare_kdump_bootinfo to get rid of the dependency.
This slightly changes the behavior for UKIs. In particular the kdump
initrd is moved from /boot to /var/lib/kdump.
While at it also simplify the logic in prepare_kdump_bootinfo as it is
unnecessarily complex and can lead to weird corner cases. For example if
the default initrd is located at /boot/$machine_id/$kernel_version/initrd
and the directory is not writable, then the kdump initrd would be stored
at /var/lib/kdump/initrdkdump without any information about the kernel
version. This can lead to all sorts of problems when multiple kernel
versions are installed. Thus always use
initramfs-${kernel_version}kdump.img when the initrd is stored at
/var/lib/kdump. Update 60-kdump.install accordingly.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: RHEL-105198
Upstream: kdump-utils
Conflict: yes, the gen-kdump-sysconfig.sh was refactored, so we need
to manually modify the KDUMP_COMMANDLINE_APPEND= options.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-137945
Upstream: kdump-utils
Conflict: None
commit b43908c20f5a028c60b0096006a26a6e52a01279
Author: Philipp Rudo <prudo@redhat.com>
Date: Wed Jan 14 15:54:25 2026 +0100
kdump-lib-initramfs: Fix performance regression in kdump_get_conf_val
Rewriting kdump_get_conf_val in Bash lead to a massive performance
regression. On my test system starting the kdump service took
$ time kdumpctl start
real 0m13.134s
user 0m8.828s
sys 0m7.450s
which is ~20 times slower compared to kdump-utils-1.0.59-1.fc44 with
$ time kdumpctl start
real 0m0.641s
user 0m0.208s
sys 0m0.538s
Looking at the traces shows that this is caused because Bash now has to
handle the whole kdump.conf, including the extensive comment at the
start, every time kdump_get_conf_val is called. This is done multiple
times when starting the kdump service and is often cloaked by other
functions, e.g. is_ssh_dump_target() or get_save_path().
To fix the issue remove comments and empty lines in a regex again so
that the Bash code only has to handle valid config entries. With this
change alone the performance is almost as good as the original version
with
$ time kdumpctl start
real 0m0.780s
user 0m0.330s
sys 0m0.604s
In the long run it would make sense to also reduce the number of calls
to kdump_get_conf_val.
This patch also fixes the issue that subsequent blanks are replaced by a
single space. Usually this is not an issue but there are corner cases,
e.g. in printf-like format strings passed as an argument, where the new
behaviour is undesirable.
Fixes: d81109c ("kdump-lib-initramfs: rewrite kdump_get_conf_val")
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-128042
Upstream: kdump-utils
Conflict: None
commit e22ca9248de44a71cdd51e0630456e53fe2554c1
Author: Baoquan He <bhe@redhat.com>
Date: Thu Dec 11 16:56:15 2025 +0800
kexec-kdump-howto.txt: update paragraphs related to disable_cpu_apicid
Long before, to support multiple CPUs on x86_64, 'disable_cpu_apicid='
was introduced. It's to avoid the case when nr_cpus=xx is added, while
crashed cpu is not BSP cpu, then the crashed CPU will send INIT to BSP
cpu in kdump kernel. While the BSP cpu being reinitialized when
receiving INIT in the 2nd time will cause kdump kernel collapsing.
Now, in kernel commit 5c5682b9f87a ("x86/cpu: Detect real BSP on crash
kernels"), the requirement of disable_cpu_apicid has been taken off by
detecting real BSP on crashed kernel and not sending INIT to it.
Now testing passed on x86_64 system w/ or w/o disable_cpu_apicid and the
kernel message can be seen as below.
===============
CPU topo: Boot CPU APIC ID not the first enumerated APIC ID: 1e != 0
CPU topo: Crash kernel detected. Disabling real BSP to prevent machine INIT
===============
However, sometime older kernels which don't contain commit 5c5682b9f87a
are still loaded in newer OS. To keep good back compatibility, still
adding disable_cpu_apicid to capture kernel. It's not harmful on newer
kernels containing commit 5c5682b9f87a.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-77197
Upstream: kdump-utils
Conflict: manually apply [Patch 2/2]
The back port contains two upstream patches:
0d38985 powerpc: consider CPU count while calculating crashkernel value
4f7970e powerpc: Set nr_cpus=16 for kdump kernel
to implement:
Configure the kdump kernel with nr_cpus=16 to enable multi-threading in
the makedumpfile core collector, allowing faster dump collection.
The commit 4f7970e (powerpc: Set nr_cpus=16 for kdump kernel) can not be
applied directly due to the big re-fractor of gen-kdump-sysconfig.sh.
But the change is simple, just increase nr_cpus=1 to nr_cpus=16, so I
modify it manually.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-75537
Upstream: kdump-utils
Conflict: None
Back porting a series patches in kdump-utils to Fix the --num-threads
and -E option issules
9a51c4b kdump.sh: Skip num-threads when -E and -F option is present
23bbb11 kdump.sh: Centralize the num-threads sub-option handling
837f1c9 kdump.sh: Centralize the -F suboption handling
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-127439
Conflict: None
commit 2de96daa10a7e30a7b1a6bb4331e831a8f794c4a
Author: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
Date: Thu Oct 30 00:59:17 2025 -0700
Add persisent device if FIPS is enabled
mkdumprd has a code to add a disk to kdump initramfs, in case FIPS is
enabled and /boot is on a separate partition. This code used to work,
since dracut was not force checking that added disk is in fact
available. Since dracut commit c79fc8f dracut in fact checks for added
device, and since disk name could have been changed between live system
and kdump initramfs, kdump can fail.
To resolve this problem we re-use get_persistent_dev from
dracut-functions.sh which will be sourced by mkdrumpd to get persistent
device name.
Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>
Signed-off-by: Harshvardhan Jha <harshvardhan.j.jha@oracle.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-124989
Upstream: kdump-utils
Conflict: none
Fixes three situations where kdump can fail by,
- adding "KeyringMode=shared" to the kdump.service unit file so it can access the LUKS volume keys
- fixing the SELinux label of crypttab file
- allowing users to use "sudo kdumpctl"
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: RHEL-103425
Upstream: kdump-utils
Conflict: Need manually edit patch 0006.
QA found a regression on powerpc arch when verifying disabling kfence.
And further tests shows only powerpc has the issue, all other
architectures all works well with disabling kfence by pass in the
parameter 'kfence.sample_interval=0' to kdump kernel.
Hence only revert the change on powerpc for now, will check what's going
on on powerpc later.
commit b061a48965476e5b2e6be59686783c85d0f14b5c
Author: Baoquan He <bhe@redhat.com>
Date: Mon Aug 11 17:02:46 2025 +0800
sysconfig: disable kfence in kdump kernel
In commit ddb0bab1f7e1, I mistakenly added the 'kfence.sample_interval=0'
into KDUMP_COMMANDLINE_APPEND which is taken as default parameters added
into kdump kernel. The KDUMP_COMMANDLINE_APPEND value is for unsupported
architecuture. We should append wanted kernel parameter to each
supported architecture in "update_param KDUMP_COMMANDLINE_APPEND" place.
Fix it now.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: RHEL-103425
Upstream: kdump-utils
Conflict: None
commit b061a48965476e5b2e6be59686783c85d0f14b5c
Author: Baoquan He <bhe@redhat.com>
Date: Mon Aug 11 17:02:46 2025 +0800
sysconfig: disable kfence in kdump kernel
In commit ddb0bab1f7e1, I mistakenly added the 'kfence.sample_interval=0'
into KDUMP_COMMANDLINE_APPEND which is taken as default parameters added
into kdump kernel. The KDUMP_COMMANDLINE_APPEND value is for unsupported
architecuture. We should append wanted kernel parameter to each
supported architecture in "update_param KDUMP_COMMANDLINE_APPEND" place.
Fix it now.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-24543
Upstream: kdump-utils
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Wed Jan 8 12:11:10 2025 +0530
powerpc: fix early exit from udev on hotplug event for fadump
Sysfs /sys/kernel/fadump/hotplug_ready contains 1 if hotplug is
supported by fadump.
Now to exit early the RUN command should grep 0 from
/sys/kernel/fadump/hotplug_ready instead of 1.
Fix it by updating RUN command.
Fixes: b4e3d3724cf3 ("fadump/udev: do not re-register fadump if kernel hotplug ready")
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-63071
Conflict: None
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit c196f5b9ebacbd60ef61ab20bfe399065e2de96b
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Oct 23 10:48:05 2024 +0800
Set up crashkernel value for osbuild
Resolves: https://issues.redhat.com/browse/RHEL-63071
Currently the cloud image built by osbuild doesn't have crashkernel set
up. Since kdumpctl will set up crashkernel only when kdump.service is
enabled, it will fail if it's done in the following order
-> kernel's %posttrans scriptlet
-> 92-crashkernel.install
-> kdumpctl _reset-crashkernel-for-installed_kernel
-> kdump-utils' %post scriptlet enables kdump.serivce
This patch now let "systemd preset" kdump.service in the %post scriptlet
instead. So when the kernel's %posttrans scriptlet is running, kdump.service
is already enabled. %posttrans runs after all packages' %post
scriptlets have been executed [1], so now crashkernel is set up in the
following order,
kdump-utils' post scriptlet which "systemd preset" kdump.service
-> kernel's posttrans RPM scriptlet
-> 92-crashkernel.install
-> kdumpctl _reset-crashkernel-for-installed_kernel
And we expect users have now upgraded to kdump-utils so there
is no need for the solution introduced in commit 5fe098fe.
Note an agreement has been reached between kdump-utils and osbuild in
https://bugzilla.redhat.com/show_bug.cgi?id=2024976 that kdump-utils
will be responsible for setting up the crashkernel kernel parameter. And
since kdump-utils will only set up crashkernel when kdump.service is
enabled, we need to make sure kdump.service is enabled in the systemd
preset.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#ordering
Fixes: 5fe098fe ("Don't systemctl preset kdump when updating kexec-tools to kdump-utils")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Related: RHEL-29941
Upstream: Fedora
Conflict: None
commit f6e00948aba7c31f722af79ed72c4020868dcad7
Author: Tao Liu <ltao@redhat.com>
Date: Fri Oct 18 21:45:03 2024 +1300
Return the correct exit code of rebuild initrd
Resolves: https://issues.redhat.com/browse/RHEL-63047
The exit code of rebuild_initrd() should be either of
rebuild_kdump/fadump_initrd(), rather than set_vmcore_creation_status(),
otherwise it will cause a regression when rebuild initrd fails.
Fixes: 88525ebf ("Introduce vmcore creation notification to kdump")
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Resolves: RHEL-50942
Upstream: https://github.com/rhkdump/kdump-utils.git
Conflict: Dropped hunks concerning OVS bridge support in patch 3 and 5
due to missing 224d310 ("Support setting up Open vSwitch
(Ovs) Bridge network")
Also contains upstream commit
commit 2970176d9e9b7b6a1191a9ee54423d2f1c56fbaf
Author: Philipp Rudo <prudo@redhat.com>
Date: Tue Sep 24 10:39:32 2024 +0200
spec: fix patching of files in subdirectories
With 23df04b ("dracut: create sub-directories for dracut modules") the
dracut modules were moved to subdirectories. This causes problems when
someone wants to include a patch to the spec file to change one of the
files in those subdirectories. Reason is that '%autosetup' in the spec
file calls 'patch' per default. 'patch' however, will strip all
directories when it is called without option -p. Which means that it
will search the file in the root directory and then fail because it
cannot find it. Thus add option -p1 to '%autosetup' which will be passed
on to 'patch'. Choose -p1 as that will work with the most common patch
creation tools like git and packit.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
