Boot linux что это

Зачем нужен раздел /boot?

Здравствуйте товарищи. Поздравляю всех с Рождеством. Если не трудно просветите пожалуйста меня в этом вопросе.
В общем когда я первый раз установил линукс Manjaro года два назад, я выбрал установить рядом с Windows 7. Установщик Manjaro создал мне раздел /boot размером 100 Мб начинающейся с сектора 2048 и точно видел своими глазами что там что там были файлы. Недавно я решил перейти на Debian. Разметку диска я уже сделал сам, и поскольку данный раздел был в Манджаро я при новой разметке диска, точно так же его сделал и до последнего думал, что загрузчик находится там, но недавно я экспериментировал с разделами и обнаружил что загрузчик находится как раз между нулевым сектором диска и 2048 сектором, а в разделе /boot у меня вообще пусто. Почитал маленько там сям, вычитал что он нужен в случае шифрования и вообще если я не знаю зачем данный раздел то он мне и не нужен. Но меня это не устраивает, поскольку если я его уберу, а потом он мне понадобится, то это лишние манипуляции что бы его опять сделать. И мне чтобы его убрать надо точно знать что он мне не понадобится. На данный момент на ноутбуке две операционные системы: Debian и Windows 7 и я еще хочу попробовать Arch. Разметка диска MBR и обычный BIOS. Только ли для шифрования он нужен? Шифрование пока использовать не собираюсь, пока с этим вопросом не разбирался. SSD накопитель поддерживает аппаратное шифрование если что.

zzplex
07.01.23 17:45:12 MSK

• Ответить на это сообщение
• Ссылка

Boot linux что это

Возможный вид каталога /boot (Fedora 12):

$ ls /boot config-2.6.32.9-70.fc12.i686.PAE System.map-2.6.32.9-70.fc12.i686.PAE grub initramfs-2.6.32.9-70.fc12.i686.PAE.img vmlinuz-2.6.32.9-70.fc12.i686.PAE

Другой вариант (CentOS 5.2):

$ ls /boot config-2.6.18-92.el5 vmlinuz-2.6.18-92.el5 grub initrd-2.6.18-92.el5.img System.map-2.6.18-92.el5

• config-* — текстовый файл конфигурационных параметров, при которых собрано текущее ядро, обычно он используется как отправная точка для последующих изменений в конфигурации, при новых сборках ядра.
• vmlinuz-* — загрузочный файл образа системы, на этот файл конкретной версии, загружаемой по умолчанию, обычно устанавливается ссылка /boot/vmlinuz.
• System.map-* — файл таблицы символов соответствующего ядра, это очень близко динамической таблице символов, формируемой в /proc/kallsyms , но это статическая таблица символов, известных на момент сборки ядра (без загружаемых позже модулей).
• initrd-* или initramfs — это образ стартовой корневой файловой системы (монтируемой как / на время загрузки) в двух альтернативных форматах (их существует больше двух, но это самые используемые).

Во втором показанном варианте образ корневой файловой системы представлен в виде RAM-диска initrd-* (с поддержанием иерархической файловой системы). В первом примере образ корневой файловой системы представлен архивом формата CPIO (один из самых старых и традиционных форматов архивирования UNIX) initramfs-* , содержащим требуемые файлы просто линейным списком — это более поздний, более современный способ представления.

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

Зачем нужен образ стартовой корневой файловой системы? Система грузится загрузкой файла-образа /boot/vmlinuz . Если вы соберёте монолитное ядро, не требующее динамической загрузки модулей (и на ранних этапах система собиралась только так, и так она собирается для малых специальных конфигураций), то никакая корневая система вас не нужна. Но если это не так, то ядру могут потребоваться модули для их динамической загрузки, в том числе и модули драйверов дисковых и файловых систем. Но модули хранятся как загружаемые файлы в файловой системе . для которой, возможно, ещё нет загруженных драйверов. Возникает проблема курицы и яйца. Образ стартовой корневой файловой системы и есть тот образ небольшой файловой системы, размещаемой полностью в RAM, в которой и лежат файлы модулей ядра. В конечном итоге, если вы не пересобираете ядро, то вам никогда не придётся беспокоиться о стартовой корневой системе, а если вы пересобираете ядро, то там предусмотрены средства создавать и образы стартовых файловых систем путём простых формальных действий.

