Kdump hangs "Rebuilding /boot/initrd-...kdump.img"

Latest response

I recently patched several RHEL6 machines. A small subset of them kernel panic with 2.6.32-504.8.1.el6.x86_64. If I go into the boot menu and choose an older kernel (like 2.6.32-431.29.2.el6.x86_64) the machine boots and then seems to hang at:

 /etc/kdump.conf
 Rebuilding /boot/initrd-2.6.32-431.29.2.el6.x86_64kdump.img

Is there any way to investigate this issue? Or does this process normally take a long time (minutes/hours)?

Any help / insight is greatly appreciated.

Responses

I have run into this problem when I have kdump configured to dump via NFS, but NFS is not currently running on the NFS server, or if the NFS server is down at the time.

I don't believe I have NFS running but the 'problem' machines in question do have multipath-IO LUNs in the multi-TB range.

I tried manually fixing things with dracut and kdump after booting fine into single user mode to no avail. Since the machines needed to be back up for users, I did not get a chance to poke around /etc/modprobe* but ultimately did a manual reboot with a known good kernel and the 'crashkernel=auto' option temporarily removed.

We will look towards a better fix in our next scheduled maintenance window. On the plus side, the machine has been running for several years and never had to put anything into /var/crash/...

I have nothing to back this up.. but I am wondering whether kdump is fine and it's the next process in the path that is actually hung up. On my system, it is
S25blk-availability
"# Short-Description: Availability of block devices"

I would boot using rescue-mode and disable Kdump (temporarily) and see if it manages to proceed. You should be able to manually start kdump later.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.