Long délai de démarrage sur l'écran de chargement / démarrage d'Ubuntu après une mise à niveau régulière de la dist sur une installation SSD propre (18.04)

24

J'exécute le 18.04 depuis une installation propre du SSD le jour de sa sortie officielle, sans problème.
La mise sous tension pour se connecter était de quelques secondes (max 10)

Ensuite, j'ai fait une mise à jour régulière ce matin:

$ sudo apt update && sudo apt dist-upgrade

Les packages installés / mis à niveau é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 j'ai noté un délai de 2-3 minutes sur l' écran de chargement / démarrage d'Ubuntu (avant la connexion) (sans aucune progression / activité indiquée sur les points).

Je me suis mis hors tension et j'ai essayé de redémarrer, mais je reçois ce délai de manière constante maintenant. La fermeture est également beaucoup plus lente.

Mise à jour # 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

Montrant cela plymouth-quit-wait.service(qui je crois maintenant est lié à l'écran de chargement / splash d'Ubuntu) et snapd.seeded.serviceétait de loin le service le plus ancien à lancer. J'ai donc comparé les temps avant dist-upgradeet aprè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.

Avant la mise à niveau a plymouth-quit-wait.servicepris 3 secondes . Après la mise à niveau, il a fallu 3 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 a snapd.seeded.servicepris 0 secondes . Après la mise à niveau, cela 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 attendons toujours la mise à jour du noyau / plymouth / snapd .

Mise à jour # 3 (2018-07-12):
Le problème semble être résolu , mais je n'ai vu aucune mise à jour pour snap ou plymouth, et j'utilise toujours le noyau 4.15.0-24. Je ne suis donc pas sûr de la mise à jour du package qui a résolu le problème, ou si elle s'est simplement résolue d'une manière ou d'une autre. En lisant les mises à jour des bogues sur le tableau de bord, je ne sais pas ce qui a été fait (ou est en cours) pour quel (s) package (s). Si quelqu'un peut clarifier cela, ce serait très utile.

boot 18.04 snap plymouth Broadsworde
la source
Il me semble que snapd était en train de seeding (actualisation de la base de données snap) pendant 2:20. Un événement rare, rien de cassé. Si c'est le cas à chaque fois, déposez un bogue contre snapd.
user535733
1
J'ai le même problème après une nouvelle installation d'Ubuntu 18.04: 3min 57.515s plymouth-quit-wait.service 2min 24.588s snapd.seeded.service
Alessandro Gaballo
1
J'ai eu ce même problème aujourd'hui après la mise à niveau de mon noyau vers 4.15.0-24-generic.
user605331
1
Pensez à démarrer un fil sur forum.snapcraft.io . C'est là que les développeurs de snap se retrouvent. Assurez-vous de démarrer un thread UNIQUEMENT si vous êtes prêt à les aider à dépanner et à tester. Tout le monde devrait s'abonner au même fil de discussion et éviter les commentaires inutiles du «moi aussi» - réduisez le bruit pour que les développeurs ne se découragent pas et ne s'éteignent pas.
user535733
2
J'ai enregistré un bogue sur: bugs.launchpad.net/snapd/+bug/1779872 Je suis certainement prêt à aider au dépannage
Broadsworde

Réponses:

15

Il s'agit d'une régression liée au noyau, le bug du tableau de bord est: https://bugs.launchpad.net/ubuntu/+bug/1779827

Pour contourner ce problème, appuyez sur les touches et / ou déplacez la souris au démarrage.

En résumé, 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 requise pour / dev / urandom.

Le dernier état 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 snapd s'est également penchée sur cette question et a travaillé avec bson en amont pour s'assurer qu'aucun / dev / unrandom n'est nécessaire au démarrage ( https://github.com/snapcore/snapd/pull/5464 )

Donc, ce problème devrait être résolu via un noyau ou une mise à jour snapd bientôt.

Michael Vogt
la source
1
Je viens d'essayer le démarrage "shift" et cela semblait refléter le démarrage aux heures de connexion que j'avais vu avant la mise à jour ... alors qu'est-ce qui est cassé ici? BTW, "shift" au démarrage ne m'a pas donné de menu grub, mais il m'a donné une connexion beaucoup plus rapidement.
Broadsworde
Michael, pourriez-vous modifier cette réponse et incorporer les informations de votre autre réponse dans celle-ci, puis supprimer l'autre? Nous aimons une question, une réponse ici ... Merci! ;-)
Fabby
veuillez contacter un mod pour fusionner vos comptes
Zanna
@Broadsworde, Spamming (frappes répétées) la touche Maj ou la touche Echap dans Ubuntu 18.04 LTS fait apparaître le menu grub pour moi. (Il ne suffit pas de garder la clé enfoncée; je suppose que cela peut différer d'un ordinateur à l'autre.)
sudodus
11

Vous pouvez déplacer la souris ou augmenter l'entropie dans le système.

sudo apt install haveged

site Web

Fonctionne pour le noyau par défaut et depuis ukuu. Cela permet au système de démarrer correctement sur le noyau 4.17.4.

Radoslaw Brzozowski
la source
Solution intéressante. Je n'ai pas encore le problème parce que je suis récemment passé à l' 4.4.0-130expérimentation de Virtualbox, mais j'ai installé havegedma machine à l'épreuve du temps.
WinEunuuchs2Unix
5

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 temporaire , il vous suffit de déplacer votre souris / pavé tactile pendant le démarrage , ce qui entraîne 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

Francio
la source
5

J'ai vu ce manifeste sur deux bureaux que je gère. L'exécution de la commande suivante pour installer rng-toolsrésout le problème pour moi:

sudo apt install rng-tools

De Arch wiki: Les outils rng sont 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 pour rendre / dev / random plus rapide.

psiphi75
la source