Menu Close

Chapter 12. Supported kdump configurations and targets

12.1. Memory requirements for kdump

In order for kdump to be able to capture a kernel crash dump and save it for further analysis, a part of the system memory has to 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 find out 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:

$ uname -m

The following table lists the minimum memory requirements to automatically reserve a memory size for kdump on the latest available versions. The size changes according to the system’s architecture and total available physical memory.

Table 12.1. Minimum amount of reserved memory required for kdump

ArchitectureAvailable MemoryMinimum Reserved Memory

AMD64 and Intel 64 (x86_64)

1 GB to 4 GB

160 MB of RAM.

4 GB to 64 GB

192 MB of RAM.

64 GB to 1 TB

256 MB of RAM.

1 TB and more

512 MB of RAM.

64-bit ARM architecture (arm64)

2 GB and more

448 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

160 MB of RAM.

4 GB to 64 GB

192 MB of RAM.

64 GB to 1 TB

256 MB of RAM.

1 TB 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 configuration of reserved memory based on the total amount of memory in the system is a best effort estimation. The actual required memory may vary due to other factors such as I/O devices. Using not enough of memory might cause that a debug kernel is not able to boot as a capture kernel in case of a kernel panic. To avoid this problem, sufficiently increase the crash kernel memory.

12.2. Minimum threshold for memory reservation

The kexec-tools utility, by default, configures the crashkernel command line parameter and reserves a certain amount of memory for kdump. For the default memory reservation to work, a certain amount of total memory must be available in the system. The amount of memory required differs based on the system’s architecture.

The following table lists the minimum threshold values for memory allocation. If the system has memory less than the specified threshold value, you must configure the memory manually.

Table 12.2. Minimum amount of memory required for memory reservation

ArchitectureRequired Memory

AMD64 and Intel 64 (x86_64)

1 GB

IBM Power Systems (ppc64le)

2 GB

IBM  Z (s390x)

1 GB

ARM (aarch64)

2GB

12.3. Supported kdump targets

When a kernel crash is captured, the vmcore dump file can be either written directly to a device, stored as a file on a local file system, or sent over a network. The table below contains a complete list of dump targets that are currently supported or explicitly unsupported by kdump.

TypeSupported TargetsUnsupported Targets

Raw device

All locally attached raw disks and partitions.

 

Local file system

ext2, ext3, ext4, and xfs file systems on directly attached disk drives, hardware RAID logical drives, LVM devices, and mdraid arrays.

Any local file system not explicitly listed as supported in this table, including the auto type (automatic file system detection).

Remote directory

Remote directories accessed using the NFS or SSH protocol over IPv4.

Remote directories on the rootfs file system accessed using the NFS protocol.

Remote directories accessed using the iSCSI protocol over both hardware and software initiators.

Remote directories accessed using the iSCSI protocol on be2iscsi hardware.

Multipath-based storages.

 

Remote directories accessed over IPv6.

 

Remote directories accessed using the SMB or CIFS protocol.

 

Remote directories accessed using the FCoE (Fibre Channel over Ethernet) protocol.

 

Remote directories accessed using wireless network interfaces.

Important

Utilizing firmware assisted dump (fadump) to capture a vmcore and store it to a remote machine using SSH or NFS protocol causes renaming of the network interface to kdump-<interface-name>. The renaming happens if the <interface-name> is generic, for example *eth#, net#, and so on. This problem occurs because the vmcore capture scripts in the initial RAM disk (initrd) add the kdump- prefix to the network interface name to secure persistent naming. Since the same initrd is used also for a regular boot, the interface name is changed for the production kernel too.

12.4. Supported kdump filtering levels

To reduce the size of the dump file, kdump uses the makedumpfile core collector to compress the data and optionally to omit unwanted information. The table below contains a complete list of filtering levels that are currently supported by the makedumpfile utility.

OptionDescription

1

Zero pages

2

Cache pages

4

Cache private

8

User pages

16

Free pages

Note

The makedumpfile command supports removal of transparent huge pages and hugetlbfs pages. Consider both these types of hugepages User Pages and remove them using the -8 level.

12.5. Supported default failure responses

By default, when kdump fails to create a core dump, the operating system reboots. You can, however, configure kdump to perform a different operation in case it fails to save the core dump to the primary target. The table below lists all default actions that are currently supported.

OptionDescription

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.

failure_action

Specifies the action to perform when a dump might fail in the event of a kernel crash. The default failure_action option is reboot.

12.6. Using final_action parameter

The final_action parameter enables you to use certain additional operations such as reboot, halt, and poweroff actions after a successful kdump or when an invoked failure_action mechanism using shell or dump_to_rootfs completes. If the final_action option is not specified, it defaults to reboot.

Procedure

  1. To configure final_action, edit the /etc/kdump.conf file and add one of the following options:

    # final_action <reboot | halt | poweroff>
  2. Restart the kdump service for the changes to take effect:

    # kdumpctl restart

12.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, which reboots the system.

failure_action specifies one of 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:

  1. 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 | halt | poweroff | shell | dump_to_rootfs>
  2. Restart the kdump service for the changes to take effect:

    # kdumpctl restart