Enable Kernel Crash Dump on Ubuntu Linux: Easy 4 Steps

By Posted on

Enable Kernel Crash Dump on Ubuntu Linux: Easy 4 Steps

In this tutorial, we aim to guide you through the process of enabling a crucial system feature: Enable Kernel Crash Dump on Ubuntu Linux. An Ubuntu Linux Kernel Crash Dump service is a configuration that allows your system to save the contents of RAM (memory) to disk when the Linux kernel encounters an unrecoverable error and halts or crashes. This dump file is invaluable for debugging and diagnosing the root cause of kernel panics.

You can follow the steps below on the Orcacore website to Install and Enable Kernel Crash Dump on Ubuntu Linux versions 20.04, Ubuntu 22.04, and Ubuntu 24.04.

To Enable Kernel Crash Dump on Ubuntu Linux, you must have access to your server as a non-root user with sudo privileges. For this purpose, you can visit the Ubuntu initial guides:

Initial server setup with Ubuntu 20.04

Initial Server Setup with Ubuntu 22.04

Now follow the steps below to Enable Kernel Crash Dump on Ubuntu Linux.

Step 1 – Install Kernel Crash Dump Packages on Ubuntu

First, you must run the system update by using the following command:

sudo apt update

Then, use the following command to install kernel crash dump packages:

sudo apt install kdump-tools crash kexec-tools makedumpfile -y

During the kdump-tools installation, you will be asked if kdump-tools should handle the reboots. You must enter Yes and continue. Then, you must enable it by choosing Yes.

When you are done, Verify your configurations by running the following commands:

sudo grep USE_KDUMP /etc/default/kdump-tools
**Output**
# USE_KDUMP - controls kdump will be configured
**USE_KDUMP=1**

As shown above, USE_KDUMP must be set to value 1.

sudo grep LOAD_KEXEC /etc/default/kexec
**Output**
**LOAD_KEXEC=true**

And your LOAD_KEXEC must be shown the true value.

Step 2 – Check the Current Crash Kernel Status on Ubuntu

At this point, you must run the following command to check the kdump status to see whether the crash dump is enabled or not:

sudo kdump-config show
**Output**
 * no crashkernel= parameter in the kernel cmdline
DUMP_MODE:              kdump
USE_KDUMP:              1
KDUMP_COREDIR:          /var/crash
crashkernel addr:
   /var/lib/kdump/vmlinuz
kdump initrd:
   /var/lib/kdump/initrd.img
current state:    Not ready to kdump

kexec command:
  no kexec command recorded

As you can see from the output, the dump crash service is not enabled.

Step 3 – How Do I Enable Crash Dump in Ubuntu?

To Enable Kernel Crash Dump on Ubuntu Linux, you must reboot your server after making the above configuration. To do this, run the command below:

sudo systemctl reboot

Then, log in back to your Ubuntu server and check the kdump status again with the following command:

sudo kdump-config show

In your output, you should see:

**Output**
**DUMP_MODE:              kdump**
USE_KDUMP:              1
**KDUMP_COREDIR:          /var/crash**
crashkernel addr: 0xb3000000
   /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-5.15.0-46-generic
kdump initrd:
   /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-5.15.0-46-generic
**current state:    ready to kdump**

kexec command:
  /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-5.15.0-46-generic root=UUID=4d1266d2-c1f9-4087-af92-2d60c8c153e4 ro net.ifnames=0 biosdevname=0 netcfg/do_not_use_netplan=true reset_devices systemd.unit=kdump-tools-dump.service nr_cpus=1 irqpoll nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

As you can see, the system is ready to kdump. Your crash dump service is enabled on your Ubuntu server.

Also, you can find core dumps in the /var/crash directory.

Step 4 – How To Verify Crash Kernel is Configured on Ubuntu?

At this point, you can check for Crash Kernel Parameter on your server by running the following command:

sudo cat /proc/cmdline
**Output**
BOOT_IMAGE=/boot/vmlinuz-5.15.0-46-generic root=UUID=4d1266d2-c1f9-4087-af92-2d60c8c153e4 ro net.ifnames=0 biosdevname=0 netcfg/do_not_use_netplan=true **crashkernel=512M-:192M**

The highlighted line crashkernel=512M-:192M means:

  1. For systems with more than 512MB of RAM, allocate 192MB for the crash kernel.
  2. For systems with less than 512MB of RAM, the crashkernel parameter is not enabled, which means the crash dump will not function.

Also, you can use the following command to list the requested memory area for the kdump kernel on Ubuntu:

sudo dmesg | grep -i crash
Verify Crash Kernel is Configured on Ubuntu

That’s it, you are done. For more information, you can visit Ubuntu Kernel Crash Dumps Docs.

Conclusion

At this point, you have learned to install kernel dumps packages and Enable Kernel Crash Dump on Ubuntu Linux. Hope you enjoy it. You may also be interested in these articles:

Install MariaDB 10.11 on Ubuntu 20.04

*Fix Exceeded LOCALRELAY limit Error**

Alternative Solutions for Enabling Kernel Crash Dumps

While the kdump-tools method is the standard and recommended approach, there are alternative ways to achieve similar results, albeit with varying degrees of complexity and functionality. Here are two such alternatives:

1. Using systemd-coredump (with adjustments for kernel crashes):

