This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 399731 - dumprd seems not using well mknod
dumprd seems not using well mknod
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
8
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
:
Depends On: 423011 425873
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-26 12:56 EST by Marc Rechte
Modified: 2008-11-26 12:36 EST (History)
2 users (show)

See Also:
Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 12:36:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Console output when booting on the kdump kernel (11.22 KB, text/plain)
2007-12-05 07:55 EST, Marc Rechte
no flags Details
demo / exploration of busybox cut bug (582 bytes, text/plain)
2007-12-13 04:23 EST, D. Hugh Redelmeier
no flags Details

  None (edit)
Description Marc Rechte 2007-11-26 12:56:12 EST
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:
Comment 1 Marc Rechte 2007-11-29 09:29:38 EST
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.
Comment 2 Marc Rechte 2007-11-29 09:31:42 EST
Sorry a typo error, I ment:

If I run `cat /sys/block/ram0/dev | cut -d: -f1` from the same shell, I get
nothing !
Comment 3 Neil Horman 2007-11-29 10:22:50 EST
please run kdump with a serial console attached, log the contents, and send them
all in.  Thanks
Comment 4 Marc Rechte 2007-11-30 02:42:24 EST
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.
Comment 5 Neil Horman 2007-11-30 10:37:33 EST
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
Comment 6 Marc Rechte 2007-12-05 07:55:00 EST
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
Comment 7 D. Hugh Redelmeier 2007-12-13 04:20:24 EST
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.
Comment 8 D. Hugh Redelmeier 2007-12-13 04:23:19 EST
Created attachment 287041 [details]
demo / exploration of busybox cut bug
Comment 9 D. Hugh Redelmeier 2007-12-13 04:50:09 EST
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.)
Comment 10 Neil Horman 2007-12-13 08:06:10 EST
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.
Comment 11 D. Hugh Redelmeier 2007-12-13 13:08:22 EST
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?
Comment 12 Neil Horman 2007-12-13 13:57:57 EST
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!
Comment 13 D. Hugh Redelmeier 2007-12-15 23:06:08 EST
The new version of busybox in the testing repository fixes the cut problem. 
kdump is now working for me.
Comment 14 Marc Rechte 2007-12-16 04:16:37 EST
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
Comment 15 D. Hugh Redelmeier 2007-12-16 11:49:44 EST
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.
Comment 16 Neil Horman 2007-12-16 16:59:38 EST
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!
Comment 17 D. Hugh Redelmeier 2007-12-16 17:44:29 EST
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).
Comment 18 Neil Horman 2007-12-16 20:03:33 EST
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.
Comment 19 D. Hugh Redelmeier 2007-12-16 21:24:53 EST
Neil cloned bug 423011, creating bug 425873
Comment 20 Marc Rechte 2007-12-17 03:48:44 EST
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 ~]#
Comment 21 Bug Zapper 2008-11-26 03:42:09 EST
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
Comment 22 Jon Stanley 2008-11-26 12:36:56 EST
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!

Note You need to log in before you can comment on or make changes to this bug.