8.83. kexec-tools

Bug Fixes

BZ#1015764

Previously, in the mkdumprd utility, the strip_comments() function was not implemented correctly. When arguments were passed to strip_comments(), it only took the first argument into account and skipped the rest. As a consequence, it passed the "makedumpfile" argument to the $config_val variable, but the parameters for "makedumpfile" were missed. With this update, the strip_comments() function has been modified. As a result, it no longer skips arguments passed to it.

BZ#886572

When the kdump file system resided on a logical volume or a volume group with another independent and encrypted device, the mkdumprd utility exited with an error message when trying to access the encrypted device, preventing kdump from functioning properly. A patch has been provided to address this problem and kdump is now properly reconfigured and restarted in the described scenario, thus fixing this bug.

BZ#920705

Certain multi-port network cards return the same PCI bus address for all ports. When the kdump utility maps the network ports, it cannot differentiate one network port from another on these cards. Consequently, when different network ports were on different networks, kdump failed to dump data over NFS or SSH. This update ensures that the MAP_NET_BY_MAC variable is set in the described scenario and kdump now dumps data for all ports as expected.

BZ#883543

Previously, a udev rule in the 98-kexec.rules file spawned processes that restarted the kdump tool with each memory added. To fix this bug, the "condrestart" parameter is used when attempting to restart a service that was previously running. As a result, kdump is no longer restarted when a restart is not needed.

BZ#921142

Previously, kernel modules in the extra_modules list were overridden by the built-in blacklist. Consequently, kdump was unable to load the mlx4_core and mlx4_en modules and dump data over network cards using these modules. With this update, modules in the extra_modules list are not excluded if they are blacklisted and kdump can use them as expected.

BZ#1008543

Previously, in makedumpfile, the dumpfile header had a field which was inherited from the deprecated "diskdump" facility. The field was used by the crash utility as a delimiter to determine whether a physical address read request was legitimate. The field could not handle Physical Frame Number (PFN) values greater than 32-bits and such values were truncated. This update adds three new fields to the header. As a result, the dumpfile header in makedumpfile correctly handels PFN values greater than 32-bits.

BZ#876667

Previously, for some kernel modules, the "modprobe --show-depends" command's output did not have the "insmod" prefix for every line. Consequently, the mkdumprd utility failed to load as the current code assumed that each line started with the "insmod" prefix. The code has been modified to only match lines starting with "insmod" in awk scripts. As a result, mkdumprd no longer fails to load in this scenario.

BZ#1009207

Previously, in cyclic mode, the makedumpfile recalculated incorrectly the size of the cyclic buffer size. As a consequence, makedumpfile did not update the length of the range of a cycle in page frame numbers, which caused a buffer overrun or a segmentation violation. Furthermore, due to the divideup() function in the recalculations, the cyclic buffer size became too much aligned and less efficient. A patch has been provided to fix these bugs and the aforementioned problems no longer occur in this scenario.

BZ#1010103

The x86_64 kernel is a relocatable kernel, and there can be a gap between the physical address statically assigned to the kernel data and texts, and the address that is really assigned to each object corresponding to the kernel symbols. The gap is the phys_base() function. The makedump utility calculates the phys_base in an ad-hoc way that compares the addresses of some of occurrences of "Linux kernel" strings in certain range of the vmcore. As a consequence, makedumpfile failed calculating phys_base and also failed converting a vmcore. This bug has now been fixed and makedumpfile calculates phys_base correctly and convers vmcore normally.

BZ#893764

Previously, setting empty Direct Access Storage Device (DASD) options, parsed from the /etc/dasd.conf file, resulted in displaying environment variables. As a consequence, restarting the kdump service displayed the complete kdump script. After this update, if there are no options specified in the /etc/dasd.conf file for a device, the kdump script proceeds to the next one. As a result, restarting the kdump service no longer displays the complete kdump script.

BZ#918372

