Enable Kdump on Linux: crash dumps for kernel panics

Level: Intermediate / Senior
Estimated time: ~30 minutes
Goal: Configure kdump linux crash dump capture for kernel panics, enabling reliable post-mortem analysis of production failures. This guide explains how to enable kdump in linux, covering the full linux crash dump configuration from memory reservation through vmcore analysis.

Introduction

A kernel panic halts the system, and without a crash dump you have zero data to work with. Kdump - the standard linux kernel crash dump framework - solves this: it pre-loads a capture kernel into reserved memory, and when the primary kernel panics, kexec boots that capture kernel to write a full memory image (vmcore) to disk. In this tutorial, you will learn how to enable kdump in linux for linux kernel panic dump capture on Ubuntu, Debian, and RHEL-based systems. We will show you exactly how to enable kdump linux systems require, with vmcore analysis linux post-mortem steps included.

What is Kdump?

Kdump is a kernel crash dumping mechanism that uses kexec to boot a secondary capture kernel from a reserved memory region whenever the primary kernel panics. The capture kernel runs with limited memory (set by the crashkernel boot parameter) and writes the failed kernel's memory image to disk as a vmcore - a complete memory dump file that can be analyzed with the crash utility or gdb. The kdump service (kdump.service on RHEL-based or kdump-tools.service on Debian-based systems) manages the loading of the capture kernel at boot time.

Key components:

• Kexec - the system call and userspace tool that loads the capture kernel into reserved memory.
• Crashkernel - the boot parameter that tells the primary kernel how much RAM to reserve for kdump linux operation (e.g., crashkernel=256M).
• Vmcore - the output file containing the full memory dump, written to /var/crash by default.
• /var/crash - the default directory where kdump stores vmcore files after a kernel panic.

Prerequisites

Before you begin, make sure the following conditions are met:

• Operating system: Ubuntu 22.04/24.04 LTS, Debian 12/13, or RHEL/CentOS/AlmaLinux 9/10 (Tested and verified on Ubuntu 24.04, Debian 13, and AlmaLinux 10)
• Access: sudo or root access to the server
• RAM: Minimum 2 GB total. Kdump reserves a portion of system memory (typically 256 MB) for the capture kernel - low-memory systems may not have enough headroom.
• Disk space: At least as much free space in /var/crash as your system has RAM (a vmcore can be as large as the physical memory)
• Required knowledge: confident use of the Linux command line, basic file editing, and familiarity with GRUB boot parameters
• Reboot window: Configuring the crashkernel parameter requires a reboot to take effect

Step 1: Install the kdump and kexec packages

Kdump relies on kexec-tools (the kexec kdump linux userspace component) and distribution-specific helpers.

Ubuntu/Debian:

sudo apt update && sudo apt install kdump-tools kexec-tools crash -y

During an interactive installation on Ubuntu, a debconf prompt may appear asking to configure the crashkernel parameter automatically. Select Yes if asked. If the prompt does not appear (e.g., in non-interactive mode), crashkernel is configured automatically via a drop-in file. If you need to adjust the value later, Step 2 covers manual configuration.

RHEL/CentOS/AlmaLinux:

sudo dnf install kexec-tools crash -y

On RHEL-based systems, the kexec-tools package provides everything needed: the kexec binary, the kdump service, and the default configuration files.

Step 2: Configure the crashkernel boot parameter

The crashkernel parameter tells the kernel how much memory to reserve memory for kdump linux at boot time. Without this reservation, the capture kernel has nowhere to run. Understanding how to configure crashkernel parameter values correctly is essential - too little and the capture kernel will not boot; too much and you waste production RAM.

2.1 Check the current configuration

First, check whether crashkernel is already set:

cat /proc/cmdline | grep crashkernel

If the output contains a crashkernel= entry, the parameter is already configured. You can verify the reserved amount and skip to Step 3 if it meets your needs.

2.2 Configure crashkernel parameter on GRUB-based systems

Ubuntu/Debian:

Before modifying the main GRUB config, check if a drop-in file already exists:

cat /etc/default/grub.d/kdump-tools.cfg

If the package has already configured crashkernel here, modify this file instead to prevent duplicate entries in grub.cfg. Otherwise, open the main GRUB defaults file:

sudo nano /etc/default/grub

Find the GRUB_CMDLINE_LINUX_DEFAULT line and add the crashkernel parameter. For most production servers with 4 GB or more RAM, 256 MB is sufficient to reserve memory for kdump linux:

GRUB_CMDLINE_LINUX_DEFAULT="quiet crashkernel=256M"

