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

I'be, работая 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):
Начальная загрузка этого утра видела возврат задержки.
Таким образом, я предполагаю, что мы все еще ожидаем обновления kernel/plymouth/snapd.

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

27
задан 12 July 2018 в 12:05

4 ответа

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

sudo apt install rng-tools

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

0
ответ дан 12 July 2018 в 12:05

У меня та же проблема с 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

0
ответ дан 12 July 2018 в 12:05

Это регрессия, связанная с ядром, ошибка панели запуска: 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 )

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

0
ответ дан 12 July 2018 в 12:05

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

sudo apt install haveged

есть веб-сайт

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

0
ответ дан 12 July 2018 в 12:05

Другие вопросы по тегам:

Похожие вопросы: