- Kdump used the Secure Shell (SSH)
StrictHostKeyChecking=nooption when dumping to SSH targets, causing the target kdump server's SSH host key not to be checked. This could make it easier for a man-in-the-middle attacker on the local network to impersonate the kdump SSH target server and possibly gain access to sensitive information in the vmcore dumps.
- mkdumprd created initial RAM disk
(initrd)files with world-readable permissions. A local user could possibly use this flaw to gain access to sensitive information, such as the private SSH key used to authenticate to a remote server when kdump was configured to dump to an SSH target.
- mkdumprd included unneeded sensitive files (such as all files from the
/root/.ssh/directory and the host's private SSH keys) in the resulting
initrd. This could lead to an information leak when
initrdfiles were previously created with world-readable permissions.
NoteWith this update, only the SSH client configuration, known hosts files, and the SSH key configured via the newly introduced sshkey option in
/etc/kdump.confare included in the
initrd. The default is the key generated when running the
service kdump propagatecommand,
- Kdump is a kexec based crash dumping mechanism for Linux. Root System Description Pointer (RSDP) is a data structure used in the ACPI programming interface. Kdump uses kexec to boot to a second kernel, the "dump-capture" or "crash kernel", when a dump of the system kernel's memory needs to be taken. On systems using Extensible Firmware Interface (EFI), attempting to boot a second kernel using kdump failed, the
dump-capturekernel became unresponsive and the following error message was logged.
ACPI Error: A valid RSDP was not foundWith this update, a new parameter,
acpi_rsdp, has been added to the
noefikernel command. Now, if EFI is detected, a command is given to the second kernel, in the format,
noefi acpi_rsdp=X, not to use EFI and simultaneously passes the address of RSDP to the second kernel. The second kernel now boots successfully on EFI machines.
- To reduce the size of the vmcore dump file, kdump allows you to specify an external application (that is, a core collector) to compress the data. The core collector was not enabled by default when dumping to a secure location via SSH. Consequently, if users had not specified an argument for
core_collectorin kdump.conf, when kdump was configured to dump kernel data to a secure location using SSH, it generated a complete vmcore, without removing free pages. With this update, the default core collector will be makedumpfile when kdump is configured to use SSH. As a result, the vmcore dump file is now compressed by default.
- Previously, the mkdumprd utility failed to parse the
/etc/mdadm.confconfiguration file. As a consequence, mkdumprd failed to create an initial RAM disk file system (
initrd) for kdump crash recovery and the kdump service failed to start. With this update, mkdumprd has been modified so that it now parses the configuration file and builds
initrdcorrectly. The kdump service now starts as expected.
- In order for Coverity to scan defects in downstream patches separately, it is necessary to make a clean raw build of the source code without patches. However, kexec-tools would not build without downstream patches. With this update, by adding a specified patch in kexec-tools spec file, kexec-tools can now be built from source in the scenario described.
- On 64-bit PowerPC-based systems with more than 1 TB of RAM, the kexec-tools utility terminated unexpectedly with a segmentation fault when kdump was started, thus preventing crash kernel capture. With this update, the problem has been fixed, kexec-tools no longer crashes, and kdump can now be used on a system with greater than 1 TB of physical memory.
- The mkdumprd utility creates an initial RAM disk file system (
initrd) for use in conjunction with the booting of a second kernel within the kdump framework for crash recovery. Prior to this update, mkdumprd became unresponsive when the running kernel was not the same as the target kernel. With this update the problem has been fixed and mkdumprd no longer hangs in the scenario described.
- A regression caused the following erroneous error message to be displayed when kdump was setting up Ethernet network connections in order to reach a remote dump target:
sed: /etc/cluster_iface: No such file or directoryA patch has been applied to correct the problem and the error no longer occurs in the scenario described.
- During kdump start up, a check was made to see if the amount of RAM the currently running kernel was using was more than 70% of the amount of RAM reserved for kdump. If the memory in use was greater than 70% of the memory reserved, the following error message was displayed.
Your running kernel is using more than 70% of the amount of space you reserved for kdump, you should consider increasing your crashkernel reservationDue to improvements in conserving memory in the kexec kernel the warning is no longer considered valid. This update removes the warning.
- Previously, if kexec-tools was installed and kdump was not running, installing the fence-agents package caused the following erroneous error message:
Non-fatal <unknown> scriptlet failure in rpm packageThis update corrects the kexec-tools spec file and the erroneous error message no longer appears.
- Removing kexec-tools on IBM System z resulted in the following error, even though the package was successfully removed.
error reading information on service kdump: No such file or directoryWith this update, changes have been made to the kexec-tools spec file and the erroneous error message no longer appears.
- When providing firmware at operating system install time, supplied as part of the Driver Update program (DUP), the installation completed successfully but the operating system would fail on reboot. An error message in the following format was displayed:
cp: cannot stat `/lib/firmware/*': No such file or directoryWith this update, a check for the directory containing the DUP supplied firmware is made and the problem no longer occurs.
- With large memory configurations, some machines take a long time to dump state information when a kernel panic occurs. The cluster software sometimes forced a reboot before the dump completed. With this update, co-ordination between kdump and cluster fencing for long kernel panic dumps is added.
- A new configuration option in
force_rebuild, has been added. When enabled, this option forces the kdump init script to rebuild
initrdevery time the system starts, thus ensuring kdump has enough storage space on each system start-up.
- On x86, AMD64 & Intel 64 platforms kexec-tools now uses
maxcpus=1to save memory required by the second kernel. PowerPC platforms currently cannot handle this feature.
- A warning was added to use
nr_cpus=1for older kernels (see the enhancement above).
- Kdump has been provided with an option so that memory usage can be logged in the second kernel at various stages for debugging memory consumption issues. The second kernel memory usage debugging capability can be enabled via the new
- BZ#740275, BZ#740277
- With this update, kdump support for dumping core to
ext4file systems, and also to
XFSfile systems on data disks (but not the root disk) has been added.
For XFS, the XFS layer product needs to be installed. Layered products are those not included by default in the base Red Hat Enterprise Linux operating system.
- With this update, kdump support for dumping core to
Btrfsfile systems has been added.
BusyBox's "findfs" utility does not yet support Btrfs, so UUID/LABEL resolving does not work. Avoid using UUID/LABEL syntax when dumping core to Btrfs file systems. Btrfs itself is still considered experimental; refer to Red Hat Technical Notes.
- Kdump did not check the return code of the
mountcommand. Consequently, when the command
mount -t debugfs debug /sys/kernel/debugwas issued in the kdump service script, if the file system was already mounted, the message returned was erroneously logged as an error message. With this update, the logic in the kdump service script has been improved and the kdump service script now functions as expected.
- When running kdump after a kernel crash on the system using the ext4 file systems, the kdump initrd could have been created with the zero byte size. This happened because the system waits for several seconds before writing the changes to the disk when using the ext4 file system. Consequently, the kdump initial root file system (rootfs) could not have been mounted and kdump failed. This update modifies kexec-tools to perform the sync operations after creating the initrd. This ensures that initrd is properly written to the disk before trying to mount rootfs so that kdump now successfully proceeds and captures a core dump.
- The kdump utility does not support Xen para-virtualized (PV) drivers on Hardware Virtualized Machine (HVM) guests in Red Hat Enterprise Linux 6. Therefore, kdump failed to start if the guest had loaded PV drivers. This update modifies underlying code to allow kdump to start without PV drivers on HVM guests configured with PV drivers.