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 so bei Compute Engine authentifizieren.
    <x0A>

    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. After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      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.

          After installing the Google Cloud CLI, initialize it by running the following command: 

          gcloud init

          If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

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

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 andere Form von Kernel-Panic kann auftreten, wenn der Kernel nicht weiß, wie er eine bestimmte Anfrage verarbeiten soll, und sich selbst schützt, indem er die Verarbeitung beendet. 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, der dem Kernel entspricht, ist in der Datei grub.cfg nicht vorhanden.
  • Die Datei initramfs wird während der Kernelinstallation nicht im Verzeichnis /boot generiert.
  • Die Datei initramfs wird nur teilweise generiert oder ist beschädigt.

Symptome

Wenn auf einer VM-Instanz ein Kernel-Panic auftritt, ist ein häufiges Symptom, dass der Kernel keine Verbindung zur VM zulässt, auch nicht über die serielle Konsole.

Sie sollten die Logs der seriellen Konsole prüfen, um den vom Gastbetriebssystem geladenen Kernel zu ermitteln, z. B.: 

[    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 (mockbuild@x86-vm-42.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Thu Aug 10 10:46:21 EDT 2023
Prüfen Sie auch den Kernel-Panik-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-Panik-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 Konsole in 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 herstellen.

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

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

    1. Generieren Sie die Datei initramfs, die dem ursprünglichen Kernel entspricht, mit dem Befehl dracut:

      dracut -f /boot/initramfs-KERNEL_VERSION.img KERNEL_VERSION

      Ersetzen Sie KERNEL_VERSION durch die aktuelle Kernelversion der VM. Beispiel: 3.10.0-1160.95.1.el7.x86_64.

    2. Aktualisieren Sie die Datei grub2.cfg mit dem Befehl grub2-mkconfig, z. B.:

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

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