Resolves: https://issues.redhat.com/browse/RHEL-127453
Upstream: kdump-utils
Conflict: None
commit e22ca9248de44a71cdd51e0630456e53fe2554c1 (HEAD -> main)
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: RHEL-115464
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: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-115464
Upstream: kdump-utils
Conflict: None
commit d81109cf9291250b42434fc51798c93b613c4ee2
Author: Philipp Rudo <prudo@redhat.com>
Date: Thu Nov 6 15:07:42 2025 +0100
kdump-lib-initramfs: rewrite kdump_get_conf_val
Previously, kdump_get_conf_val() relied on a "magic" regular
expression to parse kdump.conf, making maintenance and
extension difficult. This patch rewrites the parsing logic
to be more human-readable.
The '\|' needs to be changed to a single '|' because after
the rewrite we will use another tool to parse the options to
find.
Furthermore, kdump_read_conf() has been refactored to invoke
kdump_get_conf_val(), as their logic is functionally identical.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-130520
Upstream: kdump-utils
Conflict: yes, rhel-9 doesn't have gen-kdump-sysconfig.sh, so
we need to manually modify the kdump.sysconfig[.*].
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-77215
Upstream: kdump-utils
Conflict: manually apply
commit 4f7970eefa6cba5d7cebd739718fb947a3fedbad (HEAD -> main, origin/main, origin/HEAD)
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Thu Dec 4 13:51:21 2025 +0530
powerpc: Set nr_cpus=16 for kdump kernel
Configure the kdump kernel with nr_cpus=16 to enable multi-threading in
the makedumpfile core collector, allowing faster dump collection.
Commit d428557fc2b59 ("Use all available CPUs to collect dump")
introduced multi-threading support in the core collector.
There are two reasons for choosing nr_cpus=16:
- Multiple experiments show that optimal performance is achieved when
nr_cpus is between 16 and 30. The graph in commit d428557fc2b59
supports this.
- nr_cpus=16 is already used for the fadump kernel, so using the same
value for kdump to maintain consistency.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Since there is no gen-kdump-sysconfig.sh in RHEL-9 kexec-tools, and the
patch just change the nr_cpus from 1 to 16, so apply it manually.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-77215
Upstream: kdump-utils
Conflict: manually apply
commit 0d389855086ca3f1de8421c540ade79d403e1abd
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date: Sat Aug 23 22:29:10 2025 +0530
powerpc: consider CPU count while calculating crashkernel value
The next patch in the series adds more CPUs to the capture kernel,
which increases the memory requirement for the capture kernel.
Experiments show that powerpc needs 1 MB of additional memory for every
CPU added.
Therefore, while calculating the crashkernel size, make sure to include
an additional 1 MB for every CPU configured in the capture kernel.
The changes are implemented in such a way that if the user changes the
nr_cpus value in the kdump configuration, the script will adapt
accordingly.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Since the find_nr_cpus() function can not get the bash variable
$FADUMP_COMMANDLINE_APPEND and $KDUMP_COMMANDLINE_APPEND in RHEL-9,
extract them from /etc/sysconfig/kdump directly
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-77215
Upstream: kdump-utils
Conflict: manually apply
This patch integrates the sets of commits in kdump-utils upstream
d428557 Use all available CPUs to collect dump
and
837f1c9 kdump.sh: Centralize the -F suboption handling
23bbb11 kdump.sh: Centralize the num-threads sub-option handling
9a51c4b kdump.sh: Skip num-threads when -E and -F option is present
The latter three commits aims to fix the bug introduced by the first
one. As a result, CORE_COLLECTOR logic is centralized in
get_kdump_confs().
The CORE_COLLECTOR logic in dump_raw() is kept untouched.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-124989
Conflict: Upstream has slightly different format
commit c08d151016ab4d62addc2ec8089a756c0d89d583
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Nov 5 10:14:28 2025 +0800
Allow "sudo kdumpctl" for LUKS dump target
Some users may run kdumcptl after "sudo su" or use "sudo kdumpctl". And
kdump will fail,
# sudo kdumcptl restart
request_key: Required key not available
keyctl_set_timeout: Invalid argument
kexec_file_load failed: Required key not available
kdump: kexec: failed to load kdump kernel
This happens because the LUKS keys is can only be searched (keyctl request)
by the process but not by the user and sudo process inherits the session
keyring (@s) of the original user (test in the following example),
[test@localhost ~]$ sudo keyctl add user testkey testdata @u
711801750
[test@localhost ~]$ sudo grep testkey /proc/keys
2a6d3b96 I--Q--- 1 perm 3f010000 0 0 user testkey: 8
[test@localhost ~]$ sudo keyctl show 711801750
Keyring
Unable to dump key: Permission denied
The permission "3f010000" means the process has all the permissions but
user only has the view permission i.e. "sudo keyctl show/list @u" will list
all the keys but "sudo keyctl show KEY_ID" won't work.
Automatically use "sudo -i" which will use the session keyring (@s) of
the root to support "sudo kdumpctl". Note "sudo -i kexec" is also
needed in order for the process to read the keys in the kernel space.
Reported-by: Li Tian <litian@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-124989
Conflict: None
commit fe2891da11ce088ce14f7b2913bd3123b8f7c727
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Nov 3 09:55:07 2025 +0800
Restore SELinux label of crypttab file
Currently, for LUKS encrypted dump target, the system can have booting
problem with relatively older selinux-policy e.g. 40.13.21-1.el10 or
38.1.65-1.el9.noarch,
[*** ] Job dev-disk-by\x2duuid-55f4fce1\x2…tart running (1min 21s / 1min 30s)
...
[ TIME ] Timed out waiting for device dev-d…f4fce1-cd7f-43a6-8729-f0edcd048d73.
[DEPEND] Dependency failed for luks.mount - /luks.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.
[DEPEND] Dependency failed for selinux-auto…k the need to relabel after reboot.
...
[FAILED] Failed to start kdump.service - Crash recovery kernel arming.
See 'systemctl status kdump.service' for details.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
[ 4.375155] systemd-cryptsetup-generator[690]: Failed to open /etc/crypttab: Permission denied
[ 4.376555] audit: type=1400 audit(1762134586.538:4): avc: denied { open } for pid=690 comm="systemd-cryptse" path="/etc/crypttab" dev="vda3" ino=16916076 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
This happens because the updated crypttab file for LUKS dump target has
incorrect SELinux label as it's created by mktemp. As a result, SELinux
will prevent systemd-cryptsetup-generator from accessing crypttab and
the encrypted dump target can fail to mount,
# ls -Z /etc/crypttab
unconfined_u:object_r:user_tmp_t:s0 /etc/crypttab
Restore the SELinux label of crypttab to fix this issue,
# ls -Z /etc/crypttab
unconfined_u:object_r:etc_t:s0 /etc/crypttab
Although this issue no longer happens to newer selinux-policy like
policy-42.1.9-1.el10.noarch, it's better to restore the SELinux label of
crypttab file.
Fixes: 4e0d4cae ("Add kdumpctl setup-crypttab subcommand")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-124989
Conflict: Upstream has PrivateTmp=yes removed from kdump.service.
commit 280d4b6237b1f3bcad9cfba5e51b4f55d8b718c9
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Nov 3 09:26:21 2025 +0800
Allow kdump.service to access LUKS volume keys
Resoles: https://issues.redhat.com/browse/RHEL-124989
Currently kdump.service fails to read LUKS volume keys,
kdumpctl[4001]: Nothing to read on input.
kdumpctl[3624]: kdump: Error: Could not unlock the LUKS device.
kdumpctl[3624]: kdump: Failed to get logon key kdump-cryptsetup:vk-eed43d84-d79f-4b6d-8159-c859bb1915ee. Run 'kdumpctl restart' manually to start kdump.
kdumpctl[3624]: kdump: kexec: failed to prepare for a LUKS target
kdumpctl[3624]: kdump: Starting kdump: [FAILED]
systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: kdump.service: Failed with result 'exit-code'.
systemd[1]: Failed to start kdump.service - Crash recovery kernel arming.
Use KeyringMode=shared to link the user keyring of root to the session
keyring so kdump.service can access the LUKS volume keys stored in
root's user keyring. For more details on KeyringMode, man systemd.exec.
Fixes: d9677e17 ("Support dumping to a LUKS-encrypted target")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit 8e779ea2d805124a2e7067efe3aa7d231c2c5cf3
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Sep 24 10:35:08 2025 +0800
Wait for LUKS configfs API to be ready
Partially resolves: https://github.com/rhkdump/kdump-utils/issues/109
On Fedora 42, LUKS-encrypted volumes fail to be unlocked in the crash
kernel because somehow the volume keys are yet to be available. Wait for
the API to be ready before triggering restoring volume keys so that
later the keys will be available for cryptsetup to unlock the volumes.
Fixes: 5cbd7ddd ("Support dumping to a LUKS-encrypted target")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit 22bb0872c887df5c720572a0bcb1378c03b9e37a
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Sep 18 14:20:44 2025 +0800
Change LUKS volume key prefix to kdump-cryptsetup:vk-
Use systemd-cryptsetup:vk- is a bit misleading because we don't use
systemd to unlock LUKS volumes. Using kdump-cryptsetup:vk- makes more
sense and it can also help reliably remove unused volume keys.
Fixes: 5cbd7ddd ("Support dumping to a LUKS-encrypted target")
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit d7f96424b6dd646803191996a3000af361246f15
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Sep 17 16:03:22 2025 +0800
Remove unused LUKS volume keys from keyring
Currently the LUKS volume keys created via the link-volume-key option
won't expire. Although the logon key can never leave the kernel and can
only be used by root, it's safer to remove them from keyring if they are
no longer used by kdump.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Assisted-by: Claude Code
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit 4094199402119ad4f97d073b40a35d890754dc8e
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Sep 17 08:57:30 2025 +0800
Limit LUKS support to x86_64
The LUKS support depends on the kernel but only x86_64 kernel part is
ready. So limit this feature to x86_64.
And don't fail kdump.service even when x86_64 kernel doesn't have
/sys/kernel/config/crash_dm_crypt_keys in case users have already
manually made dumping to encrypted target work.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit ddd33c8d0f552cb46097aeade86178266637aa05
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Sep 16 16:22:18 2025 +0800
Add kdumpctl setup-crypttab subcommand
Resolves: https://issues.redhat.com/browse/RHEL-29037
Relates: https://issues.redhat.com/browse/RHEL-29039
This subcommand is to add the 'link-volume-key' option to /etc/crypttab
so the volume keys can be passed to the crash kernel to unlock
LUKS-encrypted device automatically.
This API will be also be called by kdump-anaconda-addon to set up
/etc/crypttab on installation.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Assisted-by: Google Gemini
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit 9980a416759c58e67a206525ddb82d581932c3ad
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Sep 16 11:52:00 2025 +0800
Return LUKS devices in the form of UUIDs directly
So the callers of kdump_check_crypt_targets don't need to convert the
result into UUIDs.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: .github/workflows/main.yml only exists upstream
commit e25009be073adcf00885d42c5ae3856b49ce7188
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Jul 23 13:32:42 2025 +0800
Fix SC2181 issues in kdump-udev-throttler
Fix the issues found by shellcheck,
In kdump-udev-throttler line 30:
if [ $? -ne 0 ]; then
^-- SC2181 (style): Check exit code directly with e.g. 'if ! mycmd;', not indirectly with $?.
In kdump-udev-throttler line 37:
if [ $? -ne 0 ]; then
^-- SC2181 (style): Check exit code directly with e.g. 'if ! mycmd;', not indirectly with $?.
Also add kdump-udev-throttler to shellcheck list for Github Action.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit dd8d34c4baf9878fa7ff2e5f6807cfc93ae40e0b
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Jun 4 15:51:47 2024 +0800
LUKS: make /usr writable
Since systemd commit ffc1ec73b3 ("pid1: add ProtectSystem= as system-wide
configuration, and default it to true in the initrd"), systemd makes
/usr read-only by default and it will cause dracut to not wait for the
LUKS-encrypted devices to be unlocked,
dracut-cmdline[296]: mv: inter-device move failed: '/tmp/294-daemon-reload.sh' to '/lib/dracut/hooks/initqueue/daemon-reload.sh'; unable to remove target: Read-only file syste
dracut-cmdline[294]: /sbin/initqueue: line 71: /lib/dracut/hooks/initqueue/work: Read-only file system
dracut-cmdline[221]: /lib/dracut-dev-lib.sh: line 118: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fmyvg\x2fluks_lv.sh: Read-only file system
dracut-cmdline[221]: /lib/dracut-dev-lib.sh: line 103: /lib/dracut/hooks/emergency/80-\x2fdev\x2fmyvg\x2fluks_lv.sh: Read-only file system
Fix the above issue by making /usr writable.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit 9de617170ad9bac97db53a2bf031e895fb482dba
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Jun 25 11:26:53 2025 +0800
Address CPU/memory hot plugging for kdump LUKS support
We can reuse LUKS volume keys when there is CPU/memory hot plugging by
writing 1 to /sys/kernel/config/crash_dm_crypt_keys/resue to reuse keys
already saved to kdump reserved memory.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit 0d39f4fd626fea070d9b8af624feacd89938e7db
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Jun 18 09:16:26 2025 +0800
Use cryptsetup --link-vk-to-keyring to save volume keys
cryptsetup open --link-vk-to-keyring (man cryptsetup-open) will link
volume key to specified keyring after successfully unlocking the volume.
Use this feature to save key to @u::%logon:cryptsetup:$UUID to support
the following cases
- volume is unlocked automatically say using TPM-sealed key
- ask user to input passphrase to unlock the volume
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: Manually resolve conflict in kdumpctl and mkdumprd.
Install 99kdumpbase/kexec-crypt-setup.sh in kexec-tools.spec.
commit 5cbd7ddd2e164d13f2cd992373df89912fe6e79f
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Aug 7 15:19:36 2023 +0800
Support dumping to a LUKS-encrypted target
Based on the new kernel feature that dm-crypt keys can persist for the
kdump kernel [1][2], this patch which is adapted from [3]
1) ask the 1st kernel to save a copy of the LUKS volume keys
2) ask the kdump kernel to add the copy of the LUKS volume keys to
specified keyring and then use --volume-key-keyring the unlock the
LUKS device.
Users need to set up the link-volume-key option in /etc/crypttab (man
crypttab) so kdumpctl can read the key from @u::%logon:cryptsetup:UUID
and instruct the kernel to save it to kdump-reserved memory.
[1] https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kdump/kdump.rst#write-the-dump-file-to-encrypted-disk-volume
[2] 180cf31af7
[3] https://lists.fedorahosted.org/archives/list/kexec@lists.fedoraproject.org/message/Y3KUSJQPN3JHUUC2FPIK7H4HTSX2TUCX/
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-104940
Conflict: None
commit f2c18c4934777cf55a5ea9359c8423adb8f1388b
Author: Coiby Xu <coxu@redhat.com>
Date: Mon Mar 4 17:18:46 2024 +0800
Add a helper function to get uuid by MAJ:MIN
This helper function will be used for kdump LUKS support.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: RHEL-49555
Upstream: rhkdump/kdump-utils
Conflicts: Slightly changed warning message to reference RHEL11 rather
than "the future".
commit ca6da9b484e7995d8f3ee7e74dd871ee8919e409
Author: Philipp Rudo <prudo@redhat.com>
Date: Wed Oct 2 15:26:34 2024 +0200
kdumpctl: deprecate --reboot for reset-creashkernel
The --reboot option for reset-crashkernel causes quite some confusion.
Especially, there are different expectations when --reboot shall reboot
the system. The current code only reboots the system when the
crashkernel parameter was updated during this run. But there are other
opinions, that --reboot shall also reboot the system if a previous run
of `kdumpctl reset-crashkernel` updated the crashkernel parameter and no
reboot occurred yet. While possible this would add extra complexity to
the code. Neither the confusion nor the extra complexity are justified,
given that --reboot only replaces a single additional command for the
user.
Thus deprecate the --reboot option so it can be removed later on.
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-103429
Upstream: rhkdump/kdump-utils
Conflict: Need manually edit kdump.sysconfig files
commit ddb0bab1f7e1e43a802993aadad03f85a3c045a9
Author: Baoquan He <bhe@redhat.com>
Date: Wed Jun 25 23:30:24 2025 +0800
sysconfig: disable kfence in kdump kernel
In the current fedora and RHEL, below config items related to kfence
feature are set by default:
===
CONFIG_HAVE_ARCH_KFENCE=y
CONFIG_KFENCE=y
CONFIG_KFENCE_SAMPLE_INTERVAL=100
CONFIG_KFENCE_NUM_OBJECTS=255
CONFIG_KFENCE_STRESS_TEST_FAULTS=0
CONFIG_KFENCE_KUNIT_TEST=m
===
With them set, on x86_64, it will cost 2M extra memory used for kfence when
page size if 4K; while on arm64 with 64K page size, it will cost 32M extra
memory. This doesn't take memory cost of initializing and running kfence
itself into account, here only saying the kfence objects and guarded
pages. However, it doesn't make any sense to have kfence in a kdump
kernel. Hence, disable kfence in kdump kernel to save crashkernel
memory.
Signed-off-by: Baoquan He <bhe@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-33413
Upstream: rhkdump/kdump-utils
Conflict: Miss upstream patch 0d90d580 ("dracut-module-setup:
consolidate s390 network device config (#1937048)") and
upstream switches to a different way of supporting OVS.
commit 0678138331f6de43aaee0b7fbacf8adb38e73ff0
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Jul 17 17:25:38 2025 +0800
Support dumping to NVMe/TCP configured using NVMe Boot Firmware Table
Resolves: https://issues.redhat.com/browse/RHEL-100907
Resolves: https://issues.redhat.com/browse/RHEL-33413
The dracut nvmf module can take care of all things. It can parse ACPI
NVMe Boot Firmware Table (NBFT) tables, generate NetworkManager profiles
and discover and connect all subsystems.
Currently, the dracut kdump module will try to bring up the same network
connections as in 1st kernel. But a different set of NVMe connections
and active network interfaces will be used for the case of multipathing.
So the dracut kdump module should let dracut nvmf module do everything.
Note connecting everything and having network redundancy may require extra
memory and the default crashkernel may not work. We'll document this
issue and ask users to increase the crashkernel.
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-79413
Upstream: kdump-utils
Conflict: Yes, upstream use has_command to check if a command is
avaiable but that function is not backported to RHEL-9.
commit f758448cc7f29a24d8f5ddd7418dc9dd2fc3fd35
Author: Lichen Liu <llc123456a@gmail.com>
Date: Thu May 8 17:22:17 2025 +0800
kdumpctl: check and generate /etc/vconsole.conf
For VMs created from KVM Guest images, /etc/vconsole.conf is missing
so that dracut module 10i18n will install all kbd files.
```
# du -sh initramfs/squash/usr/lib/kbd/*
438K initramfs/squash/usr/lib/kbd/consolefonts
340K initramfs/squash/usr/lib/kbd/consoletrans
2.1M initramfs/squash/usr/lib/kbd/keymaps
232K initramfs/squash/usr/lib/kbd/unimaps
```
From man 5 vconsole.conf, KEYMAP= defaults to "us" if not set. We can
safely generate a /etc/vconsole.conf with KEYMAP=us by localectl to
reduce the initramfs size.
```
# du -sh initramfs/squash/usr/lib/kbd/*
11K initramfs/squash/usr/lib/kbd/consolefonts
121K initramfs/squash/usr/lib/kbd/keymaps
```
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-91274
Upstream: rhel-only
In the previous commit (3053d959), we adjusted the default value of
crashkernel, this action changed the default behavior of RHEL-9.
Systems with less than 2G memory will not be able to start kdump by
default. This is a breaking change on small VMs that only use local
dump.
In order to keep compatibility, reserve crashkernel for systems with
1G-2G memory on RHEL-9.
Fixes: 3053d959 ("kdump-lib.sh: Adjust default crashkernel reservation for x86_64 and s390x")
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Upstream: kdump-utils
Resolves: RHEL-19064
commit 0fc7e887a20a9e8536411750b64f0f8a1315f01b
Author: Lichen Liu <lichliu@redhat.com>
Date: Tue Mar 25 14:05:49 2025 +0800
99-kdump.conf: Omit clevis related dracut modules
The clevis related dracut modules are unconditionly included into the
kdump initramfs after installing clevis-dracut package.
Normally, we don't use clevis in the kdump process, but it will increase
the size of kdump initramfs by about 11M, which is a relatively large
overhead for kdump. Omit them by default can reduce the memory required
by kdump and avoid the OOM issue.
If the user really needs to use it, it can also be added to kdump
initramfs by using dracut_args --force-add in /etc/kdump.conf.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-83645
Upstream: kdump-utils
commit 18fc5b7e7b89ee3caba04ce18bf32036aa19da6e
Author: Lichen Liu <lichliu@redhat.com>
Date: Fri Mar 7 12:22:05 2025 +0800
kdump-lib.sh: rounded up the total_mem to 128M in get_system_size
The kernel code to calculate reserving size rounded up the total_mem because
usually the memblock usable mem size is smaller than the physical dimm memory
size:
total_mem = roundup(total_mem, SZ_128M);
This patch is aimed to align with the kernel's behavior. A machine showing
4000MB of total memory will be treated as having 4G instead of 3G memory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2306493
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: RHEL-83645
Upstream: kdump-utils
commit fe18f933baed9eaa18e0c2427aaca4640d8f6fa1
Author: Lichen Liu <lichliu@redhat.com>
Date: Thu Mar 6 10:21:43 2025 +0800
kdump-lib.sh: Adjust default crashkernel reservation for x86_64 and s390x
With new kernel features being added, both the kernel itself and the initramfs
have gradually increased in size.
Previously, we used squashfs to package and reduce the initramfs size. However,
since squashfs will be replaced by erofs, we have transitioned to erofs. The
compression algorithms supported by erofs differ from those used in squashfs.
In previous squashfs implementations, we used zstd compression, but in RHEL-10,
the erofs implementation in the kernel does not yet support zstd decompression.
As a result, we had to switch to other compression algorithms, leading to
changes in the initramfs size.
In some scenarios, the previous 192M crashkernel reservation is no longer
sufficient. Recent NFS testing has shown that at least 238M is required to
successfully capture a vmcore. Given this, we have updated the default
crashkernel reservation to start from 2G, with 256M allocated for crash
recovery.
Since 256M is a significant portion of memory on smaller systems, we have
decided not to reserve crashkernel memory by default on systems with less
than 2G of RAM. However, users can still manually adjust the `crashkernel=`
setting via tools like `grubby` if needed.
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-84470
Upstream: kdump-utils
Conflict: None
commit d6e1edc677bfd15fb4553101ffb5a34130959861
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Mar 13 14:12:58 2024 +0800
doc/kdump.conf: correctly align the options
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>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-66065
Conflict: in upstream, 99-kdump.conf is introduced by
commit dacb34341 (Add kdump dracut config). And it
has been back ported to RHEL-9. So implementing the
omit based on the new skeleton.
commit 1732a3bd477b3bc0b078b0f070024f350c22ef2b
Author: Pingfan Liu <piliu@redhat.com>
Date: Mon Sep 9 11:52:00 2024 +0800
mkdumprd: Omit rdma module
Resolves: https://issues.redhat.com/browse/RHEL-57006
05rdma dracut module from rdma-core is installed unconditionally even if
kdump dumps the vmcore to local disk. And those kmod will cost
additional 200M memory on x86, which likely triggers OOM.
Since the Infiniband (and in fact none of RDMA devices are supported in
kdump), exclude the rdma dracut module explicitly.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-67131
Conflict: Upstream uses a different path dracut/99kdumpbase/module-setup.sh.
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit 821a5e648dcb72d89065078e0cadb58a5313b183
Author: Coiby Xu <coxu@redhat.com>
Date: Thu Nov 28 18:07:49 2024 +0800
Fallback to get NIC driver by /sys/class/net/NIC/device/driver/module
Resolves: https://issues.redhat.com/browse/RHEL-67131
Some drivers like dwmac_tegra may report its name incorrectly. So
fallback to /sys/class/net/NIC/device/driver/modul to address these
cases. Note this method only for physical NICs i.e it doesn't work for
virtual NICs like bonding NIC.
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-69568
Conflict: None
Upstream Status: git@github.com:rhkdump/kdump-utils.git
commit 200107e45ac2619bf7d865a19ff896a83b97fe56
Author: Coiby Xu <coxu@redhat.com>
Date: Tue Dec 10 16:38:23 2024 +0800
Note user-specified crashkernel value will be overwritten by default value
Resolves: https://issues.redhat.com/browse/RHEL-69568
When kdump-utils gets updated automatically i.e. not updated manually by
user, users won't notice custom crashkernel value gets overwritten as
the logs in /var/log/dnf.rpm.log may be ignored,
2024-12-10T02:57:12-0500 INFO kdump: For kernel=/boot/vmlinuz-6.11.0-28.el10.x86_64, crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M now. Please reboot the system for the change to take effect. Note if you don't want kexec-tools to manage the crashkernel kernel parameter, please set auto_reset_crashkernel=no in /etc/kdump.conf.
So add a note to kdump.conf.
Suggested-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://bugzilla.redhat.com/RHEL-52304
Upstream: kdump-utils
commit 77a0246cde3505777cfa1f9c2a1a834e76b7eed6
Author: Lichen Liu <lichliu@redhat.com>
Date: Mon Jan 13 17:39:56 2025 +0800
99-kdump.conf: Omit nouveau and amdgpu module
Resolves: https://issues.redhat.com/browse/RHEL-52304
The GPU module provides no significant utility in second kernel, and it
introduces firmware that occupies lots of memory, which is critical in
the constrained environment of kdump. Omit it helps reduce memory usage
and optimize the crash recovery process.
See also:
https://access.redhat.com/solutions/6977793https://access.redhat.com/solutions/7100186
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
