Re: [gentoo-amd64] chroot can't find /bin/bash

[Marek Wróbel]

Boyd Stephen Smith Jr. napisa³(a):
> The chroot binary uses the chroot and exec C-library functions to do it's
> job.
> As library functions, they don't write out error messages and exit the
> program directly.  (The program calling them might write the messages
> somewhere other than stderr or discard them entirely.  Also, it may be able
> to recover.)  Instead they either return an error *code* directly, or place
> it in a well-known location that the caller should check.  These error
> codes
> can be mapped to generic messages, but may not completely specify the
> error;
> in this case, exec (actually, probably even deeper in the bowels of glibc)
> tried to open a library and couldn't find it [probably looked in 1/2 dozen
> places for it, too :(] and returned the generic "File Not Found" error
> code.
> The chroot binary knows how it was called ("chroot"), what it was trying to
> do (execute "/bin/bash"), and the error code.  It crams these bits of
> information together to try and give a human-readable error, but computers
> are stupid and it comes up with the misleading, "chroot: cannot run command
> `/bin/bash': No such file or directory", despite the fact that clearly
> exists
> in the chroot.
>

I will add my few words:
You are almost correct, but there is defined errno for error with
loading dynamic libraries. When I execute binary with missing libraries,
I get following error:

./busybox: can't load library 'libcrypt.so.0'

I think that the actual problem is lack of /lib/ld-*.so.* (usually
/lib/ld-linux.so.2). When I remove it, I get the following error:

-bash: ./busybox: No such file or directory

As you can see, this error is written by bash. However, when dynamic
library can't be loaded, error is written by binary itself. Precisely,
this is done by /lib/ld-*.so.*. It has few basic library functions
compiled in it, so error can be printed even without libc loaded. You
can see this by executing 'objdump -Tt /lib/ld-linux.so.2'. Among
functions used to load libraries, there is implementation of malloc,
getcwd, some string functions, write/read and many more. If you take
ld-uClibc.so.0 (if you have it, of course), there are only few of them
and you can see that it is really small subset of all libc functions.

To sum up, when application can't load its libraries, it is still able
to inform a user about it. The misleading 'File not found' error is
written only when appropriate /lib/ld-*.so.* can't be found. It is
probably caused by way in which dynamic libraries are handled, but I
can't tell you more about it.

Regards,
Marek Wróbel
-- 
gentoo-amd64@g.o mailing list