chroot, ch6

Jeremy Utley jeremy at
Tue Nov 25 18:49:43 PST 2003

In article <20031125101226.48069128.epostma at>, Erik Postma wrote:
> On Tue, 25 Nov 2003 02:16:24 -0200, michael <michael8110 at>
> wrote:
>> thank you,allard and durk.. no,durk,the env binary is sitting there,what
>> happens is that for some mysterious reason the /mnt/lfs directory is
>> invisible to chroot,so it goes straight on to the next thing it
>> finds,and that's /tools/bin/env ,which is a binary,so can't be chrooted
>> into anyway.Allard,i'm in this for educational purposes,and so far i've
>> reaped hansomely-so after my first successful try,i rm-rf-ed everything
>> and started over,this time not as a zombie,but trying to understand as
>> much as possible,and here i am stuck in this chroot thing again..i don't
>> think it's what you suggested,since the host's bash  is also 2.05..
>> what's unnerving about it is that i've been there and got out,and now,no
>> way,i spent the better part of the weekend trying everything i could
>> think of,googling a lot,to no i erased tools and redid
>> everything but the same happened again.If i try simply chrooting into
>> /mnt/lfs i'm informed there's no /bin/bash and if into /mnt/lfs/tools
>> ,then it pukes out that can't be opened ,now,isn't this
>> related to dynamic loading?Thank you and please let me know if you can
>> think of something ,must be a tiny detail..
> It seems you missed the possibly most useful reply to your previous post:
> the one by Matt Burgess, who directed you to the FAQ.
> (
> There, it says you may have forgotten to apply the specs patch. You can
> check this by issuing 
> ldd $LFS/tools/bin/env
> On my machine, the answer is
> => /tools/lib/ (0x40016000)
>         /tools/lib/ => /tools/lib/ (0x40000000)
> The important part is the /tools/ part (3x).

No no no!

do NOT use ldd in testing the linking for chapter 5 binaries - ldd is just
a script, and often can produce bogus output.  Jeroen, if you're monitoring
this, you *NEED* to change this!

use the command:

readelf -l {binary} | grep interpreter

Should respond with:

Requesting program interpreter: /tools/lib/

See some of the earlier discussion pre 5.0 release between me and Greg on the
lfs-dev list (Search for sanity checks) and see why this is wrong.


More information about the lfs-support mailing list