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

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

[Daiajo Tibdixious]

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

Is there a guide for doing this sort of chroot?
What is this sort of chroot called?
Is there a better way to run a debug transcode without messing with
the live system?
I googled around but "chroot" hits so many things its hard to find the
right one.

I also tried running transcode from the image/bin directory with
PATH=/var/tmp/portage/transcode-1.0.2-r3/image/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin
however
tcextract (run in a subshell I believe) is not found.
I was going to ask why that didn't work, now I realise the subshells
aren't going to see it, doh.
I ran tcextract and tcdecode outside of transcode and they worked
without complaint, so its the main transcode at fault.
Interestingly, transcode still "Segmentation fault"d when tcextract
failed to run,
so I was able to get my backtrace, just wondering if there is a better
way to go about all this.

I wouldn't mind having a debug chroot where I could just emerge stuff,
like a 32 bit chroot (which I had up and running for a while, removed
it because it did not fix my problem, and I was running short of disk
space) but I'm not sure how to go about it.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Thomas Rösner]

Daiajo Tibdixious schrieb:
> 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.

Would splitdebug make you happy, or making a quickpackage of the 
original files, qmerging the debug ones, installing the quickpackaged 
files back? The other alternative I see to get at this is a union mount 
on /usr.

Regards,
    Thomas
-- 
gentoo-amd64@gentoo.org mailing list

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

[Daiajo Tibdixious]

On 2/7/07, Thomas Rösner <Thomas.Roesner@digital-trauma.de> wrote:
> Daiajo Tibdixious schrieb:
> > 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.
> or making a quickpackage of the
> original files, qmerging the debug ones, installing the quickpackaged
> files back?

Damn, I already have buildpkg in FEATURES, I keep forgetting about it,
that is an easy solution. Thanks.

> The other alternative I see to get at this is a union mount on /usr.

Dah? Never heard of "union mount" before.
--
gentoo-amd64@gentoo.org mailing list

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

[Daiajo Tibdixious]

On 2/7/07, Daiajo Tibdixious <daiajo@gmail.com> wrote:
> On 2/7/07, Thomas Rösner <Thomas.Roesner@digital-trauma.de> wrote:
> > Daiajo Tibdixious schrieb:
> > > 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.
> > or making a quickpackage of the
> > original files, qmerging the debug ones, installing the quickpackaged
> > files back?
>
> Damn, I already have buildpkg in FEATURES, I keep forgetting about it,
> that is an easy solution. Thanks.
>
> > The other alternative I see to get at this is a union mount on /usr.
>
> Dah? Never heard of "union mount" before.
>
--
gentoo-amd64@gentoo.org mailing list

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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]

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@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
New GPG Key!  Old key expires 2007-03-25.  Upgrade NOW!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Naga]

On Wednesday 07 February 2007 11.14.51 Boyd Stephen Smith Jr. wrote:
> On Tuesday 06 February 2007 21:03, Daiajo Tibdixious wrote:
> > 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.

+1 here. Been running splitdebug since it was introduced. And I love it :)
Great backtraces when something goes wrong but it's not noticeable when 
everything is OK.
-- 
Naga
-- 
gentoo-amd64@gentoo.org mailing list

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

[Daiajo Tibdixious]

On 2/7/07, Boyd Stephen Smith Jr. <bss03@volumehost.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@gentoo.org mailing list

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@gentoo.org mailing list