Show Table of Contents
32.2.2. Using the Kernel Dump Configuration Utility
To start the Kernel Dump Configuration utility, select → → from the panel, or type
system-config-kdump at a shell prompt. You will be presented with a window as shown in Figure 32.1, “Basic Settings”.
The utility allows you to configure
kdump as well as to enable or disable starting the service at boot time. When you are done, click to save the changes. The system reboot will be requested, and unless you are already authenticated, you will be prompted to enter the superuser password.
Important
On IBM System z or PowerPC systems with SELinux running in Enforcing mode, the
kdumpgui_run_bootloader Boolean must be enabled before launching the Kernel Dump Configuration utility. This Boolean allows system-config-kdump to run the boot loader in the bootloader_t SELinux domain. To permanently enable the Boolean, run the following command as root:
~]# setsebool -P kdumpgui_run_bootloader 1Enabling the Service
To start the
kdump daemon at boot time, click the button on the toolbar. This will enable the service for runlevels 2, 3, 4, and 5, and start it for the current session. Similarly, clicking the button will disable it for all runlevels and stop the service immediately.
For more information on runlevels and configuring services in general, see Chapter 12, Services and Daemons.
The Basic Settings Tab
The Basic Settings tab enables you to configure the amount of memory that is reserved for the
kdump kernel. To do so, select the Manual kdump memory settings radio button, and click the up and down arrow buttons next to the New kdump Memory field to increase or decrease the value. Notice that the Usable Memory field changes accordingly showing you the remaining memory that will be available to the system.
Figure 32.1. Basic Settings
Important
This section is available only if the system has enough memory. To learn about minimum memory requirements of the Red Hat Enterprise Linux 6 system, read the Required minimums section of the Red Hat Enterprise Linux Technology Capabilities and Limits comparison chart. When the
kdump crash recovery is enabled, the minimum memory requirements increase by the amount of memory reserved for it. This value is determined by the user, and defaults to 128 MB plus 64 MB for each TB of physical memory (that is, a total of 192 MB for a system with 1 TB of physical memory). The memory can be attempted up to the maximum of 896 MB if required. This is recommended especially in large environments, for example in systems with a large number of Logical Unit Numbers (LUNs).
The Target Settings Tab
The Target Settings tab enables you to specify the target location for the
vmcore dump. It can be either stored as a file in a local file system, written directly to a device, or sent over a network using the NFS (Network File System) or SSH (Secure Shell) protocol.
Figure 32.2. Target Settings
To save the dump to the local file system, select the Local filesystem radio button. Optionally, you can customize the settings by choosing a different partition from the Partition, and a target directory from the Path pulldown lists.
To write the dump directly to a device, select the Raw device radio button, and choose the desired target device from the pulldown list next to it.
To store the dump to a remote machine, select the Network radio button. To use the NFS protocol, select the NFS radio button, and fill the Server name and Path to directory fields. To use the SSH protocol, select the SSH radio button, and fill the Server name, Path to directory, and User name fields with the remote server address, target directory, and a valid remote user name respectively. See Chapter 14, OpenSSH for information on how to configure an SSH server, and how to set up a key-based authentication.
Note
When using Direct-Access Storage Devices (DASDs) as the kdump target, the devices must be specified in the
/etc/dasd.conf file with other DASDs, for example:
0.0.2098 0.0.2198 0.0.2298 0.0.2398
Where
0.0.2298 and 0.0.2398 are the DASDs used as the kdump target.
Similarly, when using FCP-attached Small Computer System Interface (SCSI) disks as the kdump target, the disks must be specified in the
/etc/zfcp.conf file with other FCP-Attached SCSI disks, for example:
0.0.3d0c 0x500507630508c1ae 0x402424aa00000000 0.0.3d0c 0x500507630508c1ae 0x402424ab00000000 0.0.3d0c 0x500507630508c1ae 0x402424ac00000000
Where
0.0.3d0c 0x500507630508c1ae 0x402424ab00000000 and 0.0.3d0c 0x500507630508c1ae 0x402424ac00000000 are the FCP-attached SCSI disks used as the kdump target.
See the Adding DASDs and Adding FCP-Attached Logical Units (LUNs) chapters in the Installation Guide for Red Hat Enterprise Linux 6 for detailed information about configuring DASDs and FCP-attached SCSI disks.
Important
When transferring a core file to a remote target over SSH, the core file needs to be serialized for the transfer. This creates a
vmcore.flat file in the /var/crash/ directory on the target system, which is unreadable by the crash utility. To convert vmcore.flat to a dump file that is readable by crash, run the following command as root on the target system:
~]# /usr/sbin/makedumpfile -R */tmp/vmcore-rearranged* < *vmcore.flat*
For a complete list of currently supported targets, see Table 32.1, “Supported kdump targets”.
Table 32.1. Supported kdump targets
| Type | Supported Targets | Unsupported Targets |
|---|---|---|
| Raw device | All locally attached raw disks and partitions. | — |
| Local file system | ext2, ext3, ext4, minix, btrfs 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 software initiators, unless iBFT (iSCSI Boot Firmware Table) is utilized. | Remote directories accessed using the iSCSI protocol using iBFT. | |
| Multipath-based storages.[a] | Remote directories accessed using the iSCSI protocol over hardware initiators. | |
| — | Remote directories accessed over IPv6. | |
Remote directories accessed using the SMB/CIFS protocol. | ||
Remote directories accessed using the FCoE (Fibre Channel over Ethernet) protocol. | ||
| Remote directories accessed using wireless network interfaces. | ||
[a]
Supported in Red Hat Enterprise Linux 6 from kexec-tools-2.0.0-245.el6 onwards.
| ||
The Filtering Settings Tab
The Filtering Settings tab enables you to select the filtering level for the
vmcore dump.
Figure 32.3. Filtering Settings
To exclude the zero page, cache page, cache private, user data, or free page from the dump, select the check box next to the appropriate label.
The Expert Settings Tab
The Expert Settings tab enables you to choose which kernel and initial RAM disk to use, as well as to customize the options that are passed to the kernel and the core collector program.
Figure 32.4. Expert Settings
To use a different initial RAM disk, select the Custom initrd radio button, and choose the desired RAM disk from the pulldown list next to it.
To capture a different kernel, select the Custom kernel radio button, and choose the desired kernel image from the pulldown list on the right.
To adjust the list of options that are passed to the kernel at boot time, edit the content of the Edited text field. Note that you can always revert your changes by clicking the button.
To choose what action to perform when
kdump fails to create a core dump, select an appropriate option from the Default action pulldown list. Available options are (the default action), (to reboot the system), (to present a user with an interactive shell prompt), (to halt the system), and (to power the system off).
To customize the options that are passed to the
makedumpfile core collector, edit the Core collector text field; see the section called “Configuring the Core Collector” for more information.
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.