• Пред. Часть II. Глава 3. Пакеты и патчи

Содержание

• 4.1. Введение
• 4.2. Создание ограниченной иерархии папок в файловой системе LFS
• 4.3. Создание пользователя LFS
• 4.4. Настройка окружения
• 4.5. О SBU (Стандартная единица времени сборки)
• 4.6. О наборах тестов

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

sudo su

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

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

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

Проверим созданные ссылки и каталоги

ls -l $LFS

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

mkdir -pv $LFS/tools

Проверим созданные нами каталоги командой

ls $LFS/

В результате данных действий мы получаем следующий вид каталога /mnt/lfs

ls -l $LFS/lost+found

Проверим наличие каталога следующей командой

ls -l $LFS/usr/lib64

Система отдала нам ответ:ls: невозможно получить доступ к «/mnt/lfs/usr/lib64»: такого файла или каталога нет. Посмотрим содержимое каталога $LFS/usr/

ls -l $LFS/usr/

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

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

Выведем имя группы, в которых состоит пользователь lfs для проверки наших действий

groups 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 является владельцем наших каталогов

ls -l $LFS/

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

su - lfs

Логинимся от имени 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

exit

[ ! -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

Посмотрим данные о процессоре

sudo apt-get install hwinfo  
hwinfo --short

На тестовой машине установлен AMD Ryzen 7 3700X 8-Core Processor Откроем файл ~/.bashrc в редакторе nano

nano ~/.bashrc

Добавим в конце нашу строку export MAKEFLAGS=-j32 CTRL+O → ENTER → CTRL+X для сохранения и выхода из редактора

nproc

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

cat >> ~/.bashrc << "EOF"
export MAKEFLAGS=-j32
EOF

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

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

su - lfs

source ~/.bash_profile

echo $MAKEFLAGS

Посмотрим что внутри нашего файла .bash_profile

nano ~/.bash_profile

Жмем CTRL+X для выхода из редактора nano

exit

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

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

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

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

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

Некоторые наборы тестов более важны, чем другие. Например, наборы тестов для основных инструментов — 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.1/, чтобы проверить, ожидаются ли сбои. Этот сайт актуален для всех наборов тестов, описанных в книге.

• След. Часть III. Глава 5. Сборка кросс-тулчейна