Une nouvelle installation d’Ubuntu 16.04 s’arrête au redémarrage (serveur i386 sur un ordinateur portable Acer Travelmate)
J'ai utilisé un vieil ordinateur portable Acer Travelmate 4000 comme serveur local avec Ubuntu Desktop.
Cette année, j'ai installé 16.04 i386 Server Edition et je ne pouvais pas être plus heureux. L'ensemble complet de travail de Linux, de la pile réseau et d'Apache2 n'utilise que 37 Mo des 2 Go intégrés ... Aucun échange pour vous!
Le problème, c’est que l’émission d’une commande de redémarrage (ou d’arrêt) est toujours suspendue au même endroit sur la console: "Arrêt de la cible atteinte", ce qui nécessite une mise hors tension puis un redémarrage.
Que puis-je faire pour diagnostiquer davantage?
UPDATE: Par suggestion, j'ai attribué des commandes à la console sous Sudo pour indiquer 'systemctl start debug-Shell' suivi d'un 'redémarrage'.
Cependant, ce serveur Vanilla n’a pas de gestionnaire de fenêtres. Ainsi, lorsque le message final de la console "Arrêter la cible atteinte" apparaît, aucune combinaison de touches ne peut générer un VT et répertorier les tâches échouées. L'incantation Alt + SysRq est également inefficace pour poursuivre le redémarrage.
Quoi qu'il en soit, il existe maintenant une nouvelle ligne de message de dernière minute qui se lit comme suit: "[278.430967] systemd-shutdown: Échec de la finalisation de DM périphériques. Ignoring"
J'ai essayé la solution de contournement pour désactiver l'espace de swap lors de l'arrêt dans un rapport de bogue similaire , mais cela n'a pas aidé; probablement parce que mon fichier d'échange de 3 Go est inutilisé et que l'utilisation de/tmp est minimale (~ 2%).
Y a-t-il autre chose que je puisse essayer de faire avancer les balises ici?
UPDATE 2: La capture de la sortie des commandes journalctl et systemctl suggérées dans un fichier ne donnait rien d'extraordinaire.
Puisqu'il n'y a pas d'interface graphique sur ce serveur, j'ai utilisé ce code github pour activer Xenial Proposed avant la mise à jour/la mise à niveau/le redémarrage afin de s'assurer que le nouveau systemd-229 faisait partie du mélange.
Malheureusement, cela n'a fait aucune différence. Je ne sais pas si c'est lié, mais au moment de l'installation d'Ubuntu, j'ai choisi d'utiliser les groupes de volumes LVM par défaut pour/boot,/home,/var,/tmp et swap.
Suis-je vraiment le seul à voir ce problème?
(Voici une capture d'écran de la console après le redémarrage, plus 3 minutes d'attente environ):
Je suis passé à Ubuntu 16.10 dès qu'il était disponible, mais le problème n'a pas été résolu. Les mises à niveau ultérieures des packages n'ont pas non plus été appliquées depuis.
Cependant, les mises à jour de paquets d'aujourd'hui doivent inclure un correctif, car je peux maintenant créer un "redémarrage Sudo" normal à partir d'une session SSH distante et me reconnecter au serveur en une minute ou deux.
Voici l'entrée la plus récente de mon /var/log/apt/history.log:
Mise à niveau: libsystemd0: i386 (231-9git1, 231-9ubuntu1), udev: i386 (231-9git1, 231-9ubuntu1), libudev1: i386 (231-9git1, 231-9ubunt1), python3: dist. .7, 1: 16.10.8), ubuntu-release-upgrader-core: i386 (1: 16.10.7, 1: 16.10.8), systemd-sysv: i386 (231-9git1, 231-9ubuntu1), libpam- systemd: i386 (231-9git1, 231-9ubuntu1), systemd: i386 (231-9git1, 231-9ubuntu1), libnss-resol: i386 (231-9git1, 231-9ubuntu1)
Parmi cette liste, un énorme "Merci!" va au responsable du paquet qui a appliqué l'incantation magique nécessaire ... vous savez qui vous êtes :)
UPDATE Ubuntu ne prenant plus en charge les machines i386, je suis heureux de passer à Lubuntu 18.04. Bon goût, moins copieux!
Qui sait quand/si ce problème: "systemd-shutdown: Impossible de finaliser DM périphériques. À ignorer." ne sera jamais réparé sur cette ancienne plate-forme - rien de ce que j'ai lu ne suggère que ce sera bientôt.
En attendant, cette solution de contournement me permet de redémarrer mon serveur sans effectuer physiquement un redémarrage de la machine.
Toutes les commandes suivantes sont sous Sudo:
- Placez ces commandes dans un fichier tel que ~/sysrq-reboot.sh
echo 1 > /proc/sys/kernel/sysrq sync && echo b > /proc/sysrq-trigger - chmod + x le fichier pour le rendre exécutable
- ensuite, pour redémarrer, lancez le script avec Sudo ~/sysrq-reboot.sh
Si j'exécute le script à distance via ssh, je dois également fermer durement ma fenêtre ssh et rétablir une nouvelle session ssh (après avoir attendu une minute que la machine soit accessible).