Долгая загрузка initramfs

Образ гибернации тоже грузится уже после загруженного initramfs. Так что если он быстрее, то 5 секунд это не загрузка initramfs а что-то уже после. Можешь его (initramfs) распаковать, насувать туда отладочных echo о разных этапах работы, и собрать назад. Или может такой режим у него уже есть и надо только включить как-то.

А почему всё примерно? Лень снять видео и точно определить? ·

Не уверен что это именно тот случай, но у меня была такая история: дебиан, системд, биос, граб0. ССД, бут отдельно, корень нешифрованый, /home шифрованый, своп-раздел шифрованый случайным ключом, LUKS через crypttab. Загрузка биоса, граба, ядра, initrd нормально, потом ~0,5c пара каких то ранних событий, потом ожидание ~15-30c и только потом запрос пароля для /home и уже после этого нормальная загрузка системы.

Оказалось что это ожидание своп-устройства (которое появится позднее) чтобы проверить его на образ гибернации, стандартное поведение системд в дебиане 9-11 (может и остальных тоже). Отключил это ожидание, система стала грузиться на эти 15-30с быстрее. Как делал не помню, когда понял причину - нагуглил параметр, сделал и забыл.

Если своп шифрованный, то, может быть, для вас это будет релевантно: https://askubuntu.com/a/1013935/517402

«Нечего на зеркало пенять, коли рожа крива.»

5 секунд смотрю на сплешскрин Леновы…7-8 секунд проходит до появления промпта LUKS… образ гибернации…Initramfs упакован lz4…

Сделано все, чтобы было медленно…

Чем меньше интрамфс - тем быстрее загружается. Оставь в нем только то, что действительно необходимо. Плюс, самое «низкозатратное сжатие».

Так вроде есть давно systemd-bootchart, к чему этот пердолинг с расстановкой echo?

Причём тут ненужнод? В initramfs его ещё в счастью не засунули.

В образах, которые dracut генерит, уже есть.

есть давно systemd-bootchart, к чему этот пердолинг с

Если с ним загрузчик будет работать так же, как разрешение зависимостей и построение порядка загрузки, то НУ ЕГО НА ЙУХ.

Я себе сплешскрин отключил, потому что мелькает так быстро что все равно его не разглядеть. Можно как то увеличить время загрузки чтобы насладится красивым сплешскрином?

systemd-analyze Startup finished in 18.036s (kernel) + 2.601s (userspace) = 20.637s graphical.target reached after 2.600s in userspace

все что смог придумать это включить принудительную проверку корневого диска при каждом буте. ноут asus k56

Написать юнит, который как-то тормознёт параллельность загрузки сервисов и отчитает нужное количество секунд?

systemd-analyze critical-chain

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2.600s
└─udisks2.service @1.522s +1.077s
  └─basic.target @1.495s
    └─sockets.target @1.494s
      └─dbus.socket @1.494s
        └─sysinit.target @1.491s
          └─systemd-timesyncd.service @1.343s +147ms
            └─systemd-tmpfiles-setup.service @1.141s +199ms
              └─systemd-journal-flush.service @701ms +438ms
                └─systemd-journald.service @593ms +106ms
                  └─systemd-journald.socket @567ms
                    └─-.mount @559ms
                      └─-.slice @559ms

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

прямо в плюмаух юнит да? или тама есть штатная средства?

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

Кстати, может есть штатное средство запретить сервисам загружаться параллельно?

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

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

а куча бегущих строк на экране очень впечатляет всех окружающих )))

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

монтируй недоступный сетевой ресурс