Не работают команды вроде bash и ls

В ответ на попытку запуска пишет что?

место на диске кончилось?

тоже первая мысль была про место на ФС

Место есть.

(lfs chroot) I have no name!:/# ls
bash: /bin/ls: No such file or directory

(lfs chroot) I have no name!:/# /tools/bin/ls
bin  dev  etc  lib  proc  root	run  sbin  sources  srv  sys  tmp  tools  tools_backup	usr  var

bash: /tool/bin/ldd: No such file or directory
(lfs chroot) I have no name!:/# /tools/bin/ldd /bin/bash 
bash: /tools/bin/ldd: /bin/bash: bad interpreter: No such file or directory

Как чувствует себе ld-elf.so?

Ты про эту либу?

(lfs chroot) I have no name!:/# file /lib/ld-2.27.so           
/lib/ld-2.27.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped

Проверь права на ВСЕ директории перед приложением вплоть до корня. У меня такое встречалось, когда корень оказался без прав на исполнение. Это было с первого раза неочевидно - проверить права на предшествующие директории, а не только на приложения.

Корень точно позволяет запуск, из /tools/bin же запускает. Но да, остальные каталоги надо проверить.

bash: /tools/bin/ldd: /bin/bash: bad interpreter: No such file or directory говорит о том, что ELF интерпретатор не запускается. file /bin/bash должен вывести путь к интерпретатору. У меня он /lib64/ld-linux-x86-64.so.2

Запускается ли он? Должно быть что-нибудь такое:

$ /lib64/ld-linux-x86-64.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
...

Не, не помогает.

Хм, а ведь точно, через него всё запускается.

(lfs chroot) I have no name!:/# /bin/ls 
bash: /bin/ls: No such file or directory

(lfs chroot) I have no name!:/# /lib/ld-2.27.so /bin/ls
bin  dev  etc  lib  proc  root	run  sbin  sources  srv  sys  tmp  tools  tools_backup	usr  var

Понять бы теперь, где именно я встал на эту порочную тропу.

в бинарниках которые не запускются, что написано на предмет какого-нибудь /lib/ld-linux.so.2 ? Это должно быть сцылкой на твой /lib/ld-2.27.so

Сделай strings /bin/true например, или file /bin/true

Если такого интерпретатора нет, сделай ln -s /lib/ld-2.27.so /lib/ld-linux-или-что-там-у-тебя.so

Путь к загрузчику определяет gcc, которым собрают бинарник (в этом случае бинарник - ls).

$ readelf -a /bin//ls | fgrep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

В gcc можно подсмотреть умолчания в spec:

$ gcc -dumpspecs | fgrep dynamic-linker

Да, про эту. Не знаю как она у вас в Линуксах называется, но она отвечает за динамические библиотеки.

Stanson, sf, благодарю, проблема действительно была в том, что интерпретатор сменился с предусмотренного LFS на /lib64/ld-linux-x86-64.so.2.

Осталось понять, как это произошло.

В последний раз когда я собирал LFS в процессе бутсрапа собиралось 2 toolchain-а:

• промежуточный в /tools (с интерпретатором /tools/lib64/ld-linux...). /tools/bin/ и /tools/usr/bin/ утилиты использовали этот интерпретатор.
• конечный в / (с интерпретатором /lib64/ld-linux...). /bin/ и /usr/bin/ утилиты использовали этот интерпретатор.

Вроде бы у Вас всё так и есть с одной мелочью: glibc установлена не в /lib64, а в /lib (управляется опцией --libdir= для glibc и равно lib по умолчанию). Достатночно должно быть создать каталог /lib64/ и положить туда симлинк для интерпретатора.

На x86_64 в linux обычно принято складывать 64-разрядные библиотеки в /lib64 (чтобы 32-битные можно было положить в /lib для совместимости). Но это не обязательно.

Достатночно должно быть создать каталог /lib64/ и положить туда симлинк для интерпретатора.

В новой книжке это делается здесь: http://linuxfromscratch.org/lfs/view/stable/chapter06/glibc.html

ln -sfv ../lib/ld-linux-x86-64.so.2 /lib64
ln -sfv ../lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3

Ну да, я примерно так и решил проблему. Хотя до сих пор не могу понять, как так вышло, что у меня несколько десятков пакетов собралось после libc, а потом вдруг всё сломалось.

Воистину, собирать LFS по ночам - нездоровое занятие)