Bug 230874 - kernel panic caused by a missing libm
kernel panic caused by a missing libm
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
Depends On: 235251
Blocks: FC7Blocker
  Show dependency treegraph
Reported: 2007-03-03 22:37 EST by Ronald Warsow
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-21 11:59:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ronald Warsow 2007-03-03 22:37:43 EST
Description of problem:
kernel panics caused by a missing libm.so.6.
exact message:
"/bin/nash: error while loading shared libraries: libm.so.6: cannot open shared
object file: No such file or directory"

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install a non-xen 2.6.20.x.y kernel on a fresh installed f7-test2 box
2. boot the non-xen kernel.
Actual results:

Expected results:

Additional info:
i installed the box new (test 6.91), cause i got this panic with each kernel i
could find on the mirrors (oldest: 2925) and i thought there is something more
wrong with it. (it was an upgrade from fc6 to devel)

comparing each initrd's shows that the xen-kernel has the missing libm under
directory /lib, whereas 2962 has this lib under /lib/i686/nosegneg/.

if i copy all under /lib/i686/nosegneg (and of cause the missing libm) from the
unpacked initrd-file under /lib and build a new initrd the box boots fine. 

this is an intel p4 box and there is a related bz 221804, but i can't see how
it's fixed. my box has the same controller (Intel Corporation 82801BA)
disk has labels ( / is labeled /DEVEL), so i exclude pata issues (changes
hda->sda). / is laying on an LVM-Volume. grub has several chainloader entries.
disk layout:
hda1 /boot
hda2 /DEVEL (chainloaded)
hda3 gentoo (no label)
hda4 lvm with fc6 and a big /opt and swap

what i can't understand. the default settings are:
init-file from xen-kernel:    mkrootdev ... sda2 (from fresh installation)
init-file from 2962-kernel:   mkrootdev ... hda2 (from update afterwards)

it seems it makes absolutely no difference if i put hda2 or sda2 in the new home
brewed init-file for this mkrootdev line, as long as i copy the libm .
Comment 1 Ronald Warsow 2007-03-03 23:13:12 EST
if i run the scripts (preuninstall and afterwards postinstall) from the 2962
/sbin/new-kernel-pkg --rminitrd ...
/sbin/new-kernel-pkg --package ...

the initrd file is build without a /i686/nosegneg directory under /lib.
booted was a non-xen kernel.

seems it's a xen-kernel -> non-xen-kernel install/update issue only...

Comment 2 Will Woods 2007-03-20 12:50:03 EDT
Confirmed - seeing the same problem here on my test machine. 

Here's the root of the problem. We're using shared libraries in initrd now, so
mkinitrd basically needs to run ldd on each binary that's going into the initrd.
Unfortunately, /etc/ld.so.conf.d/kernelcap-*.conf does some magical stuff so
that when you are running a Xen kernel, you get the following:

[wwoods@norfair ~]$ ldd /sbin/nash | grep libm
        libm.so.6 => /lib/i686/nosegneg/libm.so.6 (0x00a25000)

But if you were running a normal kernel, you would get /lib/libm.so.6 instead. 

So when you boot into the non-xen kernel, it expects /lib/libm.so.6, but that's
not there, so nash fails to start.

We may need a way to disable this nosegneg stuff when building an initrd for a
non-xen kernel, or we might need to create extra symlinks after creating it, or
we might need to force mkinitrd to only fetch /lib/$(basename $library). I'm not
really sure what the right answer is.
Comment 3 Will Woods 2007-03-30 17:58:29 EDT
A further note - the variable LD_HWCAP_MASK is supposed to let you mess with the
hwcap stuff (see /etc/ld.so.conf.d/kernelcap-*.conf in the Xen kernels), but I
can't find a way to make it mask the nosegneg bit.
Comment 4 Ronald Warsow 2007-04-07 13:10:50 EDT
today i do a fresh test install with a xen-kernel first and a update/install to
a non-xen-kernel afterwards.

seem's to be fixed !

Comment 5 Nils Philippsen 2007-04-16 11:14:49 EDT
I just tried it with 6.0.8-4 and it doesn't seem to be fixed here (started with
a problematic kernel-xen-2.6.20-2925.5.fc7.i686, installed
kernel-2.6.20-1.3071.fc7 on top of it, initrd had libs in /lib/i686/nosegneg).
Comment 6 Adam Tkac 2007-05-04 11:52:22 EDT
I have same problems. When I updated (yum update) from fc6 xen system to non-xen
rawhide non-xen kernel isn't able to boot.

Comment 7 Jeremy Katz 2007-05-21 11:59:01 EDT
With the change proposed in bug 235251 (and included in mkinitrd-6.0.9-4), this
shoudl be resolved

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