Long délai de démarrage sur l'écran de chargement / écran de démarrage d'Ubuntu après une mise à niveau régulière sur une installation de SSD propre (18.04)
J'exécute la version 18.04 depuis l'installation du disque SSD le jour de sa sortie officielle, sans problèmes.
La connexion pour ouvrir une session a duré quelques secondes (maximum 10)
Ensuite, j'ai fait une mise à jour régulière ce matin:
$ Sudo apt update && Sudo apt dist-upgrade
Les paquets installés/mis à jour étaient:
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)
J'ai redémarré une fois la mise à niveau terminée et noté un délai de 2 à 3 minutes sur le écran de chargement/démarrage d'Ubunt (avant la connexion) (sans aucun progrès/activité indiqué sur les points).
J'ai éteint et essayé de redémarrer, mais je reçois ce délai régulièrement maintenant. Aussi fermer est beaucoup plus lent aussi.
Mise à jour n ° 1 (2018-07-03):
Analyse sur 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
Montrer que plymouth-quit-wait.service (que je crois maintenant lié à l'écran de chargement/écran de démarrage d'Ubuntu) et snapd.seeded.service étaient de loin les services les plus longs à démarrer. J'ai donc comparé les temps précédant le dist-upgrade et les suivants:
$ 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.
Avant la mise à niveau plymouth-quit-wait.service a eu secondes. Après la mise à niveau a pris minutes 35 secondes
$ 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.
Avant la mise à niveau snapd.seeded.service a pris secondes. Après la mise à niveau a pris 2 minutes 2 secondes.
Mise à jour # 2 (2018-07-06):
La botte de ce matin a vu le retour du retard.
Donc, je suppose que nous sommes toujours en attente de la mise à jour du noyau/plymouth/snapd.
Mise à jour (2018-07-12):
Le problème semble avoir été résol, mais je n'ai vu aucune mise à jour de snap ou de plymouth, et j'utilise toujours le noyau 4.15.0-24. Je ne suis donc pas sûr de savoir quelle mise à jour du paquet a résolu le problème, ou si elle se résout elle-même. En lisant les mises à jour de bogues sur le tableau de bord, il m'est difficile de savoir ce qui a été fait (ou est en train de l'être) dans quel paquet/s. Si quelqu'un peut clarifier cela serait très utile.
Il s’agit d’une régression liée au noyau, le bogue du tableau de bord est le suivant: https://bugs.launchpad.net/ubuntu/+bug/1779827
Pour contourner le problème, appuyez sur les touches et/ou déplacez la souris au démarrage.
En un mot, les services qui utilisent/dev/urandom ou getrandom () bloquent maintenant jusqu'à ce que suffisamment d'entropie soit disponible. Dans le passé, beaucoup moins d'entropie était nécessaire pour/dev/urandom.
Le dernier statut de https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 est le suivant:
Les méta-packages ont été annulés et le correctif est en cours d'application et de téléchargement.
L’équipe de snapd a également examiné la question et a travaillé avec bson en amont pour s’assurer qu’il n’existe pas de/dev/unrandom au démarrage ( https://github.com/snapcore/snapd/pull/5464 )
Donc, ce problème devrait bientôt être résolu via un noyau ou une mise à jour snapd.
Vous pouvez déplacer la souris ou augmenter l'entropie dans le système.
Sudo apt install haveged
Fonctionne avec le noyau par défaut et depuis ukuu. Cela permet au système de démarrer correctement sur le noyau 4.17.4.
j'ai le même problème avec 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
Pour une solution de contournement temporaire , il vous suffit de déplacer la souris/le pavé tactile lors du démarrage , entraînant un temps de démarrage "normal"; dans mon cas:
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
Source du correctif: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509
J'ai vu ce manifeste sur deux ordinateurs de bureau que je gère. L'exécution de la commande suivante pour installer rng-tools résout le problème pour moi:
Sudo apt install rng-tools
De Arch wiki: Le rng-tools est un ensemble d’utilitaires liés à la génération de nombres aléatoires dans le noyau. Ceci est principalement utile pour augmenter la quantité d'entropie dans le noyau afin de rendre/dev/random plus rapide.