Что такое виденный выше каталог /boot/grub ? Linux давно эксплуатируется с вторичными загрузчиками, допускающими мультизагрузку (и выбор загружаемой системы из начального меню). Такие загрузчики Linux развиваются как независимые открытые проекты (независимые и от разработки ядра, и от разработки утилитного окружения GNU/FSF). Самыми известными загрузчиками являются LILO (более старый проект) и GRUB (наиболее активно применяемый на сегодня). Домашняя страница каждого из проектов легко находится в интернет для получения исчерпывающей информации. Вот в каталоге /boot/grub и находится ограниченное подмножество средств пакета GRUB, необходимое для реализации мультизагрузки в Linux (GRUB широко применяется в других операционных системах с другой структурой разделов диска и файловых систем, например, в: Solaris, BSD; все такие расширенные средства не включаются в /boot/grub ). Вот как выглядит конфигурационный файл (меню загрузки и другое) мультизагрузчика grub :

$ ls -l /boot/grub/grub.conf -rw------- 1 root root 907 Дек 3 2009 /boot/grub/grub.conf $ ls -l /boot/grub/menu.* lrwxrwxrwx 1 root root 11 Окт 29 2008 /boot/grub/menu.lst -> ./grub.conf $ sudo cat /boot/grub/grub.conf default=1 timeout=5 . title CentOS (2.6.24.3-1.rt1.2.el5.ccrmart) root (hd1,5) kernel /boot/vmlinuz-2.6.24.3-1.rt1.2.el5.ccrmart ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.24.3-1.rt1.2.el5.ccrmart.img . title QNX 6.3 rootnoverify (hd1,0) chainloader +1 title Windows 98SE rootnoverify (hd0,0) chainloader +1

В отличие от загрузчика LILO и других более ранних систем мультизагрузки, GRUB знает структуру файловой системы, и после редактирования grub.conf не требует какого-то специального прописывания в загрузчик диска (изменения сразу вступают в силу). Сам grub (программа) имеет достаточно развитую командную оболочку, что позволит вам, например, восстанавливать повреждённую загрузку с диска в диалоге с программой (которая, помимо прочего, содержит в себе обширную справочную информацию по работе с программой):

# which grub /sbin/grub # grub Probing devices to guess BIOS drives. This may take a long time. GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.]

