Absturz während des Startvorgangs auf einem aktuellen Firmencomputer

Nach einigen kürzlichen Updates bootet mein Computer nicht mehr! Folgendes könnte ich feststellen:

• Dies ist ein sehr neuer Computer, der mir von der Unternehmens-IT zur Verfügung gestellt wurde. Es hat eine neuere Intel-CPU (Skylake-Generation).
• Auf dem Computer läuft Ubuntu 16.04.
• Der Computer wurde zuletzt im März einige Zeit korrekt gestartet. Das Problem ist vermutlich auf ein Software-Update oder einen Hardware-Fehler zurückzuführen.
• Ich habe einen anderen Computer mit 16.04, auf dem so ziemlich dieselbe Software installiert ist (ich habe sie verwendet apt-clone), und er funktioniert einwandfrei. Es hat unterschiedliche Hardware (auch amd64, aber unterschiedliche CPU, unterschiedliche GPU, etc.).
• Der Kernel startet, die initrd funktioniert korrekt. Wenn ich mit einem Begrüßungsbildschirm im Grafikmodus boote, werde ich zur Eingabe des Kennworts für mein dm-crypt-Volume aufgefordert. Als letztes sehe ich, dass es erfolgreich gemountet wurde.
• Der Hang tritt auf, bevor ich eine Anmeldeaufforderung erhalte. Wenn der Computer hängt, ist es ein harter Hang. Sogar Alt+ SysRqantwortet nicht. Die CPU ist offenbar zu 100% ausgelastet, da die Lüfter auf Hochtouren laufen.
• Ich habe immer noch den Kernel, den ich vor dem Neustart ausgeführt habe. Wenn ich diesen Kernel im Grub-Menü auswähle, erhalte ich die gleiche Sperrung. Es sieht also so aus, als ob dies ein bereits vorhandener Kernel-Fehler ist, der von etwas anderem ausgelöst wird - aber was?
• Wenn ich den Begrüßungsbildschirm ausschalte ( splashvon der linuxBefehlszeile in Grub entfernen ), werden eine Reihe von Diensten gestartet, und der Bildschirm stürzt ab .

• Ich kann eine Root-Shell erhalten, indem ich init=/bin/shsie der linuxBefehlszeile in Grub hinzufüge . Ich kann durch Hinzufügen sogar noch weiter kommen

  systemd.unit=basic.target systemd.shell
  

  Dies startet eine Reihe von Diensten und führt eine Root-Shell auf tty9 aus.

• Wenn ich systemctl start multi-user.targetvon dieser Root-Shell aus starte, stürzt der Computer ab. Vermutlich wird das Problem also von einem dieser Dienste ausgelöst.
• Ich bin gelaufen, um systemctl list-dependencies multi-user.targetzu sehen, welche Dienste gestartet werden. Ich habe die aufgelisteten Abhängigkeiten einzeln manuell gestartet, und alles hat gut angefangen.

Das sieht also wie ein Hardware-Fehler aus (da er auf einem Computer auftritt, auf dem anderen jedoch nicht), der von einer bestimmten Software ausgelöst wird. Aber welche Software? Da der Computer so stark abstürzt, kann ich keine Protokolle abrufen. Ich kann nicht einmal eine nützliche Konsolenausgabe erhalten.

Nützliche Debugging-Techniken:

• Alt+ SysRq: magische SysRq-Taste , mit der Sie beispielsweise einen Notfall-Neustart durchführen können. Es greift auf den Kernel auf einer sehr niedrigen Ebene zu, sodass es bei allen außer den schlimmsten Abstürzen funktioniert. In meinem Fall reagiert Alt+ SysRqnicht, was zeigt, wie tief der Absturz geht.
• Um die Boot-Parameter zu ändern, halten Sie Shifteinige Sekunden nach dem Einschalten gedrückt. Sie müssen ihn drücken, nachdem das BIOS die Tastatur initialisiert hat, aber bevor das Betriebssystem startet. Dadurch wird das Grub- Menü angezeigt.
• Drücken Sie im Grub-Menü, eum die Befehlszeile für einen Menüeintrag zu bearbeiten. Navigieren Sie zu der Zeile, die mit beginnt, um die Linux-Startparameter zu ändern linux. Auf einem modernen Ubuntu finden Sie alte Kernel unter "Erweiterte Optionen für Ubuntu". Wenn Sie die gewünschten Änderungen in der Befehlszeile vorgenommen haben, drücken Sie Ctrl+, xum den Computer zu starten. Alle Änderungen, die Sie hier vornehmen, gelten nur für diesen Start. Sie werden nicht auf der Festplatte gespeichert.
• Einige nützliche Optionen in der linuxBefehlszeile:
  • quiet nosplashverbirgt fast alle Bootmeldungen. Entfernen Sie sie, um während des Startvorgangs Meldungen auf der Konsole zu erhalten, die erforderlich sind, um Probleme zu diagnostizieren.
  • recoverygibt Ihnen eine Root-Shell mit fast keinen Diensten. Sie müssen das root-Passwort kennen. Der Menüeintrag „Wiederherstellungsmodus“ verwendet dies.
  • init=/bin/shgibt Ihnen eine Root-Shell ohne Dienste überhaupt. Führen Sie den folgenden Befehl aus, um den normalen Startvorgang fortzusetzen exec init. Sie können an dieser Stelle systemd-Optionen übergeben, z. B. exec init --unit=basic.targetum init und einige Dienste zu starten (beachten Sie, dass dies keine Möglichkeit zur Anmeldung bietet, sodass eine Shell auf einer anderen Konsole ausgeführt werden sollte). Beachten Sie, dass das Root-Dateisystem schreibgeschützt bereitgestellt ist. laufen mount -o remount,rw /, um schreiben zu können.
  • systemd.unit=basic.targetstartet eine sehr grundlegende Reihe von Diensten. Beachten Sie, dass dies keine Art der Anmeldung beinhaltet! Sie können dies zur Standardeinstellung machen, indem Sie systemctl set-default basic.targetan einer Root-Eingabeaufforderung ausführen. Führen Sie zum Wiederherstellen des ursprünglichen Standardziels systemctl set-default graphical.target(oder systemctl set-default multi-user.targeteinen Server ohne GUI) aus.
  • systemd.debug-shellStartet eine Root-Shell auf tty9. Sie können dies für jeden Start aktivieren, indem Sie systemctl enable debug-shellan einer Root-Eingabeaufforderung ausführen. Vergessen Sie nicht, dies zu deaktivieren, nachdem Sie das Problem mit behoben haben systemctl disable debug-shell. Drücken Sie Alt+ F9wechseln tty9.
  • Siehe auch Fedora systemd Tipps , Arch Linux - Boot - Problem Tipps .

