# [SOLVED]initramfs failed with : couldn't open shared library

## qdii

Hello everybody. 

This is my first attempt at building an initramfs (without genkernel). So far I had some troubles but solved them by reading reading and reading the doc.

But there I'm stalled :/

My initramfs involves using dm-crypt to mount crypted volume using a password that I have to enter on the keyboard. I used regional characters in this password.

So I need my initramfs to load a keymap up.

I copied /usr/bin/loadkeys in my initramfs folder /usr/src/initramfs/usr/bin, and processed with its shared library :

```

qdii@ciruella /usr/bin $ ldd /usr/bin/loadkeys 

   linux-vdso.so.1 =>  (0x00007fff45bff000)

   libc.so.6 => /lib/libc.so.6 (0x00007f554873a000)

   /lib64/ld-linux-x86-64.so.2 (0x00007f5548aa0000)

```

I copied the shared libraries :

```

ciruella bin # cp -L /lib/libc.so.6 /usr/src/initramfs/lib

ciruella bin # cp -L /lib64/ld-linux-x86-64.so.2 /usr/src/initramfs/lib64

```

and modified my initramfs :

```

ciruella bin # cat /usr/src/initramfs/init 

#!/bin/busybox sh

mount -t proc proc /proc

mount -t sysfs sysfs /sys

mount -t devtmpfs devtmpfs /dev

#disposition espagnole

loadkeys es

#makes LVM partitions available

lvm vgscan --mknodes

lvm lvchange --sysinit -aly virgin/racine

#open crypted root partition

cryptsetup luksOpen /dev/mapper/virgin-racine racineCiphered

#mounting root partition

mount -o ro /dev/mapper/racineCiphered /mnt/root

exec switch_root /mnt/root /sbin/init

```

I created the initramfs file

```

ciruella initramfs # mount /boot/

ciruella initramfs # find . -print0 | cpio --null -ov --format=newc | gzip -9 > /boot/my-initramfs.cpio.gz

.

./root

./dev

./dev/sdb3

./dev/tty

./dev/null

./dev/sdb1

./dev/sda4

./dev/sdb2

./dev/console

./dev/sda3

./mnt

./mnt/root

./init

./proc

./sys

./bin

./bin/busybox

./etc

./usr

./usr/bin

./usr/bin/loadkeys

./usr/bin/kbd_mode

./usr/share

./usr/share/keymaps

./usr/share/keymaps/i386

./usr/share/keymaps/i386/qwerty

./usr/share/keymaps/i386/qwerty/es.map.gz

./usr/share/keymaps/i386/include

./sbin

./sbin/cryptsetup

./sbin/lvm

./lib64

./lib64/ld-linux-x86-64.so.2

./lib

./lib/libdevmapper-event.so.1.02

./lib/ld-linux-x86-64.so.2

./lib/libncurses.so.5

./lib/libc.so.6

./lib/libm.so.6

./lib/libdl.so.2

./lib/libreadline.so.6

./lib/libudev.so.0

./lib/libdevmapper.so.1.02

18733 blocks

```

yea some libraries are useless.

but when I boot it up, it fails with : "libc.so.6: cannot open...". 

any idea ?  :Smile: [/code]Last edited by qdii on Fri Nov 19, 2010 7:31 am; edited 1 time in total

----------

## chiefbag

Not sure about this but did you emerge

sys-libs/libstdc++-v3

----------

## Hu

 *qdii wrote:*   

> I copied /usr/bin/loadkeys in my initramfs folder /usr/src/initramfs/usr/bin, and processed with its shared library :

 There is no need to create any copies.  The kernel supports building an initramfs directly from live files.  This would also save you the trouble of manually building the cpio archive. *qdii wrote:*   

> but when I boot it up, it fails with : "libc.so.6: cannot open...". 
> 
> any idea ? 

 It appears that you failed to include a required file in the initramfs.  The rest of the error message should tell you what file you need.  Since you truncated the message, we cannot tell you the name of the file.

chiefbag: that is only useful if using proprietary programs linked to a legacy libstdc++ (or certain other rare cases where a legacy libstdc++ is required instead of just rebuilding with the current libstdc++).  It is irrelevant here, since (1) there are no C++ programs in that initramfs and (2) none of the programs in the initramfs are proprietary.

----------

## qdii

Thanks guys for your answer  :Smile: 

 *Quote:*   

> There is no need to create any copies. The kernel supports building an initramfs directly from live files.

 

Do you mean that I can really on a (symbolic/hard) link to the libraries rather than making a deep copy ? 

 *Quote:*   

> Since you truncated the message, we cannot tell you the name of the file.

 

