Larga demora de arranque en la pantalla de carga / inicio de Ubuntu después de la actualización regular dist en la instalación limpia de SSD (18.04)

24

He estado ejecutando 18.04 desde una instalación SSD limpia el día de su lanzamiento oficial, sin problemas.
El encendido para iniciar sesión fue de segundos (máximo 10)

Entonces, hice una actualización regular esta mañana:

$ sudo apt update && sudo apt dist-upgrade

Los paquetes instalados / actualizados fueron :

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)

Reinicié una vez que se completó la actualización, y noté un retraso de 2-3 minutos en la pantalla de carga / bienvenida de Ubuntu (antes del inicio de sesión) (sin ningún progreso / actividad indicada en los puntos).

Apagué e intenté arrancar de nuevo, pero ahora recibo este retraso de manera constante. También cerrar es mucho más lento también.

Actualización n. ° 1 (2018-07-03):
Análisis en 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

Mostrar eso plymouth-quit-wait.service(que ahora creo que está relacionado con la pantalla snapd.seeded.servicede inicio / carga de Ubuntu) y fueron, con mucho, los servicios más antiguos en iniciarse. Así que comparé los tiempos antes dist-upgradey después:

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

Antes de la actualización plymouth-quit-wait.servicetomó 3 segundos . Después de la actualización, tomó 3 minutos y 35 segundos

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

Antes de la actualización snapd.seeded.servicetomó 0 segundos . Después de la actualización, tardó 2 minutos y 2 segundos.

Actualización n. ° 2 (2018-07-06):
el arranque de esta mañana vio el regreso de la demora .
Así que supongo que todavía estamos esperando la actualización kernel / plymouth / snapd .

Actualización n. ° 3 (2018-07-12):
el problema parece estar resuelto , pero no vi ninguna actualización para ajustar o plymouth, y todavía estoy ejecutando el kernel 4.15.0-24. Así que no estoy seguro de qué actualización de paquete solucionó el problema, o si simplemente se resolvió de alguna manera. Al leer las actualizaciones de errores en el launchpad no me queda claro qué se hizo (o se está haciendo) en qué paquete / s. Si alguien puede aclarar eso sería muy útil.

boot 18.04 snap plymouth Broadsworde
fuente
Me parece que snapd se estaba sembrando (refrescando la base de datos de snap) durante 2:20. Un evento raro, nada roto. Si hace eso cada vez, presente un error contra snapd.
user535733
1
Tengo el mismo problema después de una nueva instalación de Ubuntu 18.04: 3min 57.515s plymouth-quit-wait.service 2min 24.588s snapd.seeded.service
Alessandro Gaballo
1
Tuve este mismo problema hoy después de actualizar mi kernel a 4.15.0-24-generic.
user605331
1
Considere comenzar un hilo en forum.snapcraft.io . Ahí es donde pasan los desarrolladores instantáneos. Asegúrese de iniciar un hilo SOLAMENTE si está dispuesto a ayudarlos a solucionar problemas y probarlos. Todos deberían suscribirse al mismo hilo y evitar comentarios inútiles de 'yo también': mantenga el ruido bajo para que los desarrolladores no se desanimen y se apaguen.
user535733
2
Logré un error en: bugs.launchpad.net/snapd/+bug/1779872 Ciertamente estoy dispuesto a ayudar a solucionar problemas
Broadsworde

Respuestas:

15

Esta es una regresión relacionada con el núcleo, el error de launchpad es: https://bugs.launchpad.net/ubuntu/+bug/1779827

Como solución alternativa, presione las teclas y / o mueva el mouse durante el arranque.

En pocas palabras, los servicios que usan / dev / urandom o getrandom () ahora se bloquean hasta que haya suficiente entropía disponible. En el pasado se requería mucha menos entropía para / dev / urandom.

El último estado de https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 es que:

Los metapaquetes se han revertido y la solución está en proceso de aplicación y carga.

El equipo de snapd también analizó esto y trabajó con bson upstream para garantizar que no se necesita / dev / unrandom para el inicio ( https://github.com/snapcore/snapd/pull/5464 )

Por lo tanto, este problema debería solucionarse mediante un kernel o una actualización de snapd pronto.

Michael Vogt
fuente
1
Acabo de probar el inicio "shift" y eso parecía reflejar el inicio al inicio de sesión que había estado viendo antes de la actualización ... entonces, ¿qué se rompe aquí? Por cierto, "shift" en el arranque no me dio un menú de grub, pero me dio un inicio de sesión mucho más rápido.
Broadsworde
Michael, ¿podrías editar esta respuesta e incorporar la información de tu otra respuesta en esta y luego eliminar la otra? Nos gusta una pregunta, una respuesta aquí ... ¡ Gracias! ;-)
Fabby
comuníquese con un mod para fusionar sus cuentas
Zanna
@Broadsworde, Spam (pulsaciones repetidas) la tecla shift o la tecla Esc en Ubuntu 18.04 LTS me abre el menú de grub. (No es suficiente simplemente mantener presionada la tecla; supongo que puede diferir entre computadoras.)
sudodus
11

Puede mover el mouse o aumentar la entropía en el sistema.

sudo apt install haveged

sitio web

Funciona para kernel predeterminado y desde ukuu. Esto permite que el sistema se inicie correctamente en el kernel 4.17.4.

Radoslaw Brzozowski
fuente
Solución interesante Todavía no tengo el problema porque recientemente 4.4.0-130cambié a Virtualbox para experimentar, pero lo instalé para preparar havegedmi máquina para el futuro.
WinEunuuchs2Unix
5

Tengo el mismo 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

Para una solución temporal , solo necesita mover su mouse / touchpad mientras arranca , lo que resulta en un tiempo de arranque "normal"; en mi 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

Fuente del arreglo: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

Francio
fuente
5

He visto este manifiesto en dos escritorios que administro. Ejecutar el siguiente comando para instalar me rng-toolsresuelve el problema:

sudo apt install rng-tools

De Arch wiki: rng-tools es un conjunto de utilidades relacionadas con la generación de números aleatorios en el núcleo. Esto es principalmente útil para aumentar la cantidad de entropía en el núcleo para hacer / dev / random más rápido.

psiphi75
fuente