For servers with less than 4 GB RAM, use crashkernel=128M. For systems with 64 GB or more, consider crashkernel=512M. You can also use the auto-scaling syntax crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M to configure crashkernel parameter values dynamically based on installed RAM.

Save and close the file, then regenerate the GRUB configuration:

sudo update-grub

RHEL/CentOS/AlmaLinux:

For RHEL/AlmaLinux 8+, the crashkernel parameter sits in GRUB_CMDLINE_LINUX (without _DEFAULT). However, on modern systems using BLS (Boot Loader Specification), the safest and recommended way to update the kernel command line is using grubby instead of modifying /etc/default/grub directly:

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

If you must modify it manually via GRUB configs, edit /etc/default/grub and update GRUB_CMDLINE_LINUX. Then regenerate the configuration (paths vary depending on boot mode):

# For legacy BIOS systems:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# For UEFI systems (e.g., AlmaLinux):
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

2.3 Reboot to apply the crashkernel reservation

The crashkernel memory reservation only takes effect after a reboot:

sudo reboot

After the system comes back up, verify the reservation is active:

cat /proc/cmdline | grep crashkernel

Expected output includes:

crashkernel=256M

Also confirm the memory was actually reserved:

sudo dmesg | grep -i "crashkernel reserved"

You should see a line like:

crashkernel reserved: 0x... - 0x... (NNN MB)

If the reservation failed (message says "crashkernel reservation failed"), you may need to increase or decrease the value. This is a common linux kernel panic troubleshooting step - the kernel could not find a contiguous block of the requested size.

Step 3: Configure kdump linux service settings

With memory reserved, configure where and how kdump stores the vmcore.

3.1 RHEL/CentOS/AlmaLinux configuration

The main configuration file is /etc/kdump.conf. Open it:

sudo nano /etc/kdump.conf

The critical directives:

path /var/crash
core_collector makedumpfile -l --message-level 7 -d 31

• path /var/crash - sets the vmcore target directory. All crash dumps land here.
• core_collector makedumpfile - compresses the dump and filters unnecessary pages. The -d 31 flag excludes zero pages, cache, user data, and free pages - typically reducing a vmcore to 10-20% of total RAM.

3.2 Ubuntu/Debian configuration

On Debian-based systems, the kdump-tools configuration lives in /etc/default/kdump-tools. Open it:

sudo nano /etc/default/kdump-tools

Ensure these lines are set:

USE_KDUMP=1
KDUMP_COREDIR="/var/crash"
KDUMP_CORE_COLLECTOR="makedumpfile -l --message-level 7 -d 31"

USE_KDUMP=1 enables the kdump service. Without it, the capture kernel will not be loaded at boot.

Step 4: Enable and start the kdump service

This is the final step in how to enable kdump in linux. Enable the kdump service so the capture kernel loads automatically on every boot, completing the kexec kdump linux setup.

Ubuntu/Debian:

sudo systemctl enable kdump-tools
sudo systemctl start kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl enable kdump
sudo systemctl start kdump

Verify the service is running:

Ubuntu/Debian:

sudo systemctl status kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl status kdump

Expected output includes:

Active: active (exited)

The "exited" state is normal - the kdump service loads the capture kernel into reserved memory and then exits. It does not run as a persistent daemon.

Step 5: Verification and testing

5.1 Verify kdump is ready

Confirm the capture kernel is loaded and ready to fire on a kernel panic:

cat /sys/kernel/kexec_crash_loaded

Expected output:

1

A value of 1 means the capture kernel is loaded. A 0 means kdump is not operational - go back and check the service status and crashkernel reservation.

You can also inspect how much memory was set aside to reserve memory for kdump linux:

cat /sys/kernel/kexec_crash_size

This returns the reservation in bytes.

5.2 Trigger a test crash

Enable SysRq triggers, then force a crash:

echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-trigger

The system will panic. If kdump is configured correctly, the capture kernel boots, writes the vmcore to /var/crash, and the system reboots automatically.

5.3 Confirm the vmcore was captured

After the reboot, check /var/crash for the dump:

ls -lh /var/crash/

Expected output (format varies by distribution):

RHEL-family (AlmaLinux/CentOS):

drwxr-xr-x 2 root root 4.0K May 23 14:00 127.0.0.1-2026-05-23-14:00:01/

Inside this timestamped directory, you will find vmcore (the memory dump) and vmcore-dmesg.txt (the kernel log).

Debian-family (Ubuntu/Debian):

drwxr-xr-x 2 root root 4.0K May 23 14:00 202605231400/

Inside this directory, the files are typically named dump.<timestamp> and dmesg.<timestamp>.

Check inside the directory:

