Le démarrage d'Ubuntu 14.04 se bloque au logo après la mise à jour
Hier, j'ai fait un update/dist-upgrade. Aujourd'hui, j'ai mis la machine sous tension et elle était accrochée à l'écran de chargement avec le logo et les points cyclistes. J'ai attendu plusieurs fois devant cet écran pendant une heure, sans résultat. Si j'interromps upstart avec ctrl-alt-del, le démarrage reprend/est terminé, mais me met à la connexion à la console tty. X démarre quelques secondes plus tard, mais une boîte de dialogue concernant une configuration incorrecte des graphiques est immédiatement affichée. Mise à jour : le problème de X a été résolu en effectuant apt-get install nvidia-current. Le problème d'interruption est toujours d'actualité.
Malheureusement, toutes les pistes que j'ai trouvées sur les raisons pour lesquelles cela pourrait se produire se sont transformées en impasse. Voici mon boot.log (de /var/log) indiquant où j'ai interrompu le démarrage. Vous pouvez voir qu'il se bloque juste au démarrage "active les périphériques de bloc chiffrés au démarrage" (ceci provient de cryptdisks), mais la suppression de ce service ne fait aucune différence. J'ai essayé à peu près tout de ce rapport de bogue Mint , qui décrit des symptômes presque identiques aux miens, mais en vain. À ce stade, je suis à peu près sûr que cryptdisks est un fouillis rouge et que c'est autre chose.
J'ai également constaté que la reprise du démarrage à partir du mode de récupération semble charger les choses dans un ordre différent. Upstart se bloque toujours, mais pas après cryptdisks. Si je ctrl-alt-suppr, cela m'amène au gestionnaire de connexion graphique au lieu d'un tty, et je peux me connecter avec succès. Cependant, le système n'est toujours pas entièrement fonctionnel. Le plug and play USB semble ne pas fonctionner, je ne peux pas utiliser mon deuxième moniteur et je dois effectuer manuellement start resolvconf pour accéder à Internet. Voici le fichier boot.log de l'une de ces startups.
Je devrais ajouter que je crypte mon disque dur avec LUKS, et le blocage se produit une fois le mot de passe de décryptage entré. Voici mon fstab, au cas où cela aurait un rapport avec des choses:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=9e7c1e90-f3e4-4075-b3b0-e3ccb6d933c7 /boot ext2 defaults 0 2
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
Que se passe t-il ici?
La cause principale était un grand nombre de fichiers dans mon répertoire /tmp.
J'avais utilisé le répertoire /tmp pour stocker des millions de fichiers auparavant. Il se trouve que le fait qu’il y ait autant de fichiers à l’origine du service qui nettoie /tmp prend très longtemps (duh). Après avoir déplacé les fichiers de /tmp, le problème est résolu. Cela n'avait rien à voir avec la mise à niveau; c'était juste une coïncidence.
Au cas où cela aiderait quelqu'un plus tard, voici le processus que j'ai utilisé pour le comprendre. J'ai activé le "clé Magic SysRq" en changeant etc/sysctl.d/10-magic-sysrq.conf. Ensuite, j'ai reproduit le problème en redémarrant; quand le démarrage a été suspendu, j'ai frappé Alt-SysRq-t. Le contenu suivant a été vidé dans le tampon du noyau, à l’aide de dmesg:
[ 36.318527] SysRq : Show Blocked State
[ 36.318696] task PC stack pid father
[ 36.318719] find D ffff88041dd93480 0 839 788 0x00000000
[ 36.318721] ffff880405d07a48 0000000000000082 ffff880401136000 ffff880405d07fd8
[ 36.318723] 0000000000013480 0000000000013480 ffff880401136000 ffff88041dd93d18
[ 36.318725] ffff88041dfab460 0000000000000002 ffffffff811ef380 ffff880405d07ac0
Il en dépose beaucoup plus que cela, mais c'est la partie pertinente. Cela montre que la tâche bloquée est find. Après cela, il ne restait plus qu’à un ami averti de savoir que le /tmp service de nettoyage était probablement le coupable.
Merci Chaosed0 d’être revenu avec votre solution (c’est-à-dire un très grand nombre de fichiers dans/tmp). [J'ai essayé de poster ceci en tant que commentaire mais je n'ai pas assez de points de réputation]
J'ai rencontré le même problème avec le serveur Ubuntu (14.04) et il était très difficile de diagnostiquer jusqu'à ce que j'ai trouvé votre message.
Lorsque j'ai redémarré la machine, celle-ci semble être bloquée juste avant que la console de connexion ne s'affiche normalement. Vous pouvez le débloquer en appuyant sur Ctrl+Alt+Del, ce qui entraînerait l’impression d’un message de journal indiquant que wait-for-state (rcplymouth-shutdown) était terminé. Ce message de log m'a envoyé dans le mauvais chemin en piquant divers scripts de plymouth et en essayant ensuite de désactiver complètement plymouth :
En réalité, le processus de démarrage n'était pas dans l'impasse, il attendait simplement le nettoyage de /tmp. Cette machine avait des dizaines de milliers de fichiers sous /tmp, le nettoyage a donc pris beaucoup de temps.
--- (Le problème pour moi était donc de démarrer la récupération, d'obtenir un shell racine puis rm -rf /tmp/*. Au bout d'une heure environ, le travail rm était terminé. Ensuite, j'ai redémarré et tout a fonctionné normalement.
Ce serait bien si un message du journal pouvait être imprimé lorsque le nettoyage de /tmp commence.