Kernel-Panik in Azure Linux-VMs

Gilt für: ✔️ Linux-VMs

Zusammenfassung

In diesem Artikel werden mehrere Bedingungen erläutert, die zu einer Kernel-Panik führen können, und enthält Anleitungen zur Problembehandlung.

Im Allgemeinen ist eine Kernel-Panik eine Situation, in der der Kernel nicht ordnungsgemäß geladen werden kann, und daher kann das System nicht gestartet werden. Eine andere Art von Kernel-Panik tritt auf, wenn der Kernel auf eine Situation trifft, die er nicht weiß, wie er handhaben soll, und sich selbst schützt, indem er stoppt.

Voraussetzungen

Stellen Sie sicher, dass die serielle Konsole in der Linux-VM aktiviert und funktionsfähig ist.

Wie kann man eine Kernel-Panik identifizieren?

Verwenden Sie das Azure Portal, um die Ausgabe des seriellen Konsolenprotokolls des virtuellen Computers im Blatt "Startdiagnose", dem seriellen Konsolenblatt oder AZ CLI anzuzeigen, um die spezifische Kernel-Panikzeichenfolge zu identifizieren.

Eine Kernel-Panik sieht ähnlich wie die nachstehende Ausgabe aus und wird am Ende des seriellen Konsolenprotokolls angezeigt:

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

Einige der häufigsten Kernel-Panikereignisse:

