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

[Daiajo Tibdixious]

On 2/7/07, Boyd Stephen Smith Jr. <bss03@××××××××××.net> wrote:
> On Tuesday 06 February 2007 21:03, Daiajo Tibdixious wrote:
> > 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
>

> 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.

Okay, will do (/lib and /usr/lib wheren't enough, but I will
investigate further tomorrow (its getting late here).

> 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:

:)

> 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.

Thanks for the explanation, that makes it very clear.

> > 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.

Okay, I'm sold on splitdebug, thanks.
-- 
gentoo-amd64@g.o mailing list