slackware-current mkinitrd libm.so.6 missing

li-la · 09-19-2014, 06:00 AM

I'm testing slackware-current (32). My hardware does need some extra modules. But my initrd is not working out of the box. First error message in a new system with my initrd.gz is from /bin/ash about a missing libm.so.6 library.

ldd confirms, libm.so.6 and libc.so.6 are used by busybox in bin/busybox of the initrd.

used an rsync mirror this morning, but I'm still at

559128 Oct 29 2013 ./linux/slackware/slackware-current/slackware/a/mkinitrd-1.4.8-i486-2.txz

verified with another ftp mirror

File:mkinitrd-1.4.8-i486-2.txz 547 KB 10/29/2013 12:00:00 AM

ls -la busybox
-rwxr-xr-x 1 root root 855376 Oct 29 2013 busybox

ldd ./busybox
linux-gate.so.1 (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7791000)
libc.so.6 => /lib/libc.so.6 (0xb7605000)
/lib/ld-linux.so.2 (0xb77d8000)

I have modified my usr/share/mkinitrd/initrd-tree.tar.gz.

Put in more programs and fullfilled the dependencies for busybox, bash, ldd, kmod. It's now working for me.

have fun,
cu Frank

Didier Spaier · 09-20-2014, 12:10 PM

Hi Frank, and welcome to LQ and the Slackware forum.

These shared libraries are shipped in packages glibc and glibc-solibs.

Make sure that one of these packages be installed. At least glibc-solibs should as it's included in the a (base) series of packages. Did you make a full installation?

li-la · 09-21-2014, 03:30 AM

Hello, thanks for the answer.

It's a normal full installation, but that's not the problem.

I need an initrd to load some extra kernel modules before my system can start.

# less /etc/lilo.conf
<snip>
# Linux bootable partition config begins
image = /boot/vmlinuz-huge-smp-3.14.18-smp
initrd = /boot/initrd.gz
root = /dev/sda1
label = Linux
read-only
# Linux bootable partition config ends

initrd is a mini linux system, just able to load some extra kernel modules, find and mount the real linux system and boot into it. The image of this small system is in "/usr/share/mkinitrd/initrd-tree.tar.gz". mkinitrd is the program that is used to specialize this image.

Contents of this image are unpackaged in /boot/initrd-tree. mkinitrd includes needed kernel modules and take care of any extra steps before booting the real system. Most important part of this small linux system is in "./bin/busybox". http://www.busybox.net/

In former slackware systems this has not been a dynamic executable. There were no libs in the "/lib" directory of this small initrd linux system. In slackware-current it's not static anymore. Not a big problem, but the used libs have to be placed in "/lib/". You shouldn't have to do this on your own. I would expect them already included in the image or to find another static busybox image.

have fun,
cu Frank

Didier Spaier · 09-21-2014, 02:38 PM

Well, I didn't understand well your first post, as I didn't realize that you had a missing or incomplete /boot/initrd-tree/lib

Anyway I don't have this problem, using an up to date Slackware-current as of Tue Sep 9 22:48:58 UTC 2014.

I used that command:

Code:

mkinitrd -c -k 3.14.18-smp -m ext4

/boot/initrd-tree was properly populated and /boot/initrd.gz properly generated. The machine booted OK using this initrd and modules included in it were loaded as expected during boot sequence.

Code:

/32-current/boot/initrd-tree/lib$ ls -l | grep -e libm.so.6 -e libc.so.6
lrwxrwxrwx 1 root root      12 sept. 21 21:08 libc.so.6 -> libc-2.19.so
lrwxrwxrwx 1 root root      12 sept. 21 21:08 libm.so.6 -> libm-2.19.so
/32-current/boot/initrd-tree/lib$

So I couldn't reproduce the issue you mentioned. Maybe you could share your mkinitrd command, so I could try it?

PS1. If you use an initrd, you could as well boot off a generic-smp kernel instead of a huge-smp, just adding the module needed for the root file system.
PS2. To be accurate, I used a non completely vanilla slackware-current as I have installed a Slint package in it. But that shouldn't change anything as far as generating the initrd is in concern.
PS3. Same behavior with Slackware 14.1 The only difference is the versions of the shared objects, as glibc has been upgraded in -current.

Code:

/boot/initrd-tree/lib$ ls -l | grep -e libm.so.6 -e libc.so.6
lrwxrwxrwx 1 root root      12 sept. 21 10:46 libc.so.6 -> libc-2.17.so
lrwxrwxrwx 1 root root      12 sept. 21 10:46 libm.so.6 -> libm-2.17.so
/boot/initrd-tree/lib$

