Вот на третьем этапе у меня проблема собранный initrd никак не находит rootfs.sfs

по порядку цитат.
первое, как пример(на самом деле, если забить в поиск "github livedvd linux", то вывалит просто море проектов) https://github.com/Tomas-M/linux-live (официальный сайтик его https://www.linux-live.org/#explore ), чем удобен конкретно этот проект, так тем, что он самодостаточен и не требует дополнительных телодвижений после создания модели системы(ака "1", "2"). Он сам создаст необходимые каталоги и структуры, а потом и сам образ, единственная забота - контролировать размер желаемой системы, образ больше чем 3-5 гигов сложновато запихнуть в озу меньше 8гиг. Но это чистая вкусовщина, каждый суслик агроном, тут советы фоном.
...
а вот вторая и третья цитата... хм?!
Тут нужно разбираться по цепочке.
Первое - нужно́ понимание всего процесса. Итак, после передачи биосом управления в загруженный образ инитрам, что происходит? А ровно то же, что и при обычной(с диска) загрузке, образ, имея на борту полноценную файловую систему(пусть и виртуальную) с уже размещёнными в ней системными утилитами и !внимание! ядерными модулями, скриптами в виртуальном /etc , и прочими прибамбасами, обеспечивающими собственно нормальную загрузку.
Второе - Вот это вот всё, когда отработает, представляет собой самодостаточную систему линукс в режиме init 1(rescue), загруженной в оперативу. После этого, собственно отрабатывает её штатный init, ну или systemd на предмет монтирования файловой системы(как частный случай расшифровке шифрованных разделов или монтированию LVM) с диска и передаче управления уже системе на нём(по сути мы имеет дважды загружаемую систему, но с разным стартовым набором)... но конкретно в твоём случае этот момент должен инициировать монтирование не с физического диска, а из той самой виртуальной системы, где находится твой rootfs.sfs, либо! должен каким-то образом(через юниты или скрипты) выполняться поиск среди доступных физических носителей именно твоего rootfs.sfs, либо по UUID, либо по метке, либо по прямому указанию и уже монтированию его, скорее всего через loop что-то-там...
  Так вот где-то в этом месте у тебя отсутствует один из этих моментов.
В предложенном выше проекте с гитхаба, который по сути набор баш-скриптов, посмотри внимательно как это всё обыгрывается, страшного там ничего нет, нудновато - да, но не очень уж заумно.
Я этими вещами уже давненько не игрался, маразм своё берёт и деталей уже не вспомню, но копать нужно как-то так.
И да, рекомендую, для облегчения всего процесса использовать федоровский dracut - http://www.bog.pp.ru/work/dracut.html (по русски, для втягивание в понимание процесса, вот оригинал -  https://dracut.wiki.kernel.org/index.php/Main_Page )

Вот на третьем этапе у меня проблема собранный initrd никак не находит rootfs.sfs

P. S. понимаю данная затея не совсем LFS но я уже не знаю куда обратится

По поводу некоторых тонкостей с правами. Гном в этом отношении самый привиреда. Суть в следующем - есть несколько чувствительных точек :
папки PolKit, директория /tmp, SUID-биты на некоторые проги и права на "домашние" папки DM например GDM/SDDM/LXDM, ну и групповые политики доступа "к телу",например ни один DM не даст запустить сессию, если юзер не состоит в группе video, хотя в явном виде этого нигде не прописано, просто так дано в исходниках.
Правила PolKit будит реализованы демоном только в том случае, если каталог с ними и сами правила принадлежат пользователю polkitd и его же группе.
/tmp должна имет права 777 (chmod 777) и перед первым запуском желательно всё от туда удалить, а потом назначить права.
GDM(и остальная компания) базируются в /var/lib/<имя-рек>, права на них должны принадлежать соответствующему пользователю и его группе(вариант группа root, но не всегда работает корректно). это же относится и к логам! ака /var/log/<имя рек>, если у GDM нет доступа к /var/log/gdm, то он не сможет вернуть return 0 и упадет при старте, это нужно отслеживать.
Суид биты тёмный лес, суть в том, что запускаемый процесс имея полномочия в системе(порой почище рута), тем не менее принадлежит пользователю который его запустил, к слову сам пользователь вообще может не иметь даже оболочки, тонкая материя, могу только посоветовать читать доки на конкретные вещи полкит, пам, дбас, иксорг, мускуль, гдм и т.д.. к примеру права на xorg(X) 4755, позволяют пускать иксы от обычного юзера, а 755 уже только от рута(или наоборот?! чёт я сам запуталсо, короче разбирайтесь с этими вопросами внимательно!).
*** Добавлено: 17.10.2020 21:20:54 ***

