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

Зачем, он будет слишком громоздкий, можете «расковырять» initramfs от Fedora, они там как раз используют Systemd, но всё же для initramfs лучше использовать простой init скрипт на bash.

Нет, не будет слишком громоздким.

В федоре для генерации его dracut используют, кстати.

Ничего себе негромоздкий, посмотрите initrd с LiveCD Fedora, например, 20 версии.

Вот размер initrd образа:

30M -rw-r--r-- 1 konstantin konstantin 30M дек 12  2013 initrd0.img

Вот размер директорий в initramfs:

du -xsh ./*
0	./bin
0	./dev
824K	./etc
0	./init
0	./lib
0	./proc
0	./root
0	./run
0	./sbin
4.0K	./shutdown
0	./sys
0	./sysroot
0	./tmp
69M	./usr
0	./var

Вот размер директории с модулями ядра:

du -xsh usr/lib/modules
21M	usr/lib/modules

А точно systemd занимает? В Росе тоже systemd в initramfs, размер образа

9817549 ноя 30 21:22 initrd-3.14.25-nrj-desktop-1rosa.img

du -xsh ./*
2,9M ./bin
4,0K ./dev
268K ./etc
0 ./init
12M ./lib
7,8M ./lib64
4,0K ./proc
4,0K ./root
4,0K ./run
2,1M ./sbin
4,0K ./shutdown
4,0K ./sys
4,0K ./sysroot
4,0K ./tmp
3,0M ./usr
4,0K ./var

initramfs из fedora 21:

ls -l /boot/initramfs-`uname -r`.img
-rw-r--r-- 1 root root 19553227 ноя 27 10:50 /boot/initramfs-3.17.4-300.fc21.x86_64.img

dracut -a systemd не то, что ты ищешь?

19 Мб, многовато.

Всё равно много, если в lib находится директория с модулями ядра, то в lib64 - библиотеки для работы systemd, его зависимости, всё равно много. Целых 9,5 Мб занимает запакованный образ.

kostik87 Да тут такой косяк произошел...

Систему устанавливал с нуля.

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

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

Погляди в пакет systemd из арча, там есть одноимённый хук для mkinitcpio. Собственно, погляди туда.

19 Мб, многовато.

Простите, я мимо шёл, для чего многовато? У меня 16 МБ на 7 центосе. Плохо? :)

Туфта все это, необращай внимания, ни на что-толком не влияет.

грузишся с дискетки?

ls -lh /boot/initramfs*
-rw-------. 1 root root 24M Mar 21  2014 /boot/initramfs-0-rescue-2d60315531d6490297c146d9f1d42323.img
-rw-r--r--. 1 root root 19M Oct 27 13:36 /boot/initramfs-3.17.1-304.fc21.x86_64.img
-rw-r--r--. 1 root root 19M Nov  8 10:11 /boot/initramfs-3.17.2-300.fc21.x86_64.img

49 MB

В моём случае размер /lib без модулей (в initcpio) составляет 11 MB.

Не слушайте kostik87, возможно, он просто неопытный пользователь systemd, во всяком случае, его пример на 70 Мб крайне неудачен, как и заявления о жирности systemd.

У меня Gentoo, initramfs генерируется с помощью dracut вот такой командой, ничего особенного:

dracut -m "base crypt dm kernel-modules lvm rootfs-block systemd udev-rules" '' 3.16.0-rc6 --force --fstab -M -v

Размер запакованого initramfs - 11 Мб, сам каталог /usr/lib/systemd занимает 3.3 Мб.

Больше всего места (8 Мб) у меня занимают утилиты для device-mapper.

UPD: распакованый initramfs занимает 30 Мб, но там много чего можно выбросить, например, device-mapper и библиотеки для шифрования, если не используется luks. Во всяком случае, это не имеет отношения к systemd.

Шёл 2014 год. Жёсткие диски по 2+тб и 8+гб оперативки. Пользователи лора считают мегабайты.

Забываешь про embedded.

У меня Gentoo с OpenRC, с initramfs без модулей, занимающий всего 1,5 мегабайт места в запакованном виде, в распакованном будет 3.5, в случае самопального initramfs даже с lvm будет ещё меньше.

Ну, у меня юзаются и модули, и device-mapper, и lvm, и шифрование. В любом случае, в чём проблема, что systemd занимает 3.3 Мб, если память освобождается после pivot_root, т.е., в момент переключения загрузки на настоящий корень?

Больше считывается с диска, в случае HDD или USB, которую BIOS инициализирует как USB1, а лишь уже после инициализации USB ядром системы она становится USB2.0, а так же при загрузке по сети это всё ненужные мегабайты, вот скажи зачем в initramfs нужна целая система инициализации? Там нужно всего функционала смонтировать корневую файловую систему и далее выполнить смену корня, а после смены корня запускай уже что хочешь, хоть SystemD. Для монтирования корневой ФС и выполнения switch_root или pivot_root достаточно bash сценария.

ИТТ мы меряемся размерами рамфс?

# ls -hl /boot/initramfs_3.16.6-geek-i5_x86_64.cpio.xz 
-rw-r--r-- 1 root root 2.2M окт 24 11:27 /boot/initramfs_3.16.6-geek-i5_x86_64.cpio.xz

# ls **
bin/busybox                 lib64/libuuid.so.1
etc/profile                 lib/modules/3.16.6-geek-i5/kernel/drivers/usb/host/ehci-hcd.ko
init                        lib/modules/3.16.6-geek-i5/kernel/drivers/usb/host/ehci-pci.ko
lib64/ld-linux-x86-64.so.2  README
lib64/libblkid.so.1         sbin/badblocks
lib64/libcom_err.so.2       sbin/e2fsck
lib64/libc.so.6             sbin/fdisk
lib64/libe2p.so.2           sbin/fsck
lib64/libext2fs.so.2        sbin/mke2fs
lib64/libmount.so.1         usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1
lib64/libm.so.6             usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6
lib64/libpthread.so.0       usr/sbin/smartctl
lib64/libsmartcols.so.1

А, ну и в распакованном виде

# du -hscx ./*
1.8M    ./bin
0       ./dev
4.0K    ./etc
4.0K    ./init
72K     ./lib
3.9M    ./lib64
0       ./mnt
0       ./proc
4.0K    ./README
0       ./root
672K    ./sbin
0       ./sys
1.5M    ./usr
7.8M    total

USB, которую BIOS инициализирует как USB1, а лишь уже после инициализации USB ядром системы она становится USB2.0

Отчасти правда, но сейчас такое редко встречается. Ещё в материнках 2006 года нередко видел в BIOS поддержку USB2.0.

вот скажи зачем в initramfs нужна целая система инициализации?

Я не скажу, что это нужно _обязательно_ всем, но

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

Это только в самом простом (но распространенном случае).

Вот тебе описание, что делает мой initramfs:

• запускает device-mapper
• запускает софтварный raid
• запускает LUKS
• ищет LUKS-header на USB (на моих личных компах)
• настраивает сеть с двумя провайдерами (тут же сразу и роутинг, и правила iptables для защиты от DoS-атак на sshd)
• поднимает sshd
• ожидает ввода пароля для LUKS (в терминале или по сети через любого доступного провайдера), а также ищет ключ на USB
• после открытия криптоконтейнера находит LVM-том с рутовым разделом
• (опционально) цепляет /var и/или /home по NFS.
• pivot_root

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

Юзкейсов может быть и больше, ведь я не настраивал ещё multipath, iscsi и т.д.

Кстати, неправильно systemd называть SystemD.

Возможно, кто-то захочет такую же схему, то имейте ввиду, что на момент написания этого коммента ванильный systemd не поддерживает отдельные header для LUKS. Но я отправил патч в апстрим https://www.libreoffice.org/bugzilla/show_bug.cgi?id=66396

Его ещё нужно причесать, тем не менее, он рабочий.

SystemD

бить ногами!

запускает device-mapper запускает софтварный raid запускает LUKS ищет LUKS-header на USB (на моих личных компах) настраивает сеть с двумя провайдерами (тут же сразу и роутинг, и правила iptables для защиты от DoS-атак на sshd) поднимает sshd ожидает ввода пароля для LUKS (в терминале или по сети через любого доступного провайдера), а также ищет ключ на USB после открытия криптоконтейнера находит LVM-том с рутовым разделом (опционально) цепляет /var и/или /home по NFS. pivot_root

Для этого всего SystemD не нужен.

Почему? Он справляется с этими задачами. Я же не утверждаю, что это может решить только systemd. Но зачем мне городить кучу разных init-ов, если я могу юзать один универсальный. Тем более, как я сказал, никакого пенальти после pivot_root нет. Что ж, 3.3 Мб при чтении с HDD/USB я переживу, на фоне тяжелых libgcrypt, openssl и device-mapper это мало.

И перестань его называть SystemD, это неправильное написание названия. Ты уподобляешься тем, кто пишет Qt как QT.

Это лёгкий троллинг такой, как я понял.

Какая разницы как его называть, если я даже напишу SyStEmD ты всё равно поймёшь.

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

Но зачем мне городить кучу разных init-ов, если я могу юзать один универсальный

И ты не можешь написать его в одном файле на ash?

Скажи спасибо, что он зовёт это не «систем-пять-сотен» или «систем-сто-пять-раз».

Какая разницы как его называть

Разница в том, что systemd есть, а SystemD - нет.

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

Spelling

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with systemd. On high holidays you may also spell it sÿstëmd. But then again, Système D is not an acceptable spelling and something completely different (though kinda fitting).

Могу. Зачем?

Уважаемый, я не вижу разницы для восприятия, при прочтении слова написанного вот так «SystemD», так «Systemd» и вот так «systemd».

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

Не надо создавать проблем на ровном месте.

Т.е. получается, вы обновляете систему инициализации, скажем была версия 215, вы обновили систему и версия стала 216, в таком случае заместо простого обновления файлов системы инициализации только собственно в системе, вам нужно обновить ещё и initramfs, потому что система инициализации у вас запускается ещё на этапе работы initrd.

Ну бред же.

Тащить ради линейного алгоритма систему инициализации и разводить файлопомойку в напёрстке удобнее, чем иметь этот алгоритм в одном файле?

Узнаю ЛОР. Только здесь неиспользуемые фичи любого софта автоматически переходят в разряд нежелательных.

Получается, я обновляю ядро (скажем, была версия 3.x.y, стала версия 3.x.y+1) и помимо обновления файлов ядра в системе, мне нужно обновить ещё и initramfs. Бред же! >.<

К слову, патчлевел ядра меняется каждую неделю, а время между релизами systemd — полтора-два месяца.

Удобство — вещь субъективная. Но сделать так, чтобы этот «алгоритм» строился и исполнялся автоматически (или не исполнялся, если конфигурация внезапно сменится и вдруг будет найден простой корневой раздел с нужной меткой) правильнее, чем хардкодить.

А если не хардкодить, то твой скрипт на ash разрастётся до 9KLOC и ты зареимплементишь половину ядра systemd.

Получается, я обновляю ядро (скажем, была версия 3.x.y, стала версия 3.x.y+1) и помимо обновления файлов ядра в системе, мне нужно обновить ещё и initramfs

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

А у вас получается то, что получается, не нужно системе инициализации быть в initramfs.

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

заместо простого обновления файлов системы инициализации только собственно в системе, вам нужно обновить ещё и initramfs, потому что система инициализации у вас запускается ещё на этапе работы initrd

Можно, но не обязательно. systemd в initramfs вполне самодостаточен. Лично я делаю обновление initramfs только по необходимости (новое ядро, новые модули, важные фиксы в используемом ПО).

Угу, т.е. у тебя выполняется pivot_root, по факту init процесс запущенный из Initramfs так и продолжает работать, а в initramfs у тебя версия SystemD, к примеру 215, а в системе у тебя версия 216. Я конечно понимаю, что, скорее всего, программисты RedHat всё пишут «правильно», но возможны проблемы. Вот поэтому и не нужно пихать в initramfs то, что должно быть в корневой ФС и ни где больше.

Уважаемый, я не вижу разницы для восприятия, при прочтении слова написанного вот так «SystemD», так «Systemd» и вот так «systemd».

Это разные названия, ибо case-sensivity. Странно, что даже после скинутой цитаты мне приходится ещё раз это объяснять, да ещё и технарю. Ладно, если бы ты был гуманитарием...

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

Угу, т.е. у тебя выполняется pivot_root, по факту init процесс запущенный из Initramfs так и продолжает работать

http://www.freedesktop.org/software/systemd/man/systemctl.html#switch-root RO...

«Switches to a different root directory and executes a new system manager process below it.»

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

Его вообще можно пересобирать хоть каждый день по крону, один фиг это скрипт делает.

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

Есть pivot_root, а есть switch_root, теперь давай разберёмся что вызывается из initramfs.

pivot_root работает так как я описал.

Если в initramfs в Fedora, к примеру находится SystemD и вызывается switch_root, а не pivot_root, то я тем более не понимаю зачем пихать в initramfs SystemD.