5.136. kexec-tools

Updated kexec-tools packages that fix one bug are now available for Red Hat Enterprise Linux 6.
The kexec-tools packages contain the /sbin/kexec binary and utilities that together form the user-space component of the kernel's kexec feature. The /sbin/kexec binary facilitates a new kernel to boot using the kernel's kexec feature either on a normal or a panic reboot. The kexec fastboot mechanism allows booting a Linux kernel from the context of an already running kernel.

Bug Fix

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 file with no NT_PRSTATUS notes. The crash also led to 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.
All users of kexec-tools are advised to upgrade to these updated packages, which fix this bug.
Updated kexec-tools packages that fix multiple bugs and add several enhancements are now available for Red Hat Enterprise Linux 6.
The kexec-tools package provides the /sbin/kexec binary that facilitates a new kernel to boot using the kernel kexec feature. This package contains ancillary utilities that together with the binary form the user-space component of the kernel kexec feature.

Bug Fixes

The kdump utility failed to find the member device if a member device of a bridge was renamed, that is, it was not using its default device name. Consequently, bridge mapping and kdump over network failed. With this update, the bridge member details are acquired from transformed ifcfg files when gaining the bridge member name for the dump kernel and kdump over network succeeds in this scenario.
The kdump utility does not support Xen para-virtualized (PV) drivers on Hardware Virtualized Machine (HVM) guests. Therefore, kdump failed to start if the guest had PV drivers. This update modifies the code that allows kdump to start without PV drivers on HVM guests configured with PV drivers.
Previously, kdump did not handle dumping over a bonding device in an IEEE 802.1Q network correctly and failed when requesting a core dump through such a device. With this update, code to allow kdump to handle VLAN tagging, so as to operate on such bonding devices properly, has been added and kdump succeeds under these circumstances.
On IBM System z architectures, kdump request over network failed as no core dump was found on the remote server. This happened because network devices were not brought online before IP configuration. The IP configuration, therefore, referred to a non-existing network interface and the connection failed. With this update, network devices are brought online before the IP information is set.
Previously, kdump did not bring up a bonding device and failed if the BOOTPROTO property in the ifcfg<device> networking script of the bonding device was set to none. This happened because the mkdumprd utility did not handle the BOOTPROTO setting correctly. With this update, mkdumprd handles the setting correctly and kdump succeeds when dumping remotely over a bonding device with the BOOTPROTO=none setting.
On x86 architectures, if the crashkernel boot option is set to auto to allow automatic reservation of memory for the kdump kernel, the threshold memory changes to 2 . However, the firstboot application was incorrectly using the 4 GB threshold. With this update, firstboot uses the same threshold value as the kernel.
When kdump did not have permissions to dump to a NFS (Network File System) target, a kernel panic occurred. This happened because the init script of the kdump kernel did not check permissions to the target NFS resource after kdump had already started. With this update, the init script checks the NFS directory permissions and kdump performs the default action specified by the user for situations when NFS dump fails due to lacking permissions.
Previously, kdump failed if run with FCoE HBA Driver (fnic) and iSCSI dump targets. This update adds support for iSCSI targets using software initiators without iBFT. Note that iSCSI targets using hardware initiators are not supported.
The mkdumprd utility uses the root device as the default dump target for the kdump initrd if the /etc/kdump.conf file does not define a dump target. However, mkdumprd used the device name instead of its UUID (Universally Unique Identifier), which could cause kdump to fail. With this update, the device UUID is used instead of its device name by default and kdump over root device succeeds in the scenario described.
Previously, kdump could not capture the core dump when the target partition was encrypted and errors occurred. With this update, kdump warns the user when they specify an encrypted device as a dump target.
Due to a bug in the makedumpfile utility, the utility failed when used to re-filter the vmcore core dump. With this update, makedumpfile has been modified to handle the input from vmcore correctly.
Previously, when makedumpfile was redirected using the pipeline to ssh and failed, kdump did not drop the shell to the user even though the default_action property was set to shell in the kdump.conf file. With this update, the pipeline redirection fails as soon as makedumpfile fails and the shell is dropped immediately in the scenario described.
Previously, due to a bug in the mkdumprd utility, data on an NFS server could be removed when the NFS unmount process failed. With this update, the problem has been fixed and the original data on the NFS server is now retained unchanged if unmounting fails.
The kdump kernel did not clear the MCE (Machine Check Exception) status propagated from the kernel; the kdump kernel continued to boot without clearing the MCE status bits and triggered the MCE error again. With this update the MCE error in the kernel is not passed to the kdump kernel.
The kdump utility did not bring DASDs (Direct Access Storage Devices) online before copying the vmcore file on IBM System z architectures. Consequently, kdump was waiting for the device and became unresponsive. With this update, DASD devices are brought online before copying vmcore and kdump works as expected in the scenario described.
When running kdump after a kernel crash on a system with an ext4 file system, the kdump initrd (initial RAM disk) could have been created with zero-byte size. This happened because the system waits for several seconds before writing the changes to the disk on an ext4 file system. Consequently, the kdump initial root file system (rootfs) could not be mounted and kdump failed. This update modifies kexec-tools so that it perform the sync operations after creating initrd. This ensures that initrd is properly written to the disk before trying to mount rootfs, and kdump now successfully proceeds and captures the core dump on systems with an ext4 file system.
When using SSH or NFS, it was not possible to capture the vmcore file if using a static IP without a gateway. This happened because the mkdumprd utility wrote an empty value as the gateway address into initrd. With this update, the gateway address is not assigned any value and kdump in such environments succeeds.
On IBM System z, the makedumpfile command could fail because it did not translate virtual addresses to physical addresses correctly. With this update, makedumpfile handles virtual addresses correctly on these architectures and the command execution succeeds in this scenario.
The kdump utility failed to load proper fonts for the kdump shell. Consequently, colored characters were returned in the Cyrillic alphabet in the kdump shell. With this update, the console fonts are installed in kdump initrd and the kdump default shell returns colored characters in the Latin alphabet as expected.
The mkdumprd utility handled only the default path (the /lib/modules/<kernelVersion>/ directory) of a modprobe and did not cover other module directories. Consequently, mkdumprd failed if there were modules located in other that the default path directory. The mkdumprd utility now handles /lib/modules/<kernelVersion>/updates/ as well as the /lib/modules/<kernelVersion>/ directory and mkdumprd succeeds under these circumstances.
Previously, even though the SELinux policycoreutils package was not installed, mkdumprd used the sestatus and setenforce utilities. Consequently, kdump threw the following error while propagating ssh keys:
/etc/init.d/kdump: line 281: /usr/sbin/sestatus: No such file or directory
With this update, mkdumprd acquires information on the policycoreutils availability and processes the SELinux attribute using the sysfs tool.


