FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 04-22-2011, 07:36 AM
Giuseppe Sacco
 
Default Bug#623584: initramfs-tools create a wrong directory tree

Hi,
I made a few tests on this report and I found that the loader is not
looking at the right directories. Please have a look at this:

root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 --list bin/sh
bin/sh: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory
root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 --list --library-path /lib64 bin/sh
linux-vdso.so.1 => (0x00007fff5f3ff000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7f96cd7000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7f96976000)
/lib64/ld-linux-x86-64.so.2 => lib64/ld-linux-x86-64.so.2 (0x00007f7f96f5b000)
root@debian:/boot/f# chroot . lib64/ld-linux-x86-64.so.2 --library-path /lib64 bin/sh


BusyBox v1.17.1 (Debian 1:1.17.1-8) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # exit

As you may see, if I manually add /lib64 in the ld search path, then
libm is found and the busybox executable starts.

So, the problem with this initramfs image is that lib64 should only
contain the loader, and all libraries should be in lib. This is how it
is:

root@debian:/boot/f# ls -ld lib lib64 lib*/*
drwxr-xr-x 4 root root 4096 Apr 21 14:28 lib
-rwxr-xr-x 1 root root 71960 Apr 21 14:28 lib/klibc-r1_A6R6EwMsdze5h5xz93JiNuoM.so
-rw-r--r-- 1 root root 128256 Apr 21 14:28 lib/libblkid.so.1
-rw-r--r-- 1 root root 139736 Apr 21 14:28 lib/libdevmapper.so.1.02.1
-rw-r--r-- 1 root root 286776 Apr 21 14:28 lib/libncurses.so.5
-rw-r--r-- 1 root root 258088 Apr 21 14:28 lib/libreadline.so.5
-rw-r--r-- 1 root root 117848 Apr 21 14:28 lib/libselinux.so.1
-rw-r--r-- 1 root root 55136 Apr 21 14:28 lib/libudev.so.0
-rw-r--r-- 1 root root 15720 Apr 21 14:28 lib/libuuid.so.1
drwxr-xr-x 3 root root 4096 Apr 21 14:28 lib/modules
drwxr-xr-x 3 root root 4096 Apr 21 14:28 lib/udev
drwxr-xr-x 2 root root 4096 Apr 21 14:28 lib64
-rwxr-xr-x 1 root root 128744 Apr 21 14:28 lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 1432968 Apr 21 14:28 lib64/libc.so.6
-rw-r--r-- 1 root root 14696 Apr 21 14:28 lib64/libdl.so.2
-rw-r--r-- 1 root root 530736 Apr 21 14:28 lib64/libm.so.6

and this is how it is on a different (and working) amd64 system:

neos@appliance-000:/tmp/gg$ ls -ld lib lib64 lib*/*
drwxr-xr-x 4 neos neos 4096 22 apr 09.17 lib
drwxr-xr-x 2 neos neos 33 22 apr 09.17 lib64
-rwxr-xr-x 1 neos neos 128744 22 apr 09.17 lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 neos neos 71960 22 apr 09.17 lib/klibc-r1_A6R6EwMsdze5h5xz93JiNuoM.so
-rw-r--r-- 1 neos neos 128256 22 apr 09.17 lib/libblkid.so.1
-rwxr-xr-x 1 neos neos 1432968 22 apr 09.17 lib/libc.so.6
-rw-r--r-- 1 neos neos 139736 22 apr 09.17 lib/libdevmapper.so.1.02.1
-rw-r--r-- 1 neos neos 14696 22 apr 09.17 lib/libdl.so.2
-rw-r--r-- 1 neos neos 530736 22 apr 09.17 lib/libm.so.6
-rw-r--r-- 1 neos neos 286776 22 apr 09.17 lib/libncurses.so.5
-rw-r--r-- 1 neos neos 258088 22 apr 09.17 lib/libreadline.so.5
-rw-r--r-- 1 neos neos 117848 22 apr 09.17 lib/libselinux.so.1
-rw-r--r-- 1 neos neos 55136 22 apr 09.17 lib/libudev.so.0
-rw-r--r-- 1 neos neos 15720 22 apr 09.17 lib/libuuid.so.1
drwxr-xr-x 3 neos neos 27 22 apr 09.17 lib/modules
drwxr-xr-x 3 neos neos 132 22 apr 09.17 lib/udev

(files order is different since these machines have different locales)

Please note that on both system (outside of chroot) /lib64 is a link
to /lib.

So, if I move all lib* files from lib64 to lib, then create the gzipped
cpio initrd image and use this for booting, the busybox load and start
it work. Then fails because it cannot mont the root file system as shown
here:

[...]
Initialize network drop monitor service
List of all partitions:
No filesystem could mount root, tried:
Kernel panic - not syncing: VFS Unable to mpunt root fs on
unknown-block(0,0)
Pid: 1, comm: swapper Not Tainted 2.6.32-5-amd64 #1
Call Trace:
[...]

Beside the very last problem (I will intestigate about it), how do
initramfs-tools create the lib and lib64 trees? Does it use a
configuration file?

Bye,
Giuseppe




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1303457811.4695.23.camel@scarafaggio">http://lists.debian.org/1303457811.4695.23.camel@scarafaggio
 
Old 04-22-2011, 02:35 PM
Ben Hutchings
 
Default Bug#623584: initramfs-tools create a wrong directory tree

On Fri, 2011-04-22 at 09:36 +0200, Giuseppe Sacco wrote:
> Hi,
> I made a few tests on this report and I found that the loader is not
> looking at the right directories. Please have a look at this:
[...]
> Please note that on both system (outside of chroot) /lib64 is a link
> to /lib.

I think that's normal; however /lib should be higher up the library
search path than /lib64.

What does 'ldd /bin/sh' say in the running system?

[...]
> Beside the very last problem (I will intestigate about it), how do
> initramfs-tools create the lib and lib64 trees? Does it use a
> configuration file?

It uses ldd to find which libraries each executable is linked to, and
copies them to the same locations they were found in the running system.
(Exception: where the library is optimised for specific CPU features, it
substitutes the unoptimised alternate from the parent directory.)

However, it does not copy the ld.so configuration files, and it does not
unset LD_LIBRARY_PATH. Also, it does not use 'readlink -f' to resolve
symbolic links, which I think would solve this particular issue.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 04-22-2011, 02:35 PM
Ben Hutchings
 
Default Bug#623584: initramfs-tools create a wrong directory tree

On Fri, 2011-04-22 at 09:36 +0200, Giuseppe Sacco wrote:
> Hi,
> I made a few tests on this report and I found that the loader is not
> looking at the right directories. Please have a look at this:
[...]
> Please note that on both system (outside of chroot) /lib64 is a link
> to /lib.

I think that's normal; however /lib should be higher up the library
search path than /lib64.

What does 'ldd /bin/sh' say in the running system?

[...]
> Beside the very last problem (I will intestigate about it), how do
> initramfs-tools create the lib and lib64 trees? Does it use a
> configuration file?

It uses ldd to find which libraries each executable is linked to, and
copies them to the same locations they were found in the running system.
(Exception: where the library is optimised for specific CPU features, it
substitutes the unoptimised alternate from the parent directory.)

However, it does not copy the ld.so configuration files, and it does not
unset LD_LIBRARY_PATH. Also, it does not use 'readlink -f' to resolve
symbolic links, which I think would solve this particular issue.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 

Thread Tools




All times are GMT. The time now is 09:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org