Das Problem

Es stellt sich heraus, dass mein Problem ein bekanntes Problem zwischen dem neuesten Intel-Mikrocode auf (einigen?) Skylake-CPUs und neueren Linux-Kerneln ist, das hauptsächlich von sssd ausgelöst wird . Siehe Ubuntu-Fehler # 1759920 „Intel-Microcode 3.20180312.0 führt zu einem Absturz des Anmeldebildschirms (mit Linux-Image-4.13.0-37-generic)“ sowie eine Reihe anderer Fehler, bei denen es sich um dasselbe Problem handelt , wie der Ubuntu-Fehler # 1746806 "sssd scheint AWS c5- und m5-Instanzen zum Absturz zu bringen, verursacht 100% CPU" und der Ubuntu-Fehler # 1746418 "System friert beim Starten von Xorg nach der Installation von linux-image-4.13.0-32-generic ein" . Dieser Fehler tritt wahrscheinlich auf, wenn:

• Sie haben eine sehr neue Intel-CPU. Soweit ich das beurteilen kann, tritt dieser Fehler nur bei Skylake- CPUs auf.
• Sie haben das Intel-Microcode- Paket installiert. Das Zurücksetzen auf einen früheren, getesteten Kernel hat bei mir nicht funktioniert, da ich diesen Kernel nur mit einem früheren Mikrocode ausgeführt habe.
• Ihr Computer ist zur Benutzerauthentifizierung mit einem Unternehmensnetzwerk (normalerweise LDAP oder Active Directory) verbunden. Obwohl es andere Möglichkeiten gibt, den Fehler auszulösen, scheint es der häufigste Schuldige zu sein , sssd auszuführen . Es gibt auch Berichte über Abstürze von Xorg .

Der Fehler ist darauf zurückzuführen, dass das im Januar 2018 veröffentlichte Spectre- Sicherheitsproblem behoben wurde. Es besteht eine Inkompatibilität zwischen Kernel-Code und Prozessor-Mikrocode , die unter bestimmten Umständen zu einem Absturz führt.

Wie zu reparieren

1. Wenn Sie nicht normal booten können, müssen Sie die Kernel-Befehlszeile an der Grub-Eingabeaufforderung bearbeiten. In der Frage finden Sie Erklärungen und mögliche Wege, um eine Root-Shell zu erhalten.
2. Eine Problemumgehung für diesen bestimmten Fehler besteht darin , den noibpbParameter zur Kernel-Befehlszeile hinzuzufügen ( 1746418/14 , 1759920/56 ). Dadurch sollten Sie normal booten und einige Reparaturen durchführen können.
   Dadurch wird die Schwachstellenbegrenzung deaktiviert, die das Problem verursacht. Dies bedeutet, dass Ihr Computer jetzt für einige Angriffe anfällig ist. Es handelt sich um lokale Angriffe, dh der Angreifer muss Code auf Ihrem Computer ausführen. Diese Angriffe können jedoch möglicherweise z. B. über JavaScript in einem Webbrowser ausgeführt werden.
   Wenn Sie keine andere Möglichkeit haben, können Sie diese permanent machen, indem Sie noibpbder Kernel-Befehlszeile hinzufügen , bis Sie einen festen Kernel erhalten.
3. In Ubuntu wird das Update in der Woche vom 23. April 2018 erwartet , voraussichtlich in Kernel 4.4.0-117 und 4.13.0-39. In der Zwischenzeit hat Tyler Hicks Testkerne für 4.4 und 4.13 veröffentlicht .

Wie ich das Problem diagnostiziert habe

Ich habe verschiedene Dinge ausprobiert (siehe Frage) und festgestellt, dass der Fehler irgendwo zwischen Erreichen basic.targetund Erreichen ausgelöst wurde multi-user.target. Also habe ich das Standardziel systemd auf basic.target( systemctl set-default basic.target) gesetzt und den debug-shellDienst ( systemctl enable debug-shell) aktiviert , um eine Root-Shell zu erhalten.

Ich habe systemctl list-dependencies multi-user.targetdie aufgeführten Abhängigkeiten einzeln ausgeführt und manuell gestartet. Dies hat den Absturz nicht ausgelöst.

Nicht alle Dienste werden direkt von systemd verwaltet . Einige werden als Upstart- Dienste verwaltet, andere als SysVinit-Skripte . Das folgende Shell-Skript führt alle aus. Hinweis: Ich habe es nur einmal getestet und es stürzte ab.

#!/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

Mein Computer ist nach dem Start abgestürzt sssd. Von dort aus führte mich eine Websuche zu "sssd linux kernel hang" zu https://bugs.launchpad.net/cloud-images/+bug/1746806 und zur Diagnose und Lösung.