Описание 1 этапа:
Не углубляясь в кучу терминов, старт ПК можно описать так: BIOS из MBR (первые 512 байт загрузочного устройства) стартует First Boot Loader. FSB находит вторичный загрузчик, используя таблицу разделов, просматривая ее, обнаруживает активный раздел, после отбнаружения этого раздела — загружает SSB в ОЗУ и запускает его. Для корректной загрузки, активный раздел должен содержать каталог /boot, который должен содержать Second Stage Boot Loader. По сути, SSB — это утилита, которая выводит меню выбора загрузки ОС. Ей может быть LILO или GRUB. Загрузчик берет свои настройки из конфигурационного файла (/etc/lilo.conf — для LILO и /boot/grub/grub.conf или /boot/grub/menu.lst — для GRUB). Существуют и другие варианты, такие как syslinux, PXElinux, Isolinux, uBoot, но в статье только про LILO и GRUB.
Описание 2 этапа:
Второй этап можно описать так: конфигурация системы для запуска демонов. При подготовке, GRUB\LILO загружает в память ядро из каталога /boot. Давайте рассмотрим пример образа ядра на примере ОС Debian:
boot@debian:~# file /boot/vmlinuz-4.0-5-686 /boot/vmlinuz-4.0-5-686: Linux kernel x86 boot executable bzImage, \ version 4.0-5-686 (unknown@Debian) #, RO-rootFS, swap_dev 0x2, Normal VGA
В приведенном логе, видно, что команда file выводит информацию о файле образа ядра. В данной информации говориться, что это ядро линукс (Linux kernel), 32-битной архитектуры (x86), содержащий возможность загрузки (boot), исполняемый (executable), в формате bzImage (то есть сжатое, бывают образы не сжатые), далее указывается версия ядра и кое-какие другие ключи образа. Данных файлов может быть несколько (в зависимости от количества установленных версий ядра) и для загрузки выбирается тот, который указан в настройках GRUB\LILO. Образ ядра, инициализирует и подготавливает ОЗУ, CPU, оборудование, монтирует корневой раздел в режиме только для чтения для загрузки остальной системы (устройство и раздел на котором размещен корень системы должен быть указан в настройках загрузчика GRUB (/boor/grub.conf) или LILO (/boor/lilo.conf)) в виде параметра root=. При этом, выводится сообщение VFS: Mounted root (ext2 filesystem) readonly. Кроме того, ядро из конфигурационного файла загрузчика получает параметры загрузки, такие как корневая файловая система, отображать сообщения ядра или нет и т.п. Параметры, переданные текущему загруженному ядру можно посмотреть в файле /proc/cmdline. Вот пример параметров все того же Debian:
boot@debian:~# cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.0-5-686 root=UUID=6852e86c-b8f1-49d0-b1eb-9d10171083c3 ro quiet
Т.к. ядро Linux является модульным, то при загрузке может возникнуть необходимость подключить модуль ядра, который находится на еще не примонтированной файловой системе. Для решения данной проблемы при загрузке подгружается архив файловой системы (он же инициализационный RAMдиск или initrd), содержащий в себе необходимый для загрузки набор модулей ядра. Вот так он выглядит для указанного выше ядра:
root@debian:~# file /boot/initrd.img-2.6.32-5-686 /boot/initrd.img-4.0-5-686: gzip compressed data, from Unix, last modified: Thu Mar 17 09:44:39 2011
Какой архив initrd подгружать при загрузке, так же указывается в GRUB или LILO:
boot@debian:~# grep initrd -B4 /boot/grub/menu.lst title Debian GNU/Linux, kernel 2.6.26-2-686 root (hd0,0) kernel /boot/vmlinuz-4.0-2-686 root=/dev/sda1 ro quiet initrd /boot/initrd.img-4.0-2-686
Т.к. стандартный вывод сообщений на монитор должен быть связан с любым процессом(ИД) а у ядра нет идентификатора, оно оно помещает сообщения ядра (и модулей) в буфер кольца ядра и выводит на экран. Данный буфер называется dmesg. Его содержимое можно увидеть командой dmesg. После полной инициализации управление переходит к демону init (первому процессу с PID=1). На экран выводится сообщение INIT: version 4.0-2 booting. Бинарный файл init по-очереди ищется в корневом разделе в каталогах: /sbin/init, /etc/init, /bin/init, если в указанных местах не обнаружен файл, то ядро пытается запустить шелл /bin/sh (это, собственно, есть однопользовательский режим загрузки, он же режим восстановления). При этом, не запускается ни один демон. Если не найден и шелл, то вываливается ошибка Kernel panic: No init found. Try passing init= option. Данная ситуация может возникнуть скорее всего, потому что ошибка в монтировании корневого раздела.
Описание 3 этапа:
До текущего момента процесс запуска любой UNIX системы практически не отличался. Третий этап загрузки может отличаться в зависимости от дистрибутива, будь то Linux, BSD, MacOS и др. Я подробно рассмотрю процесс загрузки ОС ЛИНУКС с реализацией процесса запуска с помощью пакета sysvinit (так же именуемого System V — «систем 5«). В Linux в последнее время активно внедряется разработанный «убунтологами» пакет upstart, который заменяет SysV.
На третьем этапе загрузки System V происходит следующее:
После запуска, демон init, согласно файла /etc/inittab (а точнее строкам, начинающийся на si::sysinit:/etc/……) выполняет скрипт /etc/rc.d/rc.sysinit или /etc/init.d/rcS, которые выполняют следующие действия — загрузка модулей, проверка корневой файловой системы и монтирование не read\write , установка имени hosta, времени, монтирование дополнительных Фсистем, запуск сетей, монтирование сетевых файловых системи др.), и с помощью initlog логирует о загрузке в /var/log/messages. После,стартует скрипт инициализации /etc/rc.d/rc или /etc/init.d/rc, которому передается уровень запуска в виде цифрового значения от 0 до 6 (из /etc/inittab, в котором указан уровень загрузки (выполнения) ОС по умолчанию и каталог /etc/rc*.d, в котором расположены скрипты запуска демонов/служб для соответствующего уровня запуска), запускает скрипты из каталога, соответствующего текущему уровню старта.
После демон init согласно уровню загрузки просматривает /etc/rc.d/rc0.d/ (в данном примере, цифра 0(ноль) в имени rc0.d соответствует уровню загрузки — нулевому), в котором содержатся линки на скрипты запуска служб, которые находятся в /etc/rc.d/init.d/ (для Red Hat) или в /etc/init.d/ (для Debian). Ссылки имеют вид:
<S|K><число><имя_службы>, в котором: S — запуск службы, K — остановка службы (Kill), <число> — число, определяющее последовательность запуска служб (00 — самая первая), <имя_службы> -имя запускаемой службы.
Уровни выполнения бывают следующие:
- 0: полная остановка;
- 1: single-user (однопользовательский) режим; (используется в случае серьезных проблем или для восстановления системы)
- 2: multi-user (многопользовательский) режим, без поддержки сети;
- 3: Мulti-user (многопользовательский) режим с поддержкой сети; (используется преимущественно на серверных системах)
- 4: неиспользуемый;
- 5: Мulti-user (многопользовательский) режим с поддержкой сети + графический интерфейс для входа в систему (login);
- 6: перезагрузка.
В разных дистрибутивах, возможны вариации уровней загрузки. Дистрибутив Slackware использует уровень выполнения 4 вместо 5 для полного запуска системы X Window. Debian использует один уровень выполнения для любого многопользовательского режима, обычно это уровень 2.
После запуска всех демонов, содержащихся в каталоге /etc/rc.d/rc0.d/, процесс Init запускает сценарий /etc/rc.d/rc.local (для RedHat) или /etc/rc.local (для Debian). В данном сценарии можно разместить свои настройки, которые вступят в силу после запуска всех демонов.
Далее, процесс Init запускает процесс mingetty, который запрашивает имя пользователя (о расположении mingetty, также сказано в файл /etc/inittab). После ввода имени пользователя, mingetty передает введенную информацию процессу login. Процесс login просматривает файлы /etc/passwd и /etc/shadow на наличие указанного пользователя и выводит запрос пароля. После ввода пароля пользователя, процесс login сравнивает хеш пароля с данными в файле/etc/shadow и в случае совпадения, запускает шелл.
Указанный процесс актуален для входа в текстовую консоль, при входе в графическую оболочку, вместо mingetty, процесс init запускает процесс gdm (для GNOME) или kdm (для KDE), в зависимости от того, какой оконный менеджер установлен в системе. gdm (или kdm) запускает X-сервер и выводит окно аутентификации.
После успешной аутентификации, просматривается файл конфигурации /etc/group, который определяет принадлежность пользователя к группам. А так же запускается стартовый конфигурационный сценарий /etc/X11/gdm/PreSession (для X-сервера) и конфигурационные стартовые скрипты (/etc/profile и др.) для bash, которые устанавливают настройки окружения пользователя.
Уровнем выполнения можно управлять с помощью команд.
На третьем этапе загрузки Upstart происходит следующее:
Давайте затронем вопрос загрузки системы Upstart. Основное отличие upstart от system V в том, что работа upstart основана на обработке событий. К стати будет сказано, что одной из основных задач внедрения upstart была — уйти от последовательного запуска сервисов в SysV, тем самым ускорить загрузку ОС, сделав процесс запуска служб параллельным. Итак, система upstart при запуске, процессом init генерируется событие startup(запуск — одно из двух основных событий) — старт системы, а событие shutdown — при выключении системы. Другое ключевое событие — это ctrlaltdel, которое указывает, на то, что вы нажали клавиши Ctrl-Alt-Delete. В соответствии с событием генерируемым процессом init, обрабатываются конфигурационные фалы (*.conf) из каталога /etc/init/ (в более старых версиях upstart — каталог /etc/event.d/). В этом, собственно, и заключается вся работа upstart. Для обратной совместимости с System V существует файл /etc/init/rc.conf, который запускает демоны, согласно SysV.
Содержимое файлов /etc/init/*.conf. Каждый из файлов должен содержать start on event (по какому (on) событию (event) осуществлять запуск (start) службы), stop on event (по какому событию останавливать запуск службы), exec либо script (что, собственно, запустить по указанному выше событию). Наиболее часто применяемые события в конфигурационных файлах — это startup, runlevel, stopped и started. startup — это событие запуска операционной системы, runlevel (с указанием уровня или нескольких уровней) — событие при смене уровня запуска, stopped — событие после остановки задания, started — событие после завершения старта задания. Просмотрев конфигурационные файлы в каталоге /etc/init/ можно найти и другие события, о которых можно почитать в man upstart-events (7). В дополнение к стандартным записям exec и script существуют записи pre-start и post-stop, реализующие выполнение подготовительных действия до выполнения exec и завершающие после завершения exec.
Данной системой загрузки также можно управлять командами.
Для отключения автоматического запуска службы в Upstart, необходимо:
- Переименовать конфигурационный файл запуска службы в каталоге /etc/init в файл без расширения «.conf».
- Или закомментировать строку «start on» с помощью символа ‘#’.
На третьем этапе загрузки BSD происходит следующее:
Перед описанием 3 этапа загрузки BSD хочу отметить, что по-умолчанию на 1 этапе используется загрузчик BSD Loader, работа которого аналогична любому другому загрузчику и тоже разбита на подэтапы (загрузка FSB, SSB и т.д.). Файл конфигурации BSD Loader расположен в /boot/loader.conf. Соответственно,после запуска BSD Loader, происходит передача управления ядру и запуск процесса /sbin/init. Дальше запуск несколько отличается от Linux, т.к. в BSD нет понятия runlevel, то есть существует единый уровень исполнения. НО в BSD есть 2 режима загрузки — однопользовательский (режим восстановления) имногопользовательский.
В однопользовательском режиме загрузка происходит:
- при выборе соответствующего пункта (Boot in single user mode) в меню начального загрузчика,
- при задании команды boot -s в командной строке загрузчика (после выбора пункта его меню Escape to loader prompt),
- при обнаружении серьезных (неустранимых автоматически) нарушений целостности файловой системы в ходе ее проверки на первой стадии инициализации.
При загрузке в однопользовательском режиме происходит запуск оболочки без пароля с правами суперпользователя и монтирование корневой ФС только на чтение. Запуска сценариев инициализации не происходит.
При загрузке в многопользовательском режиме, как и в Linux, выполняется 2 этап загрузки. На 3 этапе в BSD задача процесса init аналогична — этовызов и отработка сценариев инициализации, или стартовых скриптов, собранных в каталоге /etc и его подкаталогах и получение терминала (запуск процесса getty), установка его свойств и подготовка к аутентификации и авторизации (ввод логина/пароля) и последующее вытеснение getty процессом login. Отличие BSD в том, что в BSD имеет свои стартовые скрипты, отличные от Linux.
Основной стартовый скрипт -это /erc/rc, настройки применяемые по умолчанию для скрипта /etc/rc процесс init считывает, из файла /etc/defaults/rc.conf, а настройки, специфичные для текущей системы, из /etc/rc.conf, после чего осуществляется монтирование файловых систем, перечисленных в файле /etc/fstab, запуск сетевых служб, различных системных даемонов и, наконец, выполнение скриптов запуска дополнительно установленных пакаджей. Строки/etc/rc.conf имеют вид параметр=»значение» (точнее service_name_enable=»YES/NO»). Соответственно, service_name_enable — это имя службы, которое должно соответствовать имени скрипта запуска службы из каталога /etc/rc.d/* (/etc/rc.d/service_name_enable, например /etc/rc.d/sshd) или /usr/local/etc/rc.d/* — для ПО установленного из портов, значение yes или no соответственно включает или выключает службу.
Некоторые дополнительные системные сервисы могут быть не учтены в файле /etc/rc.conf. Тогда для их запуска нужно прописать соответствующую команду в/etc/rc.local
Не записывайте свои команды в /etc/rc.conf. Для запуска демонов, или для выполнения вашей команды во время запуска — запишите ваш скрипт в /usr/local/etc/rc.d.
Процесс остановки системы BSD
Во время контролируемого процесса остановки системы через утилиту shutdown программа init будет пытаться запустить скрипт /etc/rc.shutdown, после чего будет посылать всем процессам сигнал TERM, а затем и KILL тем процессам, которые не завершили работу.
Итого, в BSD процесс загрузки до ужоса прост — запуск скрипта /etc/rc согласно настроек /etc/rc.conf, в котором прописано, какие скрипты запуска демонов из/etc/rc.d/* необходимо запустить, а какие — нет и финалом загрузки является скрипт /etc/rc.local.
Маленький итог:
В данной статье я постарался, как можно прозрачней описать процесс запуска операционных систем UNIX, в том виде, в каком я его понял. Некоторые пособия/статьи разделяют загрузку на большее количество этапов.
http://studylinux.ru/protsess-zagruzki-os-linux-shematichno-i-ponyatno.html
