Система LFS будет собрана с использованием уже установленного дистрибутива Linux (например, Debian, OpenMandriva, Fedora или openSUSE). Существующая система Linux (хост) будет использоваться в качестве отправной точки для предоставления необходимых программ, включая компилятор, компоновщик и оболочку, для создания новой системы. Выберите опцию «разработка» во время установки дистрибутива, чтобы получить доступ к этим инструментам.

В качестве альтернативы установке отдельного дистрибутива на свой компьютер вы можете использовать LiveCD другого дистрибутива.

Глава 2 этой книги содержит информацию, о том, как создать новые разделы Linux и файловую систему, где будет скомпилирована и установлена новая система LFS. Глава 3 содержит информацию, о том, какие пакеты и исправления необходимо загрузить для сборки системы LFS и как их хранить на файловой системе. Глава 4 освещает вопросы настройки рабочего окружения. Пожалуйста, внимательно прочитайте Глава 4, так как в ней объясняется несколько важных моментов, о которых вам необходимо знать, прежде чем вы начнёте работать со следующими главами.

Глава 5 содержит информацию об установке первоначального набора инструментов (binutils, gcc и glibc) с использованием методов кросс-компиляции для изоляции новых инструментов от хост-системы.

Глава 6 рассказывает, как выполнить кросс-компиляцию базовых утилит с использованием только что собранного временного набора инструментов.

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

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

В Глава 8 будет собрана полноценная система LFS. Еще одно преимущество среды chroot заключается в том, что она позволяет вам продолжать использовать хост-систему во время сборки LFS. Ожидая завершения компиляции пакетов, вы можете продолжать пользоваться своим компьютером в обычном режиме.

Чтобы завершить установку, в Глава 9 происходит настройка базовой конфигурации системы, в Глава 10 настраиваются ядро и загрузчик. Глава 11 содержит информацию о том как расширить возможности системы LFS. После выполнения шагов, описанных в этой главе, компьютер будет готов к загрузке в новую систему LFS.

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

Ниже приведен список пакетов, обновленных с момента предыдущего выпуска книги.

Это версия 12.2 книги Linux From Scratch от 1 сентября 2024. Если этой книге больше шести месяцев, возможно, уже доступна более новая, улучшенная версия. Чтобы узнать это, проверьте одно из зеркал https://mirror.linuxfromscratch.ru/mirrors.html.

Ниже приведен список изменений, внесенных с момента предыдущего выпуска книги.

Если при работе с этой книгой у вас возникнут проблемы или вопросы, посетите страницу часто задаваемых вопросов по адресу https://mirror.linuxfromscratch.ru/faq/#generalfaq. Часто там уже есть ответы на большинство вопросов. Если на этой странице нет ответа на ваш вопрос, попробуйте самостоятельно найти источник проблемы. Следующий документ даст вам некоторые рекомендации по устранению неполадок: https://mirror.linuxfromscratch.ru/hints/downloads/files/errors.txt.

Если вы не можете найти решение своей проблемы в разделе часто задаваемых вопросов, выполните поиск в списках рассылки по адресу https://mirror.linuxfromscratch.ru/search.html.

У нас также есть замечательное сообщество LFS, которое готово предложить помощь через списки рассылки и IRC (см. Раздел 1.4, «Ресурсы» этой книги). Мы получаем много вопросов в службу поддержки каждый день, и на многие из них можно легко ответить, зайдя в раздел часто задаваемых вопросов и предварительно выполнив поиск в списках рассылки. Чтобы мы могли оказать помощь, вам необходимо сначала провести самостоятельное исследование. Это позволяет нам сосредоточиться на более сложных вопросах в поддержке. Если ваши поиски не привели к решению проблемы, включите всю необходимую информацию (упомянутую ниже) в свой запрос о помощи.

gcc -D ALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-D LOCALEDIR=\"/mnt/lfs/usr/share/locale\"
-D LIBDIR=\"/mnt/lfs/usr/lib\"
-D INCLUDEDIR=\"/mnt/lfs/usr/include\" -D HAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o
expand.o file.o function.o getopt.o implicit.o job.o main.o
misc.o read.o remake.o rule.o signame.o variable.o vpath.o
default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference
to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2

make [2]: *** [make] Error 1

В этой главе проверяются и при необходимости устанавливаются основные инструменты, необходимые для построения LFS. Затем подготавливается раздел, в котором будет размещаться система LFS. Мы создадим сам раздел, создадим на нем файловую систему и смонтируем его.

LFS разработан для сборки за один сеанс. То есть инструкция предполагает, что система не будет выключаться в процессе. Это не означает, что система должна быть собрана за один присест. Для возобновления сборки в точке предыдущей остановки (после перезагрузки/выключения), необходимо выполнить некоторые процедуры повторно.

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

Минимальная система требует раздел размером около 10 гигабайт (ГБ). Этого достаточно для хранения всех архивов с исходным кодом и компиляции пакетов. Однако, если система LFS предназначена для использования в качестве основной системы Linux, вероятно, будет установлено дополнительное программное обеспечение, для которого потребуется дополнительное пространство. Раздел размером 30 ГБ является разумным размером для расширения. Сама система LFS не займет столько места. Большая часть этого требования заключается в предоставлении достаточного временного хранилища, а также в добавлении дополнительных возможностей после сборки LFS. Кроме того, для компиляции пакетов может потребоваться много места на диске, которое будет освобождено после установки пакета.

Поскольку для компиляции не всегда достаточно оперативной памяти (ОЗУ), рекомендуется использовать небольшой раздел диска в качестве раздела подкачки. Он используется ядром для хранения редко используемых данных и оставляет больше памяти для активных процессов. Раздел подкачки для системы LFS может совпадать с разделом, используемым хост-системой, и в этом случае нет необходимости создавать еще один.

Запустите программу создания разделов диска, такую как cfdisk или fdisk, с параметром командной строки, указав имя жесткого диска, на котором будет создан новый раздел, например, /dev/sda для основного диска. Создайте раздел Linux и раздел подкачки, если это необходимо. Пожалуйста, обратитесь к справке cfdisk(8) или fdisk(8), если вы еще не знаете, как пользоваться этими программами.

Запомните обозначение созданного раздела (например, sda5). В этой книге он будет называться разделом LFS. Также запомните обозначение раздела подкачки. Эти имена понадобятся позже для файла /etc/fstab.

Раздел - это всего лишь диапазон секторов на диске, указанный в таблице разделов. Прежде чем операционная система сможет использовать раздел для хранения каких-либо файлов, он должен быть отформатирован, чтобы содержать файловую систему, обычно состоящую из метки, блоков каталогов, блоков данных и схемы индексации для поиска конкретного файла по запросу. Файловая система также помогает операционной системе отслеживать свободное пространство на разделе, резервировать необходимые секторы при создании нового файла или расширении существующего и повторно использует свободные сегменты данных, полученные в результате удаления файлов. Она также может обеспечивать поддержку избыточности данных и восстановления после ошибок.

LFS может использовать любую файловую систему, распознаваемую ядром Linux, но наиболее распространенными типами являются ext3 и ext4. Выбор правильной файловой системы может быть сложным; это зависит от характеристик файлов и размера раздела. Например:

Другие файловые системы, включая FAT32, NTFS, JFS и XFS, полезны для конкретных задач. Более подробную информацию об этих файловых системах и многих других можно найти по адресу https://en.wikipedia.org/wiki/Comparison_of_file_systems.

LFS предполагает, что корневая файловая система (/) имеет тип ext4. Чтобы создать файловую систему ext4 на разделе LFS, выполните следующую команду:

mkfs -v -t ext4 /dev/<xxx>

Замените <xxx> именем раздела LFS

Если вы используете существующий раздел подкачки, нет необходимости его форматировать. Если был создан новый раздел подкачки, его нужно будет инициализировать с помощью этой команды:

mkswap /dev/<yyy>

Замените <yyy> именем раздела подкачки.

В этой книге переменная окружения LFS будет использоваться несколько раз. Вы должны убедиться, что эта переменная всегда определена в процессе сборки LFS. Она должна быть установлена на каталог, в котором вы будете создавать свою систему LFS — мы, для примера, будем использовать /mnt/lfs, но вы можете выбрать любой другой. Если вы собираете LFS на отдельном разделе, этот каталог будет точкой монтирования для раздела. Выберите расположение каталога и установите переменную с помощью следующей команды:

export LFS=/mnt/lfs

Установка этой переменной полезна тем, что такие команды, как mkdir -v $LFS/tools, можно вводить буквально. Оболочка автоматически заменит «$LFS» на «/mnt/lfs» (или любое другое значение переменной) при обработке команды.

echo $LFS

Теперь, когда файловая система создана, раздел должен быть смонтирован, чтобы хост-система могла получить доступ к нему. В книге предполагается, что файловая система монтируется в каталог, указанный в переменной LFS, описанной в предыдущем разделе.

Строго говоря, нельзя «смонтировать раздел». Монтируется файловая система на этом разделе. Но так как один раздел не может содержать несколько файловых систем, люди часто говорят о разделе и связанной с ним файловой системе так, как если бы они были одним и тем же.

Создайте точку монтирования и смонтируйте файловую систему LFS с помощью этих команд:

mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS

Замените <xxx> на имя раздела LFS.

