I have the chroot command failing in chapter 7 of LFS 11.3 (with the message "
chroot: failed to run command /usr/bin/env: no such file or directory.

I have read the two relevant threads on this forum and understood what they are saying, leading me to expect a fault concerning the ld-linux-x86-64.so.2 shared library which, however, is correctly placed in $LFS/usr/lib and symlinked from $LFS/lib64 (both as ld-linux-x86-64.so.2
and ld-lsb-x86-64.so.3). A worrying feature is its size, which is stated as 1.2Mb whereas the host system equivalent (debian) is actually itself a further symlink to a file called ld-2.31.so and has a size of only 173kb.

I have tried the experiment of running chroot ldconfig as recommended in one of the threads to test whether a command not requiring dynamic linking would work and there was no error doing this. I have also run (as recommended) the full command with strace indicating that the chroot() function was successfully run but did then generate the missing file error after that point.

Any further suggestions of possible problems would gladly be received, as also would confirmation of whether the file size difference indicates a real problem or not - principally can anyone confirm that they have a similar sized file in a working system?

[I have been very careful to follow exact instructions and have scripted chapters 4, 5 and 6 while going along. I have already tried reverting to start and running the scripts (under the correct users), diverting std-error to a log file which has produced warnings but no errors].

is the LFS variable set properly, does $LFS/usr/bin/env actually exist?

Yes, Keith to both questions. The chroot call in the strace clearly shows the target as /mnt/lfs and I had in any case particularly checked that was the value of $lfs in chp 7 given the move back to root execution. $lfs/usr/bin/env does exist (as does /usr/bin/env though the command is clearly being called after the root change has occurred), but this is almost certainly irrelevant as the error message is known to inaccurately diagnose the problem as it can arise from failure of internal calls to satisfactorily carry out the dynamic linking before actually starting, in this case, env. This is the reason for suspecting ld-linux-x86-64.so.2.

Can I ask the size of your own ld-linux-x86-64.so.2 if you have a recent lfs running, as this is the most suspicious thing I can find at the moment?

Hope this helps

Thanks very much for this Keith.

I am still mystified as to what is happening but it seems increasingly likely that this file is the problem. I have rerun from start to the end of chapter 5. My ld-linux-x86-64.so.2 in $LFS/usr/lib is not a symlink but a shared library of much greater size. The expected file of $LFS/usr/lib/ld-2.37.so is simply not present, nor indeed anything similar. glibc-2.37 compiled without problems except for some rather trivial warnings and I have repeatedly checked the .\configure call which exactly matches the book. It has also populated $LFS/usr/lib with plenty of other stuff so doesn't seem to be misplacing things.

Back to the drawing board :-(

If you have got an error in something as fundamental as the ld linking loader, then I think that is probably irrecoverable. Remember glibc is about the third package that you build, way back in chapter 5.

I'd scrub it and start again from scratch, paying special attention to the boring bit about setting up the correct environment for your lfs user.

what isthecontents of $LFS/etc/ld.so.conf ?
try symlinking $LFS/usr/lib/ld-linux-x86-64.so.2 to $LFS/lib/ld-linux-x86-64.so.2

Well after a lot of fruitless activity and head scratching I eventually establsihed my mistake: $LFS/bin -> $LFS/usr/bin symlink (and the two other similar ones) were absolute instead of relative. Everything worked fine until chroot chopped off their heads!

Thanks for all the contributions