Linux plymouth quit wait service

Plymouth (Русский)

Plymouth — это проект из Fedora, обеспечивающий загрузку системы без бегущих надписей (логов) на экране. Он базируется на kernel mode setting (KMS, установка разрешения и глубины цвета на уровне ядра) для обеспечения родного разрешения экрана на раннем этапе загрузки, после чего отображает привлекательный загрузочный экран вплоть до этапа выбора пользователя.

Contents

Подготовка

Plymouth главным образом использует KMS (Kernel Mode Setting) для отображения графики. На EFI/UEFI системах plymouth может использовать EFI framebuffer.

Если вы не можете использовать KMS, например, из-за использования проприетарного драйвера или не хотите использовать EFI framebuffer, обратите внимание на Uvesafb, поскольку он поддерживает широкоформатные разрешения.

Если у вас не настроены ни KMS ни framebuffer, то Plymouth вернется в текстовый режим.

Установка

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

Включение Plymouth в Initcpio

Добавьте Plymouth в HOOKS в mkinitcpio.conf. Он обязательно должен быть добавлен после base и udev :

Если после добавления хука plymouth-encrypt вводимый пароль попадает в фон в текстовом виде, необходимо добавить модуль вашего видеодрайвера в initramfs. Пример для intel:

Также этот шаг может потребоваться для работоспособности некоторых тем.

Альтернативный хук plymouth (systemd)

Если в mkinitcpio.conf используется хук systemd , необходимо заменить plymouth на sd-plymouth . На зашифрованной системе вместо encrypt или plymouth-encrypt используйте sd-encrypt :

Командная строка ядра

Добавьте quiet splash vt.global_cursor_default=0 в параметры ядра. Другие параметры, которые помогут уменьшить вывод логов в консоли, описаны в статье Silent boot.

Настройка

Плавный переход к экранному менеджеру

Для GDM есть пакет gdm-plymouth AUR , который поддерживает плавный переход из коробки (он полностью заменяет gdm и не требует дополнительной настройки).

Пользователи Optimus-manager могут установить gdm-plymouth-prime AUR , который является форком gdm-plymouth AUR с патчами, необходимыми для поддержки Prime switching.

1. Отключите стандартную службу вашего экранного менеджера, например lxdm.service .
2. Включите аналогичную службу, совместимую с Plymouth, например lxdm-plymouth.service .

Задержка загрузки

Если система загружается настолько быстро, что загрузочная анимация не успевает нормально воспроизвестись до запуска DM, можно установить задержку загрузки ShowDelay (в секундах), чтобы вместо мерцания темы показать пустой экран. По умолчанию время задержки равно 5 секундам, однако его можно изменить, чтобы увидеть анимацию на более ранних этапах загрузки.

Изменение фонового изображения темы

В некоторых темах (таких как spinner) можно изменить фоновое изображение. Для этого следует заменить файл /usr/share/plymouth/themes/theme/background-tile.png на собственный. Во избежание перезаписи измененной темы при обновлении plymouth, все действия проводите над копией темы. После изменения нужно пересобрать initrd, как описано в следующем разделе.

Выбор темы

Plymouth поставляется со следующими темами:

1. Fade-in: «Простая тема с затухающими и разгорающимися мерцающими звездами»
2. Glow: «Производственная тема, показывающая процесс загрузки в виде круговой диаграммы»
3. Script: «Пример скрипта» (Несмотря на описание выглядит очень симпатичной темой с логотипом Arch)
4. Solar: «Космическая тема, голубая звезда с протуберанцами»
5. Spinner: «Простая тема с вращающимся индикатором загрузки»
6. Spinfinity: «Простая тема, показывающая вращающийся знак бесконечности в центре экрана»
7. BGRT: Вариант Spinner, который использует OEM-логотип, если он доступен (BGRT означает Boot Graphics Resource Table)
8. (Text: «Текстовый режим с трехцветной полосой прогресса»)
9. (Details: «Резервная тема с подробностями загрузки»)

Дополнительные темы доступны в AUR: смотрите список пакетов, зависимых от plymouth AUR .

Список установленных тем можно вызвать командой:

Изначально выбрана тема spinner. Чтобы выбрать другую, следует изменить строку Theme= в /etc/plymouth/plymouthd.conf , например:

При каждой смене темы необходимо пересобирать initrd . Это произойдет автоматически при выборе темы темы с помощью plymouth-set-default-theme с опцией -R (в противном случае самостоятельно запустите mkinitcpio -P ).

Для просмотра тем без перезагрузки следует нажать Ctrl+Alt+F6 , войти как root и набрать:

Для выхода из просмотра нажать Ctrl+Alt+F6 снова и набрать:

Hidpi

Пропишите коэффициент масштабирования (целое число) в plymouthd.conf :

и пересоберите initrd.

Советы и рекомендации

Отображение сообщений ядра

Чтобы включить отображение сообщений ядра, во время загрузки нажмите Home или Esc .

Добавление логотипа Arch Linux к темам spinner и BGRT

Чтобы добавить логотип к темам spinner и BGRT, нужно поместить его в папку темы с названием watermark.png :

Чтобы поместить логотип в центр (если он не в центре), добавьте следующие строки в файл конфигурации темы (файл с расширением .plymouth , например spinner.plymouth ):

Замена логотипа Arch и создание кастомных тем

Темы, поставляемые с plymouth (fade-in, script, solar, spinfinity), используют логотип, расположенный в /usr/share/plymouth/arch-logo.png . Чтобы заменить логитип, можно позаимствовать любой по вкусу из тем в AUR, изменить *.plymouth (и, возможно, *.script ), заменив изображение на выбранное. Из созданной темы следует создать пакет, поскольку изменения в /usr/share/plymouth могут быть переписаны при обновлении.

Не забудьте пересобрать initrd после создания и включения новой темы.

Источник

Помогите разобраться с plymouth-quit-wait. 20 секунд хватит всем?

Видно, что фейлится по таймауту. Смотрим .service файл:

20 секунд. Отлично. Меняем на 120, перезагружаемся, и в итоге:

В связи с чем есть пару вопросов:

1. Для чего используется этот таймаут? Таким образом какой-то баг пофиксили или что?

2. Почему именно 20 секунд?

Пальцем вы небо, возможно, таймаут нужен для systemd, он же «умный» запускается сервисы (юниты) параллельно, может какой-то не успевает отработать, вот и поставили таймаут, что бы это как-то работало.

Я бы ещё понял, если бы это была задержка перед запуском службы (ну мало ли). Но нет, 20 секунд — это максимальное время, которое отводится на её запуск (и работу по сути).

А вот и коммит на freedesktop.org. Только я всё равно ничего не понимаю. 🙁

plymouth-quit-wait — сервис, который ждёт завершения Plymouth. Он нужен исключительно для того, чтобы программы, работающие с графикой (в частности, иксы) запускались после plymouth и не конфликтовали за фреймбуфер.
Таймаут здесь служит для того, чтобы система смогла запуститься, если Plymouth сломается/зависнет или по иным причинам не сможет отправить процессу plymouth-quit-wait сигнал о своём завершении (там D-Bus и всё такое).

Похоже так и есть. Но тогда есть другой вопрос.

Что происходит в этом случае? plymouth-quit-wait фейлится, а что дальше? Получается, кто-то должен убить зависший plymouthd?

Ну да, по идее, дальше требуется человеческое вмешательство (свитчнуться в консоль, посмотреть логи и починить/снести plymouth).

Кстати, в systemd у всех юнитов есть неявный таймаут в 90 секунд. Здесь просто сделали меньше — видимо, оно часто падает 🙂

дальше требуется человеческое вмешательство

В моём случае оно требуется постоянно. Но всё же меня смущает старт GDM’а даже в случае фейла службы plymouth-quit-wait. Причём всё происходит без ошибок.

у всех, кроме имеющих тип «oneshot», юнитов есть неявный таймаут в 90 секунд

Справедливости ради фикс.

Defaults to 90s, except when Type=oneshot is used in which case the timeout is disabled by default.

у всех, кроме имеющих тип «oneshot», юнитов есть неявный таймаут в 90 секунд

Справедливости ради фикс.

Хм, и действительно. Надо читать маны, а не цитировать на память 🙂

Кстати, насколько понимаю, у Fedora GDM должен быть пропатчен на взаимодействие с Plymouth.. Попробуй включить gdm-plymouth.service вместо gdm.service (если ты ещё не).

у Fedora GDM должен быть пропатчен на взаимодействие с Plymouth

Ну да, он собран с флагом «—with-plymouth». gdm.spec:

Собственно в таком случае сам GDM следит за завершением работы Plymouth. Например, там есть такие строки:

В Fedora gdm.service не сильно отличается от gdm-plymouth.service из AUR:

Не думаю, что здесь что-то имеет решающее значение. Кроме того, пользователи Arch’а тоже жаловались на эту проблему.

Чтож, похоже всё же это бага в Plymouth/GDM. Причём «фейл» GDM’a не является следствием фейла plymouth-quit-wait.service (они стартуют параллельно). Тем не менее, спасибо за помощь.

p.s. Ещё пару ликов:

Всё же попробуй.

Эта строка запрещает выполнение plymouth-quit<,-wait>.service, перекладывая ответственность за завершение Plymouth на GDM. Собственно, что нам и надо.

Просто у меня было что-то похожее с KDM, когда я «игрался» с настройками.

Источник

Проблема медленной загрузки из-за plymouth-quit-wait.service + ubuntu 18.04

Это недавно установленная машина, работающая в режиме двойной загрузки поверх Win 10. При каждой перезагрузке машина зависает на 15 секунд, так как служба plymouth не может запуститься по некоторым причинам.

Ниже приведен фрагмент вывода systemd-analysis

Вот несколько фрагментов загрузочных логов

Установлен графический драйвер последней версии — 415 из репозитория ppa

Можете ли вы сообщить мне, почему происходит задержка из-за службы plymount-quit? Пожалуйста, дайте мне знать, есть ли какая-либо другая информация, которая вам потребуется для устранения неполадок?

Это связано с проблемой аппаратного / программного / графического драйвера?

1 ответ

Плимут не замедляет процесс загрузки! Плимут отвечает за заставку загрузки. Пожалуйста, прочитайте здесь.

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

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

● plymouth-quit-wait.service — удерживайте до завершения процесса загрузки

Чтобы понять больше.

Пожалуйста, выполните следующую команду в терминале:

Затем ищите SystemdAnalyzePlot.svg в вашем домашнем каталоге и запустите его в программе просмотра изображений или в интернет-браузере. Возможно, вам придется увеличить изображение, чтобы вы могли прочитать имена процессов. Это стоит проверить и даст вам лучшее понимание того, как работает процесс загрузки.

Однако вы можете сократить время загрузки, отключив NetworkManager-wait-online.service так что у Плимута есть на один процесс меньше, чтобы ждать. Это действительно может сократить время загрузки. Чтобы сделать это, пожалуйста, следуйте инструкциям в этом ответе.

Ох. и, пожалуйста, оставьте Плимут в покое, это не то, что заставляет вас ждать. это то, что ждет вас

Источник

Thread: plymouth-quit.wait.service slow at boot

Thread Tools

Display

plymouth-quit.wait.service slow at boot

When booting up my Ubuntu 18.04 the plymouth wait service takes a long time during boot. This happened this morning for the first time. Any idea how to fix this?

3min 3.994s plymouth-quit-wait.service
1min 31.194s snapd.seeded.service
6.367s NetworkManager-wait-online.service
1.937s dev-sda1.device
1.611s dev-loop19.device
1.566s dev-loop15.device
1.557s dev-loop20.device
1.553s dev-loop16.device
1.531s dev-loop22.device
1.530s dev-loop17.device
1.530s dev-loop21.device
1.515s dev-loop23.device
1.502s dev-loop24.device
1.500s dev-loop13.device
1.493s dev-loop18.device
1.469s dev-loop29.device
1.465s dev-loop14.device
1.463s dev-loop25.device
1.449s dev-loop27.device
1.444s dev-loop30.device
1.436s dev-loop31.device
1.428s dev-loop28.device
1.423s dev-loop5.device

Re: plymouth-quit.wait.service slow at boot

This has been brought up with recent updates:
Try booting to an older kernel through grub >> Advanced Options.
EDIT: I’m not affected by the slow bootup luckily.

Last edited by 1fallen; July 3rd, 2018 at 06:30 PM . Reason: Added Links

Источник