Если вы используете несколько разделов для LFS (например, один для /, а другой для /home), смонтируйте их вот так:

mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS
mkdir -v $LFS/home
mount -v -t ext4 /dev/<yyy> $LFS/home

Замените <xxx> и <yyy> соответствующими именами разделов.

Убедитесь, что этот новый раздел не смонтирован со слишком строгими разрешениями (такими как параметры nosuid или nodev). Запустите команду mount без каких-либо параметров, чтобы увидеть, какие параметры установлены для смонтированного раздела LFS. Если установлены nosuid и/или nodev, раздел должен быть размонтирован и смонтирован повторно.

/dev/<xxx>  /mnt/lfs ext4   defaults      1     1

Если вы используете раздел подкачки, убедитесь, что он включен с помощью команды swapon:

/sbin/swapon -v /dev/<zzz>

Замените <zzz> именем раздела подкачки.

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

Эта глава содержит список пакетов, которые необходимо загрузить для сборки базовой системы Linux. Перечисленные версии программного обеспечения, соответствуют версиям, которые, проверены и работают, книга основана на их использовании. Мы настоятельно рекомендуем не использовать другие версии пакетов, потому что команды сборки для одной версии могут не работать с другой, если только другая версия не указана в сообщениях об ошибках LFS или рекомендациях по безопасности. В новейших версиях пакетов также могут быть проблемы, требующие обходных путей. Эти обходные пути будут стабилизированы в разрабатываемой версии книги.

Для некоторых пакетов архив релиза и архив снимка репозитория (Git или SVN) для этого выпуска могут быть опубликованы с одинаковыми именами файлов. Релиз содержит сгенерированные файлы (например, скрипт configure, сгенерированный пакетом autoconf) в дополнение к содержимому соответствующего моментального снимка репозитория. В книге везде, где это возможно, используются релизные архивы. Использование моментального снимка вместо tar-архива, указанного в книге, может вызвать проблемы.