Previously, kdump data written on a raw device was not completely flushed. As a consequence, the saved vmcore was occasionally incomplete. This update uses the blockdev tool to flush out block device buffers. As a result, vmcore saved on a raw device is now always complete.

BZ#903529

Previously, because Storage Class Memory (SCM) devices did not expose the same sysfs attributes as Small Computer System Interface (SCSI) disks, the mkdumprd utility failed to determine the list of "critical disks" for writing a dump file. As a consequence, certain SCM devices were not correctly handled by mkdumprd, resulting in an infinite loop when trying to specify a file system on such a device as target for kdump. After this update, mkdumprd now handles waiting for SCM devices based on the device's storage increment address, a property which uniquely identifies an SCM device across reboots. As a result, mkdumprd now successfully determines the list of "critical disks" for writing a dump file and an infinite loop no longer occurs.

BZ#906601

Previously, on a system configured with multipath support, the mkdumprd tool pushed the code handling multipath devices into the kdump initrd. As a consequence, the kdump utility failed to capture vmcore on multipath devices. This update introduces a mechanism where the call to the kpartx utility is delayed until the "dmsetup ls" command lists the device names which match the multipath device where a vmcore is going to be captured. As a result, mkdumprd now waits until the multipath devices are created and then successfully captures a vmcore on them.

BZ#977651

Previously, when Red Hat Enterprise Linux was configured to use the hugepages parameter, the kdump kernel also used this parameter. As a consequence, due to its limited memory, using hugepages could lead to an Out Of Memory (OOM) error for the kdump kernel. With this update, hugepages and hugepagesz kernel parameters are not used by the kdump kernel when the Red Hat Enterprise Linux is using them. If the user wants to explicitly use hugepages in the kdump kernel, they can be specified through the KERNEL_COMMANDLINE_APPEND option in the /etc/sysconfig/kdump file.

BZ#963948

Previously, when a VMware guest was added additional RAM, multiple instances of the kdump.init script were started concurrently. As a consequence, a race condition occurred among the kdump.init instances. By introducing a global mutex lock, now only one instance can acquire this lock and run, others will be waiting for the lock in queue. As a result, the kdump.init instances are run in serial order and a race condition no longer occurs in this scenario.

BZ#951035

Previously, when the e2fsprogs package, which contains tools used by the mkdumprd utility, was not installed on the system, mkdumprd displayed a misleading error message. With this update, the error message has been improved to explicitly inform the user which of these tools is missing.

Enhancements

BZ#959449

This update allows the kdump tool to work with an arbitrary bridge, bond or vlan names over a network. Now, it is possible to name a device without following the established naming conventions, for example, bonding devices do not need to start with "bond". The user can determine whether a network device is a bond, bridge or vlan by checking for the existence of specific directories in the /sys/ or /proc/ directories.

BZ#871522

With this update, kexec-tools now respect the memory limit while building crash memory ranges on a 64-bit PowerPC. The kernel exports memory limit information through the /proc/device-tree file, which kexec-tools now read and limit the crash memory ranges accordingly.

BZ#825476, BZ#902147, BZ#902148

In Red Hat Enterprise Linux 6.5, the makedumpfile utility supports the Lempel–Ziv–Oberhumer (LZO) and snappy compression formats. Using these compression formats instead of the zlib format is quicker, in particular when compressing data with randomized content.

BZ#947621

This update includes changes to allow filtering of poisoned pages during a crash dump capture. The user can now decide if poisoned pages are dumped. Furthermore, filtering can increase dumping speed.

BZ#797231

This update adds an SELinux relabeling during kdump service startup. The kdump service now relabels files in the dumping path which have an incorrect or missing label.

BZ#909402

In previous Red Hat Enterprise Linux releases, support for SSH FIPS mode was incomplete. This update adds the relevant library files and *.hmac files to the kdump kernel. The kdump utility can now work in SSH FIPS mode.

BZ#975642

This update adds documentation for the "--allow-missing" mkdumprd option to the mkdumprd(8) manual page.