Готово. https://gitlab.com/Gramozeka/kokoro
Можно в архив, если вдруг кто решится пройти по этому тернистому пути - то лучше Ubuntu или какая федора, чем вот это вот всё. Созданием данного проекта я не преследовал никаких амбициозных целей, чистейший, незамутнённый интеллектуальный анонизм для убийства времени... с тем же успехом можно "Войну и мир" перечитывать в издании 1908 года. да.

Другой вариант зависимостей - это протухшее оносамое мамонта.
Это показатель вообще адекватности команды проекта и прямое указание на проработку вопроса - "а нужно ли иметь дело с этим?"
Суть очень проста - например, в программе заявлена обязательная зависимость от какой-нибудь супер-плюшки, но когда мы идем в официоз этой плюшки, то вдруг выясняется, что последние признаки жизни проект подавал в ...2002 году! и собирается только на gcc четвёртой версии... но, упоротость разработчиков не позволяет им взять уже этот проект под себя или переписать ту часть своего кода, которой нужно это застывшее ГЭ. Я стараюсь к подобному даже не прикасаться, всегда есть альтернатива, а упорствовать в глупости - поистине глупость в квадрате.

Итак дорогие мои, начнём забивание мозгов тем что "НИНУ́ЖНА".

С чего начать? Первое что приходит на ум, это как устроена система с точки зрения самой системы. Но это тупиковый путь, т.к. тема безгранична и до сути вопроса в практической плоскости данного топика можно никогда не добраться, поэтому задекларируем что мы это знаем. 
Для построения системы потребуется немного чистого диска, для знакомства хватит пяти гигов(на самом деле всего 600-800 метров, но накладные расходы на сборку и исходники...).
Потребуется система, способная собрать gcc и glibc, что на самом деле довольно не тривиальная задача.
Потребуется специально огороженный юзер.
  Вот с него и начнём.
Делается он так:

exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash

cat ~/.bashrc

set +h
umask 022
CLFS=/mnt/clfs
LC_ALL=POSIX
PATH=/cross-tools/bin:/bin:/usr/bin
export CLFS LC_ALL PATH
unset CFLAGS CXXFLAGS PKG_CONFIG_PATH

вот теперь надо пояснить что есть что.

exec env -i HOME=${HOME} TERM=${TERM} PS1='\u:\w\$ ' /bin/bash
эта строчка указывает системе использовать переменные окружения только из домашнего каталога, никакие другие переменные, кроме объявленных локально не будут учитываться.

set +h

в баше есть функция кеша $PATH, укоряющая поиск приложений, т.е. однажды найденная программа ls по пути /usr/bin/ls, все последующие разы будет находиться по нему, не пересматривая весь $PATH, что разумно для простоты работы. Так вот set +h эту функцию отключает, теперь каждый раз, когда пользователь вводит какую либо команду, она будет находится обходом всего пути указанного в $PATH, зачем это надо я чуть позже растолкую.

CLFS=/mnt/clfs
просто переменная, указывающая где у нас "чистый лист".

LC_ALL=POSIX
тоже понятно? Для тугих - отмена всех языковых установок - только посикс, лютый хардкор девственной консоли.

PATH=/cross-tools/bin:/bin:/usr/bin
собственно PATH, тут важна последовательность поиска, первый же путь оказавшийся валидным и будет применён, если имеется /usr/bin/ls и /cross-tools/bin/ls, то использован будет последний, т.к. он первый в поиске. Это важно для правильного линкования, т.к. задача собрать кроскомпилятор не связанный с базовой системой ничем.

export CLFS LC_ALL PATH
собственно инициация переменных указанных выше.

unset CFLAGS CXXFLAGS PKG_CONFIG_PATH
отмена флагов компилятора если вдруг таковые были где-то заявлены системой.

Собственно с этим всё. Войдя в эту учётку стоит применить :

..продолжение следует.
*** Добавлено: 29.09.2020 14:37:17 ***

..продолжим.
Сам по себе компилятор работать не может, ему нужен определённый обвяз. Фундаментом является связка с\с++, уже на ней строится всё остальное - фортраны, бейсики и прочий зоопарк из рептилий и всяких растов.
Подробно останавливаться на том кто есть кто я тут не буду, просто перечислю что нужно:

