LINUX.ORG.RU
ФорумTalks

Я понял почему гентушники не любят systemd

 ,


3

2

Давно собирался переехать со своей бывалой федоры на генту. Ну, как собирался: думал поставить на отдельный диск, душевно попиливать по тихой грусти, а когда будет готово уже и переехать.

Хотел поставить сразу с systemd, привык к нему на федоре, да и обучаться премудростям openRC было неохота, его кроме генты никто не использует. В процессе установки меня много раз посещало искренне удивление: как так-то? Неужели, блин, за столько времени нельзя было сделать все по-людски?

Это не то, чтобы пост для поплакаться, просто хочу поделиться впечатлениями, ну и гентоводов послушать, может я что-то не так понял. По старой привычке я /usr делаю отдельным разделом. Никакого технического обоснования нет, просто привычка.

Размечаю /boot, /boot/efi и большой PV на все остальное, создаю разделы, монтирую, делаю chroot, разворачиваю stage3, качаю ядро, конфигурю с поддержкой systemd и efistub. Пока все пучком. Надо ставить, собсно, systemd. Делаю emerge -av systemd, и хрен там был, udev блокирует, а emerge, понятное дело, слишком туп, в силу чего останавливается в растерянности, даже не делая попыток как-то помочь. Сношу udev, маскирую, делаю emerge -Nav virtual/udev systemd, вроде все завертелось. Пересобрал мир с -uDNav, заинсталлячил ядро и модули.

Теперь надо сделать initramfs, т.к. /usr на отдельном диске, и оно не заработает иначе. Ставлю genkernel, оно говорит, что поддержки systemd не будет и если таковая нужна, то надо ставить сабайоновский genkernel-next. Невелика беда, ставим, генерим рамдиск, копируем все хозяйство в \EFI\boot\gentoo. Прописываем все в EFI со всякими там root=, dolvm и прочими. Перезагружаемся, и тут начинается.

Ядро грузится, получает cmdline от EFI, находит группу томов и выпадает в кернел паник. Епрст, разрешение EFI фреймбуфера не позволяет увидеть что произошло, стек-трейс занимает весь экран. Что за бодяга, перекомпиляю ядро с DELAY_PRINTK, прописываю в EFI boot_delay=200, перезагружаюсь, жду пять минут пока раздуплится рамдиск, дожидаюсь паника и он опять проскакивает мгновенно и ни рожна понять не возможно.

Думаю, ладно, убираю boot_delay, ставлю debug, перезагружаюсь, попадаю в среду initramfs. Монтирую руками, все монтируется, и корень, и /usr, проверяю initramfs.mounts, проверяю fstab, все на месте, все парсится, все должно работать, но не работает.

Хрен с ним. Ставлю GRUB2, прописываю графический режим 1600х1200, убираю из ядра четверых пингвинов, которые полэкрана загораживают, делаю grub2-mkconfig, перезагружаюсь.

Понятное дело, что там «trying to kill init», я это подозревал. Интересна причина: «realpath: applet not found». Мало того, что эти утырки-майнтейнеры ставят systemd в /usr. Это, блин, надо было как минимум жопой думать, они бы еще ядро в /var/opt положили. Более того, в genkernel есть конфиг initramfs.mounts, в котором прописано какие точки монтирования из корневого fstab надо смонтировать из initramfs. По-умолчанию там стоит /usr, то есть, /usr должен монтироваться без всяких дополнительных телодвижений. Но есть одно «но». Дженкернеловские скрипты юзают realpath чтобы что-то там прочитать, девайс-ноды, видимо. Занятая коробка используется своя и пересобирается по конфигу каждый раз когда генерится initramfs. realpath в этом сраном конфиге выключен нафиг, таким образом, initramfs теряет способность что-либо монтировать кроме корня, пока ты не найдешь причину и не включишь в конфиге занятой коробки этот realpath. Очень gentooway-но: мы настроим пристаней с кораблями и заминируем нахер все подходы, чтобы никто никогда не смог подплыть. На это накладывается трудность диагностики ранних паников - буфер консоли уезжает. В результате получаем неочевидную и очень трудно-диагностируемую проблему.

