Freigeben über

Kernel-Panik in Azure Linux-VMs

  • Artikel

Gilt für: ✔️ Linux-VMs

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 Form von Kernel-Panik tritt auf, wenn der Kernel auf eine Situation trifft, die es nicht weiß, wie man sich selbst behandeln und schützt, indem er beendet wird.

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 die Azure-Portal, um die Ausgabe des seriellen Konsolenprotokolls des virtuellen Computers im Blatt "Startdiagnose", dem seriellen Konsolenblatt oder der 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 " (Protokoll für Details überprüfen) Das System ist aufgrund der Ableitung einer schlechten Adresse in Panik geraten.
SysRq: Auslösen eines Absturzdumps Das Kernabbild wurde mit sysrq-c oder durch Echo c in /proc/sysrq-trigger initiiert.
kernel BUG at <pathname/filename>:<line number>! Dieses Format ist der Standard für eine fehlerhafte FEHLERprüfung (genau wie eine ASSERTION, aber die Logik ist invertiert). Der Dateiname und die Zeilennummer geben an, welche FEHLERüberprüfung fehlgeschlagen ist.
Kernel panik - nicht synchronisieren: 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 synchronisiert: Watchdog erkannte hard 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 die nicht unterbrochene Aufgabe hat mindestens einen Vorgang erkannt, der für mehr als den Wert des blockierten Vorgangstimeouts in einem nicht unterbrechungsfähigen Zustand war.
Kernel-Panik - nicht synchronisiert: aus dem Arbeitsspeicher. panic_on_oom ist ausgewählt. Das System ist nicht mehr genügend Arbeitsspeicher und wechselt und wurde gezwungen, mit dem Töten von Prozessen zu beginnen, um Arbeitsspeicher freizugeben (kein Standardverhalten).
Kernel-Panik - nicht synchronisieren: Nicht im Arbeitsspeicher und keine killablen Prozesse... Das System ist nicht mehr genügend Arbeitsspeicher und austauscht und hat Prozesse getötet, um Arbeitsspeicher freizugeben, aber es sind keine Prozesse mehr zum Abtöten vorhanden.
Kernel-Panik - nicht synchronisiert: 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 festgelegt wurde (nicht der Standardwert).
Kernel-Panik - nicht synchronisiert: NMI: Nicht fortgesetzt Das System hat einen NMI (Hardware- oder Speicherparitätsfehler) erhalten, und kernel.panic_on_unrecovered_nmi festgelegt wurde (nicht der Standardwert).
Kernel-Panik - nicht synchronisieren: 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 eine schwerwiegende Bedingung wurde ein Ausnahmeereignis für die Computerü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.

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 der virtuelle Computer gestartet wird und die Anmeldung nicht zulässig 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 Azure-Konsole, 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 mount die Kopie der Betriebssystemdateisysteme in der Reparatur-VM. 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 Kernabbild zu generieren, um die Unterstützung für weitere Analysen zu teilen.

Spezifischere Kernel-Panikszenarien

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

Document Szenario
Ein virtueller Azure Linux-Computer mit einem 3.10-basierten Kernel gerät nach einem Hostknotenupgrade in Panik In diesem Artikel wird ein Problem erläutert, das auftritt, wenn eine Azure Linux-VM, die den 3.10-basierten Kernel ausführt, nach einem Hostknotenupgrade in Azure abstürzt.
Wiederherstellen einer Azure Linux-VM bei kernelbezogenen Startproblemen 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.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.