7.104. kexec-tools

Bug Fixes

BZ#628610

When starting the kdump service, kdump always verifies the following vendor model attributes on the present block devices: "/sys/block/vda/device/model", "/sys/block/vda/device/rev" and "/sys/block/vda/device/type". However, the virtio block devices do not provide these attributes to sysfs so if such a device was tested, the following error messages were displayed:

cat: /sys/block/vda/device/model: No such file or directory
cat: /sys/block/vda/device/type: No such file or directory

This update modifies the underlying code to restrain kdump from printing these error messages if a block device does not provide the aforementioned sysfs attributes.

BZ#770000

Previously, if memory ballooning was enabled in the first kernel, the virtio balloon driver was included in the kdump kernel, which led to extensive memory consumption. Consequently, kdump failed due to an out of memory (OOM) error and the vmcore file could not be saved. With this update, the virtio_balloon kernel module is no longer loaded in the second kernel so that an OOM failure no longer prevents kdump from capturing vmcore.

BZ#788253

Previously, the microde.ko module was included and loaded in the kdump kernel, however, related firmware was not included in the kdump initrd. As a consequence, the kdump kernel waited for 60-second timeout to expire before loading the next module. This update modifies kdump to exclude the microcode driver from the second kernel so that the kdump kernel no longer waits unnecessarily and loads kernel modules as expected.

BZ#813354

The kdump.conf(5) man page previously did not document what file system types are supported by kdump. The user could therefore attempt to specify an unsupported file-system-type option, such as "auto", in the kdump.conf file. This would result in a failure to start the kdump service while the user expected success. With this update, all supported file system types are clearly listed in the kdump.conf(5) man page.

BZ#816467

When configuring kdump to dump a core file to a remote target over SSH without requiring a password, the "service kdump propagate" command has to be executed to generate and propagate SSH keys to the target system. This action required SELinux to be switched from enforcing mode to permissive mode and back. Previously, kdump init script used an incorrect test condition to determine SELinux mode so that SELinux mode could not be switched as required. Consequently, if SELinux was in enforcing mode, SSH keys could not be generated and kdump failed to start. This update removes the code used to switch between permissive and enforcing modes, which is no longer required because with Red Hat Enterprise Linux 6.3 SELinux added a policy allowing applications to access the ssh-keygen utility to generate SSH keys. SSH keys can now be generated and propagated as expected, and kdump no longer fails to start in this scenario.

BZ#818645

When dumping a core file on IBM System z architecture using the line mode terminals, kdump displays its progress on these terminals. However, these terminals do not support cursor positioning so that formatting of the kdump output was incorrect and the output was hard to read. With this update, a new environment variable, TERM, has been introduced to correct this problem. If "TERM=dumb" is set, the makedumpfile utility produces an easily-readable output on the line mode terminals.

BZ#820474

Previously, kdump expected that the generic ATA driver was always loaded as the ata_generic.ko kernel module and the mkdumprd utility thus added the module explicitly. However, the ata_generic.ko module does not exist on the IBM System z architecture and this assumption caused the kdump service to fail to start if the SCSI device was specified as a dump target on these machines. With this update, mkdumprd has been modified to load the ata_generic module only when required by the specific hardware. The kdump service now starts as expected on IBM System z architecture with SCSI device specified as a dump target.

BZ#821376

Previously, kdump always called the hwclock command to set the correct time zone. However, the Real Time Clock (RTC) interface, which is required by hwclock, is not available on IBM System z architecture. Therefore, running kdump on these machines resulted in the following error messages being emitted:

hwclock: can't open '/dev/misc/rtc': No such file or directory

With this update, kdump has been modified to no longer call the hwclock command when running on IBM System z, and the aforementioned error messages no longer occur.

BZ#825640

When dumping a core file to a remote target using SSH, kdump sends random seeds from the /dev/mem device to the /dev/random device to generate sufficient entropy required to establish successful SSH connection. However, when dumping a core file on the IBM System z with the CONFIG_STRICT_DEVMEM configuration option enabled, reading the /dev/mem was denied and the dump attempt failed with the following error:

dd: /dev/mem: Operation not permitted

With this update, kdump has been modified to reuse the /etc/random_seed file instead of reading /dev/mem. Dumping no longer fails and the core file can now be successfully dumped to a remote target using SSH.

BZ#842476

