Red Hat Bugzilla – Bug 399731
dumprd seems not using well mknod
Last modified: 2008-11-26 12:36:56 EST
Description of problem:
The dump kernel fails to load. Many messages of the type:
Creating block device ramXX (where XX ranges in
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):
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)
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
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
please run kdump with a serial console attached, log the contents, and send them
all in. Thanks
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 (18.104.22.168-49.fc8)
kernel /vmlinuz-22.214.171.124-49.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb
title Fedora (126.96.36.199-49.fc8) debug
kernel /vmlinuz-188.8.131.52-49.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb
quiet psmouse.proto=bare crashkernel=128M@16M 1
But I did not get much output on the serial console:
Booting 'Fedora (184.108.40.206-49.fc8) debug'
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-220.127.116.11-49.fc8 ro root=/dev/VolGroup00/LogVol00 rhgb quiet psm
ouse.proto=bare crashkernel=128M@16M 1
[Linux-bzImage, setup=0x2c00, size=0x1d3c38]
[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:
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.
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, 18.104.22.168-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
# cut -d: -f1 /tmp/9 >/tmp/3
# echo $?
# 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:
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
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.
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
Install Date: lun 19 nov 2007 19:25:39 CET Build Host:
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
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.
Re comment 14:
Have you tried busybox under your normal kernel (not kexec / kdump)? Does it
exhibit the failure I described in
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,
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
[root@linux2 ~]# busybox cut -d: -f1 9 > 3
[root@linux2 ~]# busybox echo $?
[root@linux2 ~]# busybox cat 3
[root@linux2 ~]# busybox cut -d: -f1 9 | busybox cat
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:
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!