Crash au démarrage sur un ordinateur d'entreprise récent

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 splashde la linuxligne 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à la linuxligne de commande dans Grub. Je peux même aller plus loin en ajoutant

  systemd.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.targetpartir 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.targetpour 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 linuxligne de commande:
  • quiet nosplashcache 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.
  • recoveryvous 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/shvous donne un shell root sans aucun service. Pour reprendre le démarrage normal, exécutez exec init. Vous pouvez passer les options systemd à ce stade, par exemple exec init --unit=basic.targetpour 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; courir mount -o remount,rw /pour pouvoir y écrire.
  • systemd.unit=basic.targetcommence 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écutant systemctl set-default basic.targetà l'invite de la racine. Pour restaurer la cible par défaut d'origine, exécutez systemctl set-default graphical.target(ou systemctl set-default multi-user.targetpour un serveur sans interface graphique).
  • systemd.debug-shelldémarre un shell root sur tty9. Vous pouvez l'activer pour chaque démarrage en s'exécutant systemctl enable debug-shellà l'invite de la racine. N'oubliez pas de désactiver ceci après avoir résolu le problème avec systemctl disable debug-shell. Appuyez sur Alt+ F9pour passer à tty9.
  • Voir aussi Astuces Fedora systemd , Astuces pour les problèmes de démarrage Arch Linux .

Le problème

Il s’avère que mon problème est un problème connu entre le dernier microcode Intel sur certains processeurs Skylake (certains?) Et les noyaux Linux récents, qui est principalement provoqué par sssd . Voir le bogue Ubuntu n ° 1759920, «Intel-microcode 3.20180312.0 provoque le blocage de l'écran de connexion (w / linux-image-4.13.0-37-generic)» , ainsi que de nombreux autres bugs qui se rapportent au même problème. , comme le bogue Ubuntu n ° 1746806 «sssd semble bloquer les instances AWS c5 et m5, causant 100% de CPU» et le bogue Ubuntu n ° 1746418 «Le système se bloque lors du démarrage de Xorg après l’installation de linux-image-4.13.0-32-generic» . Vous êtes susceptible de rencontrer ce bogue si:

• Vous avez un processeur Intel très récent. Autant que je sache, ce bogue ne concerne que les processeurs Skylake .
• Vous avez le paquet intel-microcode installé. Revenir à un noyau testé antérieur ne fonctionnait pas pour moi car je ne l'exécutais qu'avec un microcode antérieur.
• Votre ordinateur est connecté à un réseau d'entreprise (généralement LDAP ou Active Directory) pour l'authentification de l'utilisateur. Bien qu'il existe d'autres moyens de déclencher le bogue, exécuter sssd semble être le coupable le plus courant. Il y a également des rapports de crash de Xorg .

Le bogue est dû aux mesures d'atténuation prises pour le problème de sécurité Specter publié en janvier 2018. Il existe une incompatibilité entre certains codes du noyau et certains microcodes de processeurs qui provoque un blocage dans certaines circonstances.

Comment réparer

1. Si vous ne pouvez pas démarrer normalement, vous devrez éditer la ligne de commande du noyau à l'invite de Grub. Voir la question pour des explications et des manières possibles d'obtenir un shell racine.
2. Une solution de contournement pour ce bogue spécifique consiste à ajouter le noibpbparamètre à la ligne de commande du noyau ( 1746418/14 , 1759920/56 ). Cela devrait vous permettre de démarrer normalement et d'effectuer des réparations.
   Cela désactive la limitation de la vulnérabilité à l'origine du problème, ce qui signifie que votre ordinateur est maintenant vulnérable à certaines attaques. Il s’agit d’attaques locales, c’est-à-dire que l’attaquant doit exécuter du code sur votre ordinateur, mais ces attaques peuvent potentiellement être réalisées, par exemple, via JavaScript dans un navigateur Web.
   Si vous n'avez pas d'autre moyen, vous pouvez rendre cela permanent en ajoutant noibpbà la ligne de commande du noyau jusqu'à ce que vous puissiez obtenir un noyau corrigé.
3. Sous Ubuntu, le correctif est attendu pour la semaine du 23 avril 2018 , probablement dans les noyaux 4.4.0-117 et 4.13.0-39. Dans l'intervalle, Tyler Hicks a publié des noyaux de test pour 4.4 et 4.13 .

Comment j'ai diagnostiqué le problème

J'ai essayé plusieurs choses (voir la question) et déterminé que le bogue avait été déclenché quelque part entre atteindre basic.targetet atteindre multi-user.target. J'ai donc défini la cible systemd par défaut sur basic.target( systemctl set-default basic.target) et activé le debug-shellservice ( systemctl enable debug-shell) pour obtenir un shell root.

J'ai exécuté systemctl list-dependencies multi-user.targetet commencé manuellement les dépendances énumérées une par une. Cela n'a pas déclenché le crash.

Tous les services ne sont pas gérés directement par systemd . Certains sont gérés en tant que services Upstart et d'autres en tant que scripts SysVinit . Le script shell ci-dessous les exécute tous. Remarque: je ne l'ai testé qu'une fois, et il s'est écrasé par conception.

#!/bin/sh
wants=$(systemctl show -p Wants multi-user.target | sed 's/^Wants=//' | tr ' ' '\n' | sort)
log=/var/tmp/multi-user-steps-$(date +%Y%m%d-%H%M%S)

log () {
  echo "$* ..." | tee -a "$log"
  sync
  "$@"
  ret=$?
  echo "$* -> $ret" | tee -a "$log"
  sync
  return $ret
}

# systemd services
for service in $wants; do
  log systemctl start $service
  sleep 2
done

# upstart services
for conf in /etc/init/*.conf; do
  service=${conf##*/}; service=${service%.conf}
  log service ${service} start
  sleep 2
done

# sysvinit services
for service in /etc/rc3.d/S*; do
  log ${service} start
  sleep 2
done

Mon ordinateur est tombé en panne après le démarrage sssd. À partir de là, une recherche Web sur «sssd linux kernel hang» m'a conduit à https://bugs.launchpad.net/cloud-images/+bug/1746806 et au diagnostic et à la solution.