MQMan · 09-23-2014, 03:36 PM

Out of curiosity, why are you using an initrd with the huge kernel.

Isn't it only used to load kernel modules for boot drives and file systems that aren't compiled in the kernel, which isn't the case with huge.

Cheers.

li-la · 09-24-2014, 03:58 PM

Quote:

Originally Posted by Didier Spaier

I used that command:

Code:

mkinitrd -c -k 3.14.18-smp -m ext4

/boot/initrd-tree was properly populated and /boot/initrd.gz properly generated. The machine booted OK using this initrd and modules included in it were loaded as expected during boot sequence.

So I couldn't reproduce the issue you mentioned. Maybe you could share your mkinitrd command, so I could try it?

PS1. If you use an initrd, you could as well boot off a generic-smp kernel instead of a huge-smp, just adding the module needed for the root file system.
PS2. To be accurate, I used a non completely vanilla slackware-current as I have installed a Slint package in it. But that shouldn't change anything as far as generating the initrd is in concern.
PS3. Same behavior with Slackware 14.1 The only difference is the versions of the shared objects, as glibc has been upgraded in -current.

hello, thanks for your answer and effort to reproduce my error

your answer surprised me, I used my installed slackware-current32 and *tata* mkinitrd worked for me too

was even more surprised

retraced my steps and found a reproducable way for my error symptom and why it worked in my previous installs (just luck)

it doesn't matter if you use a pxe-boot or an install cd iso image

key element is: a new pc without any previous slackware installation

1. booting with pxe (my system) or cdrom

2. partition new hdd, normal full installation with the included setup program, default lilo install without any initrd

3. "mkinitrd -c" with any necessary modules

4. expand existing lilo.conf with the newly created initrd.gz and call lilo again

step 3 at this time is important,

before you can call mkinitrd, three things have to be done

I) create a link /mnt/usr/share/mkinitrd to /usr/share/initrd,

II) remove /bin/xargs, the busybox xargs applet doesn't have a necessary parameter

III) create a link /mnt/sbin/depmod /sbin/depmod

I didn't think the first time I had done it, that creating the two links and using slackware xargs instead of the busybox xorgs applet were that important, but they are

the new created inird direct from cdboot or pxeboot doesn't include the glibc libs, even if there aren't any more error messages, everything seems to work

but without the included glibc libs my new installation with the fresh initrd cannot work and boot

in slackware 12.2 I had a static build of busybox, mkinitrd does work

in slackware 13.x and 14.x I used an already existing older slackware installation and not a fresh pc, included every change for lilo.conf in my old running slackware installation and didn't have to use the pxe boot or cdrom for my first initrd.gz, switched later to the new system, when everything was working for quite some time

so, it's a chicken egg problem, I had to use mkinitrd direct from pxe boot or cdrom to create the first initrd to boot for a fresh pc, only this initrd version does not boot

if you try to use mkinitrd inside a normal running full installation of slackware everything does work

doesn't matter if you use a normal kernel or huge kernel

I can use an iso image in virtualbox to create a new system on a new hdd and reproduce this behaviour every time, initrd is not working and your a stumped if you need some special kernel modules like me

might be a good idea to include the libs for busybox in the /usr/share/mkinitrd/initrd-tree.tar.gz image, they are always needed

will have to find out, why they are not included in my pxe boot/cdrom boot mkinitrd version

have fun,
Frank

li-la · 09-24-2014, 04:11 PM

Quote:

Originally Posted by MQMan

Out of curiosity, why are you using an initrd with the huge kernel.

Isn't it only used to load kernel modules for boot drives and file systems that aren't compiled in the kernel, which isn't the case with huge.

Cheers.

got problems on my first system, but if everything is ok it will run on several different PCs

I do prefer a generic kernel working on every hardware instead to nurse a bunch of different kernels

systems have to be initialized before I can boot, one important step is to set a working system time without hardware clock

have fun,
Frank

li-la · 09-25-2014, 02:41 AM

Quote:

Originally Posted by Didier Spaier

I used that command:

Code:

mkinitrd -c -k 3.14.18-smp -m ext4

/boot/initrd-tree was properly populated and /boot/initrd.gz properly generated. The machine booted OK using this initrd and modules included in /it were loaded as expected during boot sequence.

So I couldn't reproduce the issue you mentioned. Maybe you could share your mkinitrd command, so I could try it?

