このコンテンツは選択した言語では利用できません。
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 diskUUIDs
orLABELs
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 thevmcore
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 modifiesmkdumprd
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 thevmcore
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 theBOOTPROTO=none
parameter, and such NICs are now properly brought up when dumping a core file over network. - BZ#809983
- Previously for
ext2
,ext3
andext4
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 themakedumpfile
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 thanmakedumpfile
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 amultipath
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.