Длинная задержка загрузки на экране загрузки / заставки Ubuntu после регулярного dist-upgrade при чистой установке SSD (18.04)

24

Я работаю 18.04 с момента чистой установки SSD в день его официального выпуска, без проблем.
Включение при входе в систему было секунд (не более 10)

Затем я сделал обычное обновление этим утром:

$ sudo apt update && sudo apt dist-upgrade

Установленные / обновленные пакеты :

Install: linux-headers-4.15.0-24:amd64 (4.15.0-24.26, automatic), linux-headers-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-extra-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-image-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic)
Upgrade: gnome-control-center-data:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-headers-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-image-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), linux-signed-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center-faces:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-generic:amd64 (4.15.0.23.25, 4.15.0.24.26)

Я перезагрузил компьютер после завершения обновления и отметил 2-3-минутную задержку на экране загрузки / заставки Ubuntu (до входа в систему) (без какого-либо прогресса / активности, указанных в точках).

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

Обновление № 1 (2018-07-03):
анализ в systemd:

$ sudo systemd-analyze blame
3min 53.073s plymouth-quit-wait.service
    2min 20.699s snapd.seeded.service
         49.949s snapd.service
          6.186s NetworkManager-wait-online.service
          1.148s dev-sda2.device
          1.098s plymouth-start.service

Показывая это plymouth-quit-wait.service(что я теперь считаю, связано с загрузочным / заставочным экраном Ubuntu) и snapd.seeded.serviceна сегодняшний день были запущены самые длинные службы. Поэтому я сравнил время до dist-upgradeи после:

$ journalctl -u plymouth-quit-wait.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:38:05 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:15:46 user-laptop systemd[1]: Started Hold until boot process finishes up.
-- Reboot --
Jul 03 04:21:17 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:24:52 user-laptop systemd[1]: Started Hold until boot process finishes up.

До обновления plymouth-quit-wait.serviceпрошло 3 секунды . После обновления прошло 3 минуты 35 секунд

$ journalctl -u snapd.seeded.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:42:14 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:15:43 user-laptop systemd[1]: Started Wait until snapd is fully seeded.
-- Reboot --
Jul 03 04:22:47 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:24:49 user-laptop systemd[1]: Started Wait until snapd is fully seeded.

До обновления snapd.seeded.serviceпрошло 0 секунд . После обновления прошло 2 минуты 2 секунды.

Обновление № 2 (2018-07-06):
загрузка этим утром вернула задержку .
Так что, думаю, мы все еще ждем обновления ядра / plymouth / snapd .

Обновление № 3 (2018-07-12):
проблема, кажется, решена , но я не видел никаких обновлений для оснастки или plymouth, и я все еще использую ядро ​​4.15.0-24. Так что я не уверен, какое обновление пакета решило проблему, или оно просто как-то разрешилось. Читая обновления багов на панели запуска, мне неясно, что было сделано (или делается) с какими пакетами. Если кто-то может уточнить, это было бы очень полезно.

boot 18.04 snap plymouth Broadsworde
источник
Смотрит на меня как snapd были высев (обновление стопорных баз данных) для 2:20. Редкое событие, ничего не сломано. Если это происходит каждый раз, сообщите об ошибке в Snapd.
user535733
1
У меня та же проблема после новой установки Ubuntu 18.04: 3min 57.515s plymouth-quit-wait.service 2min 24.588s snapd.seeded.service
Алессандро Габалло
1
У меня была такая же проблема сегодня после обновления моего ядра до 4.15.0-24-generic.
user605331
1
Рассмотрите возможность создания темы на forum.snapcraft.io . Вот где тусуются разработчики оснастки. Обязательно начинайте цепочку ТОЛЬКО если вы готовы помочь им в устранении неполадок и тестировании. Все должны подписаться на одну и ту же ветку и избегать бесполезных комментариев «Я тоже» - подавляйте шум, чтобы разработчики не падали духом и не отключались.
user535733
2
Я зарегистрировал ошибку по адресу: bugs.launchpad.net/snapd/+bug/1779872 Я, конечно, готов помочь устранить неполадки
Broadsworde

Ответы:

15

Это регрессия, связанная с ядром, ошибка панели запуска: https://bugs.launchpad.net/ubuntu/+bug/1779827

В качестве обходного пути нажмите клавиши и / или переместите мышь при загрузке.

В двух словах, сервисы, которые используют / dev / urandom или getrandom (), теперь блокируются, пока не станет доступной достаточная энтропия. В прошлом гораздо меньше энтропии требовалось для / dev / urandom.

Последний статус с https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 таков :

Метапакеты были откатаны, и исправление находится в процессе применения и загрузки.

Команда Snapd также рассмотрела это и работала с bson upstream, чтобы убедиться, что для запуска не требуется / dev / unrandom ( https://github.com/snapcore/snapd/pull/5464 ).

Так что эта проблема должна быть исправлена ​​через обновление ядра или оснастки в ближайшее время.

Майкл Фогт
источник
1
Я только что попробовал загрузку "shift", и это, казалось, отражало загрузку для времени входа в систему, которое я видел до обновления ... так что здесь сломано? Кстати, «shift» при загрузке не давало мне меню grub, но оно давало мне намного быстрее вход в систему.
Broadsworde
Майкл, не могли бы вы отредактировать этот ответ и включить информацию из вашего другого ответа в этот, а затем удалить другой? Нам нравится один вопрос, один ответ здесь ... Спасибо! ;-)
Fabby
пожалуйста, свяжитесь с модом, чтобы объединить ваши аккаунты
Zanna
@Broadsworde, Спам (многократное нажатие) клавиши Shift или Esc в Ubuntu 18.04 LTS вызывает для меня меню grub. (Недостаточно просто удерживать ключ
нажатым
11

Вы можете перемещать мышь или увеличивать энтропию в системе.

sudo apt install haveged

веб-сайт

Работает для ядра по умолчанию и из укуу. Это позволяет системе корректно загружаться в ядре 4.17.4.

Радослав Бжозовский
источник
Интересное решение. У меня пока нет этой проблемы, потому что я недавно переключился на 4.4.0-130эксперименты с Virtualbox, но я установил havegedна свою машину будущее.
WinEunuuchs2Unix
5

у меня та же проблема с 4.15.0-24-generic #26-Ubuntu SMP

user@nb:~$ systemd-analyze blame |head
         4min 2s plymouth-quit-wait.service
          1.440s systemd-udev-settle.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

Для временного решения проблемы вам просто нужно переместить мышь / тачпад во время загрузки , что приведет к «нормальному» времени загрузки; в моем случае:

user@nb:~$ systemd-analyze blame |head
          1.440s systemd-udev-settle.service
           882ms plymouth-quit-wait.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

Источник исправления: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

Francio
источник
5

Я видел этот манифест на двух рабочих столах, которыми я управляю. Выполнение следующей команды для установки rng-toolsрешает проблему для меня:

sudo apt install rng-tools

Из Arch wiki: rng-tools - это набор утилит, связанных с генерацией случайных чисел в ядре. Это в основном полезно для увеличения количества энтропии в ядре, чтобы сделать / dev / random быстрее.

psiphi75
источник