Ritardo di avvio lungo nella schermata di caricamento / splash di Ubuntu a seguito di un regolare aggiornamento dist su installazione SSD pulita (18.04)

Sono in esecuzione 18.04 da un'installazione SSD pulita il giorno della sua uscita ufficiale, senza problemi.
L'accensione per l'accesso era secondi (massimo 10)

Quindi, ho fatto un aggiornamento regolare questa mattina:

$ sudo apt update && sudo apt dist-upgrade

I pacchetti installati / aggiornati erano :

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)

Ho riavviato una volta completato l'aggiornamento e ho notato un ritardo di 2-3 minuti nella schermata di caricamento / splash di Ubuntu (prima dell'accesso) (senza alcun progresso / attività indicata sui punti).

Ho spento e ho provato a riavviare, ma ora sto ricevendo questo ritardo in modo coerente. Anche chiudere è molto più lento.

Aggiornamento n. 1 (2018-07-03):
analisi su 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

Mostrando ciò plymouth-quit-wait.service(che ora credo sia correlato alla schermata di caricamento / splash di Ubuntu) ed è snapd.seeded.servicestato di gran lunga il servizio più lungo da avviare. Quindi ho confrontato i tempi prima dist-upgradee dopo:

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

Prima che l'aggiornamento plymouth-quit-wait.serviceimpiegasse 3 secondi . Dopo l'aggiornamento ci sono voluti 3 minuti e 35 secondi

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

Prima che l'aggiornamento snapd.seeded.serviceimpiegasse 0 secondi . Dopo l'aggiornamento ci sono voluti 2 minuti e 2 secondi.

Aggiornamento n. 2 (06-07-2018):
l'avvio di questa mattina ha visto il ritorno del ritardo .
Quindi immagino che stiamo ancora aspettando l'aggiornamento del kernel / plymouth / snapd .

Aggiornamento n. 3 (12-07-2018):
il problema sembra risolto , ma non ho visto alcun aggiornamento per snap o plymouth e sto ancora eseguendo il kernel 4.15.0-24. Quindi non sono sicuro quale aggiornamento del pacchetto abbia risolto il problema o se si sia risolto da solo in qualche modo. Leggere gli aggiornamenti dei bug sul launchpad non mi è chiaro cosa è stato fatto (o è stato fatto) a quale pacchetto / i. Se qualcuno può chiarire che sarebbe molto utile.

Questa è una regressione relativa al kernel, il bug del launchpad è: https://bugs.launchpad.net/ubuntu/+bug/1779827

Per ovviare al problema, premere i tasti e / o spostare il mouse all'avvio.

In breve, i servizi che usano / dev / urandom o getrandom () ora bloccano fino a quando non è disponibile abbastanza entropia. In passato era richiesta molta meno entropia per / dev / urandom.

L'ultimo stato da https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 è che:

I meta-pacchetti sono stati ripristinati e la correzione è in corso di applicazione e caricamento.

Anche il team di snapd ha esaminato questo aspetto e ha lavorato con bson a monte per assicurarsi che non sia necessario / dev / non casuale per l'avvio ( https://github.com/snapcore/snapd/pull/5464 )

Quindi questo problema dovrebbe essere risolto presto tramite un kernel o un aggiornamento snapd.

È possibile spostare il mouse o aumentare l'entropia nel sistema.

sudo apt install haveged

sito web affilato

Funziona con kernel predefinito e da ukuu. Ciò consente al sistema di avviarsi correttamente sul kernel 4.17.4.

ho lo stesso problema con 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

Per una soluzione temporanea , è sufficiente spostare il mouse / touchpad durante l'avvio , determinando un tempo di avvio "normale"; nel mio caso:

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

Fonte di correzione: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

Ho visto questo manifest su due desktop che gestisco. L'esecuzione del comando seguente per l'installazione rng-toolsrisolve il problema per me:

sudo apt install rng-tools

Da Arch wiki: rng-tools è un insieme di utility relative alla generazione casuale di numeri nel kernel. Ciò è utile principalmente per aumentare la quantità di entropia nel kernel per rendere / dev / random più veloce.