Red Hat Bugzilla – Bug 244464
kdump won't install -- initscript fails
Last modified: 2007-11-30 17:12:07 EST
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 157173 [details] patch to /etc/init.d/kdump This patch attempts to: (1) suppress "debug" in kdump_kver (2) suppress second "kdump" in kdump_initrd
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!
fixed in -57.fc6. Thanks!
Re #7: Great! I was actually reporting a problem in kexec-tools-1.101-69.fc7.x86_64. I don't see an update in http://download.fedora.redhat.com/pub/fedora/linux/updates/7/x86_64/ or http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/x86_64/
Sorry, that was a typo, and was meant for another bz. I meant to close this as WORKSFORME with the above sysconfig file on the latest F7 kexec-tools package