Linux параметры ядра при загрузке

Углубление в параметры ядра. Часть 1: загрузочные параметры

Диапазон статьи

Jul 27, 2020 · 7 min read

EC2 (эластичное облако вычислений) — это наиболее часто используемый AWS-сервис, поскольку он надёжен, гибок и позволяет масштабируемость. EC2 можно назвать “хребтом” AWS, т.к. прямо или косвенно он задействуется во множестве других сервисов AWS. По большей части публичные AMI, предоставляемые Amazon и другими крупными вендорами, уже прошли тщательные испытания на пригодность использования в продакшене. Тем не менее иногда возникает необходимость подстройки поведения инстансов EC2 через изменение параметров их ядер.

В текущей серии статей мы рассмо т рим, что представляют собой параметры ядра (включая параметры его загрузки), а также как изменять эти параметры для Amazon Linux 1/2, RHEL 5/6/7/8, CentOS 6/7, SLES 12/15 и Ubuntu 14.04/16.04/18.04/20.04 на инстансах AWS EC2. Это будет первой частью погружения в тему параметров ядра.

Знакомство с параметрами ядра

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

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

1. При загрузке ядра (загрузочные параметры). Эти параметры вызываются через загрузчика ОС.
2. В процессе работы ядра через псевдо-файловые системы /proc и /sys, используя “sysctl”.
3. При компиляции (или перекомпиляции) ядра и его подсистем (вроде initrd).

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

Загрузочные параметры ядра

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

За загрузку и запуск ядра Linux отвечает загрузчик ОС, поэтому, чтобы иметь возможность передать параметры загрузки, мы используем специализированный загрузчик вроде GRUB.

Загрузочные параметры ядра определяются в виде списка строк, разделённых пробелами следующим образом:
name[=value_1][,value_2]…[,value_10].

На данный момент код ядра может обрабатывать максимум 10 отделённых запятыми значений параметров. Тем не менее допускается переиспользование одного и того же ключевого слова.

К примеру, приведу конфигурацию grub для инстанса на Amazon Linux 1. В ней я изменил параметр “console”, определив для него 2 значения (допускается до 10).

Мы можем также предоставить ядру параметры загрузки, приведённые ниже. Здесь вместо определения значений “console” в виде одного параметра мы повторно использовали console для определения другого значения. При необходимости каждый параметр “console” может содержать до 10 значений, что позволяет выйти за рамки предыдущих ограничений.

Существует несколько способов изменения загрузочных параметров ядра. Кроме того, все дистрибутивы Linux (кроме Ubuntu), упомянутые ранее, используют схожие шаги для изменения этих параметров.

1. Универсальный способ—обновление загрузочных параметров через утилиту grubby

grubby— это инструмент командной строки для обновления и отображения информации о файлах конфигурации загрузчика. grubby отлично работает со всеми дистрибутивами Linux, включая Amazon Linux 1/2, RHEL 5/6/7/8, CentOS 6/7 и SLES 12/15, но при этом не дружит с Ubuntu.

PS: grubby по умолчанию установлен на все дистрибутивы Linux, кроме SLES. Инструкции по его установке вы можете найти в разделе “Добавить репозиторий и установить вручную” здесь.

Преимущества grubby

Работа с таким инструментом, как grubby, предоставляет множество преимуществ, включая простоту и согласованность во многих дистрибутивах. Для использования grubby вам также не нужно обладать глубокими познаниями об его файлах конфигурации. Например, вы можете получить рабочее ядро при помощи одной команды:

Обратите внимание, что это текущая версия ядра. Вы получите её же при помощи команды “uname-r” (текущая версия ядра) или через запись меню “default” в файле конфигурации. Более подробную информацию вы можете получить при помощи опции -info (аналогично использованию файла конфигурации):

Попробуйте также опцию “grubby -info ALL”.

С остальными опциями вы можете ознакомиться при помощи “grubby -help”.

В процессе загрузки загрузчик передаёт параметры ядру Linux в буфер памяти под названием kernel command line (командная строка ядра). Файл /proc/cmdline в псевдо-файловой системе /proc также содержит копию этих параметров. Проверить это мы можем при помощи следующей команды:

Работа с grubby

Чтобы добавить/изменить параметры ядра посредством grubby, нам нужно указать параметры при помощи -args=args совместно с опцией -update-kernel=default-kernel-path. Например, я добавил параметры “clocksource=tsc tsc=reliable”. Параметр “clocksource=tsc” устанавливает источник тактовой частоты как tsc (clocksource=tsc), если он ещё таковым не установлен. Параметр же “tsc=reliable” отключает все проверки стабильности TSC в процессе загрузки.

PS. Для удаления существующих параметров используйте команду -remove-arguments.

Перезагрузите систему и убедитесь, что параметры “clocksource=tsc tsc=reliable” добавлены:

Либо просто проверьте это через grubby:

В дальнейшем вы можете убедиться, что источником тактовой частоты определён tsc, при помощи следующей команды:

Это всё, что касается grubby.

2. Дистрибутивы Linux с Legacy GRUB

Amazon Linux 1 аналогично RHEL6.X, RHEL5.X и CentOS использует в качестве загрузчика GRUB (также известный как Legacy RUB). Узнать версию в подобных дистрибутивах вы можете так:

Файл конфигурации GRUB располагается в /boot/grub/grub.conf и содержит две символические ссылки на себя: /etc/grub.conf и /boot/grub/menu.lst. Нам нужно изменить эту конфигурацию grub, добавив дополнительные параметры загрузки ядра. Однако, чтобы сделать это эффективно, давайте сначала разберём основы конфигурации grub. Ниже приведён её пример из инстанса EC2 Amazon Linux 1.

Конфигурация GRUB

Здесь, как вы видите, присутствует более 1 записи меню. Запись меню наряду с параметрами содержит информацию о расположении образов ядра и initrd. Каждая запись начинается с “title…” и содержит численный порядок, начиная с 0. Значение “default” определяет текущий образ ядра, который используется для загрузки serve=. В конфигурации, приведённой выше, значение представлено как “0”. Это означает, что действует первая запись меню (4.14.181–108.257.amzn1.x86_64). Давайте взглянем на строку ядра. Вся структура name[=value_1], указанная после местоположения образа ядра (выделена жирным курсивом и разделена пробелами), представляет параметры загрузки:

kernel /boot/vmlinuz-4.14.181–108.257.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295

Важно знать её, чтобы добавлять параметры в правильную запись меню.

Работа с конфигурацией GRUB

Теперь отредактируйте файл конфигурации (/etc/grub.conf) в предпочтительном редакторе и добавьте/измените нужные вам параметры. Я добавил те же параметры “clocksource=tsc tsc=reliable”, что и ранее.

kernel /boot/vmlinuz-4.14.181–108.257.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295 clocksource=tsc tsc=reliable

Перезапустите систему, чтобы изменения вступили в силу. Проверить это мы можем тем же способом, что и в опции 1:

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

3. Дистрибутивы Linux с загрузчиком GRUB2

Amazon Linux 2, так же как RHEL7.X, CentOS7, SLES15 и SLES12, использует в качестве загрузчика GRUB2. Узнать версию такого дистрибутива вы можете следующим образом:

Для систем, по умолчанию использующих загрузчик GRUB2, конфигурация этого загрузчика размещается в /boot/grub2/grub.cfg. Управлять этим файлом должен только сам GRUB2, поскольку он генерирует его автоматически посредством grub2-mkconfig с использованием шаблонов из каталога /etc/grub.d и файла /etc/default/grub. Об этом мы поговорим чуть позже.

Понимание конфигурации GRUB2

PS. Если вы используете инстансы из семейства ARM, упомянутые здесь и здесь, то конфигурация grub должна располагаться где-то в каталоге /boot/efi/EFI. К примеру, для RHEL7, работающего на ARM, это будет /boot/efi/EFI/redhat/grub.cfg.

Загрузочные параметры ядра дистрибутивов, использующих GRUB2, определены в каталоге /etc/default/grub. Давайте взглянем на пример из инстанса на Amazon Linux 2:

“GRUB_CMDLINE_LINUX_DEFAULT” содержит загрузочные параметры (командной строки) ядра. Это строка, в которой мы редактируем конфигурацию grub для изменения загрузочных параметров.

GRUB_CMDLINE_LINUX_DEFAULT=”console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295

Работа с конфигурацией GRUB2

Отредактируйте файл конфигурации grub (/etc/default/grub.conf) с помощью предпочтительного редактора. Добавьте/измените интересующие вас параметры для строки GRUB_CMDLINE_LINUX_DEFAULT. Например, я добавил параметры systemd.log_level=debug systemd.log_target=console. Эти дополнительные параметры активируют режим отладки системы и перенаправляют в консоль. Итак, после обновления моя запись в файле /etc/default/grub будет выглядеть примерно так:

GRUB_CMDLINE_LINUX_DEFAULT=”console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0 systemd.log_level=debug systemd.log_target=console”

Теперь, чтобы автоматически сгенерировать конфигурацию grub2 на основе добавленных параметров, нам нужно запустить grub2-mkconfig, добавив путь к этой конфигурации:

Перезагрузите систему и проверьте, вступили ли изменения в силу из /proc/cmdline, как мы делали ранее.

4. Для инстансов EC2 на Ubuntu 14.04 / 16.04 / 18.04 / 20.04

GRUB2 является предустановленным загрузчиком и менеджером для Ubuntu, начиная с версии 9.10. Именно поэтому процесс изменения загрузочных параметров ядра практически такой же, как и для других дистрибутивов Linux с GRUB2, которые мы рассмотрели выше.

В данном случае местоположением файла конфигурации будет /etc/default/grub.d/50-cloudimg-settings.cfg.

Для добавления параметров откройте в редакторе /etc/default/grub.d/50-cloudimg-settings.cfg и измените нужные параметры в GRUB_CMDLINE_LINUX_DEFAULT, как мы делали ранее.

После этого выполните команду update-grub, чтобы повторно сгенерировать уже обновлённую конфигурацию grub:

PS. update-grub — это альтернатива или, так скажем, сокращённая версия команды grub-mkconfig -o /boot/grub/grub.cfg.

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

Источник

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

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

Источник