Description of problem:
kernel panics caused by a missing libm.so.6.
"/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):
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.
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.
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 .
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...
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.
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.
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 !
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).
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.
With the change proposed in bug 235251 (and included in mkinitrd-6.0.9-4), this
shoudl be resolved