Linux: Enable Kdump

Some systems may have Kernel crash dumps (kdump) disabled due to performance concerns. When encountering a kernel panic and contacting RHEL support, they might request a kdump. You are advised to enable kdump and either wait for the incident to occur or manually trigger it to observe the kernel panic. Kdump must be enabled in order for the incident to generate the dump files.

1. If kernel-tools package is removed from the system, install it:

# yum install kexec-tools -y

2. To reserve memory for Crashkernel, add the crashkernel option to the current kernel:

# grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="crashkernel=1G"

3. Reboot the System

# reboot

4. Enable and start Kdump service

# systemctl enable --now kdump.service

5. Verify Kdump is running

# systemctl status kdump.service

● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor prese>
Active: active (exited) since Tue 2025-06-24 20:29:58 UTC; 7min ago
Main PID: 1169 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 196884)
Memory: 0B
CGroup: /system.slice/kdump.service

⚠️ Testing: Trigger a Kernel Panic

Please note that I will show you a command that can trigger a kernel panic. This will allow you to check if a dump is generated. This is meant for testing purposes only and should not be executed on a production system during working hours. 🙂

Are you sure you want to cause a kernel panic right now? – If yes, then here is the command:

# echo c > /proc/sysrq-trigger

At this point, the node/VM has crashed and rebooted. When you relog in, you can check /var/crash/ directory to see if crash data was generated.

# ll /var/crash/
...
drwxr-xr-x 2 root root 67 Jun 24 20:15 127.0.0.1-2025-06-24-20:15:51

# cd /var/crash/
# ll
..
drwxr-xr-x 2 root root 67 Jun 24 20:15 127.0.0.1-2025-06-24-20:15:51

# cd 127.0.0.1-2025-06-24-20\:15\:51/

# ll
...
-rw------- 1 root root 45904 Jun 24 20:15 kexec-dmesg.log
-rw------- 1 root root 242941092 Jun 24 20:15 vmcore
-rw------- 1 root root 43877 Jun 24 20:15 vmcore-dmesg.txt
⚠️ Be sure to monitor disk space in /var/crash, as vmcore files can be large.

Change default kernel using grubby Tool

There are several ways to fulfill the same task, I am providing one of them.

  1. Check the information about currently loaded kernel:
# uname -r
5.4.17-2036.101.2.el7uek.x86_64

2. Find all available kernels in your system and locate their index number:

# grubby --info=ALL
index=0
kernel=/boot/vmlinuz-5.4.17-2036.101.2.el7uek.x86_64
args="ro console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300 numa=off transparent_hugepage=never net.ifnames=0"
root=/dev/mapper/rootvg-rootlv
initrd=/boot/initramfs-5.4.17-2036.101.2.el7uek.x86_64.img
title=Oracle Linux Server 7.9, with Unbreakable Enterprise Kernel 5.4.17-2036.101.2.el7uek.x86_64

index=1
kernel=/boot/vmlinuz-3.10.0-1160.42.2.el7.x86_64
args="ro console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300 numa=off transparent_hugepage=never net.ifnames=0"
root=/dev/mapper/rootvg-rootlv
initrd=/boot/initramfs-3.10.0-1160.42.2.el7.x86_64.img
title=Oracle Linux Server 7.9, with Linux 3.10.0-1160.42.2.el7.x86_64

index=2
kernel=/boot/vmlinuz-0-rescue-d3dd3af16fd242cebb997c6041d68ad3
args="ro console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300 numa=off transparent_hugepage=never net.ifnames=0"
root=/dev/mapper/rootvg-rootlv
initrd=/boot/initramfs-0-rescue-d3dd3af16fd242cebb997c6041d68ad3.img

3. Check currently loaded kernel index using grubby tool (actually, we could find the same from 1st and 2nd steps, but let’s do one more time):

# grubby --default-index
0

4. Change the default kernel, in my case I want to set it to vmlinuz-3.10.0-1160.42.2.el7.x86_64 and it’s index number is 1:

# grubby --set-default 1

5. Reboot the system and check the kernel again:

# reboot
# uname -r
3.10.0-1160.42.2.el7.x86_64