Источники загрузки могут быть недоступны. Если источник изменился с момента публикации этой книги, Google (https://www.google.com/) предоставляет удобную поисковую систему для поиска большинства пакетов. Если поиск не увенчался успехом, попробуйте один из альтернативных способов загрузки, расположенных по адресу https://mirror.linuxfromscratch.ru/lfs/mirrors.html#files.

Загруженные пакеты и патчи необходимо где-нибудь хранить, чтобы они были доступны на протяжении всей сборки. Рабочий каталог также необходим для распаковки исходников и их сборки. $LFS/sources можно использовать и как место для хранения архивов и патчей, и как рабочий каталог. При использовании этого каталога необходимые элементы будут расположены в разделе LFS и будут доступны на всех этапах процесса сборки.

Чтобы создать этот каталог, выполните следующую команду от имени пользователя root перед началом загрузки:

mkdir -v $LFS/sources

Сделайте этот каталог доступным для записи и установите sticky bit (дословно "липкий бит"). Атрибут «Sticky bit» означает, что даже если несколько пользователей имеют право на запись в каталог, только владелец файла может удалить файл в таком каталоге. Следующая команда активирует режимы записи и sticky bit:

chmod -v a+wt $LFS/sources

Есть несколько способов получить все необходимые пакеты и патчи для сборки LFS:

Чтобы загрузить все пакеты и патчи, используя wget-list-sysv в качестве входных данных для команды wget, наберите команду:

wget --input-file=wget-list-sysv --continue --directory-prefix=$LFS/sources

Начиная с LFS-7.0, существует отдельный файл md5sums, который можно использовать для проверки всех пакетов. Поместите этот файл в $LFS/sources и выполните:

pushd $LFS/sources
  md5sum -c md5sums
popd

Эту проверку можно использовать после загрузки файлов любым из перечисленных выше способов.

Если пакеты и исправления загружаются от имени пользователя, без привилегий root, то файлы будут принадлежать этому пользователю. Файловая система записывает владельца по его UID, а UID обычного пользователя в хост-дистрибутиве не будет присвоен в LFS. Таким образом, файлы останутся принадлежащими безымянному UID в конечной системе LFS. Если вы не назначили тот же UID для своего пользователя в системе LFS, измените владельца этих файлов на root сейчас, чтобы избежать этой проблемы:

chown root:root $LFS/sources/*

Загрузите или иным образом получите следующие пакеты:

Общий размер пакетов: примерно 517 MB

В дополнение к пакетам требуется несколько патчей. Эти патчи исправляют ошибки в пакетах, которые должны быть исправлены сопровождающими. Патчи также вносят небольшие изменения, облегчающие работу с пакетами. Для сборки системы LFS потребуются следующие патчи:

Общий размер этих патчей: примерно 190.7 KB

Помимо указанных выше обязательных исправлений, существует ряд необязательных патчей, созданных сообществом LFS. Эти необязательные исправления решают незначительные проблемы или включают функции, которые не включены по умолчанию. Не стесняйтесь просматривать базу данных исправлений, расположенную по адресу https://mirror.linuxfromscratch.ru/patches/downloads/, и применять патчи, необходимые вашей системе.

В этой главе мы выполним несколько дополнительных настроек для подготовки к сборке временной системы. Мы создадим несколько каталогов в $LFS (в котором установим временные инструменты), добавим непривилегированного пользователя и настроим окружение для этого пользователя. Кроме этого, будут даны пояснения по стандартной единице времени сборки, или «SBU», которую мы используем для измерения времени необходимого для сборки пакетов LFS, и предоставим некоторую информацию о наборах тестов.

В этом разделе мы начинаем заполнять файловую систему LFS элементами, которые будут основой конечной системы Linux. Первым шагом является создание ограниченной иерархии каталогов, чтобы программы, скомпилированные в Глава 6 (а также glibc и libstdc++ в Глава 5), могли быть установлены в их конечном расположении. Это необходимо для того, чтобы эти временные программы были перезаписаны при сборке окончательных версий в Глава 8.

Создайте необходимую иерархию каталогов, выполнив следующую команду от имени root:

mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin}

for i in bin lib sbin; do
  ln -sv usr/$i $LFS/$i
done

case $(uname -m) in
  x86_64) mkdir -pv $LFS/lib64 ;;
esac

Программы в Глава 6 будут скомпилированы с помощью кросс-компилятора (более подробная информация приведена в разделе Технические примечания по сборочным инструментам). Чтобы отделить кросс-компилятор от других программ, он будет установлен в специальный каталог. Создайте этот каталог с помощью следующей команды:

mkdir -pv $LFS/tools

При входе в систему под учетной записью root допущение одной ошибки может привести к повреждению или разрушению системы. Поэтому пакеты в следующих двух главах собираются из-под учетной записи непривилегированного пользователя. Вы можете использовать свое собственное имя пользователя, но чтобы упростить настройку рабочей среды, создайте нового пользователя с именем lfs, который является членом одноименной группы и выполняйте команды из-под этой учетной записи в процессе установки. От имени пользователя root выполните следующие команды, чтобы добавить нового пользователя:

groupadd lfs
useradd -s /bin/bash -g lfs -m -k /dev/null lfs

Если вы хотите войти в систему как lfs или переключиться на lfs из учетной записи непривилегированного пользователя (в отличие от переключения на пользователя lfs при входе в систему как root, для которого не требуется пароль пользователя lfs), вам необходимо установить пароль для lfs. Выполните следующую команду от имени пользователя root, чтобы установить пароль:

passwd lfs

Предоставьте пользователю lfs полный доступ ко всем каталогам в папке $LFS, назначив lfs владельцем:

chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown -v lfs $LFS/lib64 ;;
esac

Затем запустите оболочку, работающую от имени пользователя lfs. Это можно сделать, войдя в систему как lfs на виртуальной консоли или с помощью следующей команды замены/переключения пользователя:

su - lfs

Аргумент «-» передает значение команде su для запуска оболочки входа в систему, а не обычной оболочки. Разница между этими двумя типами оболочек подробно описана в bash(1) и info bash.

Настроим хорошо работающее окружение, создав два новых файла запуска для оболочки bash. Войдя в систему как пользователь lfs, введите следующую команду, чтобы создать новый .bash_profile:

cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF

При входе в систему под учетной записью пользователя lfs или при переключении на lfs, используя команду su с опцией «-», начальная оболочка представляет собой оболочку login, которая читает данные из /etc/profile хоста (который, вероятно, содержит некоторые настройки и переменные среды), а затем .bash_profile. Команда exec env -i.../bin/bash в файле .bash_profile заменяет запущенную оболочку новой, не содержащей переменные среды, за исключением переменных HOME, TERM, и PS1. Это гарантирует, что никакие нежелательные и потенциально опасные переменные среды из хост-системы не попадут в среду сборки.

Новый экземпляр оболочки представляет собой non-login оболочку, которая не считывает и не выполняет содержимое файлов /etc/profile и .bash_profile, а вместо этого выполняет чтение из файла .bashrc. Создайте файл .bashrc:

cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
EOF

[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE

Для многих современных систем с несколькими процессорами (или ядрами) время компиляции пакета можно сократить, выполнив «параллельную сборку», либо установив переменную среды, либо сообщив программе make, сколько ядер задействовать для сборки. Например, процессор Intel Core i9-13900K имеет 8 ядер P (производительность) и 16 ядер E (энергоэффективность), ядро P может одновременно запускать два потока, поэтому каждое ядро P моделируется ядром Linux как два логических ядра. В результате получается 32 логических ядра. Очевидный способ задействовать все эти логические ядра - разрешить make создавать до 32 заданий сборки. Это можно сделать, передав параметр -j32 команде make:

make -j32

Или установите переменную окружения MAKEFLAGS, и ее содержимое будет автоматически использоваться make в качестве параметров командной строки:

export MAKEFLAGS=-j32

Чтобы использовать все логические ядра, доступные для сборки пакетов в Глава 5 и Глава 6, укажите параметр MAKEFLAGS в .bashrc сейчас:

cat >> ~/.bashrc << "EOF"
export MAKEFLAGS=-j$(nproc)
EOF

Замените $(nproc) количеством логических ядер, которые вы хотите использовать, если вы планируете использовать не все логические ядра.

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

source ~/.bash_profile

Многие люди хотели бы знать заранее, сколько примерно времени потребуется для компиляции и установки каждого пакета. Поскольку Linux From Scratch может быть собран на различных системах, невозможно дать точную оценку времени. Сборка самого большого пакета (gcc) займет около 5 минут на быстрых системах, но может занять несколько дней на более медленных компьютерах! Вместо фактического времени в книге используется показатель "стандартная единица времени сборки" (SBU).

Показатель SBU рассчитывается следующим образом. Первым пакетом, который нужно скомпилировать, является binutils в Глава 5. Время, необходимое для компиляции этого пакета с использованием одного ядра, будет называться стандартной единицей времени сборки или SBU. Время компиляции остальных пакетов будет рассчитано относительно этого времени.

Например, рассмотрим пакет, время компиляции которого составляет 4,5 SBU. Это означает, что если вашей системе потребовалось 4 минуты для компиляции и сборки первого прохода binutils, то для сборки этого пакета потребуется примерно 18 минут. К счастью, в большинстве случаев, время сборки меньше, чем у binutils.

В целом, величина SBU не совсем точна, поскольку она зависит от множества факторов, начиная от версии GCC хост-системы. Она приведены здесь, чтобы дать оценку того, сколько времени может потребоваться для сборки пакета, но в некоторых случаях цифры могут отличаться на десятки минут.

В современных материнских платах есть возможность управлять тактовой частотой процессора. Это можно сделать с помощью команды, такой как, powerprofilesctl. Данная возможность отсутствует в LFS, но может быть доступна в хост-дистрибутиве. После сборки LFS управление производительностью и электропитанием можно добавить в систему с помощью инструкций, описанных на странице BLFS power-profiles-daemon.

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

В противном случае измеренное значение SBU может быть неточным, поскольку система может по-разному реагировать на сборку binutils-pass1 или других пакетов.

Имейте в виду, что даже если для обоих пакетов используется один и тот же профиль, все равно могут возникнуть существенные неточности, поскольку система может реагировать медленнее, если система простаивает при запуске процедуры сборки. Установка для профиля питания режима «производительность» сведет к минимуму эту проблему. И, очевидно, это также ускорит сборку LFS.

Если powerprofilesctl доступен, введите команду powerprofilesctl set performance, чтобы выбрать профиль производительность. Некоторые дистрибутивы для управления профилями предоставляют команду tuned-adm вместо powerprofilesctl, в этих дистрибутивах введите команду tuned-adm profile throughput-performance, чтобы выбрать профиль производительность.

Большинство пакетов предоставляют набор тестов. Запуск набора тестов для только что собранного пакета — хорошая идея, потому что он может обеспечить «проверку работоспособности», указывающую, что все скомпилировано правильно. Набор тестов, который проходит свой набор проверок, обычно доказывает, что пакет работает так, как задумал разработчик. Однако это не гарантирует, что пакет полностью без ошибок.

Некоторые наборы тестов более важны, чем другие. Например, наборы тестов для основных инструментов — GCC, binutils и glibc — имеют первостепенное значение из-за их центральной роли в правильно функционирующей системе. Выполнение наборов тестов для GCC и glibc может занять очень много времени, особенно на медленном оборудовании, но их выполнение настоятельно рекомендуется.

Распространенной проблемой при запуске наборов тестов для binutils и GCC является нехватка псевдотерминалов (PTY). Это может привести к большому количеству неудачных тестов. Причин может быть несколько, но наиболее вероятная причина заключается в том, что в хост-системе неправильно настроена файловая система devpts. Этот вопрос более подробно обсуждается на странице https://mirror.linuxfromscratch.ru/lfs/faq.html#no-ptys.

Иногда наборы тестов не работают, по причинам, о которых знают разработчики и которые они считают некритичными. Просмотрите журналы, расположенные по адресу https://mirror.linuxfromscratch.ru/lfs/build-logs/12.2/, чтобы проверить, ожидаются ли сбои. Этот сайт актуален для всех наборов тестов, описанных в книге.

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

Программы, скомпилированные в этой главе, будут установлены в каталог $LFS/tools, чтобы они были отделены от файлов, установленных в следующих главах. Библиотеки, же, устанавливаются на свое постоянное место, поскольку они относятся к системе, которую мы хотим создать.

В этой главе рассказывается, как выполнить кросс-компиляцию базовых утилит с использованием только что собранного кросс-тулчейна. Эти утилиты установлены в свое конечное местоположение, но пока не могут быть использованы. Выполняемые инструкции по-прежнему зависят от инструментария хоста. Тем не менее, установленные библиотеки используются при компоновке.

Использование утилит станет возможным в следующей главе после входа в среду «chroot». Все пакеты из этой главы, должны быть собраны до того, как мы это сделаем. Поэтому пока наша система зависима от хост-системы.

Еще раз напомним, что неправильная настройка LFS вместе со сборкой от root может сделать ваш компьютер непригодным для использования. Всю эту главу нужно выполнить от имени пользователя lfs, в его рабочем окружении, как описано в Раздел 4.4, «Настройка окружения».

В этой главе рассказывается, как собрать последние недостающие части временной системы: инструменты, необходимые для сборки различных пакетов. Теперь, когда все циклические зависимости устранены, для сборки можно использовать среду «chroot», полностью изолированную от операционной системы хоста (за исключением работающего ядра).

Для правильной работы изолированной среды необходимо установить связь с работающим ядром. Это делается с помощью так называемых виртуальных файловых систем ядра, которые будут смонтированы перед входом в среду chroot. Вы можете проверить, смонтированы ли они, выполнив команду findmnt.

До Раздел 7.4, «Вход в окружение Chroot» команды должны выполняться от имени root с установленной переменной LFS. После входа в chroot все команды выполняются от имени root, к счастью, без доступа к операционной системе компьютера, на котором вы собираете LFS. В любом случае будьте осторожны, так как неверными командами легко разрушить всю систему LFS.

В настоящее время вся иерархия каталогов в $LFS принадлежит пользователю lfs, существующему только на хост-системе. Если права на файлы и каталоги внутри $LFS оставить как есть, то они будут принадлежать ID пользователя без существующей учетной записи. Это опасно, так как созданная позже учетная запись, может получить такой же ID пользователя и стать владельцем всех файлов в $LFS, тем самым делая эти файлы уязвимыми для возможных злонамеренных манипуляций.

Для решения проблемы измените владельца каталогов $LFS/* на пользователя root, выполнив следующую команду:

chown --from lfs -R root:root $LFS/{usr,lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown --from lfs -R root:root $LFS/lib64 ;;
esac

Приложения, работающие в пользовательском пространстве, используют различные файловые системы, созданные ядром, для взаимодействия с самим ядром. Эти файловые системы являются виртуальными: для них не используется дисковое пространство. Содержимое файловых систем находится в памяти. Эти файловые системы должны быть смонтированы в дереве каталогов $LFS, чтобы приложения могли найти их в среде chroot.

Начните с создания каталогов, в которые будут смонтированы эти виртуальные файловые системы:

mkdir -pv $LFS/{dev,proc,sys,run}

mount -v --bind /dev $LFS/dev

mount -vt devpts devpts -o gid=5,mode=0620 $LFS/dev/pts
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run

if [ -h $LFS/dev/shm ]; then
  install -v -d -m 1777 $LFS$(realpath /dev/shm)
else
  mount -vt tmpfs -o nosuid,nodev tmpfs $LFS/dev/shm
fi

Теперь, когда все пакеты, необходимые для сборки остальных инструментов установлены в системе, пришло время войти в окружение chroot и завершить установку временных инструментов. Эта среда также будет использоваться для установки конечной системы. От имени пользователя root выполните следующую команду для входа в chroot, в которой на данный момент нет ничего, кроме временных инструментов:

chroot "$LFS" /usr/bin/env -i   \
    HOME=/root                  \
    TERM="$TERM"                \
    PS1='(lfs chroot) \u:\w\$ ' \
    PATH=/usr/bin:/usr/sbin     \
    MAKEFLAGS="-j$(nproc)"      \
    TESTSUITEFLAGS="-j$(nproc)" \
    /bin/bash --login

Если вы не хотите использовать все доступные логические ядра, замените параметр $(nproc) количеством логических ядер, которые вы хотите использовать для сборки пакетов в этой и последующих главах. На наборы тестов некоторых пакетов (в частности Autoconf, Libtool и Tar) в Глава 8 не влияет установка переменной MAKEFLAGS, вместо этого они используют переменную среды TESTSUITEFLAGS. Мы также установили её здесь для запуска тестов с поддержкой нескольких ядер.

Параметр -i команды env, очистит все переменные в среде chroot. После этого переменные HOME, TERM, PS1 и PATH будут установлены заново. Конструкция TERM=$TERM установит переменную TERM внутри chroot в то же значение, что и вне chroot. Эта переменная необходима для корректной работы таких программ как vim и less. Если понадобятся другие переменные окружения, такие как CFLAGS или CXXFLAGS, то это подходящее место для их установки.

С этого момента больше нет необходимости использовать переменную LFS, поскольку вся работа будет ограничена файловой системой LFS; команда chroot запускает оболочку Bash с корневым каталогом (/), установленным в $LFS.

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

Также обратите внимание, что в командной строке bash будет указано I have no name!. Это нормально, поскольку файл /etc/passwd еще не создан.

Пришло время создать полную структуру каталогов в файловой системе LFS.

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

mkdir -pv /{boot,home,mnt,opt,srv}

Создайте необходимые подкаталоги, выполнив следующие команды:

mkdir -pv /etc/{opt,sysconfig}
mkdir -pv /lib/firmware
mkdir -pv /media/{floppy,cdrom}
mkdir -pv /usr/{,local/}{include,src}
mkdir -pv /usr/lib/locale
mkdir -pv /usr/local/{bin,lib,sbin}
mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv /usr/{,local/}share/man/man{1..8}
mkdir -pv /var/{cache,local,log,mail,opt,spool}
mkdir -pv /var/lib/{color,misc,locate}

ln -sfv /run /var/run
ln -sfv /run/lock /var/lock

install -dv -m 0750 /root
install -dv -m 1777 /tmp /var/tmp

По умолчанию каталоги создаются с правами 755, но это нежелательно делать для всех каталогов. В приведенных выше командах вносятся два изменения — одно в домашний каталог пользователя root, а другое в каталоги для временных файлов.

Первое изменение гарантирует, что никто не сможет войти в каталог /root — точно так же, как обычный пользователь сделал бы это со своим собственным домашним каталогом. Второе изменение гарантирует, что любой пользователь может писать в каталоги /tmp и /var/tmp, но не может удалять из них файлы другого пользователя. Последнее запрещено так называемым «sticky bit (липким битом)», старшим битом (1) в битовой маске 1777

Исторически сложилось, что Linux хранит список примонтированных файловых систем в файле /etc/mtab. Современные ядра хранят этот список внутри себя и предоставляют его пользователю через файловую систему /proc. Чтобы удовлетворять требованиям утилит, которые ожидают наличия /etc/mtab, создайте следующую символическую ссылку:

ln -sv /proc/self/mounts /etc/mtab

Создайте файл /etc/hosts, на который будут ссылаться некоторые наборы тестов, а также один из файлов конфигурации Perl:

cat > /etc/hosts << EOF
127.0.0.1  localhost $(hostname)
::1        localhost
EOF

Чтобы пользователь root мог войти в систему и распознавался системой, в файлах /etc/passwd и /etc/group должны быть соответствующие записи.

Создайте файл /etc/passwd выполнив следующую команду:

cat > /etc/passwd << "EOF"
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/dev/null:/usr/bin/false
daemon:x:6:6:Daemon User:/dev/null:/usr/bin/false
messagebus:x:18:18:D-Bus Message Daemon User:/run/dbus:/usr/bin/false
uuidd:x:80:80:UUID Generation Daemon User:/dev/null:/usr/bin/false
nobody:x:65534:65534:Unprivileged User:/dev/null:/usr/bin/false
EOF

Пароль пользователя root будет задан позднее.

Создайте файл /etc/group, выполнив следующую команду:

cat > /etc/group << "EOF"
root:x:0:
bin:x:1:daemon
sys:x:2:
kmem:x:3:
tape:x:4:
tty:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
cdrom:x:15:
adm:x:16:
messagebus:x:18:
input:x:24:
mail:x:34:
kvm:x:61:
uuidd:x:80:
wheel:x:97:
users:x:999:
nogroup:x:65534:
EOF

Созданные группы не являются частью какого-либо стандарта — это группы, определяемые частично требованиями конфигурации Udev в главе 9, а частично общими соглашениями, используемыми в ряде существующих дистрибутивов Linux. Кроме того, некоторые наборы тестов зависят от конкретных пользователей или групп. Спецификация LSB (доступна по адресу https://refspecs.linuxfoundation.org/lsb.shtml) рекомендует, чтобы, помимо группы root с идентификатор (GID) 0 присутствовала группа bin с GID 1. GID 5 широко используется для группы tty, число 5 также используется в /etc/fstab для файловой системы devpts. Все остальные имена групп и GID могут свободно выбираться системным администратором, так как хорошо написанные программы не зависят от номеров GID, а чаще используют название группы.

Идентификатор 65534 используется ядром для NFS и отдельных пользовательских пространств имен для несопоставленных пользователей и групп (они существуют на сервере NFS или родительском пространстве имен пользователя, но «не существует» на локальном компьютере или в отдельном пространстве имен). Мы присваиваем nobody и nogroup для того, чтобы избежать несопоставленных идентификаторов. Другие дистрибутивы могут обрабатывать этот идентификатор по-разному, поэтому любая переносимая программа не должна зависеть от этого присвоения.

Для некоторых пакетов требуется локаль.

localedef -i C -f UTF-8 C.UTF-8

Для некоторых тестов в Глава 8 требуется обычный пользователь. Добавим такого пользователя здесь и удалим эту учетную запись в конце главы.

echo "tester:x:101:101::/home/tester:/bin/bash" >> /etc/passwd
echo "tester:x:101:" >> /etc/group
install -o tester -d /home/tester

Чтобы удалить приглашение «I have no name!», запустите новую оболочку. Поскольку файлы /etc/passwd и /etc/group были созданы, разрешение имен пользователей и групп теперь будет работать:

exec /usr/bin/bash --login

Программы login, agetty, init (и другие) используют ряд журналов для записи такой информации, как кто и когда входил в систему. Однако эти программы не будут записывать данные в журналы, если они еще не существуют. Инициализируйте журналы и предоставьте им соответствующие разрешения:

touch /var/log/{btmp,lastlog,faillog,wtmp}
chgrp -v utmp /var/log/lastlog
chmod -v 664  /var/log/lastlog
chmod -v 600  /var/log/btmp

В файл /var/log/wtmp записываются все входы и выходы из системы. В файл /var/log/lastlog записывается время последнего входа каждого пользователя в систему. В файл /var/log/faillog записываются неудачные попытки входа в систему. В файл /var/log/btmp также записываются неудачные попытки входа в систему.

В этой главе мы приступаем к сборке конечной системы LFS.

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

Мы не рекомендуем использовать оптимизации. С ними программа может работать немного быстрее, но также они могут вызвать сложности при компиляции и проблемы при запуске программы. Если пакет не компилируется при использовании оптимизации, попробуйте скомпилировать его без оптимизации и посмотрите, решает ли это проблему. Даже если пакет компилируется при использовании оптимизации, существует риск, что он может быть скомпилирован неправильно из-за сложных взаимодействий между кодом и инструментами сборки. Также обратите внимание, что параметры -march и -mtune, не тестировались со значениями отличными от указанных в книге. Это может вызвать проблемы с пакетами набора инструментов (Binutils, GCC и Glibc). Небольшие потенциальные плюсы, достигаемые за счет оптимизации, часто перевешиваются рисками. Тем кто собирает LFS впервые рекомендуется делать это без пользовательских оптимизаций.

С другой стороны, мы сохраняем оптимизацию включенной в конфигурации пакетов по умолчанию. Кроме того, иногда мы явно включаем оптимизированную конфигурацию, предоставляемую пакетом, но не включенную по умолчанию. Сопровождающие пакета уже протестировали эти конфигурации и считают их безопасными, поэтому маловероятно, что они сломают сборку. Как правило, конфигурация по умолчанию уже включает параметры -O2 или -O3, поэтому результирующая система по-прежнему будет работать очень быстро без какой-либо пользовательской оптимизации и в то же время будет стабильной.

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

Управление пакетами — часто cпрашиваемое дополнение к книге LFS. Менеджер пакетов позволяет отслеживать установку файлов, упрощая удаление и обновление пакетов. Хороший менеджер пакетов также будет обрабатывать конфигурационные файлы, чтобы сохранить пользовательские настройки при переустановке или обновлении пакета. Прежде чем вы начнете задаваться вопросом, НЕТ—в этом разделе не будет ни говориться, ни рекомендоваться какой-либо конкретный менеджер пакетов. Что он действительно предоставляет, так это обзор наиболее популярных методов и того, как они работают. Идеальным менеджером пакетов для вас может быть один из этих методов или комбинация двух и более методов. В этом разделе кратко упоминаются проблемы, которые могут возникнуть при обновлении пакетов.

Некоторые причины, по которым менеджер пакетов не упоминается в LFS или BLFS представлены ниже:

Есть несколько советов, написанных на тему управления пакетами. Посетите проект Советы возможно вы найдете решение, которое соответствует вашим потребностям.

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install