Systemd в initramfs своими руками

switch_root(8) — это команда. pivot_root(2) — это системный вызов.

Реализация команды systemctl switch-root, как и команды switch_root, внутренне использует системный вызов pivot_root(). В initramfs на основе systemd, естественно, используется первая, но в обоих случаях init перезапускается.

зачем пихать в initramfs SystemD.

Chaser_Andrey уже рассказал: затем, чтобы обобщить процесс поиска и монтирования корневой ФС на различные конфигурации.

Ну так-то в XXI веке уже в моде терабайтники. Где этот порог, что 19 МиБ — много, а 5 МиБ — в самый раз?

Почему пересобирать initcpio при обновлении ядра раз в неделю — это нормально, а пересобирать initcpio при обновлении инита раз в два месяца — это вдруг плохо и ужасно?

Я тебе уже ответил, я не пересобираю initramfs при обновлении ядра.

Зачем его вообще пересобирать при грамотно настроенном ядре, там находится функционал, который нужен для монтирования корневой файловой системы, без разницы где она находится, просто на разделе, lvm томе, raid, плюс всё это ещё может быть зашифровано, весь этот функционал статичен, его нет смысла обновлять, обновление нужно только в случае, если нужно обновить версии, к примеру lvm, luks, и всё. Но обновлять его из-за того, что туда запихнули систему инициализации, смысла не вижу.

Самый просто init это:

mount /dev
mount /proc
mount /dev/root /new_root
umoount /proc
umount /dev
switch_root /new_root 3

Всё, зачем туда пихать систему инициализации? Если как ты говоришь ещё выполняется не pivot_root, при котором запущенный в initramfs процесс с pid 1 продолжает работать и далее при переключении в корневую фс, а switch_root, который запускает новый init, то это ещё больше лишает смысла всё это.

на версию systemd в initramfs в некотором смысле пофиг.

Если пофиг, то зачем он там, ведь что получается, запускается ядро, распаковывает initramfs, запускает SystemD, он монтирует корень и, видимо, выполняет switch_root, а это значит этот init процесс завершается, запускается новый процесс init с pid 1 из корневой фс. Так зачем вообще в таком случае его запускать? Целесообразнее, если уж там запускается SystemD выполнять pivot_root, это что бы хотя бы было хоть какое-нибудь оправдание всего этого.

Считай, что мне так нравится писать название этой системы инициализации.

Похоже на аргумент гуманитария. Мы же ведем техническую дискуссию?

весь этот функционал статичен

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

mount /dev/root /new_root

А кто этот симлинк, который /dev/root, создавать будет? А если он должен указывать не на /dev/sdXY, а на /dev/mapper/wtf/is/this/nested/encrypted/crap, и появляется этот девайс только после инициализации USB-хост-контроллера и втыкания флешдиска?

Там по-любому используются не дистры общего назначения. Там вообще самый минимум используют, причём не только в initramfs, но и в уже загруженной ОСи.

Что-то сильно сомневаюсь, распакуй, к примеру initramfs от Slax, там как раз используется pivot_root, посмотри.

Если процесс init всё таки перезапускается, в таком случае скажи, зачем пихать полноценную систему инициализации в initramfs, что бы она выполнила лишь mount /dev/root и затем смену корня.

Это всё излишества.

А кто этот симлинк, который /dev/root, создавать будет?

Строго говоря под /dev/root я как раз имел ввиду не ссылку, а конкретную файловую систему, будь то на разделе, lvm томе, raid, всё это ещё допустим зашифрованное, монтировать можно напрямую, если так уж хочется через ссылку, то после команд, необходимых для получения доступа к контейнеру корневой файловой системы и перед, собственно, командой монтирования можно добавить команду создания символьной ссылки /dev/root -> /dev/$container, необходимости иметь полноценную систему инициализации в initramfs из-за этого нет.

и появляется этот девайс только после инициализации USB-хост-контроллера и втыкания флешдиска?

Строго говоря всё это решается, необходимости наличия системы управления различными стартовыми сценариями (юнитами), уровнями запуска, логирования, прочего, на этапе работы initramfs нет.

mount /dev/root

Здесь уже несколько сообщений о том, что есть вещи посложнее, чем mount /dev/root, особенно, если root за несколькими слоями абстракции.

И она не исполняет _только_ смену корня.

http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

If an initrd is used it is a good idea to pass a few bits of runtime information from the initrd to systemd in order to avoid duplicate work and to provide performance data to the administrator.

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

Во-первых, в секции %post пакетов с обновой это прописать не так уж и трудно. В общем, так оно и должно делаться.

Во-вторых, проблема если и актуальна, то лишь на RR. Пользователи RR должны были знать, на что идут.

Это всё излишества.

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

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

там как раз используется pivot_root

Вполне вероятно. Есть ещё команда pivot_root(8). Она самая низкоуровневая из трёх, это тупо обёртка над системным вызовом.

зачем пихать полноценную систему инициализации в initramfs, что бы она выполнила лишь mount /dev/root

Я скажу это ещё раз: «mount /dev/root» могут поедшествовать действия любой степени сложности. И обобщённое выполнение таких действий — как раз то, ради чего создавались udev и (впоследствии) systemd.

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

Угу, SystemD в initrd, к примеру, для активации LVM вызывает:

vgchange -ay

без предварительной работы SystemD в initramfs не может определить, что уже активирована группа томов? Нет, это абсурд.

Не верно. systemd определяет, был запуск switch-root или его запустил другой init. Если не было switch-root из-под systemd из initramfs - то он сделает необходимое.

Проблемы нет. Если она всё же есть - то это баг, и нужно запостить на баг-трекер.

Я скажу это ещё раз: «mount /dev/root» могут поедшествовать действия любой степени сложности. И обобщённое выполнение таких действий — как раз то, ради чего создавались udev и (впоследствии) systemd.

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

Да, в некотором роде это удобно, т.к. уже написан один большой универсальный инструмент, но использовать его везде - это плохо, то же самое, как забивать гвоздь микроскопом, ну или мой пример в этом сообщении, так сказать можно, но он всё же не для этого придуман.

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

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

Да, именно так. Идёт развитие, что поделать. Страшно представить, что находится внутри прошивок современных SSD, UEFI, или даже в VGA BIOS.

Я уже написал, что всё это прекрасно делается обычным скриптом

Я тоже уже написал, что «обычный скрипт» придётся переписывать под каждую конфигурацию (или, по крайней мере, под каждый класс конфигураций), а systemd решает задачу обобщённо.

написан один большой универсальный инструмент, но использовать его везде - это плохо

Почему? Он не работает? Он создаёт проблемы?

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

Впрочем, этот же аргумент ты можешь применить, например, в таком вопросе: зачем для локалхоста для раздачи файлов через http поднимать высокотехнологичный и навороченный nginx, если можно обойтись простым, как доска, inetd и простеньким скриптом?

deterok, попробуй генерировать с помощью dracut, он простой и прозрачный.