Ранее мне было неясно, чем genkernel-next отличается от Dracut. Сейчас я думаю, что genkernel-next недоработан, потому что почти нигде не используется. А утилита командной строки dracut используется для сборки initrd для многих операционных систем (Fedora, Debian, Gentoo - то есть все форматы пакетов - rpm, deb, ebuild). К сожалению, на википедии страница про dracut не переведена на русский язык.
Я предполагаю, что ключевая разница между этими двумя утилитами заключается в том, что dracut умеет помещать systemd внутрь initrd, а genkernel-next не умеет. Мне было непонятно, как будут уживаться два systemd, один из которых запущен их initrd, а другой запускается с корневой файловой системы. Полегчало, когда случайно в интернете увидил команду systemctl switch-root
switch-root ROOT [INIT]
Switches to a different root directory and executes a new system manager process below it. This is intended for usage in initial RAM disks ("initrd"), and will transition from the initrd's system manager process (a.k.a. "init" process) to the main system manager process which is loaded from the actual host volume. This call takes two arguments: the directory that is to become the new root directory, and the path to the new system manager binary below it to execute as PID 1. If the latter is omitted or the empty string, a systemd binary will automatically be searched for and used as init. If the system manager path is omitted, equal to the empty string or identical to the path to the systemd binary, the state of the initrd's system manager process is passed to the main system manager, which allows later introspection of the state of the services involved in the initrd boot phase.
Я так и не понял, что происходит с тем systemd, который из initramfs - он завершается, или засыпает на время, что сработать в момент выполнения shutdown, но перестал беспокоиться на эту тему.
genkernel-next имеет плохую документацию, в частности там не написано чётко и ясно, в чём риск настройки
# Run 'make mrproper' before configuration/compilation?
MRPROPER="no"
без этой настройки сборка ядра со всеми модулями занимает много времени (примерно полчаса). Мучительно больно обнаружить, что в конце сборки не найден файл при копировании одного из скриптов udev для lvm. Таких скриптов там примерно десяток, и это приводит к потере трёх часов времени на выполнение команды touch для отсутствующего файла, и затем на запуск команды genkernel all по-новой.
Не всегда возможно воспользоваться программой qemu для тестирования загрузки (например потому что текущее ядро может быть взято со старой флешки для восстановления системы, и не поддерживать модуль kvm). Это означает, что тестировать правильность формирования initramfs надо путём перезагрузки реального железа, что выполняется гораздо дольше.
При запуске у меня возникла проблема: ядро не обнаруживает жесткие диски при запуске, не формируются устройства /dev/sd*, а затем происходит вываливание в busybox, откуда ничего сделать уже нельзя. Похоже, что initramfs при этом не выполняется, вместе с его udev. Отдельно я бы хотел заметить, что использование busybox на текущем этапе развития вычислительной техники определённо идёт во вред. Это экономия за счёт пользователя нескольких байтов пространства, которая урезает возможности пользователя и удлиняет время обучения и отладки. Было бы гораздо лучше, если бы в initramfs по-умолчанию был стандартный bash и все утилиты, которые могут понадобится для работы с дисками, и совершенно неважно, какого они размера.
Также, очень плохо во всех интернет-материалах, что они не пролинкованы между собой. При сборке initramfs очень помогли бы гиперссылки на статьи про то, как отлаживают загрузку ядра, и как отлаживают сам initrd, какие параметры запуска можно в ядро передавать (например «debug»).
Собственно суть проблемы: собранное при помощи genkernel-next ядро с initrd не стартует. С dracut тоже не собирается. Два года назад я начал копировать ядро с initramfs из дистрибутива sabayon готовое. Это быстро, удобно. Но есть трудность: при возникновении проблем с gentoo люди просят логи emerge. А там написано, что используется ядро sabayon. И gentoo-шники встают в позу «ты пользуешься sabayon, туда и иди». Хотя от сабайона там давно только одно ядро.
Так же хотел бы высказаться по поводу модерирования на LOR. Некоторые участники форума выдвигают гипотезы, например о том, что я думаю «что мне все должны». Я так не думаю. Эти участники форума ошибаются, выдвигают ошибочные гипотезы. Я думаю по-другому (но всё равно не так, как они хотели бы, чтобы я думал). Однако модераторы поддаются на влияние неправильно думающих участников и стирают темы, содержащие полезную техническую информацию о проблемах, которая могла бы помочь другим пользователям (это я про ошибку при сборке firefox). Я понимаю, что модераторы тоже имеют право быть ТАКИМИ, это же LOR.
