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 bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

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

      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.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        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 der Kernelpanik kann in einer Situation auftreten, in der der Kernel nicht weiß, wie er mit einer bestimmten Anfrage umgehen soll, und sich durch Anhalten 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, der sich auf die initramfs-Datei bezieht, die dem Kernel entspricht, ist in der grub.cfg-Datei 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 bei einer VM-Instanz ein Kernel-Panik auftritt, können Sie häufig nicht über den Kernel eine Verbindung zur VM herstellen, 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-Panikfehler. 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

So beheben Sie den Kernel-Panikfehler:

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

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

  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 Sie auf die VM zugreifen können, können Sie eine SSH-Verbindung zur VM herstellen.

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

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

    1. Generieren Sie die initramfs-Datei für den ursprünglichen Kernel 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. so:

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

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