Проблему пока получилось воспроизвести только, когда внутри luks файловая система btrfs c subvolumes. На nvme+luks+ext4 проблема не воспроизвелась.

(Ответ для Антон Мидюков на комментарий #1)
> Проблему пока получилось воспроизвести только, когда внутри luks файловая
> система btrfs c subvolumes. На nvme+luks+ext4 проблема не воспроизвелась.

Должно было повезти, чтобы нарваться на проблему. Но я научился воспроизводить проблему. Нужен медленный процессор и быстрый накопитель.
В virtualbox выставил 1 ядро на 50 % и проблема стала хорошо воспроизводиться. Изначально было 2 ядра на 100%.
Так что дело действительно в рейсе (я уже стал сомневаться).

Это странно. сервис plymouth стартует раньше обработчика эвентов.

Created attachment 14934 [details]
0001-feature-plymouth-try-to-wait-plymouthd.patch

luks делает plymouth --ping чтобы определить наличие запущенного plymouthd.

Можешь попробовать вот такой патч ?

(Ответ для Alexey Gladkov на комментарий #3)
> Это странно. сервис plymouth стартует раньше обработчика эвентов.

Он долго стартует на медленном процессоре.

(Ответ для Alexey Gladkov на комментарий #4)
> Создано вложение 14934 [details] [подробности]
> 0001-feature-plymouth-try-to-wait-plymouthd.patch
> 
> luks делает plymouth --ping чтобы определить наличие запущенного plymouthd.
> 
> Можешь попробовать вот такой патч ?

Сейчас попробую.

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

(In reply to Alexey Gladkov from comment #6)
> Если долго, то таймаута может не хватить. С другой стороны я боюсь ожидать
> вечно т.к. можно завесить систему, если у plymouth будут проблемы.

Можно добавить что-то типа вот такого для подстраховки:

[ "$timeout" -gt 0 ] ||                                                                                                                                                                                 
  plymouth --hide-splash

(Ответ для Антон Мидюков на комментарий #5)
> (Ответ для Alexey Gladkov на комментарий #3)
> > Это странно. сервис plymouth стартует раньше обработчика эвентов.
> 
> Он долго стартует на медленном процессоре.
> 
> (Ответ для Alexey Gladkov на комментарий #4)
> > Создано вложение 14934 [details] [подробности]
> > 0001-feature-plymouth-try-to-wait-plymouthd.patch
> > 
> > luks делает plymouth --ping чтобы определить наличие запущенного plymouthd.
> > 
> > Можешь попробовать вот такой патч ?
> 
> Сейчас попробую.

Не помогло. 40 мало оказалось. 70 поставил и помогло. Это, получается, 7 секунд стартует?

(In reply to Антон Мидюков from comment #8)
> Не помогло. 40 мало оказалось. 70 поставил и помогло. Это, получается, 7
> секунд стартует?

этого цикла скрипт делает довольно сомнительную вещь:

udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev
udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev
plymouth show-splash

и всё это в асинхронном режиме. Мне кажется это очень странным подходом.

Можно убрать счётчик таймаута и надеяться, что раз "$RETVAL" = 0, то и plymouthd рано или поздно будет доступен.

(Ответ для Alexey Gladkov на комментарий #9)
> (In reply to Антон Мидюков from comment #8)
> > Не помогло. 40 мало оказалось. 70 поставил и помогло. Это, получается, 7
> > секунд стартует?
> 
> этого цикла скрипт делает довольно сомнительную вещь:
> 
> udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev
> udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev
> plymouth show-splash
> 
> и всё это в асинхронном режиме. Мне кажется это очень странным подходом.
> 
> Можно убрать счётчик таймаута и надеяться, что раз "$RETVAL" = 0, то и
> plymouthd рано или поздно будет доступен.

А если не будет? Общий тайм-аут? А если он не найдёт, куда ему выводиться, и не будет стартовать?(Ответ для Alexey Gladkov на комментарий #9)
> (In reply to Антон Мидюков from comment #8)
> > Не помогло. 40 мало оказалось. 70 поставил и помогло. Это, получается, 7
> > секунд стартует?
> 
> этого цикла скрипт делает довольно сомнительную вещь:
> 
> udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev
> udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev
> plymouth show-splash
> 
> и всё это в асинхронном режиме. Мне кажется это очень странным подходом.
> 
> Можно убрать счётчик таймаута и надеяться, что раз "$RETVAL" = 0, то и
> plymouthd рано или поздно будет доступен.

Т.е. убрать обе строки udevadm?
Я думаю, что эти тайм-ауты были введены, чтобы plymouth не стартанул слишком рано и не начал выводить тему "три точки" вместо нормальной графической заставки.

(In reply to Антон Мидюков from comment #10)
> > Можно убрать счётчик таймаута и надеяться, что раз "$RETVAL" = 0, то и
> > plymouthd рано или поздно будет доступен.
> 
> А если не будет? Общий тайм-аут? А если он не найдёт, куда ему выводиться, и
> не будет стартовать?

Да, если $timeout убрать совсем и если plymouth так и не стартанёт, то сработает общий таймаут на initrd. Загрузка будет застревать на этом месте.

> > Можно убрать счётчик таймаута и надеяться, что раз "$RETVAL" = 0, то и
> > plymouthd рано или поздно будет доступен.
> 
> Т.е. убрать обе строки udevadm?
> Я думаю, что эти тайм-ауты были введены, чтобы plymouth не стартанул слишком
> рано и не начал выводить тему "три точки" вместо нормальной графической
> заставки.

Их убирать нельзя. Они нужны для синхронизации с udev и ожидания framebuffer.

Другое дело, что это делается асинхронно. То есть после того как plymouthd вроде как запустился и сервис завершился и загрузка пошла дальше на самом деле splash ещё не показан, потому что udevadm settle.

Кстати, в plymouth(1) написано:

--ping  Check if plymouthd is running.

то есть это тоже не гарантирует ожидаемый результат. Предложенным мной циклом мы дождёмся запуска plymouth, но не show-splash. Поэтому я не уверен, какой результат будет у ask-for-password.

Created attachment 14941 [details]
0001-feature-plymouth-Show-splash-in-synchronous-mode.patch

Я бы попробовал что-то вот такое. Мы сначала ждём необходимых устройств, потом запускаем plymouthd и ждём его запуска, а уже потом делаем show-splash. Таким образом plymouthd должен быть полностью готов после завершения скрипта сервиса.

(Ответ для Alexey Gladkov на комментарий #12)
> Создано вложение 14941 [details] [подробности]
> 0001-feature-plymouth-Show-splash-in-synchronous-mode.patch
> 
> Я бы попробовал что-то вот такое. Мы сначала ждём необходимых устройств,
> потом запускаем plymouthd и ждём его запуска, а уже потом делаем
> show-splash. Таким образом plymouthd должен быть полностью готов после
> завершения скрипта сервиса.

Всё отлично, и даже решились некоторые другие проблемы.
У меня есть старенький ноутбук, на котором plymouth перестал запускаться в графическом режиме (тема три точки). Теперь запускается. На этом же ноутбуке make-initrd-bootchain вываливался в выбор с чего грузиться. Теперь нормально грузится.

А вы там не можете потестировать этот патч на разных конфигурациях на тему есть ли заметная деградация в скорости загрузки и возможности зависания ?

Если всё будет нормально, то выкатим.

(Ответ для Alexey Gladkov на комментарий #14)
> А вы там не можете потестировать этот патч на разных конфигурациях на тему
> есть ли заметная деградация в скорости загрузки и возможности зависания ?
> 
> Если всё будет нормально, то выкатим.

На всём, что у меня есть, проверил, включая одноплатники aarch64. И проблем не обнаружил. Деградации в скорости загрузки не было. Зависания не поймал.

make-initrd-2.39.0-alt1 -> sisyphus:

 Tue Nov 07 2023 Alexey Gladkov <legion@altlinux.ru> 2.39.0-alt1
 - New version (2.39.0).
 - Feature plymouth:
   + Show splash in synchronous mode to avoid race with plymouth users (ALT#48254).
 - Feature fsck:
   + Fix typo in boot variable and fix the FASTBOOT parameter.
 - Utilities:
   + initrd-scanmod: Add support for kmod > v30-25-g5c004af.