Dracut linux что это

Обновлено: 05.07.2024

Dracut - это набор инструментов, которые обеспечивают расширенную функциональность для автоматизации процесса загрузки Linux. Инструмент под названием dracut используется для создания загрузочного образа Linux (initramfs) путем копирования инструментов и файлов из установленной системы и объединения их с фреймворком Dracut, который обычно находится в /usr/lib/dracut/modules.d .

В отличие от существующих загрузочных образов Linux, фреймворк Dracut пытается ввести как можно меньше жестко запрограммированной логики в initramfs. По сути, initramfs имеет одну цель: найти и смонтировать настоящую корневую файловую систему, чтобы процесс загрузки мог перейти к ней. Эта функция зависит от доступности устройства. Поэтому вместо жестко запрограммированных сценариев для определения доступности и пригодности устройства initramfs Dracut зависит от диспетчера устройств Linux ( udev ) для создания символических ссылок на узлы устройств. Когда появляется узел устройства корневой файловой системы, Dracut монтирует его как новую корневую файловую систему. Это помогает сократить время, необходимое для initramfs, так что теперь стали возможны такие вещи, как 5-секундная загрузка.

Большая часть функциональных возможностей генерации initramfs в Dracut обеспечивается модулями генерации, источником которых является основной инструмент dracut , для установки определенных функций в initramfs. Они живут в подкаталоге modules и для своей работы используют функции, предоставляемые dracut-functions.

СОДЕРЖАНИЕ

Принятие

Red Hat - оригинальный автор дракута. Дистрибутивы, производные от Red Hat, используют dracut для создания initramfs. Использование вне дистрибутивов, производных от Red Hat, ограничено.

Fedora с версии 12, Константин
Red Hat Enterprise Linux, начиная с версии 6
openSUSE с версии 13.2, когда он стал инструментом создания initramfs по умолчанию
SUSE Linux Enterprise Server, начиная с версии 12

Дистрибутивы, которые включают dracut, но не используются по умолчанию для создания initramfs:

К данному моменту нам известно, что initramfs обладает встроенным bash и мы пользовались им время от времени через особые точки входа rd.break . Цель данной главы состоит в том, чтобы разобраться как systemd снабжает нас некой оболочкой изнутри initramfs. В чём состоят те шаги, которые надлежит предпринимать и как следует применять его более действенно? Однако перед этим давайте подведём итоги того, что мы узнали на данный момент относительно отладочной и аварийной оболочек initramfs.

Оболочка

rd.break

свалиться в оболочку в самом конце

Содержимое журнала времени исполнения rdsosreport.txt

Далее мы обсудим как мы можем применять аварийные оболочки для исправления некоторых проблемных ситуаций "can’t boot". Например, For example, initramfs ничем не хуже своей корневой файловой системы пользователей. Итак, она обладает исполняемыми файлами lvm , raid и относящимся к файловой системе, которые мы можем применить для обнаружения, сборки, диагностирования и исправления этой утраченой корневой файловой системы пользователя. После этого мы обсудим как мы можем смонтировать её в /sysroot и изучим её содержимое, скажем, для исправления неверных записей grub.cfg .

Более того, rd.break предоставляет нам различные варианты прерывания своей последовательности запуска на различных этапах.

cmdline : Эта особая точка входа получает установленные параметры командной строки ядра.

pre-udev : Прерывает нашу последовательность запуска перед обработчиком udev .

pre-trigger : Вы имеете возможность установить переменные среды udev со значением упрвления udevadm либо можете установить подобные --property=KEY=value параметры или управлять своим дальнейшим исполнением udev с udevadm .

pre-mount : Прерывает нашу последовательность перед монтированием нашей корневой файловой системы пользователя в /sysroot .

mount : Прерывает исполняемую последовательность запуска после монтирования установленной корневой файловой системы пользователя в /sysroot .

pre-pivot : Прерывет данную последовательность запуска непосредственно перед переключением на свою реальную корневую файловую систему.

Теперь давайте рассмотрим как в точности systemd управляет предоставлением нам соответствующих оболочек на этих различных этапах.

Каким образом systemd перебрасывает нас в аварийную оболочку?

Давайте рассмотрим некий пример особой точки входа pre-mount . Systemd из initramfs выбирает параметр командной строки rd.break=pre-mount из dracut-cmdline.service , и это запускает службу systemd dracut-pre-mount.service из местоположения initramfs /usr/lib/systemd/system . Эта служба запускается перед запуском initrd-root-fs.target , sysroot.mount и systemd-fsck-root.service .

Как вы можете видеть, это всего лишь исполнение сценария /bin/dracut-pre-mount из initramfs.

Внутри этого сценария /bin/dracut-pre-mount наиболее важной является следующая строка:

Мы уже обсуждали функцию getarg , которая применяется для проверки того какой параметр был передан в rd.break= . Как только был передан параметр rd.break=pre-mount , тогда будет вызвана только функция emergency-shell() . Эта функция определена в /usr/lib/dracut-lib.sh и она передаёт в неё pre-mount в качестве строкового параметра -n означает следующее:

Эта функция emergency_shell принимает для переменной _rdshell_name значение pre-mount .

Здесь -n рассматривается как первый аргумент ( $1 ), а pre-mount это второй аргумент ( $2 ). Поэтому _rdshell_name становится pre-mount .

После этого, в самом конце, это вызовет другую функцию _emergency_shell из того же самого файла (обратите внимание на подчёркивание перед самим названием функции). Как вы можете видеть, _rdshell_name выступает соответствующим аргументом для такой функции _emergency_shell .

_emergency_shell _name pre-mount

Та же самая строка pre-mount была передана в PS1 . Давайте вначале рассмотрим чем собственно является PS1 .

PS1 носит название псевдо переменной. Она будет отображена bash после того как соответствующий пользователь успешно зарегистрировался. Вот некий пример:

Значениями идеальных записей, принимаемых bash являются: PS1='\u:\w\$' .

u = значение имени пользователя.

w/code> = Это значение рабочего каталога.

Итак, в нашем случае, когда мы получаем некую аварийную оболочку, PS1 будет выведена на печать этой оболочкой следующим образом:

Далее в этом исходном коде вы можете наблюдать, что установленное новое значение переменной PS1 также добавляется в /etc/profile . Основная причина состоит в том, что bash считывает данный файл всякий раз перед предоставлением своей оболочки текущему пользователю. В самом конце мы просто запускаем dracut-emergency .

Ниже приводится содержимое файла dracut-emergency.service из usr/lib/systemd/system/ в initramfs.

Эта служба всего лишь выполняет /bin/dracut-emergency . Данный сценарий вначале останавливает запущенную службу plymouth .

Это запоминает текущим значением переменной hook emergency и вызывает соответствющую функцию source_hook с этим аргументом emergency .

Данная функция source_hook снова определена в usr/lib/dracut-lib.sh .

Значение переменной _dir перехватило значение название особой точки входа, коим выступает emergency . Все такие особые точки входа ничто иное, как некий пакет сценариев, хранимых и исполняемых из каталога /lib/dracut/hooks/ initramfs.

Для некой аварийной специальной точки входа исполняется usr/lib/dracut/hooks/emergency/50-plymouth-emergency.sh , который останавливает plymouth .

После выполнения особой точки входа и останова plymouth , выполняется возврат в bin/dracut-emergency и выдаётся на печать такой баннер:

Итак нет значения какое rd.break=hook_name было передано пользователем. Systemd выполнит соответствующую особую точку входа emergency и после вывода на печать надлежащего баннера он извлечёт тот каталог /etc/profile , в который мы добавили PS1=_rdshell_name/PS1=hook_name , а затем просто запустит свою оболочку bash.

Когда пользователь передаёт в rd.break какой- то иной параметр, скажем, initqueue , тогда он будет скормлен в переменные PS1 , _rdshell_name и hook . Позднее через соответствующую авариную службу будет вызван bash. Bash считает значение PS1 из файла /etc/profile и отобразит в своём приглашении имя initqueue .

Основное заключение состоит в том, что соответствующемы пользователю будет предоставляться одна и та же оболочка bash с различными именами приглашений ( cmdline , pre-mount , switch_root , pre-udev , emergency и т.п.), однако на различных этапах initramfs.

Аналогично этому, systemd будет исполняться rescue.target .

rescue.service и emergency.service

Блок-схема общей последовательности запуска

Параметр командной строки ядра

Это сбросит нас в некую аварийную оболочку. Этот однопользовательский режим, служба спасения и аварийная служба, все они запускают исполняемый файл dracut-emergency . Это тот же самый исполняемый файл, который мы запускали в особой точке входа dracut.

И, как нам известно, этот сценарий dracut-emergency запускает оболочку bash.

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

СОДЕРЖАНИЕ

Принятие

Fedora с версии 12, Константин
Red Hat Enterprise Linux, начиная с версии 6
openSUSE с версии 13.2, когда он стал инструментом создания initramfs по умолчанию
SUSE Linux Enterprise Server, начиная с версии 12

Дистрибутивы, которые включают dracut, но не используются по умолчанию для создания initramfs:

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Dracut - новое средство для создания initramfs в Fedora

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

Содержимое данного дневника не обязано Вам нравиться, как-то развлекать Вас или совпадать с Вашими мыслями и мнением.

Все авторские материалы данного дневника размещаются на условиях Creative Commons Attribution-Noncommercial-Share Alike 3.0 License (CC-BY-NC-SA).

В новой Fedora 12 появилось одно важное новшество, о котором хотелось бы поговорить. Разработчики Fedora (и Red Hat, стоящей за ней) решили-таки разрубить гордиев узел, который тянется еще со времен царя гороха и выкинуть из системы порядком устаревший скрипт mkinitrd, сменив заодно и «начинку» initramfs. Получившееся решение просто-таки прельщает своей красотой и стройностью. Но обо всем по порядку.