PS1. If you use an initrd, you could as well boot off a generic-smp kernel instead of a huge-smp, just adding the module needed for the root file system. PS2. To be accurate, I used a non completely vanilla slackware-current as I have installed a Slint package in it. But that shouldn't change anything as far as generating the initrd is in concern. PS3. Same behavior with Slackware 14.1 The only difference is the versions of the shared objects, as glibc has been upgraded in -current.

hello, thanks for your answer and effort to reproduce my error

your answer surprised me, I used my installed slackware-current32 and *tata* mkinitrd worked for me too

was even more surprised

retraced my steps and found a reproducable way for my error symptom and why it worked in my previous installs (just luck)

it doesn't matter if you use a pxe-boot or an install cd iso image

key element is: a new pc without any previous slackware installation

1. booting with pxe (my system) or cdrom

2. partition new hdd, normal full installation with the included setup program, default lilo install without any initrd

3. „mkinitrd -c“ with any necessary modules

4. expand existing lilo.conf with the newly created initrd.gz and call lilo again

step 3 at this time is important,

before you can call mkinitrd, three things have to be done

I) create a link /mnt/usr/share/mkinitrd to /usr/share/initrd,

II) remove /bin/xargs, the busybox xargs applet doesn't have a necessary parameter

III) create a link /mnt/sbin/depmod /sbin/depmod

I didn't think the first time I had done it, that creating the two links and using slackware xargs instead of the busybox xorgs applet were that important, but they are

the new created inird direct from cdboot or pxeboot doesn't include the glibc libs, even if there aren't any more error messages, everything seems to work

but without the included glibc libs my new installation with the fresh initrd cannot work and boot

in slackware 12.2 I had a static build of busybox, mkinitrd does work

in slackware 13.x and 14.x I used an already existing older slackware installation and not a fresh pc, included every change for lilo.conf in my old running slackware installation and didn't have to use the pxe boot or cdrom for my first initrd.gz, switched later to the new system, when everything was working for quite some time

so, it's a chicken egg problem, I had to use mkinitrd direct from pxe boot or cdrom to create the first initrd to boot for a fresh pc, only this initrd version does not boot

if you try to use mkinitrd inside a normal running full installation of slackware everything does work

doesn't matter if you use a normal kernel or huge kernel

I can use an iso image in virtualbox to create a new system on a new hdd and reproduce this behaviour every time, initrd is not working and your a stumped if you need some special kernel modules like me

might be a good idea to include the libs for busybox in the /usr/share/mkinitrd/initrd-tree.tar.gz image, they are always needed

will have to find out, why they are not included in my pxe boot/cdrom boot mkinitrd version

have fun, Frank

Didier Spaier · 09-25-2014, 12:06 PM

You are just missing a step between 2. and 3. I think:

Code:

mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
chroot /mnt

PS Have a look to /sbin/mkinitrd. You'll see that /boot/initrd-tree/lib is populated by the function copy_libs(). This function first copy essential glibc files in /boot/initrd-tree/lib, then copy in /boot/initrd-tree/lib all remaining libs the files already installed in that directory link against, using ldd.

But the copied files are expected to come from an already installed system, not from an initrd loaded in RAM. That's why you need to chroot in the installed system before running the script mkinitrd.

juggling_ben · 12-02-2014, 02:54 PM

I know this is somewhat an old thread, but I ran into this the other day.

The problem for me was an incorrect first line (shebang) in the ldd script. Therefore, ldd wasn't working and the initrd tree not being populated properly with dependencies.

It was a tricky problem and took a while to debug, so hopefully this helps some people out there.

Didier Spaier · 12-02-2014, 03:13 PM

@juggling_ben: Welcome to this forum.

Did you try that in a genuine Slackware? I ask because in Slackware's ldd script the shebang is:

Code:

#! /usr/bin/bash

And that is of course correct.

juggling_ben · 12-02-2014, 03:52 PM

Yes it was.

It was slightly old and not up to date. The shebang was /usr/bin/bash, but bash is/was in /bin.

Actually, my solution was to symlink /usr/bin/bash to /bin/bash, as was done with some of the other tools. So most likely the issue was a missing symlink.

How it got erased is a mystery. But it's possible the poster or others had the same problem, since it spit out the exact same error.

Didier Spaier · 12-02-2014, 04:22 PM

Quote:

Originally Posted by juggling_ben

So most likely the issue was a missing symlink.

Yes. But that look weird as this symlink is made during the installation of the bash package...

Code:

( cd usr/bin ; rm -rf bash )
( cd usr/bin ; ln -sf /bin/bash bash )