Długie opóźnienie rozruchu na ekranie ładowania / przywracania systemu Ubuntu po regularnej aktualizacji dystrybucji przy czystej instalacji SSD (18.04)

Używam 18.04 od czasu czystej instalacji SSD w dniu jej oficjalnej premiery, bez problemów.
Włączenie do zalogowania trwało sekundy (maks. 10)

Potem rano przeprowadziłem regularną aktualizację :

$ sudo apt update && sudo apt dist-upgrade

Zainstalowane / zaktualizowane pakiety to :

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)

Po zakończeniu aktualizacji uruchomiłem się ponownie i zauważyłem 2-3 minutowe opóźnienie na ekranie ładowania / powitania Ubuntu (przed zalogowaniem) (bez postępu / aktywności zaznaczonego kropkami).

Wyłączyłem się i spróbowałem ponownie uruchomić komputer, ale teraz opóźnienie jest konsekwentne. Także zamykanie jest znacznie wolniejsze.

Aktualizacja nr 1 (2018-07-03):
Analiza w systemied:

$ 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

Pokazuje to plymouth-quit-wait.service(co, jak sądzę, jest związane z ładowaniem / ekranem powitalnym Ubuntu) i snapd.seeded.servicebyło zdecydowanie najdłużej działającymi usługami do zainicjowania. Porównałem więc czasy przed dist-upgradei po:

$ 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.

Zanim aktualizacja plymouth-quit-wait.servicezajęła 3 sekundy . Po aktualizacji zajęło 3 minuty 35 sekund

$ 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.

Zanim aktualizacja snapd.seeded.servicezajęła 0 sekund . Po aktualizacji zajęło 2 minuty 2 sekundy.

Aktualizacja nr 2 (06.07.2018): Dzisiejszy
rozruch przyniósł opóźnienie .
Sądzę więc, że wciąż czekamy na aktualizację jądra / plymouth / snapd .

Aktualizacja nr 3 (2018-07-12): Wygląda na to , że
problem został rozwiązany , ale nie widziałem żadnej aktualizacji do snapu lub plymoutha, a ja nadal korzystam z jądra 4.15.0-24. Nie jestem więc pewien, która aktualizacja pakietu rozwiązała problem, czy też jakoś się rozwiązała. Czytanie aktualizacji błędów na starterze nie jest dla mnie jasne, co zostało zrobione (lub co jest zrobione) do jakiego pakietu / pakietów. Jeśli ktoś może wyjaśnić, byłoby to bardzo przydatne.

Jest to regresja związana z jądrem, błąd startera to: https://bugs.launchpad.net/ubuntu/+bug/1779827

Aby obejść ten problem, naciśnij klawisze i / lub porusz myszą podczas uruchamiania.

W skrócie usługi, które używają / dev / urandom lub getrandom (), teraz blokują, aż dostępna będzie wystarczająca entropia. W przeszłości dla / dev / urandom wymagana była znacznie mniejsza entropia.

Najnowszy stan z https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 to:

Metapakiety zostały wycofane, a poprawka jest w trakcie stosowania i przesyłania.

Zespół snapd również to przeanalizował i współpracował z bson upstream, aby upewnić się, że do uruchomienia nie jest potrzebny żaden / dev / unrandom ( https://github.com/snapcore/snapd/pull/5464 )

Dlatego ten problem powinien zostać wkrótce naprawiony przez jądro lub aktualizację snapd.

Możesz przesunąć mysz lub zwiększyć entropię w systemie.

sudo apt install haveged

haveged website

Działa dla domyślnego jądra i z ukuu. Pozwala to na prawidłowe uruchomienie systemu w jądrze 4.17.4.

mam ten sam problem z 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

Aby tymczasowo obejść ten problem , wystarczy przesunąć mysz / touchpad podczas uruchamiania , co powoduje „normalny” czas uruchamiania; w moim przypadku:

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

Napraw źródło: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

Widziałem ten manifest na dwóch komputerach, którymi zarządzam. Uruchomienie następującego polecenia w celu instalacji rng-toolsrozwiązuje problem:

sudo apt install rng-tools

Z Arch wiki: Narzędzia rng to zestaw narzędzi związanych z generowaniem liczb losowych w jądrze. Przydaje się to głównie do zwiększenia ilości entropii w jądrze, aby przyspieszyć / dev / random.