When the policycoreutils package is removed, SELinux must be disabled by adding the selinux=0 option to the kernel command line. A system with SELinux enabled and the policycoreutils package not installed is considered a broken environment in which kdump returns the aforementioned errors. When you remove the policycoreutils package, make sure you have also disabled SELinux with selinux=0; otherwise, the problem will preserve.
The restricted shell (rksh) does not allow redirections using a pipeline. Consequently, kdump failed if the remote user that was used when requesting the core dump was configured with a restricted shell. With this update, the dd command is used instead of cat to copy vmcore, and kdump succeeds when a remote user uses the rksh shell.
Previously, kdump could become unresponsive if called through a wireless interface as this option is not supported even though the iwlwifi (Intel Wireless WiFi Link) modules for interface devices were included in kdump initrd. With this update, the iwlwifi modules are no longer loaded into kdump initrd.
Previously, the order in which kdump loaded storage drivers caused that a USB-attached storage was sometimes not correctly detected on certain 32-bit x86 systems. Consequently, devices were enumerated wrongly, and dumps therefore failed. The code has been fixed and the core dump takes place successfully.
The mkdumprd utility ignored the PREFIX variable setting and the ifconfig utility failed during core dumping over network. With this update, the mkdumprd utility handles the PREFIX variable setting in ifcfg-<device> network scripts correctly.
When the dump target was a raw device, the kdump init script created an unnecessary directory and an empty vmcore file in the /var/crash/ directory. With this update, kdump checks the device header of the target device. If the header is invalid, kdump does not handle the situation as a crash and the redundant resources are no longer created on raw devices.
When booting the kdump environment failed, kdump mounted the root device and ran the init script in user space if no default action was specified in the kdump.conf file. However, running init in user space to capture the core dump could cause an OOM (Out of Memory) state in the dump kernel. With this update, the kernel is now rebooted by default under these circumstances. Also, a new default option, mount_root_run_init, has been added to kdump. With this option, the kernel mounts the root partition, and runs the init and kdump service to try to save the kernel core dump, which allows the user to apply the previous behavior of kdump.


Support for kdump on IBM System z has been added.
The firstboot utility now supports configuring kdump for IBM S/390 architectures.
Previously, the vmcore code dump could contain sensitive information, such as security keys, and potentially leak security information of the root user. With this update, the makedumpfile tool filters out such sensitive kernel data and vmcore no longer contains any sensitive security information.
On IBM System z, the makedumpfile utility has been improved to handle vmcore correctly and the output no longer contains spurious errors.
The kdump utility now supports the NFSv4 file system format.
The makedumpfile can now handle Fujitsu's sadump dump format.
The kdump utility now supports multipath storage devices as its dump targets.
Users of kexec-tools should upgrade to these updated packages, which fix these bugs and add these enhancements.