When booting to the kdump kernel and the local file system specified as the dump target was unmounted, the kernel module required for the respective file-system driver would not have to be included in dumprd. Consequently, kdump could not mount the dump device and failed to capture vmcore. With this update, mkdumprd has been modified to always install the required file system module when dumping a core file to the local file system. The vmcore file can be successfully captured in this scenario.

BZ#859824

When dumping a core file to a remote target using a bonded interface and the target was connected by other than the bond0 interface, kdump failed to dump the core file. This happened because a bonding driver in the kdump kernel creates only one bonding interface named bond0 by default. This update modifies kdump to use the correct bonding interface in the kdump init script so that a core file can be dumped as expected in this scenario.

BZ#870957

When dumping a core file to a SCSI device over Fibre Channel Protol (FCP) on IBM System z, the zFCP device has to be configured and set online before adding WWPN and SCSI LUN to the system. Previously, the mkdumprd utility parsed the zfcp.conf file incorrectly so that the zFCP device could not be set up and the kdump kernel became unresponsive during the boot. Consequently, kdump failed to dump a core file to the target SCSI device. With this update, mkdumprd has been modified to parse the zfcp.conf file correctly and kdump can now successfully dump a core file to the SCSI target on IBM System z. Also, mkdumprd previously always tried to set online Direct Access Storage Devices (DASD) on IBM System z. This resulted in the "hush: can't open '/sys/bus/ccw/devices//online': No such file or directory" error messages to be emitted when booting the kdump kernel in a SCSI-only environment. This update modifies mkdumprd to skip entries from the dasd.conf file if the Linux on IMB System z runs without DASD devices. The aforementioned error messages no longer occur during the kdump kernel boot in the SCSI-only environment on IBM System z.

BZ#872086

Previously, the kexec utility incorrectly recognized the Xen DomU (HVM) guest as the Xen Dom0 management domain. Consequently, the kernel terminated unexpectedly and the kdump utility generated the vmcore dump file with no NT_PRSTATUS notes. The crash also led to a NULL pointer dereference. With this update, kexec collects positions and sizes of NT_PRSTATUS from /sys/devices/system/cpu/cpuN/crash_notes on Xen DomU and from /proc/iomem on Xen Dom0. As a result, the crashes no longer occur.

BZ#874832

Due to recent changes, LVM assumes that the udev utility is always present on the system and creates correct device nodes and links. However, the kdump initramfs image does not contain udev so that LVM was unable to create disk devices and kdump failed. With this update, the mkdumprd utility modifies the lvm.conf configuration file to inform LVM that initramfs does not contain functional udev. If the lvm.conf file does not exist, mkdumprd creates it. The LVM now creates the devices correctly and kdump works as expected.

BZ#876891

Previously, the mlx4_core kernel module was loaded in the kdump kernel on systems using Mellanox ConnectX InfiniBand adapter cards. However, the mlx4_core module requires an extensive amount of memory, which caused these systems to run into an OOM situation and kdump failed. With this update, the second kernel no longer loads the mlx4_core module so that the OOM situation no longer occurs and kdump captures the vmcore file successfully in this scenario.

BZ#880040

Due to recent changes, the libdevmapper library assumes that the udev utility is always present on the system and creates correct device nodes for mulitpath devices. However, the kdump initramfs image does not contain udev therefore LVM was unable to create disk devices and kdump failed. With this update, the mkdumprd utility sets the DM_DISABLE_UDEV environment variable to 1 to inform libdevmapper that the initramfs image does not contain functional udev. The LVM now creates the devices correctly and kdump can successfully dump a core file to a multipath device.

BZ#892703

When setting up a network in the kdump kernel, the mkdumprd code incorrectly renamed network bridges along with NIC names in the network configuration files. This caused the kdump network setup to fail and the vmcore file could not be captured on the remote target. This update modifies kdump to substitute names of network devices correctly so that the network can be set up and vmcore dumped on the remote target as expected.

Enhancements

BZ#822146

With this update, the mkdumprd utility has been modified to support multipath storage devices as dump targets, which includes the ability to activate multiple NICs in the second kernel.

BZ#850623

This update modifies kdump to always extract the dmesg output from the captured vmcore dump file, and save the output in a separate text file before dumping the core file.

BZ#878200

The /usr/share/doc/kexec-tools-2.0.0/kexec-kdump-howto.txt file has been modified to provide a comprehensive list of supported, unsupported, and unknown dump targets under the “Dump Target support status” section.