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.
With the provided information and procedures, you understand the supported configurations and targets on your RHEL 8 systems and properly configure kdump
and validate it’s working.
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 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
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.
Architecture | Available Memory | Minimum Reserved Memory |
---|---|---|
AMD64 and Intel 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 ( | 2 GB and more | 480 MB of RAM |
IBM Power Systems ( | 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 ( | 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.
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 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.
18.2. Minimum threshold for automatic memory reservation
The kexec-tools
utility, by default, configures the crashkernel
command line parameter and reserves a certain amount of memory for kdump
. On some systems however, it is still possible to allocate 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.
Architecture | Required Memory |
---|---|
AMD64 and Intel 64 ( | 2 GB |
IBM Power Systems ( | 2 GB |
IBM Z ( | 4 GB |
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
.
Target type | Supported Targets | Unsupported Targets |
---|---|---|
Physical storage |
|
|
Network |
|
|
Hypervisor |
| |
File systems | The ext[234], XFS, and NFS file systems. |
The |
Firmware |
|
Additional resources
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` .
Option | Description |
---|---|
| Zero pages |
| Cache pages |
| Cache private |
| User pages |
| Free pages |
Additional resources
18.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.
Option | Description |
---|---|
| 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 the system, losing the core dump in the process. |
| Halt the system, losing the core dump in the process. |
| Power off the system, losing the core dump in the process. |
| Run a shell session from within the initramfs, allowing the user to record the core dump manually. |
|
Enable additional operations such as |
Additional resources
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.# kdumpctl restart
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
, which 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 thefailure_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.# kdumpctl restart