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. ,= ,-_-. =.
[EMAIL PROTECTED] ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
New GPG Key! Old key expires 2007-03-25. Upgrade NOW!
pgpgMEKc0uwgu.pgp
Description: PGP signature
