Description of problem: The dump kernel fails to load. Many messages of the type: Creating block device ramXX (where XX ranges in 1,10,11,12,13,14,15,2,3,4,5,6,7,8,9,sda) Busy Box v1.16... Usage mknod ... ... ... Making device-mapper control node Busy Box v1.6... Usage: mknod ... Scanning logical volumes No volume group found (actually there are some) Saving to the local fs ... fsck.ext3 : not found ... Dropping to iniramfs shell Version-Release number of selected component (if applicable): kexec-tools-1.102pre How reproducible: Always Steps to Reproduce: 1. I configured grub.conf according to /usr/share/doc/kexec-tools 2. Test loading the usual kerenel with kexec / reboot is OK 3. start the kdump service is OK 4. create a kernel panic (echo c > /proc/sysreq-trigger) Actual results: Expected results: Additional info:
I further inquired to notice the following strange thing in the init script (from dump initrd). It contains lines like this one: MAJOR_NUM=`cat /sys/block/$i/dev | cut -d: -f1` If i run "cat /sys/block/ram0/dev | cut -d: -f1" from the drop-in shell prompt I get "1" If I run `cat /sys/block/$i/dev | cut -d: -f1` from the same shell, I get nothing ! Therefore the MAJOR_NUM like variables are not properly initialized making mknod command fail because of lack of major/minor parameters Note that on the other hand running something like `ls` works... Hope you can fix this quickly.
Sorry a typo error, I ment: If I run `cat /sys/block/ram0/dev | cut -d: -f1` from the same shell, I get nothing !
please run kdump with a serial console attached, log the contents, and send them all in. Thanks
Hello, I plugged a serial cable to a Windows machine with Hyperterminal configured 115200 / 8 data bit / No parity / 1 stop / no stream control I set in grub.conf the following: serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 terminal --timeout=15 serial console title Fedora (2.6.23.1-49.fc8) root (hd0,0) kernel /vmlinuz-2.6.23.1-49.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet psmouse.proto=bare initrd /initrd-2.6.23.1-49.fc8.img title Fedora (2.6.23.1-49.fc8) debug root (hd0,0) kernel /vmlinuz-2.6.23.1-49.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet psmouse.proto=bare crashkernel=128M@16M 1 initrd /initrd-2.6.23.1-49.fc8.img But I did not get much output on the serial console: Booting 'Fedora (2.6.23.1-49.fc8) debug' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.23.1-49.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet psm ouse.proto=bare crashkernel=128M@16M 1 [Linux-bzImage, setup=0x2c00, size=0x1d3c38] initrd /initrd-2.6.23.1-49.fc8.img [Linux-initrd @ 0x37c30000, 0x3bfcbd bytes] That's all from this side. I am doubting this will help you.
no it doesn't help. you configured a serial console for grub, but you need to do the same for the kernel. Add this to your kernel command line: console=ttyS0,115200n8
Created attachment 278251 [details] Console output when booting on the kdump kernel Thank you for the hint. Please find attached the serial output console while booting the kernel with dumprd image. Best regards
I am experiencing this too. I'm running on F7. kexec/kdump stopped working after an update a few months ago and now I'm trying to figure out the problem. I start with the normal latest kernel, 2.6.23.8-34.fc7 x86_64 (but earlier would have this effect to). I issue an echo c >/proc/sysrq-trigger I get a reboot into a 2.6.21-1.3228.fc7kdump kernel It gets lost in the weeds, with lots of mknod blather from busybox's mknod (see above) and drops me into a shell. After much thrashing about, I find what Marc discovered: that particular shell backquote construct does not work. I've boiled it down to a simple # echo 1:0 >/tmp/9 # cut -d: -f1 /tmp/9 1 # cut -d: -f1 /tmp/9 >/tmp/3 # echo $? 0 # cat /tmp/3 # cut -d: -f1 /tmp/9 | cat # In other words, cut works UNTIL its output goes somewhere other than the console. I WISH my computer had a serial port so that I could use a serial console. I find that I can duplicate this bad cut behaviour with busybox-1.2.2-8.fc7 on my "real" f7 system, not as part of kdump. See the attached log. So: I claim that this is a busybox bug. When it is fixed, a new kdump package should be built to incorporate the fixed busybox.
Created attachment 287041 [details] demo / exploration of busybox cut bug
I've reported this as a busybox bug: https://bugzilla.redhat.com/show_bug.cgi?id=423011 Perhaps it should get increased severity because of the implications for kdump. (I don't think that this report is a kexec-tools problem, I think that correct component is kernel-kdump. My version is kernel-kdump-2.6.21-1.3228.c7.)
no, based on the description above, this is a busybox bug. I'll block this bug on busybox and when its confirmed, we-ll re-verify that busybox starts working. As a workaround, I imagine that downgrading your version of busybox would likely be sufficient to get kdump working again.
Clearly I agree that the root cause is a busybox bug. I am guessing that the kernel-kdump package contains an initial ramdisk (boot/initrd-2.6.21-1.3228.fc7kdump.img) and that the bad busybox is inside this. If so, will upgrading the busybox package installed on my system actually fix the one that kdump uses? If not, this is reason to roll a new kernel-kdump rpm once busybox is working. PS: why does Bugzilla call the module kexec-kdump while the package is called kernel-kdump?
there is no kernel-kdump package, thats just a pseudo component to track kdump problems with the kenrels kexec infrastucture. kdump initrds are generated on the flywhen the kdump service is started. Upgrading busybox should be sufficient to make this work. According to the package maintainer a new version of busybox is available now for F-7 forward, which should fix this problem. Please do the following: 1) upgrade busybox 2) touch /etc/kdump.conf 3) service kdump restart 4) crash the system Kdump should once again be working as you expect. Please confirm this and I'll close out this bug. Thanks!
The new version of busybox in the testing repository fixes the cut problem. kdump is now working for me.
Hello, As far as I am concerned I still have the problem. My busbox version is: [root@linux2 ~]# rpm -qi busybox Name : busybox Relocations: (not relocatable) Version : 1.6.1 Vendor: Fedora Project Release : 2.fc8 Build Date: mar 04 sep 2007 14:53:53 CEST Install Date: lun 19 nov 2007 19:25:39 CET Build Host: xenbuilder4.fedora.phx.redhat.com Group : System Environment/Shells Source RPM: busybox-1.6.1-2.fc8.src.rpm Size : 2099696 License: GPLv2 Signature : DSA/SHA1, jeu 25 oct 2007 02:40:34 CEST, Key ID b44269d04f2a6fd2 Packager : Fedora Project URL : http://www.busybox.net Summary : Statically linked binary providing simplified versions of system commands Description : Busybox is a single binary which includes versions of a large number of system commands, including a shell. This package can be very useful for recovering from certain types of system failures, particularly those involving broken shared libraries. It seems it is an old version. However if I enable the [updates-testing] in /etc/yum.repos.d/fedora-updates-testing.repo, followed by "yum update busybox", I do not get a newer version. Regards
Re comment 14: Have you tried busybox under your normal kernel (not kexec / kdump)? Does it exhibit the failure I described in https://bugzilla.redhat.com/show_bug.cgi?id=423011 ? If you still have the problem, please add to that bug report. That is the one that the busybox maintainer seems to pay attention to. When I tried busybox on F8, I used a live i386 CD. busybox was performing properly. If yours does not, perhaps the problem is limited to x86_64.
Yes, the fix was limited to F-7 which was at busybox version 1.2.2 IIRC, and the only version that should have been affected. I agree with Hugh, you should try the test using comment 7 from this bug, or the link that he mentions. The F-8 busybox should already have the fix for this problem picked up from upstream. My guess is that you're experiencing a different problem, for which a new bug should be opened. Thanks!
I would be mildly surprised if Marc is experiencing a different bug since the symptoms are so similar. Seen comment 1 where Marc describes "cut" misbehaving. If the bug I encountered is different, it would seem rude to make Marc report a new bug since this report was his originally and I've just tagged along. Sorry, Marc. If you do end up opening another report, please do mention it here. I'd like to follow this since I intend to move to F8. I looked at Marc's transcript in comment 6. The busybox banner shows that it is 1.6.1 (I had wondered if the initrd contained some older version).
My bad, I just tested on my F8 system and the problem is in that version too. We need to clone 423011 for F-8 as well. The bug you encountered was not different. The patch just needs to be moved forward.
Neil cloned bug 423011, creating bug 425873
Test from a shell (normal boot): [root@linux2 ~]# busybox BusyBox v1.6.1 (2007-09-04 08:50:14 EDT) multi-call binary ... [root@linux2 ~]# busybox echo 1:0 > 9 [root@linux2 ~]# busybox cut -d: -f1 9 1 [root@linux2 ~]# busybox cut -d: -f1 9 > 3 [root@linux2 ~]# busybox echo $? 0 [root@linux2 ~]# busybox cat 3 [root@linux2 ~]# busybox cut -d: -f1 9 | busybox cat [root@linux2 ~]#
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report. If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against. Thanks for the report!