ls -lh /var/crash/*/

Seeing these files confirms your linux kernel crash dump pipeline is fully operational.

Step 6: Analyze a vmcore file

Capturing a crash dump is only useful if you can read it. The crash utility is the standard tool for vmcore analysis linux administrators rely on for linux kernel panic troubleshooting.

6.1 Install the debug kernel

The crash tool requires the debug symbols for the exact kernel version that panicked.

Ubuntu:

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse" | sudo tee /etc/apt/sources.list.d/ddebs.list
sudo apt install ubuntu-dbgsym-keyring
sudo apt update
sudo apt install linux-image-unsigned-$(uname -r)-dbgsym

Debian:

echo "deb http://deb.debian.org/debian-debug/ $(lsb_release -cs)-debug main" | sudo tee /etc/apt/sources.list.d/debian-debug.list
sudo apt update
sudo apt install linux-image-$(uname -r)-dbg

RHEL/CentOS/AlmaLinux:

sudo dnf --enablerepo='*-debuginfo' install -y kernel-debuginfo-$(uname -r)

6.2 Open the vmcore with crash

Before running crash, verify that the debug symbols are installed and match your kernel version so you don't run it blindly:

# RHEL/Debian:
ls -lh /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

# Ubuntu:
ls -lh /usr/lib/debug/boot/vmlinux-$(uname -r)

Navigate to the crash dump directory and open the vmcore (the exact command varies by OS):

RHEL/CentOS/AlmaLinux:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

Debian:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/dump.*

Ubuntu:

sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/*/dump.*

The crash utility loads and drops you into an interactive shell. Key commands for initial triage:

bt          # backtrace of the panicking task
log         # kernel log buffer (same as dmesg at panic time)
ps          # list processes at the time of the crash
mod         # loaded kernel modules
sys         # system information

Type exit or quit to leave the crash shell.

Rollback

To undo the kdump configuration and reclaim the reserved memory:

1. Stop and disable the kdump service:

Ubuntu/Debian:

sudo systemctl disable --now kdump-tools

RHEL/CentOS/AlmaLinux:

sudo systemctl disable --now kdump

2. Remove the crashkernel parameter:

Ubuntu/Debian:

Open the drop-in configuration file:

sudo nano /etc/default/grub.d/kdump-tools.cfg

Remove the crashkernel parameter (if you added it to /etc/default/grub manually, edit that file instead).

RHEL/CentOS/AlmaLinux:

Open the GRUB defaults file:

sudo nano /etc/default/grub

Remove crashkernel=256M from the GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT line.

Regenerate GRUB:

Ubuntu/Debian:

sudo update-grub

RHEL/CentOS/AlmaLinux:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

3. Reboot to release the reserved memory:

sudo reboot

4. Remove the packages (optional):

Ubuntu/Debian:

sudo apt remove --purge kdump-tools kexec-tools crash -y

RHEL/CentOS/AlmaLinux:

sudo dnf remove kexec-tools crash -y

Troubleshooting

Kdump service fails to start

Check the journal for the reason:

journalctl -xeu kdump

Common causes:

• No crashkernel reservation. Verify with cat /proc/cmdline | grep crashkernel. If missing, repeat Step 2.
• Insufficient reserved memory. The capture kernel needs enough RAM to initialize and write the dump. Try increasing the value (e.g., crashkernel=512M).
• Secure Boot conflict. Some Secure Boot configurations prevent kexec from loading unsigned kernels. Either sign the capture kernel or disable Secure Boot in BIOS.

Vmcore not written after a panic

• Disk space. Verify /var/crash has enough free space. A vmcore can approach the size of physical RAM (before makedumpfile compression).
• Wrong path. Confirm path in /etc/kdump.conf (or KDUMP_COREDIR in /etc/default/kdump-tools) points to a writable, mounted filesystem.
• SELinux denial. On RHEL-based systems, check ausearch -m avc -ts recent for kdump-related denials.

System hangs instead of capturing the dump

This typically indicates a hardware or driver issue preventing the kexec kdump linux transition. Try adding irqpoll nr_cpus=1 reset_devices to the kdump kernel command line in /etc/sysconfig/kdump (RHEL) or /etc/default/kdump-tools (Debian) as KDUMP_CMDLINE_APPEND.

Conclusion

That is all. Crashkernel reserves memory, the kdump service loads the capture kernel at boot, and on a linux kernel panic dump the vmcore lands in /var/crash - ready for linux crash dump configuration you can actually trust. You now have a working setup to enable kdump linux crash dump capture automatically; for deeper linux kernel panic troubleshooting, feed the vmcore to crash and start with the backtrace.

Document Version: 1.0
Last Updated: May 2026
Owner: Technical Documentation Team