Chapter 17. Configuring kdump on the command line

Procedure

• Enter the following command to generate a memory usage report:

  # makedumpfile --mem-usage /proc/kcore
  
  
  TYPE        PAGES    EXCLUDABLE    DESCRIPTION
  -------------------------------------------------------------
  ZERO          501635      yes        Pages filled with zero
  CACHE         51657       yes        Cache pages
  CACHE_PRIVATE 5442        yes        Cache pages + private
  USER          16301       yes        User process pages
  FREE          77738211    yes        Free pages
  KERN_DATA     1333192     no         Dumpable kernel data

  Important

  The makedumpfile --mem-usage command reports required memory in pages. This means that you must calculate the size of memory in use against the kernel page size.

  By default the RHEL kernel uses 4 KB sized pages on AMD64 and Intel 64 CPU architectures, and 64 KB sized pages on IBM POWER architectures.

Prerequisites

• You have root permissions on the system.
• You have fulfilled kdump requirements for configurations and targets. For details, see Supported kdump configurations and targets.
• You have installed the zipl utility if it is the IBM Z system.

Prerequisites

• You have root permissions on the system.
• Fulfilled requirements for kdump configurations and targets. For details, see Supported kdump configurations and targets.

Procedure

• To store the crash dump file in /var/crash/ directory of the local file system, edit the /etc/kdump.conf file and specify the path:

  path /var/crash

  The option path /var/crash represents the path to the file system in which kdump saves the crash dump file.

  Note
  • When you specify a dump target in the /etc/kdump.conf file, then the path is relative to the specified dump target.
  • When you do not specify a dump target in the /etc/kdump.conf file, then the path represents the absolute path from the root directory.

  Depending on the file system mounted in the current system, the dump target and the adjusted dump path are configured automatically.

• To secure the crash dump file and the accompanying files produced by kdump, you should set up proper attributes for the target destination directory, such as user permissions and SELinux contexts. Additionally, you can define a script, for example kdump_post.sh in the kdump.conf file as follows:

  kdump_post <path_to_kdump_post.sh>

  The kdump_post directive specifies a shell script or a command that executes after kdump has completed capturing and saving a crash dump to the specified destination. You can use this mechanism to extend the functionality of kdump to perform actions including the adjustments in file permissions.

• Displaying and understanding the kdump target configuration:

  1. Show the effective configuration by filtering out comments and empty lines:

     # grep -v '^#' /etc/kdump.conf | grep -v '^$'

  2. Example output:

     ext4 /dev/mapper/vg00-varcrashvol
     path /var/crash
     core_collector makedumpfile -c --message-level 1 -d 31

     The dump target is specified (ext4 /dev/mapper/vg00-varcrashvol), and, therefore, it is mounted at /var/crash. The path option is also set to /var/crash. Therefore, the kdump saves the vmcore file in the /var/crash/var/crash directory.

• To change the local directory for saving the crash dump, edit the /etc/kdump.conf configuration file as a root user:

  1. Remove the hash sign (#) from the beginning of the #path /var/crash line.

  2. Replace the value with the intended directory path. For example:

     path /usr/local/cores

     Important

     In Red Hat Enterprise Linux 10, the directory defined as the kdump target using the path directive must exist when the kdump systemd service starts to avoid failures. The directory is no longer created automatically if it does not exist when the service starts.

• To write the file to a different partition, edit the /etc/kdump.conf configuration file:

  1. Remove the hash sign (#) from the beginning of the #ext4 line, depending on your choice.

     • device name (the #ext4 /dev/vg/lv_kdump line)
     • file system label (the #ext4 LABEL=/boot line)
     • UUID (the #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 line)

  2. Change the file system type and the device name, label or UUID, to the required values. The correct syntax for specifying UUID values is both UUID="correct-uuid" and UUID=correct-uuid. For example:

     ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937

     Important

     You must specify storage devices by using a LABEL= or UUID=. Disk device names such as /dev/sda3 are not guaranteed to be consistent across reboot.

     When you use Direct Access Storage Device (DASD) on IBM Z hardware, ensure the dump devices are correctly specified in /etc/dasd.conf before proceeding with kdump.

• To write the crash dump directly to a device, edit the /etc/kdump.conf configuration file:

  1. Remove the hash sign (#) from the beginning of the #raw /dev/vg/lv_kdump line.

  2. Replace the value with the intended device name. For example:

     raw /dev/sdb1

• To store the crash dump to a remote machine by using the NFS protocol:

  1. Remove the hash sign (#) from the beginning of the #nfs my.server.com:/export/tmp line.

  2. Replace the value with a valid hostname and directory path. For example:

     nfs penguin.example.com:/export/cores

  3. Restart the kdump service for the changes to take effect:

     $ sudo systemctl restart kdump.service

     Note

     While using the NFS directive to specify the NFS target, kdump.service automatically attempts to mount the NFS target to check the disk space. There is no need to mount the NFS target in advance. To prevent kdump.service from mounting the target, use the dracut_args --mount directive in kdump.conf. This enables kdump.service to call the dracut utility with the --mount argument to specify the NFS target.

• To store the crash dump to a remote machine by using the SSH protocol:

  1. Remove the hash sign (#) from the beginning of the #ssh user@my.server.com line.
  2. Replace the value with a valid username and hostname.

  3. Include your SSH key in the configuration.

     1. Remove the hash sign from the beginning of the #sshkey /root/.ssh/kdump_id_rsa line.

     2. Change the value to the location of a key valid on the server you are trying to dump to. For example:

        ssh john@penguin.example.com
        sshkey /root/.ssh/mykey

• Compressing the size of a crash dump file and copying only necessary pages by using various dump levels.
• Excluding unnecessary crash dump pages.
• Filtering the page types to be included in the crash dump.

Prerequisites

• You have root permissions on the system.
• Fulfilled requirements for kdump configurations and targets. For details, see Supported kdump configurations and targets.

Prerequisites

• Root permissions.
• Fulfilled requirements for kdump configurations and targets. For details, see Supported kdump configurations and targets.

• Package upgrades.
• Hardware level changes, for example, storage or networking changes.
• Firmware upgrades.
• New installation and application upgrades that include third party modules.
• If you use the hot-plugging mechanism to add more memory on hardware that support this mechanism.
• After you make changes in the /etc/kdump.conf or /etc/sysconfig/kdump file.

Prerequisites

• You have root permissions on the system.
• You have saved all important data. The commands to test kdump cause the kernel to crash with loss of data.
• You have scheduled significant machine maintenance time depending on the system architecture.

• vmcore - main kernel memory dump file containing system memory at the time of the crash. It includes data according to the configuration of the core_collector program specified in kdump configuration. By default the kernel data structures, process information, stack traces, and other diagnostic information.
• vmcore-dmesg.txt - contents of the kernel ring buffer log (dmesg) from the primary kernel that panicked.
• kexec-dmesg.log - has kernel and system log messages from the execution of the secondary kexec kernel that collects the vmcore data.

Prerequisites

• You have root permissions on the system.
• You have completed kdump requirements for configurations and targets. See Supported kdump configurations and targets.
• All configurations for installing kdump are set up as required.

• rd.driver.blacklist=<modules>
• modprobe.blacklist=<modules>

Prerequisites

• You have root permissions on the system.