Chapter 18. Supported kdump configurations and targets The kdump mechanism is a feature of the Linux kernel that generates a crash dump file when a kernel crash occurs. The kernel dump file has critical information that helps to analyze and determine the root cause of a kernel crash. The crash can be because of various factors, hardware issues or third-party kernel modules problems, to name a few. By using the provided information and procedures, you can perform the following actions: Identify the supported configurations and targets for your RHEL 8 systems. Configure kdump. Verify kdump operation. 18.1. Memory requirements for kdump For kdump to capture a kernel crash dump and save it for further analysis, a part of the system memory should be permanently reserved for the capture kernel. When reserved, this part of the system memory is not available to the main kernel. The memory requirements vary based on certain system parameters. One of the major factors is the system's hardware architecture. To identify the exact machine architecture, such as Intel 64 and AMD64, also known as x86_64, and print it to standard output, use the following command: With the stated list of minimum memory requirements, you can set the appropriate memory size to automatically reserve a memory for kdump on the latest available versions. The memory size depends on the system's architecture and total available physical memory. Table 18.1. Minimum amount of reserved memory required for kdump Architecture Available Memory Minimum Reserved Memory AMD64 and Intel 64 ( x86_64 ) 1 GB to 4 GB 192 MB of RAM 4 GB to 64 GB 256 MB of RAM 64 GB and more 512 MB of RAM 64-bit ARM architecture ( arm64 ) 2 GB and more 480 MB of RAM IBM Power Systems ( ppc64le ) 2 GB to 4 GB 384 MB of RAM 4 GB to 16 GB 512 MB of RAM 16 GB to 64 GB 1 GB of RAM 64 GB to 128 GB 2 GB of RAM 128 GB and more 4 GB of RAM IBM Z ( s390x ) 1 GB to 4 GB 192 MB of RAM 4 GB to 64 GB 256 MB of RAM 64 GB and more 512 MB of RAM On many systems, kdump is able to estimate the amount of required memory and reserve it automatically. This behavior is enabled by default, but only works on systems that have more than a certain amount of total available memory, which varies based on the system architecture. Important The automatic configuration of reserved memory based on the total amount of memory in the system is a best effort estimation. The actual required memory might vary due to other factors such as I/O devices. Using not enough of memory might cause debug kernel unable to boot as a capture kernel in the case of kernel panic. To avoid this problem, increase the crash kernel memory sufficiently. Additional resources How has the crashkernel parameter changed between RHEL8 minor releases? (Red Hat Knowledgebase) Technology capabilities and limits tables Minimum threshold for automatic memory reservation 18.2. Minimum threshold for automatic memory reservation By default, the kexec-tools utility configures the crashkernel command line parameter and reserves a certain amount of memory for kdump . On some systems however, it is still possible to assign memory for kdump either by using the crashkernel=auto parameter in the boot loader configuration file, or by enabling this option in the graphical configuration utility. For this automatic reservation to work, a certain amount of total memory needs to be available in the system. The memory requirement varies based on the system's architecture. If the system memory is less than the specified threshold value, you must configure the memory manually. Table 18.2. Minimum amount of memory required for automatic memory reservation Architecture Required Memory AMD64 and Intel 64 ( x86_64 ) 2 GB IBM Power Systems ( ppc64le ) 2 GB IBM Z ( s390x ) 4 GB Note The crashkernel=auto option in the boot command line is no longer supported on RHEL 9 and later releases. 18.3. Supported kdump targets When a kernel crash occurs, the operating system saves the dump file on the configured or default target location. You can save the dump file either directly to a device, store as a file on a local file system, or send the dump file over a network. With the following list of dump targets, you can know the targets that are currently supported or not supported by kdump . Table 18.3. kdump targets on RHEL 8 Target type Supported Targets Unsupported Targets Physical storage Logical Volume Manager (LVM). Thin provisioning volume. Fibre Channel (FC) disks such as qla2xxx , lpfc , bnx2fc , and bfa . An iSCSI software-configured logical device on a networked storage server. The mdraid subsystem as a software RAID solution. Hardware RAID such as cciss , hpsa , megaraid_sas , mpt2sas , and aacraid . SCSI and SATA disks. iSCSI and HBA offloads. Hardware FCoE such as qla2xxx and lpfc . BIOS RAID. Software iSCSI with iBFT . Currently supported transports are bnx2i , cxgb3i , and cxgb4i . Software iSCSI with a hybrid device driver such as be2iscsi . Fibre Channel over Ethernet (FCoE). Legacy IDE . GlusterFS servers. GFS2 file system. Clustered Logical Volume Manager (CLVM). High availability LVM volumes (HA-LVM). Network Hardware using kernel modules: tg3 , igb , ixgbe , sfc , e1000e , bna , cnic , netxen_nic , qlge , bnx2x , bnx , qlcnic , be2net , enic , virtio-net , ixgbevf , igbvf . IPv4 protocol. Network bonding on different devices, such as Ethernet devices or VLAN. VLAN network. Network Bridge. Network Teaming. Tagged VLAN and VLAN over a bond. Bridge network over bond, team, and VLAN. IPv6 protocol. Wireless connections. InfiniBand networks. VLAN network over bridge and team. Hypervisor Kernel-based virtual machines (KVM). Xen hypervisor in certain configurations only. VMware ESXi 4.1 and 5.1. Hyper-V 2012 R2 on RHEL Gen1 UP Guest only. File systems The ext[234], XFS, and NFS file systems. The Btrfs file system. Firmware BIOS-based systems. UEFI Secure Boot. Additional resources Configuring the kdump target 18.4. Supported kdump filtering levels To reduce the size of the dump file, kdump uses the makedumpfile core collector to compress the data and also exclude unwanted information, for example, you can remove hugepages and hugetlbfs pages by using the -8 level. The levels that makedumpfile currently supports can be seen in the table for Filtering levels for `kdump` . Table 18.4. Filtering levels for kdump Option Description 1 Zero pages 2 Cache pages 4 Cache private 8 User pages 16 Free pages Additional resources Configuring the kdump core collector 18.5. Supported default failure responses By default, when kdump fails to create a core dump, the operating system reboots. However, you can configure kdump to perform a different operation in case it fails to save the core dump to the primary target. Table 18.5. Failure responses for kdump Option Description dump_to_rootfs Attempt to save the core dump to the root file system. This option is especially useful in combination with a network target: if the network target is unreachable, this option configures kdump to save the core dump locally. The system is rebooted afterwards. reboot Reboot the system, losing the core dump in the process. halt Halt the system, losing the core dump in the process. poweroff Power off the system, losing the core dump in the process. shell Run a shell session from within the initramfs, allowing the user to record the core dump manually. final_action Enable additional operations such as reboot , halt , and poweroff actions after a successful kdump or when shell or dump_to_rootfs failure action completes. The default final_action option is reboot . Additional resources Configuring the kdump default failure responses 18.6. Using final_action parameter When kdump succeeds or if kdump fails to save the vmcore file at the configured target, you can perform additional operations like reboot , halt , and poweroff by using the final_action parameter. If the final_action parameter is not specified, reboot is the default response. Procedure To configure final_action , edit the /etc/kdump.conf file and add one of the following options: final_action reboot final_action halt final_action poweroff Restart the kdump service for the changes to take effect. 18.7. Using failure_action parameter The failure_action parameter specifies the action to perform when a dump fails in the event of a kernel crash. The default action for failure_action is reboot that reboots the system. The parameter recognizes the following actions to take: reboot Reboots the system after a dump failure. dump_to_rootfs Saves the dump file on a root file system when a non-root dump target is configured. halt Halts the system. poweroff Stops the running operations on the system. shell Starts a shell session inside initramfs , from which you can manually perform additional recovery actions. Procedure: To configure an action to take if the dump fails, edit the /etc/kdump.conf file and specify one of the failure_action options: failure_action reboot failure_action halt failure_action poweroff failure_action shell failure_action dump_to_rootfs Restart the kdump service for the changes to take effect.

Commands:
uname -m
kdumpctl restart
kdumpctl restart