systemd-coredump is a built-in systemd service that handles core dumps for user-space applications. While it’s not primarily designed for kernel crash dumps, it can be adapted to capture some information in case of a kernel panic. The key is to configure the kernel to trigger a reboot upon panic and ensure systemd-coredump is configured to capture the relevant data. This method won’t provide a full kernel memory dump like kdump, but it might capture some useful context information.

  • Explanation: systemd-coredump relies on the kernel.panic sysctl setting. When the kernel panics, it will wait for the number of seconds specified by kernel.panic before rebooting. By setting kernel.panic to a small non-zero value, and ensuring systemd-coredump is active, you might be able to capture user-space context before the reboot occurs.

  • Configuration:

    • Enable systemd-coredump: Ensure the systemd-coredump.service is enabled and running. You can check its status with systemctl status systemd-coredump. If it’s not enabled, use sudo systemctl enable systemd-coredump.

    • Configure kernel.panic: Edit /etc/sysctl.conf (or create a file in /etc/sysctl.d/) and add the following line:

      kernel.panic = 5

      This tells the kernel to wait 5 seconds after a panic before rebooting. Adjust this value as needed; too short, and systemd-coredump might not have time to capture data.

    • Apply the sysctl settings: Run sudo sysctl -p to apply the changes.

    • Configure storage for core dumps: Check and adjust the /etc/systemd/coredump.conf file for the location and size limits of the core dumps.

  • Limitations: This method won’t capture a full kernel memory dump, making it less useful for in-depth kernel debugging. It primarily captures user-space information. It is also reliant on the system remaining responsive enough for systemd-coredump to function correctly during the panic, which is not always guaranteed.

2. Using a custom panic handler and remote logging (for limited information):

This approach involves creating a custom kernel panic handler that attempts to log some minimal debugging information to a remote server before the system crashes. This is a more advanced and potentially fragile method, requiring kernel module development.

  • Explanation: You would need to write a kernel module that registers a custom panic handler using the panic_notifier_list mechanism. This handler would attempt to transmit relevant kernel state (e.g., register values, stack traces) to a remote logging server (e.g., using UDP).

  • Conceptual Code Snippet (Highly Simplified):

    #include <linux/kernel.h>
#include <linux/module.h>
#include <linux/notifier.h>
#include <linux/net.h>
#include <linux/socket.h>
#include <net/sock.h>
#include <linux/in.h>
#include <linux/string.h>

static struct notifier_block panic_notifier;
static struct socket *sock;
static struct sockaddr_in addr;

static int panic_handler(struct notifier_block *this, unsigned long event, void *data) {
    char msg[256];
    struct kvec iov;
    struct msghdr hdr;
    int len;

    if (event == KERNEL_PANIC) {
        // Craft a message (e.g., include some register values)
        snprintf(msg, sizeof(msg), "Kernel Panic: RIP = %lxn", (unsigned long)__builtin_return_address(0));

        // Send the message via UDP
        iov.iov_base = msg;
        iov.iov_len = strlen(msg);

        memset(&hdr, 0, sizeof(hdr));
        hdr.msg_name = &addr;
        hdr.msg_namelen = sizeof(addr);
        hdr.msg_iov = &iov;
        hdr.msg_iovlen = 1;

        len = kernel_sendmsg(sock, &hdr, &iov, 1, strlen(msg));
        if (len < 0) {
            printk(KERN_ERR "Error sending panic log: %dn", len);
        }

    }
    return NOTIFY_DONE;
}

static int __init panic_module_init(void) {
    int ret;

    // Create a UDP socket
    ret = sock_create(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
    if (ret < 0) {
        printk(KERN_ERR "Error creating socket: %dn", ret);
        return ret;
    }

    // Configure the destination address
    addr.sin_family = AF_INET;
    addr.sin_port = htons(514); // Syslog port
    addr.sin_addr.s_addr = in_aton("192.168.1.100"); // Replace with your syslog server IP

    // Register the panic handler
    panic_notifier.notifier_call = panic_handler;
    panic_notifier.priority = 0;
    ret = atomic_notifier_chain_register(&panic_notifier_list, &panic_notifier);
    if (ret) {
        printk(KERN_ERR "Error registering panic notifier: %dn", ret);
        sock_release(sock);
        return ret;
    }

    printk(KERN_INFO "Panic module loadedn");
    return 0;
}

static void __exit panic_module_exit(void) {
    atomic_notifier_chain_unregister(&panic_notifier_list, &panic_notifier);
    sock_release(sock);
    printk(KERN_INFO "Panic module unloadedn");
}

module_init(panic_module_init);
module_exit(panic_module_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("Sends panic information to a remote syslog server");

    Important Considerations:

    • This code is a highly simplified example. A real-world implementation would need to handle error conditions, network connectivity issues, and security considerations.
    • Accessing kernel memory and hardware directly within a panic handler is risky and can lead to further instability.
    • The network stack might not be fully functional during a panic, making network communication unreliable.

  • Limitations: This method provides only very limited information. It is highly dependent on the system’s ability to transmit data over the network during a panic, which is often unreliable. Developing and maintaining kernel modules requires significant expertise and carries inherent risks. Debugging is extremely difficult.

In summary, while kdump-tools offers the most robust and complete solution for kernel crash dump analysis, these alternative methods provide limited functionality and come with significant limitations. They should only be considered in specific scenarios where kdump-tools is not feasible and the benefits outweigh the risks.

Related posts: