How to Enable and Configure kdump on Rocky Linux

Introduction

kdump is a kernel crash dumping mechanism that allows you to save the contents of system memory when a kernel panic or system crash occurs. This memory dump (vmcore) can be analyzed to determine the root cause of the crash. This guide covers installation, configuration, and testing of kdump on Rocky Linux 8, 9, and 10, including important differences between versions.

Problem

System administrators need to capture kernel crash dumps for troubleshooting kernel panics and system failures. Without kdump properly configured, diagnostic information is lost when the system crashes, making root cause analysis difficult or impossible.

Resolution

Understanding Version Differences

Before configuring kdump, be aware of key differences across Rocky Linux versions:

Rocky Linux 8:

• Supports crashkernel=auto parameter for automatic memory allocation
• The crashkernel=auto parameter will only work when the available memory is greater than 1GB

Rocky Linux 9:

• The crashkernel=auto parameter is officially deprecated, but still available if needed

Rocky Linux 10:

Rocky Linux 10 follows the same crashkernel configuration approach as Rocky Linux 9. Use explicit memory range specifications for the crashkernel parameter, as crashkernel=auto remains deprecated.

Step 1: Install kdump Packages

Install the required kexec-tools package:

sudo dnf install kexec-tools

Verify installation:

rpm -q kexec-tools

Step 2: Configure crashkernel memory reservation

The crashkernel parameter reserves memory for the crash kernel. Configuration differs by Rocky Linux version.

For Rocky Linux 8

Check if crashkernel is already configured:

grep crashkernel /proc/cmdline

If using automatic allocation:

sudo grubby --update-kernel=ALL --args="crashkernel=auto"

Or specify a fixed amount:

sudo grubby --update-kernel=ALL --args="crashkernel=256M"

For Rocky Linux 9 and 10

Check current configuration:

grep crashkernel /proc/cmdline

Use kdumpctl estimate to calculate recommended memory:

sudo kdumpctl estimate

Example output:

Reserved crashkernel:    256M
Recommended crashkernel: 192M

Kernel image size:   57M
Kernel modules size: 8M
Initramfs size:      36M
Runtime reservation: 64M
Large modules:
    xfs: 2686976
    kvm: 1404928

Configure the crashkernel based on the recommendation using a fixed value:

sudo grubby --update-kernel=ALL --args="crashkernel=192M"

Alternative: Range-based allocation (for deployments across multiple systems)

If you're deploying the same configuration to multiple servers with different RAM amounts, use a range-based allocation:

sudo grubby --update-kernel=ALL --args="crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"

The kernel automatically selects the appropriate reservation based on total system RAM at boot time:

• If system has 1-4GB total RAM: reserves 192MB for crashkernel
• If system has 4-64GB total RAM: reserves 256MB for crashkernel
• If system has 64GB+ total RAM: reserves 512MB for crashkernel

One crashkernel memory value is reserved per system - the kernel picks the matching range. This is useful for gold images, Warewulf nodes, or automated deployments where the same kernel configuration is used across different hardware.

Verify Bootloader Configuration

Check that the parameter was added:

sudo grubby --info=ALL | grep crashkernel

The grubby tool directly modifies the Boot Loader Specification (BLS) entries in /boot/loader/entries/. No additional steps are needed - the changes will take effect after reboot.

Step 3: Configure kdump target and behavior

Edit the kdump configuration file:

sudo vi /etc/kdump.conf

Configure Dump Location

The default location is /var/crash. To change it, modify the path directive:

path /var/crash

For network storage (disabled by default):

#nfs [2001:db8::1:2:3:4]:/export/tmp

For an SSH target:

#ssh user@my.server.com
#ssh user@2001:db8::1:2:3:4
#sshkey /root/.ssh/kdump_id_rsa

Configure Core Collector

The core_collector allows you to modify how the vmcore dump is copied from the system. One feature of core_collector is that it includes the ability to reduce the size of the vmcore dump using makedumpfile.

core_collector makedumpfile -l --message-level 7 -d 31

Parameters explained:

• -l: Use lzo compression
• -c: Use zlib compression (alternative to -l)
• -d 31: Exclude certain memory pages to reduce dump size
• --message-level 7: Control verbosity of dump process

For SSH targets, add the -F flag:

core_collector makedumpfile -l --message-level 1 -d 31 -F

Common kdump.conf directives

# Default dump path
path /var/crash

# Core collector with compression
core_collector makedumpfile -l --message-level 7 -d 31

# Dump level (31 excludes free pages, cache pages, etc.)
# Valid values: 1, 2, 4, 8, 16, 31 (combination)

# For encrypted LUKS volumes, additional memory may be required

Step 4: Enable and start kdump service

Enable kdump to start on boot:

sudo systemctl enable kdump

Start the kdump service:

sudo systemctl start kdump

Check service status:

sudo systemctl status kdump

You should see:

● kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2025-11-26 15:09:01 JST; 35min ago
   Main PID: 1115 (code=exited, status=0/SUCCESS)
        CPU: 1.646s

Nov 26 15:09:00 rocky-linux96 systemd[1]: Starting Crash recovery kernel arming...
Nov 26 15:09:01 rocky-linux96 kdumpctl[1133]: kdump: kexec: loaded kdump kernel
Nov 26 15:09:01 rocky-linux96 kdumpctl[1133]: kdump: Starting kdump: [OK]
Nov 26 15:09:01 rocky-linux96 systemd[1]: Finished Crash recovery kernel arming.

Step 5: Reboot to Apply Crashkernel Reservation

The crashkernel memory reservation only takes effect after a reboot:

sudo reboot

After reboot, verify the crash kernel is loaded:

cat /proc/cmdline | grep crashkernel

Check that memory has been reserved:

cat /sys/kernel/kexec_crash_size

This should show a non-zero value (in bytes). For example, 512MB would show as 536870912.

Verify kdump is active:

sudo kdumpctl status

Expected output:

# From Rocky Linux 9
kdump: Kdump is operational
kdump: Notice: No vmcore creation test performed!

Step 6: Test kdump Configuration

Before relying on kdump in production, test that it captures crashes correctly.

WARNING: This will crash your system. Only perform on test systems or during maintenance windows.

Enable the kernel SysRq functionality:

echo 1 | sudo tee /proc/sys/kernel/sysrq

Trigger a kernel panic:

echo c | sudo tee /proc/sysrq-trigger

The system will crash immediately, reboot, and save the vmcore dump.

After the system restarts, check for the crash dump:

ls -lh /var/crash/

You should see a timestamped directory containing:

vmcore           - The crash dump file
vmcore-dmesg.txt - Kernel log at time of crash
kexec-dmesg.log  - kdump kernel boot log

Verify the vmcore file was created and has a reasonable size:

du -sh /var/crash/*/vmcore

Notes

• kdump requires reserved memory that is unavailable to the running system. This is a small trade-off for crash dump capability.
• For systems with encrypted LUKS volumes, additional memory may be required for kdump to function properly.
• The memory reservation configured with crashkernel= is allocated at boot time and cannot be changed without a reboot.
• Network-based crash dumps (NFS, SSH) require network connectivity during the crash kernel boot, which may not always be available.
• The dump level parameter (-d 31) excludes free pages, cache pages, and other non-essential memory to reduce dump size while retaining critical information.
• If kdump fails to start with "Memory for crashkernel is not reserved" error, verify the crashkernel parameter is set correctly and the system has been rebooted.
• On systems with Secure Boot enabled, the crash kernel must be properly signed.

References

Rocky Linux: Kernel Crash Dump Analysis Rocky Linux: Kernel Panics Caused by CrowdStrike Falcon