4.78. kexec-tools


Updated kexec-tools packages that fix a bug are now available for Red Hat Enterprise Linux 5.
The kexec fastboot mechanism allows booting a Linux kernel from the context of an already running kernel. The kexec-tools package provides the /sbin/kexec binary and ancillary utilities that form the user-space component of the kernel's kexec feature.

Bug Fix

BZ#822617
When one interface was used for a iSCSI boot environment while is other was used by kdump with the "net" option on, the ifconfig utility caused an error. Consequently, vmcore was not collected in a dump server that stores vmcore specified in the kdump.conf file. This bug has been fixed and a memory dump capture now succeeds by kdump in an iSCSI boot environment.
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 one enhancement are now available for Red Hat Enterprise Linux 5.
The kexec fastboot mechanism allows booting a Linux kernel from the context of an already running kernel. The kexec-tools package provides the /sbin/kexec binary and ancillary utilities that form the user-space component of the kernel's kexec feature.

Bug Fixes

BZ#716340
Previously, kdump could become unresponsive if a disk name was changed. This could happen because the kdump initrd did not include irrelevant disk drivers that were used in the first kernel. Persistent disk names change in kdump presents considerable risk to Red Hat Enterprise Linux 5 stability. Therefore, this problem has been resolved by updating the kdump.conf file to recommend to use disk UUIDs or LABELs instead of disk names for file-system based dump targets.
BZ#716386
Previously, kdump did not verify whether the target raw dump device exists before attempting to dump a core file. Instead, kdump started to rebuild an initrd image directly, which resulted in a kdump failure. Furthermore, even though raw dump succeeded, kdump did not verify whether the vmcore file was saved and the core file could not be recovered. This update modifies the kdump init script to perform verification tests on the target device. Kdump now no longer rebuilds the initrd image if the target device does not exist and properly recovers a core file if the raw dump has succeeded.
BZ#752930
Kdump previously used an IP address as a part of the core dump directory name only for remote core dumps, which was confusing the users. With this update, kdump was modified to use the IP address of the loopback device (127.0.0.1) for local dumps so that the core dump directory name has the same form for both local and remote core dumps.
BZ#771829
Usually, when dumping a vmcore file over network, kdump has to bring up only one network interface card (NIC). However, when dumping to an iSCSI device, kdump may need to bring up multiple NICs. This functionality was not previously implemented in kdump and any dump attempt to the iSCSI device that required multiple NICs failed. With this update, kdump has been modified to be able to bring up multiple NICs if needed, and vmcore can now be successfully dumped on the iSCSI device.
BZ#788678
The mkdumprd utility did not detect the /var file system if it was mounted on a separate partition, which caused kdump to fail to dump a core file. This update modifies mkdumprd to detect the partition that contains the /var file system correctly. Kdump no longer fails in this scenario.
BZ#801496
When dumping a core file using ssh and the remote kdump user is configured to use restricted shell (rksh), the core dump attempt failed. This happened because kdump used the cat > command to store the vmcore file and the restricted shell forbids redirection. This update modifies kdump to use the dd command to save the vmcore file instead and dumping is now successful in this scenario.
BZ#802928
The mkdumprd utility did not correctly handled NICs if the NIC had the BOOTPROTO=none parameter configured in the ifcfg file. Consequently, kdump was not able to bring the NIC up and failed to dump a core file over network. This update corrects mkdumprd to recognize the BOOTPROTO=none parameter, and such NICs are now properly brought up when dumping a core file over network.
BZ#809983
Previously for ext2, ext3 and ext4 file systems, if the dump location was on different file system than was the root file system, the mkdumprd utility searched only for the ext4 kernel module. Consequently, kdump failed to recognize a file system and dump a core file. This update modifies mkdumprd to find proper kernel module also for ext2 and ext3 file systems and kdump works as expected in this scenario.
BZ#832017
Currently on Red Hat Enterprise Linux 5, the dd utility is the default core collector when dumping on a raw partition. However, the only core collector supported by kdump is the makedumpfile utility, which is not able to recognize vmcore files copied by dd. Previously, when the vmcore file was dumped on a raw partition, it was considered invalid and the core file recovery failed. With this update, mkdumprd has been modified to display a warning message when a different core collector than makedumpfile was used to compress the core file on the raw partition. The user has to recover the core dump manually.

Enhancement

BZ#587361
Previously, the vmcore file could not be dumped to a multipath device because kexec-tools did not support this option. This update introduces multipath target support, which allows vmcore to be captured with multipath devices.
Users of kexec-tools are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.