Après quelques mises à jour récentes, mon ordinateur ne démarre plus! Voici ce que j'ai pu déterminer:
- C'est un ordinateur très récent qui m'a été fourni par l'informatique d'entreprise. Il a un processeur Intel récent (génération Skylake).
- L'ordinateur exécute Ubuntu 16.04.
- La dernière fois que l'ordinateur a démarré correctement, au mois de mars. Le problème est probablement dû à une mise à jour logicielle ou à un bogue matériel.
- J'ai un autre ordinateur qui exécute 16.04 avec à peu près le même logiciel installé (j'ai utilisé
apt-clone
), et cela fonctionne très bien. Il a un matériel différent (également amd64, mais un processeur différent, un GPU différent, etc.). - Le noyau démarre, initrd fonctionne correctement. Lorsque je démarre avec un écran de démarrage en mode graphique, on me demande le mot de passe de mon volume dm-crypt, et la dernière chose que je vois, c'est qu'il a été monté correctement.
- Le blocage se produit avant que je reçoive une invite de connexion. Lorsque l'ordinateur se bloque, c'est un coup dur. Même Alt+ SysRqne répond pas. Le processeur est évidemment indexé à 100% puisque les ventilateurs se mettent en marche à fond.
- J'ai toujours le noyau que j'utilisais avant de redémarrer. Lorsque je sélectionne ce noyau dans le menu Grub, je reçois le même blocage. Il semble donc qu’il s’agisse d’un bogue du noyau préexistant qui est déclenché par autre chose - mais quoi?
- Si j'éteins l'écran d'accueil (supprimer
splash
de lalinux
ligne de commande dans Grub), un certain nombre de services démarrent, puis se bloquent. Je peux obtenir un shell root en ajoutant
init=/bin/sh
à lalinux
ligne de commande dans Grub. Je peux même aller plus loin en ajoutantsystemd.unit=basic.target systemd.shell
Cela démarre un certain nombre de services et exécute un shell root sur tty9.
- Si je cours à
systemctl start multi-user.target
partir de ce shell racine, l'ordinateur se bloque. Donc, vraisemblablement, le problème est déclenché par l'un de ces services. - J'ai couru
systemctl list-dependencies multi-user.target
pour voir quels services ont été lancés. J'ai démarré manuellement les dépendances répertoriées une par une et tout a bien commencé.
Cela ressemble donc à un bogue matériel (puisqu'il se produit sur un ordinateur mais pas sur l'autre) qui est déclenché par certains logiciels. Mais quel logiciel? Puisque l'ordinateur se bloque si fort, je ne peux obtenir aucun journal. Je ne peux même pas obtenir de sortie de console utile.
Techniques de débogage utiles:
- Alt+ SysRq: clé magique SysRq , qui vous permet d'effectuer des tâches telles qu'un redémarrage d'urgence. Il accède au noyau à un niveau très bas, de sorte qu'il fonctionne dans toutes les crashes, sauf les pires. Dans mon cas, le Altsigne + SysRqne répond pas, ce qui indique la profondeur du crash.
- Pour modifier les paramètres d’amorçage, maintenez Shiftquelques secondes après la mise sous tension. Vous devez appuyer dessus après l’initialisation du clavier par le BIOS, mais avant le démarrage du système d’exploitation. Cela fait apparaître le menu Grub .
- Dans le menu Grub, appuyez sur epour modifier la ligne de commande d'une entrée de menu. Pour modifier les paramètres de démarrage de Linux, accédez à la ligne qui commence par
linux
. Sur un Ubuntu moderne, vous trouverez les anciens noyaux sous «Options avancées pour Ubuntu». Une fois que vous avez apporté les modifications souhaitées à la ligne de commande, appuyez sur Ctrl+ xpour démarrer. Toutes les modifications que vous apportez ici ne concernent que ce démarrage, elles ne sont pas enregistrées sur le disque. - Quelques options utiles sur la
linux
ligne de commande:quiet nosplash
cache presque tous les messages de démarrage. Supprimez-les pour obtenir des messages sur la console lors du démarrage, ce qui est nécessaire pour pouvoir diagnostiquer les problèmes.recovery
vous donne un shell root avec presque pas de services. Vous aurez besoin de connaître le mot de passe root. L'entrée de menu «mode de récupération» l'utilise.init=/bin/sh
vous donne un shell root sans aucun service. Pour reprendre le démarrage normal, exécutezexec init
. Vous pouvez passer les options systemd à ce stade, par exempleexec init --unit=basic.target
pour démarrer init et quelques services (notez que cela ne démarre en aucun cas pour vous connecter, il est donc préférable d’exécuter un shell sur une autre console). Notez que le système de fichiers racine est monté en lecture seule; courirmount -o remount,rw /
pour pouvoir y écrire.systemd.unit=basic.target
commence un ensemble très basique de services. Notez que cela n'inclut aucun moyen de vous connecter! Vous pouvez en faire la valeur par défaut en exécutantsystemctl set-default basic.target
à l'invite de la racine. Pour restaurer la cible par défaut d'origine, exécutezsystemctl set-default graphical.target
(ousystemctl set-default multi-user.target
pour un serveur sans interface graphique).systemd.debug-shell
démarre un shell root sur tty9. Vous pouvez l'activer pour chaque démarrage en s'exécutantsystemctl enable debug-shell
à l'invite de la racine. N'oubliez pas de désactiver ceci après avoir résolu le problème avecsystemctl disable debug-shell
. Appuyez sur Alt+ F9pour passer à tty9.- Voir aussi Astuces Fedora systemd , Astuces pour les problèmes de démarrage Arch Linux .