Well, I kept the name of the file within the truncated part, maybe you did not pay attention  :Smile:  The truncated part only says "cannot open or read file" I guess, I was not sure of the exact terminology.

 *Quote:*   

> but when I boot it up, it fails with : "libc.so.6: cannot open...". 
> 
> any idea ?

 

My point is that libc.so.6 does exist in the initramfs, and it cannot open it.

```

ciruella qdii # cd /usr/src/initramfs/

ciruella initramfs # cd lib

ciruella lib # ls -lh

total 3,3M

-rwxr-xr-x 1 root root 153K nov 12 22:51 ld-linux-x86-64.so.2

-rwxr-xr-x 1 root root 1,7M nov 13 01:21 libc.so.6

-r-xr-xr-x 1 root root  28K nov 12 22:50 libdevmapper-event.so.1.02

-r-xr-xr-x 1 root root 170K nov 12 22:50 libdevmapper.so.1.02

-rwxr-xr-x 1 root root  19K nov 12 22:50 libdl.so.2

-rwxr-xr-x 1 root root 585K nov 12 22:50 libm.so.6

-rwxr-xr-x 1 root root 322K nov 12 22:51 libncurses.so.5

-r-xr-xr-x 1 root root 274K nov 12 22:50 libreadline.so.6

-rwxr-xr-x 1 root root  68K nov 12 22:51 libudev.so.0

```

----------

## frostschutz

If you only need it for the passphrase, my solution there was to add another passphrase, that matches whatever comes out using US keyboard layout when typing in the passphrase. LUKS allows you to add up to 8 passwords, so you can add the same passphrase twice, only difference being the keyboard layout.

Of course it'd still be interesting to know how to make loadkeys work in initramfs, but loadkeys may well depend on locale entirely (at least when executing it without initramfs it goes to /usr/lib64/locale/locale-archive among other things). If it's not absolutely necessary all you achieve is making your initramfs much more complicated than it need to be.

If you want to debug this, try emerging dev-util/strace with static useflag, include that in your initramfs, make it drop you in a rescue shell, then 'strace loadkeys es' and see where it fails. That way you can tell if it's looking for any files that are missing, or any libraries but in the wrong directory.

----------

## Sadako

What you have in /lib and /lib64 is a little confusing, if using ld-linux-x86-64.so.2 from your live system then it will need to be in /lib64 (which you have in your first post but looks like you moved it to /lib?).

Just dump all libs and ld-linux-x86-64.so.2 in either lib and lib64, doesn't really matter which, then create a lib symlink to lib64 (or vice-versa).

Although I think it should work with everything in /lib64 without a lib symlink, but anyways...

----------

## qdii

frostschuz : thanks for your workaround, but now I've got quite excited about having the right keyboard loaded at boot and I really wish to solve this problem the right way  :Smile:  Your idea of using strace, however, was bright.  I did it and came to the same conclusion as Sadako (what an insight you had Sadako !)

loadkeys was looking for libc.so.6 in /lib64. 

Now I got loadkeys to be executed but it behaves strangely. Let me explains : the log says that "Loading /usr/share/keymaps/i386/qwerty/es.map.gz" has been loaded, but when I run in into verbose mode, it outputs "Changed 0 keys". 

This is not correct, however : my passwords are still not recognized, meaning that my keyboard is not yet set on the right keymap.

"loadkeys -v es" normally outputs "Changed 793 keys and 26 strings."

Now I'm scanning "strace loadkeys -v es" and try to copy all the files it opens  :Smile: 

----------

## Hu

 *qdii wrote:*   

> Do you mean that I can really on a (symbolic/hard) link to the libraries rather than making a deep copy ?

 No.  I mean that there is no need to create any copy, hard link, or soft link explicitly.  You can give the kernel build system a file that explains what to pull in and it will insert those files into its archive automatically.

----------

## qdii

I'm still stuck with that thing not working, but I found that busybox was embedding a tool called "loadkmap" that did the exact same thing. This is a workaround.

----------

## frostschutz

 *qdii wrote:*   

> I'm still stuck with that thing not working, but I found that busybox was embedding a tool called "loadkmap" that did the exact same thing. This is a workaround.

 

 :Laughing: 

Sorry, I didn't even think of that. There is so much stuff included in busybox, you should always check whether it can be done with busybox first, before including your own binaries. I should add that to the Wiki page.

----------

## qdii

I'm going to set the thread to [SOLVED] even though the underlying problem was not (I didn't make loadkeys work). The busybox alternative suits me perfectly. Thanks for all your help guys  :Smile: 

----------

