На данный момент мы достигли своей службы ,
когда наша корневая файловая система пользователя ещё не смонтирована внутри initramfs. Следующая стадия запуска
systemd смонтирует эту корневую файловую систему в .
Sysroot. mount
systemd принимает параметр командной строки dracut , который
сбрасывает нас в аварийную оболочку -. Как вы видите на
Рисунке 9-1,
мы передали параметр командной строки ядра .
Как вы можете видеть на
Рисунке 9-2,
была смонтирована с корневой файловой системой пользователя в режиме
только для чтения.
Особая точка входа монтирования
Особая точка входа
() запустит надлежащий сценарий
из initramfs, который и выполнит необходимую часть
монтирования.
Как вы можете видеть, этот выполняет сценарий из iniramfs
и к тому же экспортирует соответствующую переменную со значением
.
В Главе 8 мы увидели как именно это сбрасывает нас в некую
аварийную оболочку и все связанные функции этого. Так как мы остановили свою последовательность запуска после
монтирования необходимой корневой файловой системы внутри initramfs, как вы можете обнаружить на
Рисунке 9-3,
наш уже был выполнен и уже были созданы файлы элементов
.
Поведение нашего systemd-fstab-generator
Помните, что значение названия корневой файловой системы в
было взято из соответствующего файла . Сам
чётко указывает что следует монтировать и где это надлежит
монтировать.
Initrd. target
Как мы уже говорили много раз, конечная цель рассматриваемой последовательности запуска состоит в предоставлении
корневой файловой системы пользователя самому пользователю и при выполнении этого основные достигаемые systemd
стадии таковы:
Как вы можете видеть, на данный момент мы достигли этапа 2, коим выступает монтирование необходимой корневой
файловой системы пользователя. Мы знаем, что systemd имеет , а
это ни что иное, как пакет файлов элементов. Такой
может быть успешно запущен только когда все эти файлы элементов
были успешно запущены.
Наша последовательность запуска
Обычно эта служба выполняет с неким переключателем
. Это перезапускает установленную конфигурацию диспетчера
systemd. Что перезапустит все генераторы, перезагрузит все файлы элементов и повторно создаст всё дерево
зависимостей целиком. В то время как этот демон перезапускается, будут оставаться доступными все сокеты, в которых
systemd от имени пользователя выполняет ожидание. Те генераторы, которые повторно исполняет systemd таковы:
# ls usr/lib/systemd/system-generators/ -l
total 92
-rwxr-xr-x. 1 root root 3750 Jan 10 19:18 dracut-rootfs-generator
-rwxr-xr-x. 1 root root 45640 Dec 21 12:19 systemd-fstab-generator
-rwxr-xr-x. 1 root root 37032 Dec 21 12:19 systemd-gpt-auto-generator
Как вы можете видеть, это выполнит , который считает
записи и создаст необходимые монтируемые файлы элементов
для и для устройств, обладающих установленным параметром
. Короче говоря,
исполняется дважды.
Поэтому когда вы сваливаете себя в соответствующую оболочку монтирования
(), вы на самом деле прерываете свою последовательность
запуска после соответствующей . Эта цель запускает всего лишь
такие службы:
# ls usr/lib/systemd/system/initrd.target.wants/
dracut-cmdline-ask.service dracut-mount.service dracut-pre-trigger.service
dracut-cmdline.service dracut-pre-mount.service dracut-pre-udev.service
dracut-initqueue.service dracut-pre-pivot.service
Для понимания всего этого обращаем ваше внимание на
Рисунок 9-5.
Общее исполнение initrd.target
Switch_root/pivot_root
Теперь мы достигли окончательного этапа запуска systemd, коим выступает .
Systemd переключает свою корневую файловую систему с initramfs () на
смонтированную корневую файловую систему пользователя (). Systemd
достигает этого предпринимая следующие шаги:
Имеются три основных момента, которые мы обсудим в данной главе:
Переключение к файловой системе Нового корня в системе на основе init
Основанная на init система применяет для переключения на
некую новую корневую файловую систему (). Основная цель
достаточно хорошо поясняется в её странице руководства, отображаемой
здесь:
Итак, это переключает в некую новую корневую файловую систему ()
и совместно с самим корнем это перемещает все старые виртуальные фаловые системы корневой файловой системы
(, ,
и т.п.) в свой новый корень. Наилучшая функциональная возможность
состоит в том, что после монтирования своей новой корневой
файловой системы она запускает сам процесс в ней самой. Переключение в
новую корневую файловую систему имеет место в исходном коде dracut. Самой
версией dracut на момент написания этих строк была
. Функция определяется
в файле .
В нашем предыдущем коде вы можете обнаружить, что
вызывалось в точности так, как это было описано в странице руководства .
Определяемыми значениями переменных для и
выступают такие:
NEWROOT = «/sysroot»
INIT = ‘init’ or ‘sbin/init’
Просто для вашего сведения, в наши дни этот файл выступает
для .
Для успешного всех виртуальных файловых систем они прежде
всего должны быть смонтированы. Это достигается через
. Имеются определённые этапы и они
таковы:
Переключение к файловой системе Нового корня в системе на основе systemd
Необходимые шаги почти такие же как и те, что мы обсуждали для систем на основании .
Единственным отличием для является то, что его исполняемый код сделан
на C. Поэтому, очевидно, переключение своего корня имеет место в исходном коде C systemd, что отражено тут:
Вначале рассмотрим следующее:
new_root = sysroot
old_root = /
Это переместит все те виртуальные файловые системы, которыми уже была наполнена корневая файловая система
initramfs; затем функция проверит доступен ли путь
.
if (path_equal(new_root, «/»))
return 0;
Позднее вызывается syscall (
применяет ) и изменяет текущий корень с
(корневой файловой системы самой initramfs) на
(настраиваемая корневая файловая система пользователя).
Прежде чем мы двинемся далее, нам требуется разобраться с тем что из себя представляет
и что она делает.
# man pivot_root
NAME
pivot_root — изменяет текущую корневую файловую систему
SYNOPSIS
pivot_root new_root put_old
DESCRIPTION
pivot_root перемещает собственную корневую файловую систему текущего процесса в каталог put_old и создаёт новую корневую файловую систему new_root. Поскольку pivot_root(8) просто вызывает pivot_root(2), для дополнительных сведений мы отсылаем к соответствующей странице руководства:
Обратите внимание, что в зависимости от реализации
pivot_root, root и cwd вызывающей стороны могут измениться, а могут остаться прежними. Ниже приводится
последовательность для вызова pivot_root, которая работает в любом случае в предположении что pivot_root и
chroot пребывают в текущем PATH:
pivot_root . put_old
exec chroot . command
Заметьте, что chroot обязан быть доступным в своём старом
корне, а также и в новом корне, ибо pivot_root может обладать, а может и нет в явном виде изменённым значением
корневого каталога своей оболочки.
Обратите внимание, что выполнение chroot изменяет запущенный
исполняемый файл, что необходимо когда его старый корневой каталог должен быть размонтирован после всего. Также
отметьте, что стандартные input, output и error могут всё ещё указывать на некое устройство своей старой корневой
файловой системе, сохраняя их занятыми. Их запросто можно заменить при вызове chroot (см. далее; обратите внимание на
отсутствие начальных косых черт, чтобы это работало независимо от того изменил pivot_root корень своей оболочки или
нет).
изменяет свою корневую файловую систему (корневую файловую
систему самого initramfs) текущего процесса (systemd) на новую корневую файловую систему
(), а также он изменяет сам запущенный исполняемый файл
(systemd из initramfs) на новый (systemd из корневой файловой системы пользователя).
После успешного вот наше текущее состояние:
Наконец, удаляем устройство
().
Здесь мы успешно переключились на корневую файловую систему пользователя и покинули свою среду initramfs. Теперь
начинает выполнение с systemd из корневой файловой системы пользователя и
он заботится обо всей остающейся процедуре запуска, которая такова:
Но что происходит с тем имеющимся процессом , который стартовал
из initramfs (своей корневой файловой системы)? Убивается ли он после
или ? Запускается ли из созданной корневой файловой системы
пользователя новый ?
Надеюсь, вы удовлетворены знакомством systemd внутри initramfs. Как мы уже упоминали ранее, вся остающаяся
последовательность запуска systemd, которая будет происходить вне initramfs, будет более или менее походить на то,
что мы обсуждали до сих пор.
Как запускается GUI выходит за рамки данной книги. В своей следующей главе мы обсудим образы live ISO, а
также аварийный режим.
