Настройка linux для загрузки по

Бездисковая загрузка по сети и жизнь после нее

История

Теория

По сути, для того, чтобы система загрузилась ей необходимо 3 компонента — ядро, начальное окружение initramfs и корневой каталог, в котором система будет работать.

Практика

Все действия проводятся на машине с ubuntu precise.

Для начала настроим PXE. Мануалов на эту тему уйма, поэтому я расскажу только самую суть.
Ставим ваш любимый dhcp сервер, например isc-dhcp-server, который будет раздавать машинкам ip адреса и указывать путь к файлу pxelinux.0, который будет отдавать tftp сервер (tftp-hpa или же atftp).

Пример конфига dhcp сервера. В примере pxe-сервер находится по адресу 10.0.0.1.

Запускаем tftp сервер (в ubuntu он имеет init-скрипт, но вполне вероятно, что вам придется запускать его и через inetd/xinetd).
Проверяем работоспособность. Кладем файл в каталог /var/lib/tftpboot и пробуем стянуть его tftp клиентом.

В принципе неважно, где вы возьмете файл pxelinux.0, так как он является просто начальным загрузчиком, в который мы передаем то, что надо грузить дальше.
Вы можете сделать красивую менюшку в загрузчике, но сейчас нам это не нужно, поэтому мой pxelinux.cfg/default выглядит так

rootfs

Образ rootfs собираем через debootstrap, чрутимся в него и ставим необходимые программы. Настраиваем сеть, hostname, фаервол и прочее, чем больше сделаем настроек, тем больше будет образ. Главное не забудьте сменить пароль на рута.

С нашим минимальным набором система получилась весом 200Мб.

Initramfs

В этом примере мы будем забирать образ корневой фс с веб-сервера, расположенного на нашем сервере сетевой загрузки, то есть на 10.0.0.1. Решение было таким просто потому, что в нашем initramfs была утилита wget. Чтобы не тянуть большой объем данных по сети, мы решили сжать образ. Это можно было бы сделать и обычным tar, но можно попробовать squashfs, тем более, что обычно в initramfs tar не встроен, с другой стороны, ничего не мешает его туда добавить.

Squashfs
Squashfs — это сжимающая файловая система, которая включена в ядро с версии 2.6.29. С ее помощью можно заархивировать каталог, примонтировать на loop устройство и читать с него, для записи же необходимо провести процедуру добавления файлов в архив. Так как при обращении к squashfs, вы читаете из архива, то это дает дополнительную нагрузку на cpu.

Для более эфферктивного сжатия вы можете использовать опцию -comp, чтобы установить тип сжатия, по умолчанию используется gzip.

Далее надо научить init из initramfs забирать образ корня и помещать его в оперативную память.

init в initramfs — это скрипт на sh, который производит разбор опций из cmdline, монтирует фс, делает switch_root и запускает гланый init-процесс системы.
Воспользуемся этим и допишем свои опции для cmdline. Напишем скрипт ram, который будет вызываться при значении опции boot=ram.

Через параметр rooturl можно указывать откуда качать образ корневой фс. Для работы со squashfs необходимо подгрузить ее модуль в ядро. Указываем в /etc/initramfs-tools/initramfs.conf BOOT=ram и пересобираем initramfs

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

В это примере, мы использовали squashfs просто для сжатия образа, но почему бы нам не попробовать примонтировать корневой раздел в squashfs и не посмотреть, что получится? Меняем наш скрипт, в функции do_rammount() оставляем только монтирование squashfs.

Пересобираем initramfs, запускаем, смотрим. Система загружается в режиме ro, но зато занимает в памяти всего около 180Мб.
В каких-то случаях монтирование в режиме ro это хорошо, но нас это не устраивает, но и просто так тратить оперативную память нам тоже не хочется. Выход же был найден при помощи Aufs.

Aufs
Aufs позволяет делать каскадно-объединённое монтирование файловых систем — одну в режиме только на чтение, а вторую в rw. Работает она в режиме copy-on-write, то есть все изменения записываются на rw систему и после этого чтение производится с нее же.
Опять переписываем наш скрипт.
В фукнцию mountroot() добавляем

А фукнцию do_rammount() приводим к следующему виду:

Пересобираем initramfs, запускаем, смотрим. Система занимает в памяти 181Мб, при этом мы можем менять ее, писать, читать. Все изменения хранятся отдельно в /mnt/rw, а сама система хранится в /mnt/ro.

В результате мы получили систему, которая грузится по сети, занимает небольшой объем в памяти, при этом после каждой перезагрузки пропадают все изменения (поэтому надо заранее собирать все нужные продукты жизнедеятельности системы в надежное место).

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

Источник

Бездисковая загрузка с использованием PXE и iSCSI на примере Ubuntu

В этой статье будет рассказано, как запилить сервер, который будет при включении грузиться по PXE, потом монтировать корневую файловую систему по iSCSI и спокойно жить дальше.

Что необходимо?

Для загрузки системы нужны три компонента: ядро, initramfs и корневая файловая система.
Ядро и initramfs мы передадим по TFTP, а корневую файловую систему — по iSCSI.

iSCSI-таргеты

Для Ubuntu возможно использовать различные iSCSI-таргеты. Вот неполный их список:

• ISCSI Enterprise Target — одна из самых старых реализаций iSCSI-таргета на Linux. Насколько мне известно, жива и здравствует, однако требует установки (в Ubuntu) через DKMS и совсем лёгкого дребезга бубнов. На opennet.ru есть рабочий HOWTO, применимый и к более поздним версиям ОС (Precise)
• SCSI Target Framework (STGT/TGT) — реализация iSCSI-таргета, портированная из BSD-систем. В отличии от IET, позволяет использовать не только iSCSI, но и другие родственные технологии (такие, как, например, SRP). К сожалению, код STGT в части iSCSI в линуксе работает в userspace. Как следствие, производительность получается где-то в районе плинтуса.
• SCST — новая реализация универсального таргета для Linux. По заявлениям разработчиков обладает массой преимуществ и фишек. В ядро не включена, для установки требует патчей исходников ядра и продолжительного зубодробительного секса. По слухам, мила, прекрасна и похожа на сакуру. Когда-то давно ее использовали, например, в Оверсан-Скалакси (их опыт вкратце описан на хабре). Пакеты для Ubuntu перестали поддерживаться около полутора лет назад, в SVN есть некоторая активность, то есть проект жив и здравствует. Кстати, разработчики — русские парни 🙂
• LIO — Linux Unified Target, универсальная система, реализующая iSCSI, SRP, FCoE и несколько других вариантов экспорта устройств в сеть. Официально включена в ядро и является стандартным таргетом, начиная с версии 2.6.38. К ней есть определенные претензии в плане того, что на официальном сайте активно продвигается проприетарная сборка, обладающая большим функционалом, но оставим вопли RMS.

Я буду пользоваться LIO, но ничто не мешает реализовать аналогичный функционал на другом таргете или на проприетарной промышленной СХД, вроде NetApp или EMC.

Вариант, предлагаемый ниже, состоит из двух серверов: таргета, который дополнительно к iSCSI-таргету содержит на себе DHCP и tftp-сервер, необходимые для начальной загрузки и инициатора, у которого дисков нет, а есть только сетевая карта.

На таргете желательно использовать LVM для нарезания томов, но можно использовать и обычные файлы.

1. Образ целевой системы

Создадим том размером 16 ГиБ, который будет отдаваться по iSCSI (моя VolumeGroup называется vg00, том будет называться client):

1.1. Разделы и файловые системы

Я люблю и уважаю LVM за его гибкость и удобство в работе, поэтому использую сетап, не требующий таблицы разделов на образе client. Вместо этого сразу на client создаётся еще одна VolumeGroup, которая потом режется на lv-тома.

Создадим файловую систему и разметим раздел под swap:

1.2 Сам образ системы

Примонтируем файловую систему и развернем туда с помощью debootstrap минимальный образ:

Стоит слегка подправить получившуюся систему:

Обратите внимание, мы заменили initiatorname.iscsi. IQN — это iSCSI Qualified Name, он обязательно должен быть уникальным. IQN нашего инициатора — iqn.2013-02.org.example.client:default.

Приведем fstab к нужному виду:

Чтобы не оказаться в глупом положении, нужно изменить пароль в новой системе.

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

Образ системы готов! Загрузчик ему не нужен, ядро будет запускаться с помощью pxelinux.

2. iSCSI-таргет

Установим userspace-утилиты для управления таргетом:

И запустим утилиту управления таргетом — targetcli:

2.1. Backstore

Находясь в консоли targetcli необходимо выполнить следующие команды:

Таким образом будет создан backstore для нашего тома vg00-client.

2.2. iSCSI

Назначим предварительно созданный backstore этому таргету:

Назначим таргету интерфейс для работы (без указания параметров назначатся все активные интерфейсы):

Настроим права доступа (документация по правам доступа доступна на официальном сайте:

2.3. Сохранение настроек

Несмотря на то, что действия в targetcli выполняются немедленно, они не сохраняются и после перезагрузки все таргеты не вернутся. В этом поведение LIO похоже на поведение любых других ядерных служб (iptables, ebtables, ipvsadm и т. п.). При сохранении настроек targetcli компилирует всю конфигурацию в shell-скрипт, который просто скармливает нужные данные в configFS.

Сохраним все настройки:

Таргет готов! Перейдем к настройке DHCP + TFTP.

3. DHCP-сервер

Предполагаем следующую конфигурацию:
Серверы живут в сети 10.0.0.0/24, таргет живет на 10.0.0.2, клиент получает по DHCP адрес 10.0.0.5.

Мануалов в сети море, поэтому коротко:

4. TFTP-сервер

Опять же, мануалов в сети море.

5. Syslinux

Копируем pxelinux.0 в /var/lib/tftpboot:

Также нам необходим образ ядра (можно взять с хост-системы). Сейчас у меня используется ядро от Ubuntu версии 3.2.0.37:

Дальше нужно собрать правильный initramfs. Для этого нам нужен модуль iSCSI:

Pxelinux будет искать файл с конфигурацией в директории pxelinux.cfg относительно корня tftp-сервера. Создадим ему конфигурацию:

Вместо XX необходимо подставить MAC-адрес сетевой карты client’а, записанный в нижнем регистре через минусы, а не через двоеточия.

Логин и пароль здесь необходимо использовать те же, что были указаны при настройке прав доступа к таргету.

Настройка Syslinux закончена. Теперь можно насладиться загрузкой 🙂

Мой лог загрузки выглядит примерно так:

Итоги:

Можно вполне использовать iSCSI для загрузки серверов, не имеющих своих дисков (актуально для виртуализации, самопильных систем хранения данных, серверов, которые не должны долго жить и т.п.).

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

Присутствует security-hole, поскольку /proc/cmdline доступен любому желающему в системе и этот любой желающий может получить доступ к экспортированному тому. Поэтому можно на таргете закрыть фаерволом все адреса, кроме необходимого.

Описанная схема — по большей части драфт и основа для инфраструктуры сетевой загрузки.

Источник

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

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

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

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

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

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

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

Обратите внимание, что в этой статье ведется речь именно о 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 список его страниц представлен полностью. За большей информацией обратитесь к ссылкам ниже:

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

Источник