В результате я включил realpath, все пересоздал, снес обратно GRUB2, перепрописал все в EFI и наконец получил заветный шелл. Осталось немного потрахаться с конфигурацией ядра (не уверен, что звуковухи подцепились) и все будет ОК.

Зато я понял почему те, кто сидит на генте, так не любят systemd. Просто в дистрибутиве все сделано через жопу. init ставится в /usr, одна генерилка рамдисков заброшена уже лет пять, вторая сломана, emerge слегка недалек и туповат.

Зато интересно. Надо будет продолжить, давно я такого удовольствия от техноложества не получал.

Ответ на: комментарий от a1batross

initrd в большинстве случаев вообще бесполезная сущность.

Согласен. Нужно только если:
1 boot splash
2 systemd и /usr на отдельной партиции
3 шифрованный корень
4 какое-то хитрое железо очень нужно для загрузки
5 другое

Лично я сталкивался c ним лишь 2 раза: по п 1. и по п 5 (делал кастомную сборку Knoppix)

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

Ну, бутсплэш как по мне лишний. Тем более, всё равно блобоюзерам не увидеть там нормальное разрешение экрана. %)

Второе — это проблемы только кривой архитектуры самого systemd.

Вот кстати, третье и четвертое реально нужно. Тут уже без него не обойтись.

a1batross ★★★★★
()
Ответ на: комментарий от alex_the_v

Я говорил о том, что ставить systemd в /usr - само по себе странное решение. В федоре systemd установлен в /.

lrwxrwxrwx. 1 root root 7 ноя 18 15:33 /bin -> usr/bin
lrwxrwxrwx. 1 root root 7 ноя 18 15:33 /lib -> usr/lib
lrwxrwxrwx. 1 root root 9 ноя 18 15:33 /lib64 -> usr/lib64
lrwxrwxrwx. 1 root root 8 ноя 18 15:33 /sbin -> usr/sbin

Что значит systemd установлен в /?

Ivan_qrt ★★★★★
()

у меня вообще нет разделов, grub2 в gentoo норм. грузит initramfs и btrfs rootfs

УМВР

armbox
()

Гентушник без systemd, но гента надоела и systemd параллелен.

Shadow1251
()
Ответ на: комментарий от daemonpnz
$ for file in /lib/systemd/systemd* /bin/systemctl /bin/journalctl; do ldd "$file"; done | grep dbus

$ systemctl --version
systemd 219
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

$ cd ~/devel/__external/systemd; git describe $(git merge-base origin/master build)
v219-605-g3c80009

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Ivan_qrt
^_^ m47261@5cg50803mb [~] $ realpath /lib/systemd/systemd
/usr/lib/systemd/systemd

Пипец, у меня крушение идеалов. Точняк, все в /usr. Блин, было же, вроде, в корне, я точно помню. Я тогда еще думал: «Вот пацаны ваще ребята, позаботились о нас, горемыках».

Ну, тогда все ок с гентой. genkernel-next починили, systemd в норме, emerge - няшка, кругом единороги блюют радугой.

alex_the_v ★★★
() автор топика
Ответ на: комментарий от alex_the_v

Справедливости ради отмечу, что оно умеет класть самое необходимое в корень, если сделать ./configure --enable-split-usr. Но при этом оно на каждом углу орёт, мол, вы всё равно не правы. Ну и отваливаются мелкие вещи вроде таймстампов загрузки, если часовой пояс не UTC.

intelfx ★★★★★
()
Ответ на: комментарий от eternal_sorrow

«ЧЯДНТ?» - используешь /usr на отдельном разделе.

Ага, ничего не могу с собой поделать.

//неосилятор dracut

Я имею странную склонность предпочитать родной инструментарий неродному, поэтому dracut даже не ставил. Официальная документация по initramfs говорит:

Warning
At the time of writing, dracut is not marked stable yet, so it may need unmasked before continuing.

То, что должно быть unmasked перед continuing, на мой взгляд лучше вообще не использовать, особенно когда есть альтернативы,

alex_the_v ★★★
() автор топика
Ответ на: комментарий от intelfx

Блин, а нафига вообще было так делать? Какова была изначальная мотивация класть все в /usr? Косяк же явный.

alex_the_v ★★★
() автор топика
Ответ на: комментарий от eternal_sorrow

А вообще, я вот что подумал. Надо мне будет засунуть /usr в корень, выкинуть в жопу этот initramfs целиком и не выеживаться. Тогда мои волосы будут более мягкими и шелковистыми.

Сегодня вечером замучу.

alex_the_v ★★★
() автор топика
Ответ на: комментарий от alex_the_v

Это не баг, это фича.

Они считают, что вся система должна быть в /usr (в идеале — пустой корень, читать сюда), а то, что требуется для первого этапа загрузки (т. е. «найти и подмонтировать /usr»), нужно класть в initramfs. Мотивация такая: заранее (на этапе построения дистрибутива) неизвестно, что потребуется в каждом конкретном случае для «первого этапа загрузки». Вдруг тебе половина системы нужна. А может быть и наоборот — нужны три с половиной бинарника, а остальное подтягивается по сети.

Если дизайн ОС выглядит как «минимальная система в корне, остальное в /usr», то в каждом из вышеописанных случаев придётся менять набор того, что лежит в корне. А это, на минуточку, пересборка затронутого софта с другим префиксом. initramfs же, напротив, можно «задёшево» кастомизировать до бесконечности.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от alex_the_v

initramfs — вообще вещь полезная. Без него, к примеру, ты не сможешь писать root=UUID=... (ну или root=/dev/disk/by-uuid/...) в командной строке ядра. Только /dev/sdXY. Аналогично с resume=.

Более того, если у тебя корневая ФС потенциально потребует fsck, то тебе придётся делать его из-под живой ФС, смонтированной в RO. Это вообще плохо.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от alex_the_v

родной инструментарий

и с каких пор genkernel-next родной?

Deleted
()
Ответ на: комментарий от eternal_sorrow

Воистину так. Вернул /usr в корень, но initramfs оставил - intelfx истину глаголет, полезная фича для рекавери.

Сконфигурил вчера ядро по-человечески, и у меня теперь стоит вопрос: это нормально, что при загрузке подключаются ваще все модули которые есть, включая всякие там inet6_sit, gre и прочая-прочая? modules-load.d пустой. Это мне опять в initramfs ходить?

alex_the_v ★★★
() автор топика
Ответ на: комментарий от intelfx

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

alex_the_v ★★★
() автор топика
Ответ на: комментарий от alex_the_v

это нормально, что при загрузке подключаются ваще все модули которые есть

нет, не нормально

Насчёт initramfs - я согласен, что оно может быть нужно. Лёня вроде говорил вроде даже, что оно ускоряет загрузку с systemd. Я собственно для того и пытался осилить dracut, чтоб проверить - правда или нет. но почему то он отказался загружаться у меня. Почему - быстро выяснить не удалось, а долго колупаться было лень. От genkernel-next отказался в первую очередь из за обилия у него ненужных зависимостей.

eternal_sorrow ★★★★★
()
Ответ на: комментарий от alex_the_v

Да тут сложный вопрос. С одной стороны, впиливать в каждую программу отдельную логику оверрайда конфигов («если есть конфиг в /etc, взять его, иначе взять из /usr») — это дублирование кода. Элегантнее было бы просто взять overlayfs (по сути, так логика оверрайда переносится на уровень VFS).

Но, с другой стороны, такой подход работает только в случае «stateless systems». Для обычных систем пользовательские модификации должны находиться на том же разделе, что и файлы, задающие исходное состояние системы; при этом обновления не должны трактоваться как пользовательские модификации, а сразу применяться к исходному состоянию. Не знаю, можно ли это сделать в рамках идеи «слоёной ФС».

intelfx ★★★★★
()
Ответ на: комментарий от eternal_sorrow

Уже нашел причину, просто нечаянно вкомпилил проблемные места в ядро. Я аж офигел когда сделал ip link от обилия всяких sit и прочей шняги, которую не юзаю.

Dracut - отличная штука, по крайней мере в редхатах. Насколько он хорош для генты мне непонятно. Будет время, надо будет попробовать. genkernel-next - не такая уж и отрава, а зависимости меня особо не парят, диска у меня достаточно. Засада с конфигурацией занятой коробки, конечно, обескураживает, но можно на это закрыть глаза.

alex_the_v ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.