file
linux(заголовочные файлы ядра)
m4
ncurses
pkg-config
gmp
mpfr
mpc
isl(опционально, пакет не обязательный, но иногда дюже полезный, подробности можно почитать на сайте самого проекта http://isl.gforge.inria.fr/ )
binutils
gcc(собственно виновник этого треша)
glibc

но!!!
это только обвязка! Сам кросс-компилятор собирается отдельно с опорой вот на этот список.

Тут следует немного отступить от темы и погрузится  теорию и практику собственно "сборки из исходных кодов".
Тема бездонная и крайне неоднозначная, но без базовых знаний дальнейшее будет просто непонятно.

...

*** Добавлено: 29.09.2020 15:32:12 ***

... про исходники.
Систем сборки существует море, и каждый день кто-то изобретает что-то новое. Но.. есть исторически сложившаяся практика применения самых древних, первых систем, и, негласное соглашение программистов, работающих над основами системы, использовать только их, вернее Её. Система на основе configure→make→make install.
Вот с её помощью и собирается базовый набор компиляции.
Там не сложно :
В дереве исходников запускается скрипт configure, который обрабатывает по своему алгоритму всё доступное пространство переменных(вот тут то и нужен наш огород!) и составляет последовательность компиляции.
Далее, если конфигурация завершается положительно, make, на основе выхлопа configure собирает всё в бинарные файлы.
А напоследок make же, на основе  выхлопа configure выполняет процедуру install, устанавливая собранное в заранее обговоренные места.

configure, в зависимости от прямоты рук тех, кто его составлял принимает кучу аргументов, расписывающих какие переменные использовать, как и куда устанавливать программы, библиотеки и прочее.
вот тут то и встречается главная засада всех новичков - "как это работает вообще?!!!"... что тут можно посоветовать? - читайте доки(авось поможет). Важно понимать - без знания как этим пользоваться самостоятельно что-то собрать не получится... хотя... дуракам порой везёт, как знать, как знать...
*** Добавлено: 29.09.2020 16:28:29 ***

ну ладно, это всё лирика.
Практика - критерий истины, это нужно знать.
Попробуем создать первый кросс-тул.(их два).
Дальше можно просто копипастить шаги в консоль, позже я прокомментирую что зачем, пока тупо Ctrl+C & Ctrl+V...
Открываем консоль и становимся root'ом натурально:
0.

Сейчас все действия выполняются от root'а, пока я явно не укажу другое(п. 5)
1.

2.

3.

Всё это нужно поместить в только что созданный каталог ${CLFS}/sources и присвоить нашему огороженному юзеру, а потом и войти в учётную запись:

4.

5.(!!! ахтунг !!! теперь очень важные танцы с бубной !!!) мы теперь пользователь clfs и все действия в дальнейшем выполняются от его имени, пока я явно не укажу другое!!!

6.

Ну вот теперь можно собирать...

продолжение следует...

*** Добавлено: 29.09.2020 19:28:58 ***

...ну да, ну да, собирать. Надо прояснить некоторые моменты до того как.
Есть два подхода к процессу сборки - первый самый тупой и надёжный: зайти в дерево исходника и скомандовать "ату яво! фас!", как там в фильме: "...машина надёжная, убойная, 75 патронов, но весит...", это срабатывает для маленьких наколеночных вещей ака "Hello World!", но для чего-то серьёзного это не годится(если конечно важен не просто результат, а предсказуемый и, что важнее, обратимый результат, когда всё можно обернуть взад).
Для второго нужны скрипты, как правило на баше(не обязательно). В них прописывается весь сценарий сборки целиком, задача просто запустить скрипт и он всё что нужно выполнит.
В первой иттерации пакетирование(ещё одна фишка) не нужно, всё будем делать "по живому", но таки скриптиками запастись стоит...

*** Добавлено: 29.09.2020 20:20:19 ***

сама процедура проста:
распаковываем архив, заходим в него, выполняем последовательность команд:

./configure --prefix=/cross-tools
make -j4
make install

тут важен --prefix=/cross-tools (выше мы сделали симлинк в главном дереве системы на реальное расположение директории). Это нужно для того, чтоб готовые программы, оказавшись в изоляции, продолжали считать своё местоположение от корня.
Но это не всё, для каждого архива набор специфических установок разный. Чуть позже я залью обновлённое дерево на гитлаб, а пока просто приведу по порядку сборки для каждого архива:

file-5.39

./configure --prefix=/cross-tools
make
make install

linux-5.8.9

make mrproper
make INSTALL_HDR_PATH=dest headers_install
mkdir -pv /tools/include || true
cp -rv dest/include/* /tools/include

m4-1.4.18

sed -i 's/IO_ftrylockfile/IO_EOF_SEEN/' lib/*.c
echo "#define _IO_IN_BACKUP 0x100" >> lib/stdio-impl.h
./configure --prefix=/cross-tools
make
make install

сид тут редактирует устаревшие или глюкнутые артефакты, такого будет много, не пугайтесь.

ncurses-6.2

sed -i s/mawk// configure
./configure \
            --prefix=/cross-tools \
            --with-shared   \
            --without-debug \
            --without-ada   \
            --enable-widec  \
            --enable-overwrite \
            --without-gpm
make -C include
make -C progs tic
install -v -m755 progs/tic /cross-tools/bin

pkg-config-lite-0.28-1

./configure \
    --prefix=/cross-tools \
    --build=${CLFS_TARGET} \
    --with-pc-path=/tools/lib64/pkgconfig:/tools/share/pkgconfig
make
make install

gmp-6.2.0

./configure   \
    --prefix=/cross-tools \
    --enable-cxx \
    --disable-static
make
make install

mpfr-4.1.0

LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
    --prefix=/cross-tools \
    --disable-static \
    --with-gmp=/cross-tools
make
make install

mpc-1.2.0

LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
    --prefix=/cross-tools \
    --disable-static \
    --with-gmp=/cross-tools \
    --with-mpfr=/cross-tools
make
make install

isl-0.22.1

LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
./configure \
    --prefix=/cross-tools \
    --disable-static \
    --with-gmp-prefix=/cross-tools
make
make install

binutils-2.35

mkdir -v build
cd       build

AR=ar AS=as \
../configure \
    --prefix=/cross-tools \
    --host=${CLFS_HOST} \
    --target=${CLFS_TARGET} \
    --with-sysroot=${CLFS} \
    --with-lib-path=/tools/lib:/tools/lib64 \
    --disable-nls \
    --disable-static \
    --enable-64-bit-bfd \
    --enable-gold=yes \
    --enable-plugins \
    --enable-threads \
    --disable-werror
make
make install

тут надо пояснить - некоторые проекты требуют, чтоб дерево исходников и директория сборки различались, поэтому создаём отдельную площадку где будет сборка.

gcc-10.2.0 - первый ход, предварительный. Далее директория для сборки будет создаваться вообще вне дерева исходников, для удобства.

patch -Np1 -i ../gcc-10.2.0-specs-1.diff
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_1\n#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"\n' >> gcc/config/linux.h
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_2\n#define STANDARD_STARTFILE_PREFIX_2 ""\n' >> gcc/config/linux.h
touch /tools/include/limits.h
mkdir -v ../gcc-build
cd ../gcc-build
AR=ar \
LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
../gcc-10.2.0/configure \
    --prefix=/cross-tools \
    --build=${CLFS_HOST} \
    --host=${CLFS_HOST} \
    --target=${CLFS_TARGET} \
    --with-sysroot=${CLFS} \
    --with-local-prefix=/tools \
    --with-native-system-header-dir=/tools/include \
    --disable-shared \
    --with-mpfr=/cross-tools \
    --with-gmp=/cross-tools \
    --with-mpc=/cross-tools \
    --with-isl=/cross-tools \
    --without-headers \
    --with-newlib \
    --disable-decimal-float \
    --disable-libgomp \
    --disable-libssp \
    --disable-libatomic \
    --disable-libitm \
    --disable-libsanitizer \
    --disable-libquadmath \
    --disable-libvtv \
    --disable-threads \
    --with-isl=/cross-tools \
    --enable-languages=c,c++ \
    --with-glibc-version=2.11
make -j4 all-gcc all-target-libgcc
make install-gcc install-target-libgcc

сам патч вот тут - https://gitlab.com/Gramozeka/kokoro/-/b … ecs-1.diff , он исправляет пути для автоматического линковщика, чтоб получившийся прекомпилятор не ломился в родительскую систему за каждой мелочёвкой, это важная примочка, но есть современные средства позволяющие получать тот же результат, но тогда надо полностью следовать путём предлагаемым в официальном руководстве и забыть о multilib.

glibc-2.32 32-бита.

mkdir -v ../build
cd      ../build
echo "libc_cv_slibdir=/tools/lib" >> config.cache
BUILD_CC="gcc" \
CC="${CLFS_TARGET}-gcc ${BUILD32}"  \
BUILD_CXX="g++"  \
CXX="${CLFS_TARGET}-g++ ${BUILD32}" \
AR="${CLFS_TARGET}-ar" \
RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.32/configure \
    --prefix=/tools \
    --host=${CLFS_TARGET32} \
    --build=${CLFS_HOST} \
    --enable-kernel=3.2 \
    --with-binutils=/cross-tools/bin \
    --with-headers=/tools/include \
         --enable-add-ons \
  --enable-obsolete-nsl \
  --enable-obsolete-rpc \
  --enable-profile \
  --enable-static-nss \
  --disable-werror
    make -j4
    make install

glibc-2.32 64-бита.

mkdir -v ../build
cd      ../build

echo "libc_cv_slibdir=/tools/lib64" >> config.cache

BUILD_CC="gcc ${BUILD64}" \
CC="${CLFS_TARGET}-gcc ${BUILD64}"  \
BUILD_CXX="g++ ${BUILD64}"  \
CXX="${CLFS_TARGET}-g++ ${BUILD64}" \
AR="${CLFS_TARGET}-ar" \
RANLIB="${CLFS_TARGET}-ranlib" \
../glibc-2.32/configure \
    --prefix=/tools \
    --host=${CLFS_TARGET} \
    --build=${CLFS_HOST} \
        --libdir=/tools/lib64 \
    --enable-kernel=3.2 \
    --with-binutils=/cross-tools/bin \
    --with-headers=/tools/include \
       --enable-add-ons \
  --enable-obsolete-nsl \
  --enable-obsolete-rpc \
  --enable-profile \
  --enable-static-nss \
 --cache-file=config.cache --disable-werror
    make -j4
    make install

Тут надо пояснить - материнская система должна уметь в мультилиб! Это без вариантов.

gcc-10.2.0_cross
Собственно первый ход кросс-компиляции, всё что выше это только прелюдия была.

patch -Np1 -i ../gcc-10.2.0-specs-1.diff
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_1\n#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"\n' >> gcc/config/linux.h
echo -en '\n#undef STANDARD_STARTFILE_PREFIX_2\n#define STANDARD_STARTFILE_PREFIX_2 ""\n' >> gcc/config/linux.h
mkdir -v ../gcc-build
cd ../gcc-build
AR=ar \
LDFLAGS="-Wl,-rpath,/cross-tools/lib" \
../gcc-10.2.0/configure \
    --prefix=/cross-tools \
    --build=${CLFS_HOST} \
    --target=${CLFS_TARGET} \
    --host=${CLFS_HOST} \
    --with-sysroot=${CLFS} \
    --with-local-prefix=/tools \
    --with-native-system-header-dir=/tools/include \
    --disable-static \
    --enable-languages=c,c++ \
    --with-mpc=/cross-tools \
    --with-mpfr=/cross-tools \
    --with-gmp=/cross-tools \
    --with-isl=/cross-tools
make -j4 AS_FOR_TARGET="${CLFS_TARGET}-as" \
    LD_FOR_TARGET="${CLFS_TARGET}-ld"
make install

Выполнив всё это, мы получим первый кросс-компилятор, способный собрать полноценное дерево cross-tools, с помощью которого можно собрать готовую систему, причём платформу можно выбирать в широких пределах, на то он и "кросс"... ну а можно и просто хелоуворды кАнпилять, какая разница в общем-то...
PS// об одной "мелочи" я не рассказал, это такая фича как

make check

это девелоперская примочка, позволяющая тестировать собранное на предмет багов и вообще годности к использованию. Она важна с академической точки зрения, но простому обывателю мало пригодна и понятна, однако знать о ней нужно и даже иногда пользоваться. Только стоит учесть - если на сборку(make) глибса уйдёт примерно минут десять, то на make check после неё уйдёт более часа.

продолжение обязательно будет...
*** Добавлено: 30.09.2020 02:19:08 ***

...продолжим.

Маленькое лирическое отступление.
Современные тенденции в мире Linux меня лично не очень радуют. Корпорации медленно но верно прибирают к рукам все наработки сообщества. Потерингиада уже показывает своё истинное нутро, лишая по большей части манёвра и превращая систему в аналог Венды. Это удручает, но многим нравится, с этим тоже нужно считаться. Я несколько раз пробовал это поделие(systemD), но каждый раз убеждался - не стоит тратить на него время, оно как раковая опухоль, суёт свои метастазы в каждый уголок системы, а по последним сведениям и уже в ядро! Мутная, глюкавая, абсолютно не прозрачная прога пытается стать самой системой - это не юникс-вей! Кто бы что не говорил, нравится? Пользуйтесь, дело хозяйское, мы пока ещё в относительно свободном мире. Но по этой дороге я не ходок...

Итак, кросс-тул нейтрален, на его базе можно и системДЭ собрать, главное понимать что творишь, а там дело техники, но не спрашивайте меня как это делать, на сайте проекта есть ветка посвящённая этому чуду-юду.
А я по старинке, на SysVinit.

*******************************************
Важный момент. Мультилиб специфическая штука и во многих дистрах уже свернули работы по его поддержке, поэтому собрать gcc с его поддержкой будет проблематично. Я не совсем дока по части железа, поэтому стопроцентной гарантии не дам, но полный набор инструментов я построил на Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz , обладатели аналогичных железок могут ими воспользоваться.
Лежит тут - https://gitlab.com/Gramozeka/kokoro/-/t … ross-tools
Достаточно распаковать оба архива в нужное место и после небольших манипуляций можно делать chroot в полностью готовую для сборки системы среду. Она уже умеет в мультилиб, поэтому иметь какую-то продвинутую систему не обязательно, лишь бы она(система) умела в chroot, и могла в 64-битное ядро, более-менее свежее.
********************************************

продолжу описание процесса.

...после сборки gcc-10.2.0_cross, мы всё ещё сильно зависим от материнской системы, нам нужны всякие тары, сиды, перлы и прочие питоны с башами. Второй этап это создание этих всех инструментов с привязанным к ним компилятором, который будет зависим только от самого себя.
Вот нужные инструменты по порядку сборки:

gmp
mpfr
mpc
isl
zlib
binutils
gcc
ncurses
bash
bzip2
check
coreutils
diffutils
file
findutils-
gawk
grep
gzip
m4
make
patch
sed
tar
xz
СТОП!!!!!! ЭТО ОТДЕЛЬНАЯ ПЕСТНЯ́!
gettext
bison
perl
Python
multiarch_wrapper
texinfo
util-linux
vim

Некоторые повторяются? ..хм, да, есть такое. Сейчас объясню механизм.
Наша цель с помощью работающей системы с компилятором А, построить работающую систему с компилятором С.
Но, прямым ходом, этого сделать нельзя, ибо динамическая линковка наше всё. Но её можно обмануть.
Схематично это работает так:
А собирает В1(выше это оно) с привязкой к посторонней директории в корне(это важно), со своим набором библиотек и заголовков, никак не слинкованными с основной системой.
Далее В1, собирает для себя вспомогательные инструменты и В2, которые привязаны только к нему, слинкованы с ним, и не имеют с материнской системой ничего общего.
Единственный недостаток - это всё привязано не к корню системы "/ ", а к директории в корне, при том, что имеет некоторые связи с В1.
Так вот когда мы соберём С с помощью В2 основываясь на реальном корне системы "/", мы избавимся и от В1, и от В2, и получим самодостаточный компилятор в нативной среде. Для этого нам понадобится chroot.(но это чуть позже)

В этот раз, мы уже имеем компилятор который к материнской системе не принадлежит, всё ещё оставаясь огороженным пользователем clfs, добавим несколько переменных и изменим саму среду сборки:

Это очень важный момент, так как в окружении пользователя глобально объявлены переменные  CC, CXX и т.д., то при умолчании, скрипты configure, сперва будут искать в системе именно эти компиляторы и инструменты, а в некоторых, так и вовсе только эти переменные и отвечают за правильное обращение к сборочному процессу, а т.к. хеширование у оболочки отключено, то в первую очередь будет найден наш новый кросс-компилятор

x86_64-unknown-linux-gnu-gcc , а не системный gcc.

После объявления этих переменных, можно начинать собирать вторую часть кросс-компилятора(выше список). Подробно расписывать все 33 позиции наверно не стоит, слишком уж много места это занимает.
Подробно можно посмотреть вот тут - https://gitlab.com/Gramozeka/kokoro/-/t … ary-System
там всё должно быть понятно, если есть желание, то немного доработав(заменив или убрав переменные скрипта) можно просто собирать вручную.

На счет "СТОП!!!!!! ЭТО ОТДЕЛЬНАЯ ПЕСТНЯ́!". Это один из тонких моментов.
Некоторые вещи, такие как perl или python, при сборке крайне неразборчивы и мало-управляемые, поэтому практически не пригодны для кросс-компиляции, т.к. собираясь, они находят в системе самих же себя установленных, и наглухо линкуются с тем, что есть, запретить это или как-то ограничить просто не реально. Поэтому, дойдя до этого места, дособирать кросс-тул придётся уже в chroot-окружении.
***************************************
Вернёмся к вопросу возможности материнской системы к собиранию мультилиба, выше ссылка на два архива, если нет возможности собрать нативный мультилиб, то можно воспользоваться уже готовым кросс-тулом, в нем уже собраны все нужные вещи, в том числе и эта пестня с питонами и перлами...
  Кто-то заметил - а что за приблуда multiarch_wrapper ? В самом низу поясню зачем это.
*************************************************

Для этого, собрав всё до xz включительно, нужно выйти из учетки clfs, он больше не нужен и его можно удалить из системы полностью, необходимо, оставаясь root'ом, создать в устанавливаемой системе необходимое дерево процессов ака proc, dev, var и т.д., создать ноды(что это вообще за чертовщина!?) и прочие моменты, монтируем это всё хозяйство в ядро работающей системы и выполняем chroot:
(!!!Ахтунг!!! Теперь мы root! Практически партизан в тылу врага, поэтому делаем всё очень вдумчиво и аккуратно.)

Выполнив это мы увидим вот такую картинку:

теперь мы единственный и безраздельный пользователь с безграничными полномочиями в системном пространстве будущей системы, в которой пока нет ничего, кроме пустоты.

Теперь нужно построить всё системное дерево "как у людей":

Чтобы всё это заработало как надо, нужно создать системные декорации для root'а и системы сборки:

А теперь объявляем себя Государем Мира!

и увидим скромное:

Тут нужно оговориться - я собираю всё в специально организованном загончике, но можно всё делать и по живому, например в /tmp.
Делаем cd /tmp, распаковываем нужный исходник, например unxz /sources/gettext-0.21.tar.xz, переходим в него и собираем.
Все нужные опции можно подсмотреть в ветке Temporary-System тут https://gitlab.com/Gramozeka/kokoro/-/tree/master/ . Все программы из второго списка собираются в /tools, а после входа в чрут, туда же дособираются и эти :

gettext
bison
perl
Python
multiarch_wrapper
texinfo
util-linux
vim

Когда это всё собрано, можно приступать собственно к построению своей собственной системы, так, как взбредёт в голову. Есть конечно базовый минимум, который нужно построить чтобы просто удалить наши кросс-инструменты, вот примерный список :

linux-5.8.9
man-pages-5.08
glibc-2.32
tools-prep
link-glibc-32
zlib-1.2.11
bzip2-1.0.8
xz-5.2.5
zstd-1.4.5
file-5.39
ncurses-6.2
readline-8.0
m4-1.4.18
bc-3.1.5
flex-2.6.4
binutils-2.35
gmp-6.2.0
mpfr-4.1.0
mpc-1.2.0
isl-0.22.1
attr-2.4.48
acl-2.2.53
libcap-2.43
shadow-4.8.1
gcc-10.2.0-final
pkg-config-0.29.2
ncurses-6.2-final
sed-4.8
psmisc-23.3
gettext-0.21
bison-3.7.2
binutils-2.35_i686
grep-3.4
bash-5.0
libtool-2.4.6
gdbm-1.18.1
gperf-3.1
expat-2.2.9
inetutils-1.9.4
perl-5.32.0
XML-Parser-2.46
intltool-0.51.0
autoconf-2.69
automake-1.16.2
kmod-27
elfutils-0.181
libffi-3.3
openssl-1.1.1g
Python-3.8.5
re2c-2.0.3
ninja-1.10.1
meson-0.55.3
coreutils-8.32
check-0.15.2
diffutils-3.7
gawk-5.1.0
findutils-4.7.0
groff-1.22.4
grub-2.04
less-551
gzip-1.10
iproute2-5.8.0
kbd-2.3.0
libpipeline-1.5.3
make-4.3
patch-2.7.6
man-db-2.9.3
tar-1.32
texinfo-6.7
vim-8.2.1361
eudev-3.2.9
procps-ng-3.3.16
util-linux-2.36
e2fsprogs-1.45.6
sysklogd-1.5.1
sysvinit-2.97
libseccomp-2.5.0
iana-etc-2.30
libsigsegv-2.12
pcre-8.44
cpio-2.13
gc-8.0.4
gpm-1.20.7
libatomic_ops-7.6.10
lsb-release-1.4

После сборки shadow нужно задать пароль рута, после сборки bash который /bin/bash(не забыли, у нас есть ещё и /tools/bin/bash) нужно войти в новый баш, и продолжать уже из него...
Важная тонкость - есть такой пакет libffi, отвечает за интерфейсы программных вызовов при работе с процессором, так вот по умолчанию у неё стоит флаг сборки --with-gcc-arch=native, т.е. она собирается под тот процессор, который сейчас реально собирает, и если мы попытаемся перенести всю собранную систему на другое железо, с другим процессором(пусть даже и того же вендора), то есть большой шанс словить "Illegal Operation Errors" и полностью неработающую систему, чтобы это избежать нужно либо явно указывать архитектуру на которой в последствии всё это будет работать, либо выставлять некие виртуальные усреднения ака x86_64. Подробности читать тут - https://gcc.gnu.org/onlinedocs/gcc-10.2 … tions.html
...
Список дан в той последовательности, в которой он гарантированно соберётся, без конфликта зависимостей,цифры дело временное, на момент написания этого поста этот набор был собран и проверен, система загрузилась штатно, без костылей и примочек, можно собирать любой собственный софт по задачам.
Да-да, про ядро и настройки ни слова  .
Это отдельное лютое шаманство.
Когда вот это всё собрано, собственно и наступает момент истины, насколько мы вообще представляем "как это работает".
Последовательность действий такова:
Сперва нужно выйти из системы в материнскую систему и войти обратно явно указав использовать /tools/bin/bash, это нужно для процедуры strip, она сильно уменьшает объём занимаемого пространства, буквально в разы, да и быстродействие повышает. Чистится всё хозяйство примерно так:

Когда всё это сделано собственно остаётся только собрать своё ядро, установить загрузчик и всё, система готова. Правда она ещё ничерта не может, ни сеть толком, ни всяких гитов и иксов, но это уже другая глава, где нужно решать вопросы с пакетной системой, стратегический план построения системы, что нужно, а что не очень, как автоматизировать те или иные процессы и т.д.. Частично это описано тут - http://www.linuxfromscratch.org/blfs/view/svn/, но далеко не всё, тут уже личная квалификация рулит и педалит. Я конечно это всё решил по своему и сейчас пишу из вот этого всего, есть проект моих портянок, скорее всего через какое-то время(до месяца, возможно и дольше) я залью свой набор готовой системы под вот это ядро - https://gitlab.com/Gramozeka/kokoro , но это процесс не быстрый, так что придумывайте без меня, задавайте вопросы, что знаю подскажу.
*** Добавлено: 30.09.2020 03:39:24 ***

*********
отдельно про multiarch_wrapper.
Т.к. у нас мультилиб, встаёт вопрос - как сепарировать библиотеки и бинарники разных битностей.
Вот это multiarch_wrapper для того и нужен. Если библиотеки можно разнести по lib32 и lib64, то с бинарниками это всё сложнее, потом, когда система уже собрана, это всё решается в индивидуальном порядке, я например всю ветку 32-бит вынес в отдельный анклав в корне /i686 со своим системным деревом, практически контейнер аль-ля docker, но на этапе сборке это всё не так просто.
Работает он (multiarch_wrapper) очень просто, кто секёт в ссях может почитать сам:

#define _GNU_SOURCE

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

#ifndef DEF_SUFFIX
#  define DEF_SUFFIX "64"
#endif

int main(int argc, char **argv)
{
  char *filename;
  char *suffix;

  if(!(suffix = getenv("USE_ARCH")))
    if(!(suffix = getenv("BUILDENV")))
      suffix = DEF_SUFFIX;

  if (asprintf(&filename, "%s-%s", argv[0], suffix) < 0) {
    perror(argv[0]);
    return -1;
  }

  int status = EXIT_FAILURE;
  pid_t pid = fork();

  if (pid == 0) {
    execvp(filename, argv);
    perror(filename);
  } else if (pid < 0) {
    perror(argv[0]);
  } else {
    if (waitpid(pid, &status, 0) != pid) {
      status = EXIT_FAILURE;
      perror(argv[0]);
    } else {
      status = WEXITSTATUS(status);
    }
  }

  free(filename);

  return status;
}

работает это так:
имеем приложение uasya_hakir под обе архитектуры( т.е. два бинарника с одинаковым названием, но разной битности). То, что на 32-bit переименовываем в uasya_hakir-32, а то что на 64-bit в uasya_hakir-64. Теперь создаём ссылку uasya_hakir на скомпилированный бинарник multiarch_wrapper.
И ??? Объявляем глобальную системную переменную USE_ARCH в двух видах : USE_ARCH=32 и USE_ARCH=64. Теперь, чтобы запустить 32-х битный вариант uasya_hakir , вызываем его так :

или, если нам нужна 64-х битная версия то :

или вообще :

+

Сам обещал показать болгарку под управлением Gentoo Linux.

пруфы!!
я такого не говорил, но на сие поделие бы глянул...
и таки да! Прекращайте оффтоп, давайте по существу темы.
Тут копался в wine, так обнаружил одну забавную фичу - а именно, оказывается можно построить практически аналог WoW64, для этого нужен корректный multilib и ванильный i686-based, в первом строится чистый wine-win64, во втором чистый wine-i686, потом в первом собирается гибрид wine-win64+wine-i686=wine-multilib.
В таком гибриде корректно работают проги как 32-бит, так и 64-бит, собственно как в любой 64-бит винде.
вот так выглядит дерево такого вайна:

при winecfg ошибок меньше в разы!(и да, я собираю актуальный staging с ./patches/patchinstall.sh DESTDIR=../$PRGNAM-$VERSION --all
...............

болгарку под управлением Gentoo Linux.

я тоже хочу такое увидеть, это же шедевр

под управлением Gentoo Linux.

хАчуу! ХАчууу болгарку! ((с) Адская белочка)

после второго инфаркта мне недолго осталось

Отставить паническое настроение, надо верить в лучшее. И да 100 лет желаю вам ещё прожить. 

сами, всё сами, ищ обленились, "..во-о-от мы в ваше время !"... ag

  Ни фига! Сам обещал показать болгарку под управлением Gentoo Linux.

А мастер-классы "на все руки мастер" кто проводить будет?

сами, всё сами, ищ обленились, "..во-о-от мы в ваше время !"...
как говорят на лоре "нинужна". Достаточно документации в /usr/share/doc{,info}(/usr/doc{,info}).
Никогда раньше внимания не обращал, а тут залез случайно и залип на месяц - это ж  клондайк знаний, даже интернет не нужен, сиди читай, вся система под микроскопом.