On 2/7/07, Boyd Stephen Smith Jr. <[EMAIL PROTECTED]> 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.
--
[email protected] mailing list
