Зачем, он будет слишком громоздкий, можете «расковырять» initramfs от Fedora, они там как раз используют Systemd, но всё же для initramfs лучше использовать простой init скрипт на bash.
Всё равно много, если в lib находится директория с модулями ядра, то в lib64 - библиотеки для работы systemd, его зависимости, всё равно много. Целых 9,5 Мб занимает запакованный образ.
В общем у меня какого-то черта перестали монтироваться устройства(т.е. система ждет пока не смонтируются разделы из fstab'а, этого за 1.5 минуты не происходит и система вываливается в консоль востановления). Хотя делал все как и раньше...
Неробит... Сначала происходит чудной косяк, он ищет какую-то чудную версию ядра, пришлось указывать. В итоге что-то идет не так, и история повторяется как описано выше.
Не слушайте kostik87, возможно, он просто неопытный пользователь systemd, во всяком случае, его пример на 70 Мб крайне неудачен, как и заявления о жирности systemd.
У меня Gentoo, initramfs генерируется с помощью dracut вот такой командой, ничего особенного:
Размер запакованого initramfs - 11 Мб, сам каталог /usr/lib/systemd занимает 3.3 Мб.
Больше всего места (8 Мб) у меня занимают утилиты для device-mapper.
UPD: распакованый initramfs занимает 30 Мб, но там много чего можно выбросить, например, device-mapper и библиотеки для шифрования, если не используется luks. Во всяком случае, это не имеет отношения к systemd.
У меня 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 сценария.
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 не поддерживает отдельные header для LUKS. Но я отправил патч в апстрим https://www.libreoffice.org/bugzilla/show_bug.cgi?id=66396
Его ещё нужно причесать, тем не менее, он рабочий.
запускает device-mapper
запускает софтварный raid
запускает LUKS
ищет LUKS-header на USB (на моих личных компах)
настраивает сеть с двумя провайдерами (тут же сразу и роутинг, и правила iptables для защиты от DoS-атак на sshd)
поднимает sshd
ожидает ввода пароля для LUKS (в терминале или по сети через любого доступного провайдера), а также ищет ключ на USB
после открытия криптоконтейнера находит LVM-том с рутовым разделом
(опционально) цепляет /var и/или /home по NFS.
pivot_root
Почему? Он справляется с этими задачами. Я же не утверждаю, что это может решить только systemd. Но зачем мне городить кучу разных init-ов, если я могу юзать один универсальный. Тем более, как я сказал, никакого пенальти после pivot_root нет. Что ж, 3.3 Мб при чтении с HDD/USB я переживу, на фоне тяжелых libgcrypt, openssl и device-mapper это мало.
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).
Т.е. получается, вы обновляете систему инициализации, скажем была версия 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. Странно, что даже после скинутой цитаты мне приходится ещё раз это объяснять, да ещё и технарю. Ладно, если бы ты был гуманитарием...
Я не путаю ситуации, я применяю ту же логику. Почему пересобирать initcpio при обновлении ядра раз в неделю — это нормально, а пересобирать initcpio при обновлении инита раз в два месяца — это вдруг плохо и ужасно?
Его вообще можно пересобирать хоть каждый день по крону, один фиг это скрипт делает.
Более того, как правильно заметил Chaser_Andrey, на версию systemd в initramfs в некотором смысле пофиг.
Есть pivot_root, а есть switch_root, теперь давай разберёмся что вызывается из initramfs.
pivot_root работает так как я описал.
Если в initramfs в Fedora, к примеру находится SystemD и вызывается switch_root, а не pivot_root, то я тем более не понимаю зачем пихать в initramfs SystemD.