Сначала немного предыстории. Опытные администраторы могут сразу пропустить данный абзац и перейти в следующему. Поскольку дистрибутивное ядро Linux не может включать в себя все возможные драйвера, критичные для загрузки на всем возможном оборудовании, а также не может загружаться сразу с разных RAID-массивов, LVM или по NFS, то ему в помощь применяется специальный образ сжатой файловой системы, который называется Initial Ram Disk или сокращенно initrd. В современных дистрибутивах его заменил initramfs (Initial Ram Filesystem). С точки зрения администратора системы разницы между ними нет. Так вот в initramfs обычно встраиваются модули ядра, критичные для запуска системы (драйверы дискового контроллера, драйверы корневой файловой системы, а при необходимости и драйверы поддержки NFS, LVM и RAID) и специальный скрипт (называется или init или linuxrc), который и запускается на ранних стадиях загрузки и начинает искать раздел, несущий файловую систему. Именно он собирает софтовые RAID-массивы, активирует LVM и т.д и т.п. Затем, когда он находит корневую систему, то переключает корень системы на него (а на ранних стадиях роль временной корневой системы играет как раз initramfs) и дальше запускается системный init, который и ведет дальнейшую загрузку. Скорость инициализации в данном случае прямо скажем не ахти какая. RHEL достаточно известна своей неторопливой загрузкой.

Так что же решили сделать разработчики Dracut? Решение достаточно простое. Коль скоро при запуске системы все равно запускается udev, то и поиск корневой системы можно возложить на него. Более того, мы же все равно указываем корневой раздел в строке параметров ядра, поэтому и задача его поиска существенно упрощается. Теперь udev запускается прямо из initramfs, инициализирует все дисковые разделы, собирает RAID-массивы, LVM и т.п., а затем и передает управление скрипту, который находит корень и переключает дальнейшую загрузку на него. А то средство, которое и формирует новый initramfs назвали dracut. Причем, что здорово на мой взгляд, его опции для создания initramfs по-умолчанию аналогичны опциям хорошо известного администраторам RHEL и Fedora скрипта mkinitrd . Т.е. если раньше они для создания initramfs делали так:

mkinitrd /boot/ name_of_initramfs $(uname -r)

то теперь для этого нужно только поменять имя запускаемой команды:

dracut /boot/name_of_initramfs $(uname -r)

При запуске dracut определяет какие модули ему необходимы для загрузки системы и формирует новый initramfs. Модули для dracut расположены в /usr/share/dracut/modules.d/ :

Здесь мы видим набор директорий с модулями на все случаи жизни. Например, директория с правилами для LVM содержит следующее содержимое:

]$ ls -1 /usr/share/dracut/modules.d/90lvm/

PROGRAM=="/bin/sh -c 'for i in $sys/$devpath/holders/dm-6*; do [ -e $$i ] && exit 0; done; exit 1;' ", \

RUN+="/sbin/initqueue --settled --onetime --unique /sbin/lvm_scan"

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

Всю работу по управлению начальной загрузкой ведет скрипт init внутри initramfs, который сначала выполняет некоторую предварительную работу (создание предварительного окружения для запуска udev), затем запускает udev, обнаруживая корневую ФС и все устройства компьютера. Заканчивается данный скрипт переключением на корневой раздел, а дальнейшая загрузка практически ничем не отличается от прежней, т.е. теперь стадия обнаружения корневого раздела и его предварительной подготовки (сборка RAID, активация LVM или загрузка по сети через NFS) логичным образом совмещена со стадией обнаружения устройств. По оптимистичным заявлениям разработчиков Dracut теперь стало возможным (пока только теоретически) сократить длительность загрузки системы до 5 сек. Да и вообще Fedora здорово теперь прибавила в скорости запуска.

Опции для окружения, располагающегося внутри initramfs передаются через строку параметров ядра, которая теперь здорово увеличилась:

title Fedora (2.6.31.9-174.fc12.i686.PAE)

kernel /vmlinuz-2.6.31.9-174.fc12.i686.PAE ro \

SYSFONT=Cyr_a8x16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet \

initrd /initramfs-2.6.31.9-174.fc12.i686.PAE.im g

В частности здесь помимо указания корневой системы указана переменная LANG, задающая локаль по умолчанию для загружающейся системы, системный шрифт SYSFONT, параметры клавиатуры и запрет для активации зашифрованных дисков (опция rd_NO_LUKS). Последний параметр я спеуиально указал для того, чтобы во время запуска у меня не спрашивали пароль для разблокирования зашифрованного диска. Данный диск я подключаю вручную позже при необходимости. За списком всех возможных опций отправляю всех заинтересовавшихся в man dracut и на вики-страницу проекта Fedora, посвященную Dracut.

Читайте также: