Description of problem:
After following the instructions in
http://fedoraproject.org/wiki/FC6KdumpKexecHowTo
"/sbin/service kdump start" fails with a non-informative message.
The actual command inside the script that failed was:
/sbin/kexec --args-linux -p '--command-line=ro root=LABEL=/ irqpoll
maxcpus=1' --initrd=/boot/initrd-2.6.21-1.3228.fc7debugkdump.img
/boot/vmlinuz-2.6.21-1.3228.fc7debug
The message that it generates (but that is suppressed in the script) is:
BzImage is not relocatable. Can't be used as capture kernel.
Cannot load /boot/vmlinuz-2.6.21-1.3228.fc7debug
This kernel is fedora supplied. file(1) says of it:
/boot/vmlinuz-2.6.21-1.3228.fc7debug: Linux kernel x86 boot executable
RO-rootFS, swap_dev 0x1, Normal VGA
Version-Release number of selected component (if applicable):
kernel-debug-2.6.21-1.3228.fc7.x86_64
kexec-tools-1.101-69.fc7.x86_64
kernel-kdump-2.6.21-1.3228.fc7.x86_64
How reproducible:
all the time
Steps to Reproduce:
See above
Actual results:
"service kdump start" fails
Expected results:
"service kdump start" succeeds
Additional info:
During the first run of kdump initscript, it seems to have built a new initial
ramdisk.
What is /boot/vmlinux-2.6.21-1.3228.fc7kdump?
Should there be a /boot/vmlinux-2.6.21-1.3228.fc7debugkdump?

Just run 'service kdump start' instead of following those directions. They
appear out of date. Also, what is vmlinuz-2.6.21-1.3228.fc7debug? That doesn't
seem like a fedora built kernel (unless its out of the debuginfo package). You
should either be using the kernel that you normally boot with (no extension
beyond the fc7 package name), or, if you use an older kexec-tools, you should
use the kernel-kdump package, and point /etc/sysconfig/kdump at the kernel it
installs.

I just switched to booting the non-debug kernel. Still the same failure. The
failing command in the script is the same one but with different args:
# /sbin/kexec --args-linux -p '--command-line=ro root=LABEL=/ irqpoll
maxcpus=1' --initrd=/boot/initrd-2.6.21-1.3228.fc7kdump.img
/boot/vmlinuz-2.6.21-1.3228.fc7
zImage is not relocatable. Can't be used as capture kernel.
Cannot load /boot/vmlinuz-2.6.21-1.3228.fc7
However, I can manually run the command with a different kernel arg and it WORKS:
/sbin/kexec --args-linux -p '--command-line=ro root=LABEL=/ irqpoll
maxcpus=1' --initrd=/boot/initrd-2.6.21-1.3228.fc7kdump.img
/boot/vmlinux-2.6.21-1.3228.fc7kdump
There seem to be two bugs and a deficiency.
(1) no kdump kernel for the debug variant of the kernel
(2) the kdump initscript looks for vmlinuz not vmlinux
(3) (RFE) the diagnostics produced by kexec, when it fails, should be logged
How important is it that the kexeced kernel match the main kernel? For example,
is it reasonable to run the kdump kernel (without debug) and the regular kernel
with debug?
Perhaps one problem is in /etc/sysconfig/kdump where KDUMP_IMG is defined to be
vmlinuz, not vmlinux.

regarding #1.
Thanks for looking at this so promptly.
The directions I followed included 'service kdump start' and that is the command
that failed. To clarify, the chkconfig in those directions causes the kdump
service to start at boot time. But I ran it manually too to figure out the
manner of its failure.
The debug kernel was from a Fedora-supplied package that I listed in my original
report (kernel-debug-2.6.21-1.3228.fc7.x86_64).
Even when I use a non-debug kernel, 'service kdump start' fails (see #2). I do
point out a work-around.
Using a debug kernel would seem fairly natural when trying to crack a kernel
problem. And so would using kdump. It would be good if they could co-exist.
My *guess* is that the initscript could strip "debug" off the kernel name just
the way it strips off "smp". But I don't know.

In /etc/sysconfig/kdump, I set
KDUMP_KERNELVER="2.6.21-1.3228.fc7kdump"
(My earlier suggestion of changing KDUMP_IMG and stripping "debug" was not
sufficient to get things working.)
This causes the initscript to look for an initrd with the name
/boot/initrd-2.6.21-1.3228.fc7kdumpkdump.img
Upon failing to find that, it builds one. I don't imagine that this is a good
idea. There does not seem to be a setting that avoids this, so I'd call this a
bug in the initscript.

Created attachment 157299[details]
x86_64 sysconfig file for kdump
I'd really rather not take that patch, mostly because you shouldn't be
rebooting using the debug kernel with kexec under x86_64. The kernel-kdump
package is specifically built to run after a kexec-initiated reboot (at least
until such time as the relocatable patch is in place for x86_64). We could
suppress the second kdump in the initrd, but its not really necessary, if you
set up your /etc/sysconfig/kdump properly. I've just tested the attached
sysconfig file with kernel-2.6.20-1.2952.fc6 and kernel-kdump-2.6.20-1.2952.fc6
and it works just fine. I'll check this change in shortly for x86_64. Thanks!