Следующий шаг – создание символической ссылки /etc/mtab на /proc/mounts. Для этого выполните:

ln -sf /proc/mounts /etc/mtab

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

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

Некоторые программы при компиляции прописывают ссылки на пока не существующие программы. Для предотвращения связанных с этим проблем, создадим символические ссылки /bin/bash и /bin/sh, указывающие на программу bash, скомпилированную с использованием статических ссылок.

Для создания символических ссылок /bin/bash и /bin/sh, выполните:

ln -s /static/bin/bash /bin/bash &&

ln -s bash /bin/sh

Для возможности входа в систему под учетной записью root и для распознавания оболочкой имени «root», необходимо создать соответствующие записи в файлах /etc/passwd и /etc/group.

Для создания файла /etc/passwd, выполните:

echo «root:x:0:0:root:/root:/bin/bash» > /etc/passwd

Пароль для root ( "x" всего лишь метка заполнения) будет задан позже.

Для создания файла /etc/group, выполните:

cat > /etc/group << «EOF»

root:x:0:

bin:x:1:

sys:x:2:

kmem:x:3:

tty:x:4:

tape:x:5:

daemon:x:6:

floppy:x:7:

disk:x:8:

lp:x:9:

dialout:x:10:

audio:x:11:

EOF

Созданные группы не относятся ни к какому стандарту – их использует скрипт MAKEDEV, см. след. секцию. Помимо группы «root», стандарт LSB рекомендует наличие только группы «bin», с GID <идентификатор группы> равным 1. Все остальные названия групп и их GID пользователю разрешается выбирать произвольно, т.к. грамотно написанные программы не зависят от номеров GID, а используют название группы.

Приблизительное время компиляции: 0.07 SBU Необходимое дисковое пространство: 50 KB

Создание файлов устройств

Примите к сведению, что при распаковке архива MAKEDEV-1.7.bz2 не создается директория для перехода, т.к. архив содержит только файл скрипта.

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

cp MAKEDEV-1.7 /dev/MAKEDEV && cd /dev && chmod 754 MAKEDEV

Большинство пользователей захотят сразу же создать файлы устройств командой:

./MAKEDEV -v generic

Однако, если вы планируете использовать devpts, выполните:

./MAKEDEV -v generic-nopty

Если вы не уверены в своих действиях, для создания всех необходимых устройств лучше выполнить команду ./MAKEDEV -v generic. В случае, если вы уверены, что собираетесь использовать devpts, вторая команда пропускает создание ненужных устройств.

MAKEDEV создает устройства с hda[1-20] по hdh[1-20] и многие другие подобные файлы дисковых узлов, однако имейте ввиду, что из-за ограничений ядра на максимальное количество разделов многие из них будут недоступны.

Пояснения команд

./MAKEDEV -v generic: Эта команда создает огромное количество файлов устройств. Обычно, это все, что вам нужно. Однако существует вероятность, что некоторые специфические файлы для ваших аппаратных устройств отсутствуют. Их можно создать командой ./MAKEDEV -v <устройство>. Опция generic-nopty в создает, в основном, те же устройства, что и опция generic, за исключением тех, которые не нужны при использовании devpts.

Содержимое MAKEDEV

Последняя проверка: версия 1.5.

Программы

MAKEDEV

Описания

MAKEDEV

MAKEDEV – скрипт, создающий необходимые статические связи с устройствами, обычно располагающимися в каталоге /dev. Детальная информация о связях с устройствами может быть найдена в дереве исходных кодов ядра Linux в Documentation/devices.txt.

Зависимости MAKEDEV

Последняя проверка: версия 1.5.

Bash: sh Fileutils: chmod, chown, cp, ln, mknod, mv, rm Grep: grep Sh-utils: expr, id

Приблизительное время компиляции: 0.02 Необходимое место на диске: 142 MB

Установка заголовочных файлов ядра

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

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

ln -s /static/bin/pwd /bin/pwd && make mrproper && make include/linux/version.h && make symlinks && mkdir /usr/include/asm && cp include/asm/* /usr/include/asm && cp -R include/asm-generic /usr/include && cp -R include/linux /usr/include && touch /usr/include/linux/autoconf.h && rm /bin/pwd

Пояснения команд

ln -s /static/bin/pwd /bin/pwd: В исходных кодах ядра путь к программе pwd прописан как /bin/pwd, поэтому создадим временную символическую ссылку, а в конце удалим ее.

make mrproper: Выполнение данной команды обеспечивает чистое дерево исходников ядра. Команда разработчиков ядра рекомендует выполнять эту команду перед каждой компиляцией ядра, даже если вы только что распаковали исходные коды из tar-архива.

make include/linux/version.h и make symlinks: Создадим файл include/linux/version.h file и символическую ссылку include/asm для конкретной платформы.

mkdir /usr/include/asm , cp include/asm/* /usr/include/asm и cp -R include/asm-generic /usr/include: Эти команды копируют заголовочные файлы ядра ассемблера для конкретной платформы в /usr/include/asm и /usr/include/asm-generic.

cp -R include/linux /usr/include: Эта команда копирует кросс-платформенные файлы заголовков в /usr/include.

touch /usr/include/linux/autoconf.h: Создаем пустой файл autoconf.h. Так как на данном этапе мы не конфигурируем ядро, необходимо вручную создать этот файл для некоторых заголовочных файлов ядра, использующих его, чтобы избежать ошибок при компиляции.

Почему мы копируем заголовки ядра, а не создаем для них символические ссылки?

Раньше было принято создавать символические ссылки директорий /usr/include/{linux,asm} на /usr/src/linux/include/{linux,asm}. Однако, это была плохая идея, как объясняет Линус Торвальдс в списке рассылки ядра Linux (Linux Kernel Mailing List, отрывок):

Тем, кто компилирует новые ядра, настоятельно рекомендую: – не создавать символических ссылок (кроме той, которую создает само ядро, «linux/include/asm», символическая ссылка, которая используется при внутренней компиляции ядра.) Да, именно так делаю я. В моем каталоге /usr/src/linux есть заголовки старого ядра 2.2.13, несмотря на то, что я не использовал ядро 2.2.13 уже очень давно. Однако именно с этими заголовками компилировался пакет glibc, соответственно именно эти заголовки соответствуют файлам объектов библиотеки. Также именно такое положение вещей являлось рекомендуемым на протяжении последних пяти лет. Я не могу понять, почему вся эта заморочка с символическими ссылками все еще существует, как зомби. Практически во всех дистрибутивах есть эта неработающая символическая ссылка, и люди до сих пор помнят, что исходники ядра Linux должны находится в «/usr/src/linux», несмотря на то, что это уже давно не так.