How should the crashkernel parameter be configured for using kdump on Red Hat Enterprise Linux 10 ?

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 10
  • all supported architectures
  • kdump

Issue

  • When configuring the crashkernel parameter the kdump service fails to start:
# kdumpctl status
kdump: Kdump is not operational

○ kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: enabled)
     Active: inactive (dead) (Result: exec-condition) since Thu 2025-05-08 16:35:08 IST; 2min 0s ago
 Invocation: 5867b4a368914434b8b7f36b8069391c
  Condition: start condition unmet at Thu 2025-05-08 16:35:08 IST; 2min 0s ago
    Process: 1077 ExecCondition=/bin/sh -c grep -q -e "crashkernel" -e "fadump" /proc/cmdline (code=exited, status=1/FAILURE)
   Mem peak: 1.2M
        CPU: 7ms

May 08 16:35:08 localhost.localdomain systemd[1]: Starting kdump.service - Crash recovery kernel arming...
May 08 16:35:08 localhost.localdomain systemd[1]: kdump.service: Skipped due to 'exec-condition'.
May 08 16:35:08 localhost.localdomain systemd[1]: Condition check resulted in kdump.service - Crash recovery kernel arming being skipped.
  • What is the correct crashkernel parameter for kdump to work?
  • "crashkernel reservation failed - memory is in use" errors when kernel panics

Resolution

Configuring crashkernel on Red Hat Enterprise Linux 10 kernels

There are two ways through which we can set the crashkernel parameter:

1. Using kdumpctl reset-crashkernel command:

# kdumpctl reset-crashkernel

After running the above command, we can check using grubby command whether crashkernel parameter has been set or not:

# grubby --info DEFAULT
index=0
kernel="/boot/vmlinuz-6.12.0-77.el10.aarch64"
args="ro rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap crashkernel=2G-4G:256M,4G-64G:320M,64G-:576M"
root="/dev/mapper/rhel-root"
initrd="/boot/initramfs-6.12.0-77.el10.aarch64.img $tuned_initrd"
title="Red Hat Enterprise Linux (6.12.0-77.el10.aarch64) 10.1 (Coughlan)"
id="b08f9e99c20944a3a31efc0ffbde492c-6.12.0-77.el10.aarch64"
  • Reboot the machine to take its effect:
# reboot

Note: The reset-crashkernel option reserves crashkernel memory on systems with more than 2 GB of RAM. For systems with less than 2 GB of RAM check Why does kdumpctl reset-crashkernel set an incorrect crashkernel value on systems with less than 2 GB RAM in RHEL 10?

2. Change the crashkernel by using grubby command:

  • We can use estimate sub-command to estimate a suitable crashkernel value for the current machine.
  • Else to automatically reserve an appropriate amount of memory for the kdump kernel use crashkernel=2G-4G:256M,4G-64G:320M,64G-:576M value.
  • For system having less than 2 GiB of RAM use crashkernel=256M or the estimated value from kdumpctl estimate command.
#  kdumpctl estimate
Reserved crashkernel:    0M
Recommended crashkernel: 256M

Kernel image size:   45M
Kernel modules size: 5M
Initramfs size:      43M
Runtime reservation: 64M
Large modules:
    xfs: 2461696
WARNING: Current crashkernel size is lower than recommended size 256M.

# grubby --update-kernel=ALL --args="crashkernel=2G-4G:256M,4G-64G:320M,64G-:576M"

  • Note: By default auto_reset_crashkernel yes is present in /etc/kdump.conf file. If the crashkernel parameter is configured manually, it's suggested to make it to auto_reset_crashkernel no inside the /etc/kdump.conf file to prevent grub from being modified with the default crashkernel range value upon kdump-utils update.

  • Reboot the machine to take its effect:

# reboot

To check whether crashkernel parameter has taken effect we can use below two methods,

  • From /proc/cmdline,
# cat /proc/cmdline
BOOT_IMAGE=(hd1,gpt2)/vmlinuz-6.12.0-77.el10.aarch64 root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap crashkernel=2G-4G:256M,4G-64G:320M,64G-:576M
  • Using showmem or estimate sub-command,
# kdumpctl showmem
kdump: Reserved 320MB memory for crash kernel

# kdumpctl estimate
Reserved crashkernel:    320M
Recommended crashkernel: 256M

Kernel image size:   45M
Kernel modules size: 5M
Initramfs size:      43M
Runtime reservation: 64M
Large modules:
    xfs: 2461696

Where to find generated vmcores:

When the system becomes available again, the vmcore can be found by default under /var/crash/:

# egrep '^path' /etc/kdump.conf
path /var/crash

  • To test the kdump functionality check the Kdump Testing page.

  • Once tested, check the location:

# ls /var/crash/kdump-test-1746699656-306673567/ -alh
total 173M
drwxr-xr-x. 2 root root   97 May  8 15:51 .
drwxr-xr-x. 3 root root   45 May  8 15:50 ..
-rw-------. 1 root root  51K May  8 15:51 kexec-dmesg.log
-rw-------. 1 root root 173M May  8 15:51 vmcore
-rw-r--r--. 1 root root   43 May  8 15:51 vmcore-creation.status
-rw-------. 1 root root  53K May  8 15:50 vmcore-dmesg.txt

Root Cause

The kdump procedure

The received warning indicates that the kdump operation may fail due to improper configuration of the crashkernel parameter. To ensure successful execution, the crashkernel parameter must be correctly set. The kdump process is outlined as follows:

  1. The system boots into the primary (normal) kernel with the crashkernel=... parameter specified, which reserves a dedicated portion of system memory for the kdump (secondary) kernel. This reserved memory is not available to the primary kernel during standard operation.
  2. A system crash or kernel panic occurs.
  3. The kdump kernel is loaded via kexec, utilizing the memory reserved by the crashkernel parameter.
  4. The memory contents of the crashed (primary) kernel are captured and saved into a vmcore file for subsequent analysis.

Note: Failure to reserve a sufficient amount of memory for the kdump kernel may result in the failure of the kdump process.

kdumpctl estimate command reserves crashkernel memory for system having RAM size more than 2 GiB due to the patch available in Content from github.com is not included.kdump-lib.sh: Adjust default crashkernel reservation for x86_64 and s390x.

Further information

How should the crashkernel parameter be configured for using kdump on Red Hat Enterprise Linux?

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.