Bootprobleme einer Linux-VM aufgrund von Kernel-Panik beheben

Dieses Dokument enthält Informationen zur Fehlerbehebung für eine VM, die aufgrund von Kernel Panic-Fehlern nicht mehr reagiert.

Hinweise

  • Wenn Sie Cloud Logging zum Logging der Ausgabe des seriellen Ports verwenden möchten, machen Sie sich mit Cloud Logging vertraut.
  • Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud-Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich wie folgt bei Compute Engine authentifizieren.

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.

        Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl: 

        gcloud init

      Weitere Informationen finden Sie unter Für die Verwendung von REST authentifizieren in der Dokumentation zur Google Cloud-Authentifizierung.

Kernel Panic

Ein Kernel Panic kann auftreten, wenn der Kernel nicht ordnungsgemäß initramfs-Module laden kann, die für das Booten des Gastbetriebssystems erforderlich sind.

Eine weitere Form von Kernel Panic kann in einer Situation auftreten, in der der Kernel nicht weiß, wie eine bestimmte Anfrage verarbeitet werden soll, und sich selbst durch Beenden schützt. Kernel Panic kann auf einer Compute Engine-VM unter RedHat, SUSE, CentOS oder Ubuntu auftreten.

Häufige Fehlermeldungen

Im Folgenden sind einige der häufigsten Kernel Panic-Ereignisse als Beispiel aufgeführt:

Kernel panic - not syncing: hung_task: blocked tasks
Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Kernel panic - not syncing: NMI: Not continuing
Kernel panic - not syncing: out of memory. panic_on_oom is selected
Kernel panic - not syncing: Fatal Machine check

Allgemeine Ursachen

Der Kernel Panic-Fehler kann aus verschiedenen Gründen auftreten. Einige der häufigsten Gründe sind:

  • Der Eintrag für die Datei initramfs, die dem Kernel entspricht, ist nicht in der Datei grub.cfg vorhanden.
  • Die Datei initramfs wird während der Kernel-Installation nicht im Verzeichnis /boot generiert.
  • Die Datei initramfs wird nur teilweise generiert oder ist beschädigt.

Symptome

Wenn bei einer VM-Instanz eine Kernel Panic auftritt, ist ein häufiges Symptom, dass der Kernel keine Verbindung zur VM zulässt, auch nicht bei Verwendung der seriellen Konsole.

Sie sollten die Logs der seriellen Konsole prüfen, um den Kernel zu ermitteln, der vom Gastbetriebssystem geladen wurde. Beispiel: 

[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.0-1160.95.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Thu Aug 10 10:46:21 EDT 2023
Überprüfen Sie auch den Kernel Panic-Fehler. Dieser Fehler tritt normalerweise entweder in der Kernel-Zeile beim Start der VM oder am Ende der Logs der seriellen Konsole mit mehreren Stack-Aufruf-Traces auf.

Das folgende Beispiel zeigt ein Kernel Panic-Ereignis aufgrund von initramfs-Problemen:

[    1.520840] No filesystem could mount root, tried:
[    1.520840]
[    1.521964] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.523495] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.0-1160.95.1.el7.x86_64 #1
[    1.524932] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
[    1.526901] Call Trace:
[    1.527421]  dump_stack+0x41/0x60
[    1.527978]  panic+0xe7/0x2ac
[    1.528578]  mount_block_root+0x2be/0x2e6
[    1.529693]  ? do_early_param+0x95/0x95
[    1.530441]  prepare_namespace+0x135/0x16b
[    1.531237]  kernel_init_freeable+0x203/0x22d
[    1.532081]  ? rest_init+0xaa/0xaa
[    1.532808]  kernel_init+0xa/0x103
[    1.533395]  ret_from_fork+0x35/0x40
[    1.535229] Kernel Offset: 0x23a00000 from 0xffffffff81000000

Kernel Panic-Fehler beheben

Führen Sie die folgenden Schritte aus, um den Kernel Panic-Fehler zu beheben:

  1. Stellen Sie eine Verbindung zur seriellen Konsole her und melden Sie sich über die Google Cloud Console bei der VM an.

  2. Klicken Sie in der Google Cloud Console für die VM auf Zurücksetzen.

  3. Wenn der GRUB-Ladebildschirm angezeigt wird, wählen Sie den zuvor funktionierenden Kernel oder Rettungs-Kernel aus und starten Sie dann das System. Dadurch wird die VM mit dem ausgewählten Kernel gestartet.

    Kernel Panic

  4. Wenn die VM zugänglich ist, können Sie eine SSH-Verbindung zur VM initiieren.

  5. Ermitteln Sie die Ursache des Problems und ergreifen Sie entsprechende Maßnahmen.

    Wenn die Datei initramfs beispielsweise fehlt oder beschädigt ist, führen Sie die folgenden Schritte aus:

    1. Generieren Sie die Datei initramfs für den ursprünglichen Kernel mit dem Befehl dracut. Beispiel:

      dracut -f /boot/initramfs-3.10.0-1160.95.1.el7.x86_64.img 3.10.0-1160.95.1.el7.x86_64

    2. Aktualisieren Sie die Datei grub2.cfg mit dem Befehl grub2-mkconfig. Beispiel:

      grub2-mkconfig -o /boot/grub2/grub.cfg

    3. Nachdem die Datei initramfs generiert wurde, können Sie die VM ohne Fehler neu starten.