Arch boot process (Русский)
Эта статья призвана описать процесс загрузки Arch Linux и перечислить вовлеченные в процесс загрузки системные файлы, предоставляя ссылки на соответствующие статьи в вики там, где это потребуется. Arch славится своей приверженностью стилю загрузки BSD, в отличии более распространенного SysV. Это означает, что существует небольшое различие между уровнями выполнения(Wikipedia:runlevel), поскольку система по умолчанию сконфигурирована использовать и запускать одни и те же модули и процессы на всех уровнях выполнения. Преимуществом такой схемы выступает то, что пользователю становится легче настроить процесс запуска (см. rc.conf); с другой стороны, некоторые способы углубленного конфигурирования (какие были в SysV) потеряны. Тем, кого это не устраивает, будет полезно обратиться к статье Adding Runlevels. Чтобы узнать больше о различиях между стилями инициализации BSD и SysV см. Wikipedia:Init
Contents
До выполнения init
После подачи питания системе и завершения POST, BIOS определяет с какого устройства необходимо начать загрузку и передает управление на Master Boot Record этого устройства. На машине под управлением GNU/Linux в качестве загрузчика ОС чаще всего используют GRUB или LILO, который собственно и располагается в MBR. Загрузчик может предоставить пользователю выбор ОС для загрузки. Такая установка описана в статье Windows and Arch Dual Boot (Русский). После выбора Arch Linux в качестве ОС для запуска, загрузчик размещает в памяти ядро Linux (vmlinuz-linux
) и образ первичной корневой файловой системы (initramfs-linux.img
), затем загрузчик запускает ядро, передавая ему также параметры запуска, указанные в конфигурационном файле загрузчика.
Ядро выполняет роль прослойки между аппаратной частью и программами, которые используют ресурсы системы, необходимые им для работы. Для эффективного использования процессора в ядре имеется планировщик, который определяет какой задаче передать приоритет выполнения в любой конкретный момент времени, таким образом создавая иллюзию одновременного выполнения задач.
Также, после запуска, ядро распаковывает initramfs (сокр. от initial RAM filesystem/первичная файловая система в ОЗУ), которая становится первичной корневой файловой системой. Затем ядро запускает на выполнение /init
. Таким образом, init становится первым процессом пространства пользователя
Конечной целью работы initramfs является получение доступа к корневой файловой системе с устройства (см. также FHS). Для работы с устройствами IDE, SCSI, SATA, USB/FW (если загрузка происходит с внешнего носителя) требуются соответствующие модули, которые должны быть либо встроены в ядро, или непосредственно загружены из initramfs; как только подходящий модуль найден (с помощью программы/скрипта или через udev), процесс загрузки продолжится. Для получения доступа к корневой файловой системе, initramfs не обязательно содержать все возможные модули, которые только могут потребоваться во время работы с устройствами хранения данных. Большинство остальных модулей устройств будут загружены позже, во время инициализации, с помощью udev.
На заключительной стадии раннего пространства пользователя взамен первичной(инициализирующей) корневой файловой системы монтируется ФС с устройства. И с неё запускается /sbin/init
, подменяя собой временный /init
.
Пользовательские ловушки
Ловушки полезны, когда необходимо включить какой-либо код в различные места скриптов rc.* без их редактирования.
Наименование ловушки | Момент исполнения |
---|---|
sysinit_start | В начале rc.sysinit |
sysinit_udevlaunched | После запуска udev в rc.sysinit |
sysinit_udevsettled | После получения uevents в rc.sysinit |
sysinit_prefsck | Перед запуском fsck в rc.sysinit |
sysinit_postfsck | После запуска fsck в rc.sysinit |
sysinit_premount | Перед монтированием локальных файловых систем, но после того, как был монтирован корень(/) в режиме чтения-записи в rc.sysinit |
sysinit_end | В конце rc.sysinit |
multi_start | В начале rc.multi |
multi_end | В конце rc.multi |
single_start | В начале rc.single |
single_prekillall | Перед убийством всех процессов в rc.single |
single_postkillall | После убийства всех процессов в rc.single |
single_udevlaunched | После запуска udev в rc.single |
single_udevsettled | После получения uevents в rc.single |
single_end | В конце rc.single |
shutdown_start | В начале rc.shutdown |
shutdown_prekillall | Перед убийством всех процессов в rc.shutdown |
shutdown_postkillall | После убийства всех процессов в rc.shutdown |
shutdown_poweroff | Непосредственно перед отключением питания в rc.shutdown |
Для объявления функции-ловушки создайте файл в /etc/rc.d/functions.d
используя в качестве примера:
function_name() { ... } add_hook hook_name function_name
Файлы из /etc/rc.d/functions.d
читаются скриптом /etc/rc.d/functions
.
Позволяется регистрировать как несколько функций-ловушек на один и тот же тип ловушки, так и несколько типов ловушек на одну и ту же функцию-ловушку. В этих файлах запрещается именовать функцию как add_hook или run_hook, поскольку функции с такими именами уже объявлены в /etc/rc.d/functions
.
Пример
Добавление следующего файла отключает кэш отложенной записи на жестком диске перед стартом сервисов (полезно для устройств, содержащих файлы MySQL InnoDB).
/etc/rc.d/functions.d/hd_settings
hd_settings() { /usr/bin/hdparm -W0 /dev/sdb } add_hook sysinit_udevsettled hd_settings add_hook single_udevsettled hd_settings
Сперва объявляется функция-ловушка hd_settings, затем она регистрируется на ловушки типа single_udevsettled и sysinit_udevsettled. Функция-ловушка будет вызываться незамедлительно после получения uevents в /etc/rc.d/rc.sysinit
или /etc/rc.d/rc.single
.
init: Идентификация в системе
По умолчанию, после завершения всех скриптов запуска, программа /sbin/agetty
просит вас представиться в системе. После ввода имени пользователя /sbin/agetty
вызывает программу /bin/login
, чтобы она запросила пароль.
Наконец, после успешного входа, программа /bin/login
запускает командный интерпретатор (shell / оболочку) пользователя. Стандартный шелл а также переменные среды (environment variables) могут быть объявлены глобально, с помощью /etc/profile
. Все переменные, объявленные в стартовых скриптах домашней директории пользователя, получают приоритет над переменными объявленными глобально в /etc
. К примеру, если переменная с одним и тем же одним именем объявлена в /etc/profile
и ~/.bashrc
, та, что находится в ~/.bashrc
будет иметь преимущественную силу.
Большинство пользователей, желающих запустить при старте оконную систему X, пожелают также установить графический менеджер входа в систему (см. Экранный менеджер). Также, статья Запуск X при входе охватывает методы, которые не требуют установки менеджера входа.