Paniknachricht Ursache
Oops: 0000 [#1] SMP " (Protokolldatei auf Details überprüfen) Das System ist aufgrund der Ableitung einer schlechten Adresse in Panik geraten.
SysRq: Auslösen eines Speicherabbildes Das Kernabbild wurde vom Benutzer mit sysrq-c initiiert oder durch das Eingeben des Befehls "echo c" in /proc/sysrq-trigger.
Kernel-Fehler bei <pathname/filename>:<Zeilennummer>! Dieses Format ist der Standard für eine fehlgeschlagene BUG-Prüfung (genau wie eine ASSERT-Anweisung, aber die Logik ist invertiert). Der Dateiname und die Zeilennummer geben an, welcher Bug-Check fehlgeschlagen ist.
Kernel-Panic - nicht synchronisiert: Softlockup: hung tasks Der Soft Lockup-Detektor hat eine CPU gefunden, die den Watchdog-Vorgang nicht innerhalb des Schwellenwerts für die weiche Sperrung geplant hat.
Kernel-Panik - nicht synchronisierend: Watchdog erkannte hartes LOCKUP auf CPU 0 Der Hard Lockup-Detektor hat eine CPU gefunden, die keine Hrtimer-Unterbrechungen innerhalb des Sperrschwellenwerts erhalten hat.
Kernel-Panik - nicht synchronisiert: hung_task: blockierte Aufgaben Der Watchdog für hängen gebliebene Aufgaben hat mindestens eine Aufgabe erkannt, die sich für mehr als den Wert des blockierten Aufgabentimeouts in einem nicht unterbrechbaren Zustand befand.
Kernel-Panik - nicht mehr synchronisiert: Speichermangel. panic_on_oom ist ausgewählt. Das System hat keinen Speicher und Swap mehr und wurde gezwungen, Prozesse zu beenden, um Speicher freizugeben (nicht das Standardverhalten).
Kernel-Panik - nicht synchronisiert: Speichermangel und keine abbrechbaren Prozesse... Das System hat keinen Arbeitsspeicher und Swap mehr und hat Prozesse beendet, um Speicher freizugeben, aber es sind keine weiteren Prozesse mehr zum Beenden vorhanden.
Kernel-Panik - nicht synchronisieren: Ein NMI ist aufgetreten, Details finden Sie im integrierten Verwaltungsprotokoll. Watchdog hat einen NMI abgefangen (nicht maskierbarer Interrupt).
Kernel-Panik - nicht synchronisiert: NMI IOCK-Fehler: Nicht fortgesetzt Das System hat eine E/A-Prüfung von der Hardware erhalten (kein Speicherparitätsfehler), und kernel.panic_on_io_nmi wurde aktiviert (nicht der Standardwert).
Kernel-Panik - nicht synchronisiert: NMI: Nicht fortgesetzt Das System hat ein NMI (entweder einen Hardware- oder einen Speicherparitätsfehler) erhalten, und kernel.panic_on_unrecovered_nmi wurde festgelegt, was nicht dem Standardwert entspricht.
Kernel-Panik - nicht synchronisiert: NMI Watchdog Das System erhielt einen NMI, und entweder kernel.panic_on_timeout oder kernel.panic_on_oops festgelegt wurde (nicht die Standardwerte).
Kernel-Panik - nicht synchronisiert: Tödliche Computerüberprüfung Für einen schwerwiegenden Fehlerzustand wurde ein Ausnahmeereignis für die Maschinenüberprüfung ausgelöst.
Kernel-Panik - nicht synchronisiert: Versucht, init zu töten! Der Init-Prozess ist der erste zu startende Prozess und sollte nie beendet werden.
Kernel-Panik - nicht synchronisiert: VFS: Root fs kann nicht auf unbekannten Block (0,0) bereitgestellt werden. Es wird davon ausgegangen, dass der Kernel ein Initramfs verwendet, um die Rootfs zu mounten. Dieser Fehler tritt auf, wenn der Kernel keine Initramfs aufweist.

Szenario 1: Kernel-Panik tritt zur Startzeit auf

Eine Kernel-Panik zur Startzeit verhindert, dass der virtuelle Computer den Startvorgang des Betriebssystems beendet. Dies geschieht jedes Mal, wenn die virtuelle Maschine gestartet wird und die Anmeldung nicht möglich ist.

Diese Art von Ereignis ist häufig verwandt, aber nicht beschränkt auf:

Lösung für Szenario 1

Um mit dieser Art von Kernel-Panik umzugehen, können die folgenden Ansätze verwendet werden:

Methode 1: Verwenden der seriellen Azure Konsole

Verwenden Sie die serielle konsole Azure, um den Startvorgang zu unterbrechen und ggf. eine frühere Kernelversion auszuwählen. Auf diese Weise kann der virtuelle Computer erneut gestartet werden, und Sie können dann eine der folgenden Methoden verwenden, um das spezifische Problem mit dem nicht bootenden Kernel zu beheben:

Methode 2: Offlinereparatur mit einem virtuellen Rettungscomputer

Falls die serielle Azure Konsole nicht verfügbar ist oder kein vorheriger Kernel verfügbar ist, benötigen Sie eine Rettungs-/Reparatur-VM, um eine Offlinereparatur auszuführen.

Verwenden Sie den Befehl "VM reparieren" , um eine Reparatur-VM zu erstellen, die über eine Kopie des Betriebssystemdatenträgers der Ziel-VM verfügt. Verwenden Sie dann chroot, um die Kopie der Betriebssystemdateisysteme in der Reparatur-VM einzubinden. Versuchen Sie danach die folgenden Methoden, um die Kernelprobleme zu beheben:

Szenario 2: Kernel-Panik zur Laufzeit

Diese Art von Kernel-Panik wird häufig zu unvorhersehbaren Zeiten ausgelöst, nachdem der Startvorgang des Betriebssystems abgeschlossen wurde und bewirkt, dass die VM nicht mehr reagiert und verhindert, dass sie sich anmeldet. Es ist häufig verwandt, aber nicht beschränkt auf:

Lösung für Szenario 2

Um mit dieser Art von Kernel-Panik umzugehen, können die folgenden Ansätze verwendet werden:

  • Überprüfen Sie die Ressourcennutzung und die Gesamtleistung des Systems. Die Kernel-Panik kann mit einem möglichen Ressourcenmangel zusammenhängen, der zu einer VM-Größenänderung führen könnte.
  • Installieren Sie nach Möglichkeit die neuesten Updates, die in den entsprechenden Linux-Distributionsrepositorys verfügbar sind. Die Kernel-Panik kann mit bekannten Fehlern in der Kernel- oder anderen Software zusammenhängen.
  • Es besteht die Möglichkeit, dass die Kernel-Panik mit einer aktuellen Kerneländerung zusammenhängt, in diesem Fall ist es auch ratsam, über eine frühere Kernelversion zu starten, wie in Der Lösung für Szenario 1 erläutert.
  • Wenn die oben genannten Optionen nicht anwendbar sind, kann es erforderlich sein, kdump zu konfigurieren und ein Speicherabbild zu erstellen, um es mit dem Support für weitere Analysen zu teilen.

Spezifischere Kernel-Panikszenarien

Häufige Kernel-Panikszenarien mit spezifischen Anleitungen zur Problembehandlung/Wiederherstellung:

Dokument Szenario
Eine Azure-Linux-VM auf einem 3.10-basierten Kernel panikt nach einem Host-Knoten-Upgrade In diesem Artikel wird ein Problem erläutert, das auftritt, wenn ein Azure Linux-VM, auf dem der 3.10-basierte Kernel ausgeführt wird, nach einem Hostknotenupgrade in Azure abstürzt.
Wie sie einen Azure virtuellen Linux-Computer aus kernelbezogenen Startproblemen wiederherstellen Dieser Artikel enthält Lösungen für ein Problem, bei dem ein virtueller Linux-Computer (VM) nach dem Anwenden von Kerneländerungen nicht neu gestartet werden kann.
  • Last updated on