grub> help blocklist FILE boot cat FILE chainloader [--force] FILE clear color NORMAL [HIGHLIGHT] configfile FILE device DRIVE DEVICE displayapm displaymem find FILENAME geometry DRIVE [CYLINDER HEAD SECTOR [ halt [--no-apm] help [--all] [PATTERN . ] hide PARTITION initrd FILE [ARG . ] kernel [--no-mem-option] [--type=TYPE] makeactive map TO_DRIVE FROM_DRIVE md5crypt module FILE [ARG . ] modulenounzip FILE [ARG . ] pager [FLAG] partnew PART TYPE START LEN parttype PART TYPE quit reboot root [DEVICE [HDBIAS]] rootnoverify [DEVICE [HDBIAS]] serial [--unit=UNIT] [--port=PORT] [-- setkey [TO_KEY FROM_KEY] setup [--prefix=DIR] [--stage2=STAGE2_ Grub will attempt to avoid printing an terminal [--dumb] [--no-echo] [--no-ed terminfo [--name=NAME --cursor-address testvbe MODE unhide PARTITION uppermem KBYTES vbeprobe [MODE]

Предыдущий раздел:	Оглавление	Следующий раздел:
Каталог устройств (/dev)	Монтирование файловых систем

Процесс загрузки в Linux

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

Начнем с того, что процесс загрузки отличается в зависимости от того, какой режим был выбран в BIOS: Legacy (Compatibility Mode), Native UEFI. Некоторые материнские платы умеет комбинировать режимы, например, Dell.

Legacy boot

1. BIOS: базовая система ввода/вывода выполняет POST или самотестирование при включении питания, обнаружить и инициализировать аппаратные компоненты системы. Она же отвечает за аппаратные прерывания.

2. MBR: главная загрузочная запись расположена в первом секторе загрузочного диска, обычно /dev/hda или /dev/sda. Его размер составляет менее 512 байт, и он состоит из трех компонентов. Информация основного загрузчика в первых 446 байтах, информация таблицы разделов в следующих 64 байтах и проверка MBR в последних 2 байтах.

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

3. GRUB2: GRUB начинает поиск в vmlinuz, который представляет собой сжатый образ ядра Linux, и загружает его в память, а затем извлекает содержимое образа initramfs. Обычно этот файл хранится в /boot и путь к образу можно прочитать командой:

cat /proc/cmdline

Там же указывается и UUID корневой файловой системы, которую надо смонтировать.

4. ЯДРО: Ядро монтирует корневую файловую систему, как указано в параметре «root=» в grub.conf, затем выполняет программу /sbin/init .

5. SYSTEMD: Systemd (заменил старый SysVinit) вызывает таргеты. В Linux есть так называемые режимы запуска, в первой системе инициализации они назывались «Уровни запуска» (runlevel). В SystemD они называются загрузочными таргетами, или boot targets. Таргеты systemd — это разные состояния, в которых может загружаться ваша система, сопоставимые с уровнями запуска System V. В отличие от уровней выполнения SysV, целевые модули имеют имена, а не нумеруются. Например, graphical.target аналогична уровню запуска SysV 5, многопользовательская с сетью и графической средой.

6. RUNLEVEL. Уровень запуска — это один из режимов, в котором будет работать Linux. На каждом уровне выполнения останавливается или запускается определенное количество служб, что дает пользователю контроль над поведением машины. Обычно существует семь уровней выполнения, пронумерованных от нуля до шести. В зависимости от настроек уровня запуска по умолчанию система будет выполнять программы из одного из следующих режимов:

Run Level	Mode	Action
0	Halt	Выключение
1	Single-User Mode	Не настраивает сетевые интерфейсы, старт демонов, не-root вход
2	Multi-User Mode	Не настраивает сетевые интерфейсы, старт демонов
3	Multi-User Mode with Networking	Нормальный запуск в консольном режиме
4	Undefined	Не используется
5	X11	Аналогичен 3 + графический интерфейс (X)
6	Reboot	Перезагрузка

Systemd по умолчанию активирует модуль default.target при загрузке системы. Давайте проверим наш target по умолчанию:

systemctl get-default

Теперь давайте посмотрим на связь между runlevel и target:

• poweroff.target, уровень запуска 0
• rescue.target, уровень запуска 1
• multi-user.target, уровень запуска 3
• graphical.target, уровень запуска 5
• restart.target, запустите уровень 6
• emergency.target: уровень аварийного запуска

Например, таргет по умолчанию для рабочей станции с графическим интерфейсом пользователя (GUI) равно 5. Это значение соответствует уровню выполнения 5, который равен Graphical.target. Кроме того, runlevel для сервера равен 3, поскольку целью по умолчанию является multi-user.target.

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

systemctl list-units --type target

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

sudo systemctl set-default rescue.target

UEFI загрузка

Одним из ключевых различий между UEFI и BIOS является то, что UEFI поддерживает более современную схему разбиения lbcrf GPT, а встроенное ПО UEFI имеет возможность читать файлы из небольшой системы FAT. Это означает, что ваша конфигурация UEFI и двоичные файлы находятся в разделе GPT на вашем жестком диске. Это часто называют ESP (системный раздел EFI), обычно монтируемый в /efi .

Будучи более гибким, UEFI устраняет необходимость использования загрузчика второго этапа, такого как GRUB. Часто, если вы устанавливаете одну операционную систему, например Ubuntu Desktop или Windows с включенным UEFI, вы можете обойтись без использования GRUB или любого другого промежуточного загрузчика. Если система установлена с поддержкой совместимости как BIOS, так и UEFI, в первых нескольких секторах жесткого диска будет иметься MBR-совместимый блок. Аналогично, если вам нужно выполнить загрузку с несколькими ОС или просто использовать загрузчик второго этапа по другим причинам, вы можете использовать GRUB или любой другой загрузчик.

Secure Boot

Безопасная загрузка — это стандарт безопасности. При включении компьютера с UEFI начинается процесс безопасной загрузки с прошивки материнской платы, которая проверяет криптографические подписи каждого из загрузочных файлов. Сюда входят драйверы прошивки UEFI (дополнительные ROM), приложения EFI и операционная система. После проверки компьютер загружается, и прошивка передает управление операционной системе.

Secure Boot использует 4 ключевые базы данных:

• База данных разрешенных подписей (db) — содержит список криптографических подписей, которые разрешено загружать во время процесса загрузки.
• База данных запрещенных подписей (dbx) — содержит список криптографических подписей, которые не разрешено загружать во время процесса загрузки.
• База данных ключей регистрации ключей (KEK) — содержит ключи обмена ключами, используемые для аутентификации других баз данных.
• База данных ключей платформы (PK) — содержит открытый ключ, который используется для проверки подписи любого загрузчика или прошивки, подписанной соответствующим закрытым ключом. Рекомендуемый ключ платформы для UEFI — RSA-2048.

MOK — это дополнительная база данных ключей, которой может управлять пользователь. Он не связан с ключом центра сертификации, который поставляется с shim. Они дают пользователю больше контроля над тем, какие модули можно загружать. Например, когда пользователь регистрирует MOK в системе, связанный с ним ключ добавляется в базу данных разрешенных подписей (db). Это означает, что любой двоичный файл, подписанный этим ключом, будет проверен прошивкой во время процесса загрузки.

Обычно они расположены в каталоге /var/lib/shim-signed/mok/ под именами MOK.der, MOK.pem или MOK.priv .

Shim

При включении безопасной загрузки важно понимать, что такое shim («прокладка»). В контексте SecureBoot прокладка — это программа предварительного загрузчика, предназначенная для работы с прошивкой Secure Boot. Он позволяет загружать и выполнять загрузчики и модули ядра, если они не включены в базу данных безопасной загрузки. В Ubuntu загрузчик shim предустановлен и подписан центром сертификации Microsoft.

Secure Boot использует асимметричную криптографию, то есть используются открытый и закрытый ключи. Пара ключей может быть сгенерирована пользователем, а закрытый ключ используется для подписи всех программ, запуск которых разрешен, включая загрузчик GRUB. Прошивка UEFI будет использовать открытый ключ для проверки контрольных сумм и подписей программ перед их выполнением.

Переменные UEFI

Еще одна концепция — это переменные UEFI, которые хранятся в энергонезависимой памяти прошивки (NV-RAM). Эти переменные хранят различные данные, такие как настройки порядка загрузки, значения тайм-аута, настройки сети, сведения об устройстве хранения и настройки безопасной загрузки. Каждая переменная UEFI будет иметь собственный двоичный файл в папке /sys/firmware/efi/efivars/ .

В дальнейшем UEFI загрузка аналогична legacy загрузке: загружается и распаковывается ядро из раздела /boot с тем лишь исключением, что проверяются подписи образов, модулей и драйверов. Утилита modinfo позволяет посмотреть подписи модулей, который находятся в /lib/modules/ .

Системные драйверы, загружаемые ядром (initramfs) содержатся в /boot/initrd*

[Посещений: 73, из них сегодня: 1]

Введение в процессы загрузки ядра и запуска системы Linux

Всем привет! Вот мы и открыли очередной, четвёртый по счёт уже, поток курса «Администратор Linux», который уверенно занимают свою нишу рядом с девопсерским курсом. Больше преподавателей, больше информации и стендов. Ну и как всегда больше интересной информации, которую подобрали преподаватели.

Задумывались ли вы когда-нибудь, что нужно для того, чтобы ваша система была готова к запуску приложений?

Понимать процессы загрузки ядра и запуска системы Linux, важно для настройки Linux и решения проблем запуска. В этой статье представлен обзор процесса загрузки ядра с использованием GRUB2 загрузчика и запуска, выполняемого системой инициализации systemd.

На самом деле, есть два ряда событий, необходимых для приведения компьютера с Linux в рабочее состояние: загрузка ядра (boot) и запуск системы (startup). Процесс загрузки ядра начинается при включении компьютера и заканчивается с инициализацией ядра и запуском systemd. После этого начинается процесс запуска системы, и именно он доводит компьютер Linux до рабочего состояния.

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

• BIOS POST;
• Загрузка ядра (GRUB2);
• Инициализация ядра;
• Запуск systemd, родителя всех процессов.

Процесс загрузки ядра

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

BIOS POST

Первый шаг процесса загрузки ядра Linux не имеет никакого отношения к Linux. Это аппаратная часть процесса, одинаковая для всех операционных систем. Когда питание подается на компьютер, в первую очередь происходит запуск POST (Power On Self Test), являющегося частью BIOS (Basic I/O System, Базовая Система Ввода-Вывода).

Когда IBM выпустила первый персональный компьютер в 1981 году, BIOS был разработан для инициализации аппаратных компонентов. POST — часть BIOS, задачей которого является обеспечение корректной работы компьютерного оборудования. Если POST заканчивается неудачно, то возможно компьютер неисправен, и процесс загрузки не продолжается.

BIOS POST проверяет базовую работоспособность железа, а затем вызывает прерывание BIOS — INT 13H, которое находит секторы загрузки ядра на всех подключенных устройствах с возможностью загрузки. Первый найденный сектор, в котором содержится валидная загрузочная запись, загружается в RAM, после чего контроль передается коду из загрузочного сектора.
Загрузочный сектор — только первый этап. В большинстве дистрибутивов Linux используется один из трех вариантов загрузчика: GRUB, GRUB2 и LILO. GRUB2 — самый новый и сейчас его используют гораздо чаще более старых вариантов.

GRUB2 расшифровывается как “GRand Unified Bootloader, version 2”, и теперь он является основным загрузчиком для большинства современных дистрибутивов Linux. GRUB2 — программа, которая делает компьютер достаточно “умным”, чтобы тот смог найти ядро операционной системы и загрузить его в память. Поскольку говорить и писать просто GRUB легче, чем GRUB2, в этой статье я возможно буду использовать термин GRUB, но подразумевать GRUB2, если не будет иного уточнения.

GRUB совместим со спецификацией мультизагрузки, что позволяет ему загружать разные версии Linux и других операционные системы; он также может запустить по цепочке загрузочную запись проприетарных операционных систем.

GRUB также позволяет пользователю выбрать загрузку ядра из нескольких возможных для любого предоставленного дистрибутива Linux. Это дает возможность загрузить предыдущую версию ядра, если обновленная не сможет загрузиться корректно или окажется несовместима с какой-то важной частью ПО. GRUB можно настроить в файл /boot/grub/grub.conf .

GRUB1 сейчас уже считается устаревшим и в большинстве современных дистрибутивов заменен на GRUB2, который является его переписанным вариантом. Дистрибутивы на основе Red Hat обновились до GRUB2 около Fedora 15 и CentOS/RHEL 7. GRUB2 имеет тот же загрузочный функционал, что и GRUB1, но в дополнении предоставляет mainframe-like, pre-OS окружение на базе команд и бОльшую гибкость на предзагрузочном этапе. Настройка GRUB2 происходит в /boot/grub2/grub.cfg .

Основная задача любого из GRUB — загрузить ядро Linux в память и запустить его. Обе версии GRUB работают схожим образом в три этапа, но в этой статье я буду использовать именно GRUB2 для описания работы GRUB. Настройка GRUB и GRUB2 и использование команд GRUB2 выходит за рамки этой статьи.

Хоть официально GRUB2 не использует нумерацию этапов, ради удобства я воспользуюсь ей в этой статье.

Как уже упоминалось в разделе BIOS POST, в конце POST BIOS ищет загрузочные записи на прикрепленных дисках, обычно расположенных в Главной Загрузочной Записи (Master Boot Record, MBR), после чего он загружает первую найденную запись в память и приступает к ее исполнению. Bootstrap-код, то есть 1-ый этап GRUB2, занимает очень мало места, потому что должен влезать в первый 512-байтовый сектор на жестком диске вместе с таблицей разделов. Общее количество места, выделенного для самого bootstrap-кода в стандартной MBR — 446 байт. 446-байтовый файл для этапа 1 называется boot-img и не содержит таблицу разделов — она добавляется в загрузочную запись отдельно.

Поскольку загрузочная запись должна быть настолько маленькой, она не очень “умная” и не понимает структуру файловой системы. Поэтому единственной целью этапа 1 является обнаружение и загрузка этапа 1.5. Чтобы достичь этого, этап 1.5 GRUB должен располагаться в пространстве между самой загрузочной записью и первым разделом на диске. После загрузки этапа 1.5 GRUB в RAM, этап 1 передает контроль этапу 1.5.

Как было замечено выше, этап 1.5 GRUB должен находиться между загрузочной записью и первый разделом на диске. Исторически сложилось, что это пространство остается неиспользованным по техническим причинам. Первый раздел на жестком диске начинается в 63 секторе, а с учетом MBR в секторе 0, остается 62 512-байтовых секторов — 31744 байта — в которых можно хранить файл core.img — 1.5 этап GRUB. Файл core.img весит 25389 байт, что достаточно места для его хранения между MBR и первым разделом диска.

Поскольку для этапа 1.5 можно использовать больше кода, его может быть достаточно для содержания нескольких распространенных драйверов файловых систем, например, стандартной EXT и прочих Linux файловых систем, FAT и NTFS. core.img в GRUB2 более сложный и функциональный, чем в этапе 1.5 GRUB1. Это значит, что этап 2 GRUB2 может находиться в стандартной EXT файловой системе, но не в логическом томе. Поэтому стандартное местоположение для файлов этапа 2 — файловая система /boot , а точнее /boot/grub2 .

Обратим внимание, что директория /boot должна располагаться в файловой системе, которая поддерживается GRUB. Не все файловые системы имеют эту поддержку. Задача этапа 1.5 — начать с необходимыми драйверами файловой системы поиск файлов этапа 2 в файловой системе /boot и загрузить нужные драйверы.

Все файлы этапа 2 GRUB находятся в директории /boot/grub2 и нескольких поддиректориях. В GRUB2 нет файла образа как в этапах 1 и 2. Вместо этого он по большей части состоит из runtime модулей ядра, которые грузятся по необходимости из директории /boot/grub2/i386-pc .

Задача этапа 2 GRUB2 — обнаружить и загрузить ядро Linux в RAM и передать контроль управления компьютером ядру. Ядро и связанные с ним файлы находятся в директории /boot . Файлы ядра легко узнать, поскольку их названия начинаются с vmlinuz. Вы можете составить список содержимого директории /boot , чтобы посмотреть текущие установленные ядра в вашей системе.

GRUB2, как и GRUB1, поддерживает загрузку одного из нескольких ядер Linux. Система управления пакетами Red Hat поддерживает сохранение нескольких версий ядра, чтобы можно было загрузить старую версию ядра в случае возникновения проблем с самой новой. По умолчанию, GRUB предоставляет предварительно загруженное меню установленные ядер, включая опцию rescue, а после настройки, и опцию recovery.

Этап 2 GRUB2 загружает выбранное ядро в память и передает контроль управления компьютером ядру.

Все ядра находятся в самораспаковывающемся, сжатом формате для экономии места. Ядра расположены в директории /boot , вместе с исходным образом диска RAM и списком разделов на жестких дисках.

После того, как выбранное ядро загружено в память и начинает исполняться, в первую очередь, оно должно извлечь самого себя из сжатой версии файла, перед тем как начать выполнять полезную работу. Как только извлечение произошло, оно загружает systemd, который является заменой старой программе SysV init, и передает ему контроль.

Это конец процесса загрузки ядра. К этому моменту, ядро Linux и systemd запущены, но не могут выполнять какие-либо полезные задачи для конечного пользователя, так как выполнять еще нечего.

Процесс запуска системы

Процесс запуска системы следует за процессом загрузки ядра и приводит компьютер с Linux в рабочее состояние.

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

Сначала, systemd монтирует файловые системы, как определено в /etc/fstab , включая любые swap-файлы и разделы. К этому моменту, он может получить доступ к файлам конфигурации, расположенным в /etc , включая его собственным. Он использует собственный конфигурационный файл /etc/systemd/system/default.target , чтобы определить таргет (target), по которому нужно загрузить хост. Файл default.target — просто симлинк на настоящий target файл. Для настольной рабочей станции обычно это graphical.target, эквивалентный runlevel 5 в старом инициализаторе SystemV. Для сервера, по умолчанию скорее всего будет multi-user.target, аналогичный runlevel 3 в SystemV. emergency.target похож на однопользовательский режим.

Обратите внимание, что target’ы и сервисы являются юнитами systemd.

Ниже представлена Таблица 1, в которой идет сравнение всех таргетов systemd со старыми уровнями выполнения (runlevel) в SystemV. Псевдонимы таргета systemd предоставляются systemd для обратной совместимости. Псевдонимы таргета разрешают скриптам — и многим сисадминам, мне в том числе — использовать такие SystemV команды как init3 для изменения уровней выполнения. Конечно, команды SystemV направлены systemd для интерпретации и исполнения.

Runlevel	aliases	Description
halt.target	Приостанавливает систему без отключения питания
0	poweroff.target	runlevel0.target	Приостанавливает систему и отключает питание
S	emergency.target	Однопользовательский режим. Сервисы не запущены; файловые системы не смонтированы. Это самый базовый уровень оперирования. Для взаимодействия пользователя с системой в главной консоли запущена только аварийная оболочка.
1	rescue.target	runlevel1.target	Базовая система, включающая монтирование файловой системы с самым базовым набором сервисов и rescue оболочкой в главной консоли.
2	runlevel2.target	Многопользовательский режим, без NFS, но все сервисы, не относящиеся к GUI, запущены.
3	multi-user.target	runlevel3.target	Все сервисы запущены, но только через интерфейс командной строки (CLI).
4	runlevel4.target	Не используется.
5	graphical.target	runlevel5.target	Многопользовательский режим с GUI.
6	reboot.target	runlevel6.target	Перезагрузка.
default.target	Этот таргет всегда имеет симлинк с multi-user.target или graphical.target. systemd всегда использует default.target для запуска системы. default.target никогда не должен быть связан с halt.target, poweroff.target или reboot.target.

Таблица 1: Сравнение уровней управления SystemV с target’ами systemd и некоторые псевдонимы таргетов.

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

systemd также просматривает устаревшие директории инициализации SystemV на предмет наличия стартап файлов. Если они есть, systemd использует их в качестве файлов конфигурации для запуска сервисов описанных в файлах. Устаревший сетевой сервис — хороший пример одного из тех, что до сих пор используют стартап файлы SystemV в Fedora.

Рисунок 1, представленный ниже, напрямую скопирован с главной страницы bootup. На нем показана общая последовательность событий во время запуска systemd и базовые требования для обеспечения его успешности.

Таргеты sysinit.target and basic.target можно считать чекпоинтами в процессе запуска системы. Хоть одна из целей systemd — параллельно запускать системная сервисы, есть некоторые сервисы и функциональные таргеты, которые должны быть запущены раньше других. Эти контрольные точки не могут быть пройдены до тех пор, пока все сервисы и таргеты, необходимые для них, не будут выполнены.

Таким образом, sysinit.target достигается, когда завершены все юниты, от которых он зависит. Должны быть завершены все следующие юниты: монтирование файловых систем, настройка swap-файлов, запуск udev, настройка начального состояния генератора случайных чисел, инициализация низкоуровневых сервисов, настройка криптографических сервисов, если хотя бы одна файловая система зашифрована. В sysinit.target они могут выполняться параллельно.
sysinit.target запускает все низкоуровневые сервисы и юниты необходимые для минимальной функциональности системы, и те, что нужны для перехода к basic.target.

Рисунок 1. Карта запуска systemd

После выполнения sysinit.target, systemd запускает basic.target, начиная со всех юнитов, необходимых для его выполнения. Базовый таргет предоставляет дополнительный функционал, запуская юниты необходимые для следующего таргета, включая настройку путей до различных исполняемых директорий, коммуникационных сокетов и таймеров.

Наконец, можно начать инициализацию таргетов пользовательского уровня: multi-user.target или graphical.target. Стоит отметить, что multi-user.target должен быть достигнут до того, как будут выполнены зависимости графического таргета.

Подчеркнутые таргеты в Рисунке 1 — обычные стартап таргеты. Запуск системы завершается по достижении одного из них. Если multi-user.target является таргетом по умолчанию, то в консоли вы увидите логин в текстовом режиме. Если же по умолчанию задан graphical.target, то увидите графический логин; GUI экрана логина зависит от экранного менеджера, который вы используете.

Недавно мне пришлось поменять дефолтное загрузочное ядро на компьютере Linux, который использовал GRUB2. Я обнаружил, что некоторые команды перестали работать корректно, или же я пользовался ими как-то некорректно. До сих пор не знаю, в чем была проблема, потребуется больше времени на ее исследование.

Команда grub2-set-default неправильно настроила дефолтный индекс ядра в файле /etc/default/grub , поэтому желаемое альтернативное ядро не загружалось. Я вручную поменял /etc/default/grub GRUB_DEFAULT=saved на GRUB_DEFAULT=2 , где 2 — индекс установленного ядра, которое я хотел запустить. Затем, я запустил команду grub2-mkconfig > /boot/grub2/grub.cfg для создания нового конфигурационного файла grub. Эта уловка сработала, и альтернативное ядро было запущено.

GRUB2 и система инициализации systemd — ключевые компоненты для фаз загрузки ядра и запуска системы большинства современных дистрибутивов Linux. Несмотря на противоречия, особенно вокруг systemd, эти два компонента хорошо работаю вместе для загрузки ядра и запуска всех системных сервисов, необходимых для создания функциональной системы Linux.
Хоть я и считаю GRUB2 и systemd в целом более сложными, чем их предшественники, они ничуть не сложнее в освоении и управлении. В мануалах содержится большое количество информации о systemd, а на freedesktop.org список его страниц представлен полностью. За большей информацией обратитесь к ссылкам ниже:

• GNU GRUB (Wikipedia)
• GNU GRUB Manual (GNU.org)
• Master Boot Record (Wikipedia)
• Multiboot specification (Wikipedia)
• systemd (Wikipedia)
• systemd bootup process (Freedesktop.org)
• systemd index of man pages (Freedesktop.org)

Вот и всё. Ждём вопросы и комментарии тут или их можно задать напрямую на открытом уроке.