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

[Boyd Stephen Smith Jr.]

On Tuesday 06 February 2007 21:03, Daiajo Tibdixious wrote:
> transcode is giving me a segmentation fault, which I reported as a bug.
> They now want a backtrace & I've roughly followed
> http://www.gentoo.org/proj/en/qa/backtraces.xml
> I used ebuild directly, ending at the install phase, as I don't want
> to overwrite the live transcode.
>
> I then built a /mnt/debug chroot using roughly
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2
> (32bit chroot guild for AMD64) with the following binds:
> mount -o bind /bin /mnt/debug/bin
> mount -o bind /etc /mnt/debug/etc
> mount -o bind /dev /mnt/debug/dev
> mount -o bind /proc /mnt/debug/proc
> mount -o bind /sys /mnt/debug/sys
> mount -o bind /tmp /mnt/debug/tmp
> mount -o bind /home/daiajo /mnt/debug/home/daiajo
> and moved the /var/tmp/portage/transcode-*/image dirs into /mnt/debug
> (just usr in this case)
> The problem comes when trying to chroot into it:
> # ls /bin/bash
> /bin/bash
> # ls /mnt/debug/bin/bash
> /mnt/debug/bin/bash
> # chroot /mnt/debug /bin/bash
> chroot: cannot run command `/bin/bash': No such file or directory

Okay, this error message is just misleading.  I've seen it before when 
chrooting, and it can also happen after your screw up your glibc/libstdc++ 
install.  (Done both a number of times.)

The problem is that one of the libraries that /bin/bash dynamically links 
to 
cannot be found inside the chroot.  I suggest that you add /lib, and 
possibly /usr/lib to your list of bind mounts.  That, or copy the libraries 
into the chroot.

The reason you get such a lame error message probably best described as a 
historical oddity, but others might describe it as anything from the 
inherent 
suck of C and UNIX to a poor example of excellent design under resource 
constraints that no longer exist.  A fairly detailed, but hopefully 
understandable, description of what is happening follows:

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.

> Is there a better way to run a debug transcode without messing with
> the live system?

Not really, although the splitdebug FEATURE can give you a lot of the 
advantages of a full debug build without the runtime memory overhead.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@××××××××××.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
New GPG Key!  Old key expires 2007-03-25.  Upgrade NOW!