Thanks to all who replied.
Our problem was resolved. It was caused by two different
configuration issues:
1) As Don and Neil said, the kdump initrd img should not be
in the menu.lst. Not sure why it was there at first place.
So we changed the boot line to use the orignial initrd img.
2) We had multiple lines of "ext3 LABEL=xxx" and it
guarantees at least one of them fail during mkdumprd
and kdump not started properly.
All is fine now. Thanks to all who replied!
Jay
On 09/28/2011 07:30 AM, Neil Horman wrote:
> On Wed, Sep 28, 2011 at 09:08:42AM -0400, Don Zickus wrote:
>> On Tue, Sep 27, 2011 at 11:38:28AM -0700, Jay Lan wrote:
>>> Hi all,
>>>
>>> I have a system running 2.6.18-238.12.1.el5 kernel.
>>> The kexec version is kexec-tools-1.102pre-126.el5_6.6.
>>>
>>> The kernel was booted OK. Then it ran /etc/init.d/kdump
>>> and a new kdump initrd image was created.
>>> A kernel crash was triggered. The kdump kernel was booted
>>> alright. However, it failed to boot when it tried to boot
>>> back the regular kernel (now with the kdump initrd image
>>> specified in the menu.lst.)
>> Not sure why you would see the kdump initrd image in the menu.lst, it is
>> just a parameter sent to kexec.
>>
> Its actually not even passed to kexec, we build the initrd using the output of
> uname -a, or override it manually with an option in /etc/sysconfig/kdump. We
> don't ever mount the /boot partition, so /boot/grub/menu.lst shouldn't be
> accessible for re-writing.
>
>> You might have more success filing a Red Hat bz (bugzilla.redhat.com), as
>> the RHEL-5 kernel and kexec-tools are probably too old for discussion on
>> this list.
>>
> Agreed, initramfs construction is a distro specific operation, the upstream
> project doesn't contain bits on how to do that.
> Neil
>
>> Cheers,
>> Don
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
