Startprobleme von Linux-Compute Engine-Instanzen beheben

In diesem Dokument erfahren Sie, warum Ihre Linux-Compute Engine-Instanz nicht gestartet werden kann, und wie Sie häufige Probleme beheben.

Eine Compute-Instanz, die nicht gestartet werden kann, weist in der Regel eines oder mehrere der folgenden Symptome auf:

  • Die Compute-Instanz hat den Status RUNNING, aber Sie können keine SSH-Verbindung zu ihr herstellen.
  • Die Ausgabe der seriellen Konsole wird während der Bootsequenz unterbrochen oder endet mit einem Notfall- oder Rettungsprompt.
  • Die Ausgabe der seriellen Konsole enthält FAILED, error:, Kernel panic oder emergency mode.

Um ein Bootproblem zu beheben, müssen Sie zuerst die Ursache ermitteln. Anschließend können Sie das Problem entweder in der Compute-Instanz beheben, wenn Sie noch eine Verbindung herstellen können, oder offline, indem Sie das Bootlaufwerk an eine andere Compute-Instanz anhängen.

Wenn die Compute-Instanz hochgefahren wurde, Sie aber keine Verbindung zu ihr herstellen können, lesen Sie den Abschnitt SSH-Fehler beheben.

Hinweis

  • Achten Sie darauf, dass die Compute-Instanz die Ausgabe der seriellen Konsole schreibt. Die Ausgabe des seriellen Ports ist verfügbar, während die Compute-Instanz ausgeführt wird. Wenn Sie sie nach dem Beenden der Compute-Instanz beibehalten möchten, aktivieren Sie das Logging des seriellen Ports in Cloud Logging. Weitere Informationen finden Sie unter Ausgabe des seriellen Ports ansehen.
  • 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:

    1. Installieren Sie die Google Cloud CLI. Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl: 

      gcloud init

      Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

    2. Legen Sie eine Standardregion und -zone fest.

Ursache automatisch erkennen

Bevor Sie die Ausgabe der seriellen Konsole manuell lesen, verwenden Sie eines der folgenden Tools. Jede liest die Ausgabe des letzten Starts der Compute-Instanz, gibt die wahrscheinlichste Ursache an und verweist auf den entsprechenden Abschnitt in diesem Dokument.

Console

  1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

    Zur Seite „VM-Instanzen“

  2. Klicken Sie in der Zeile für die Compute-Instanz auf SSH.

  3. Wenn die Verbindung fehlschlägt, klicken Sie im Verbindungsdialogfeld auf Fehlerbehebung. Die Fehlerbehebung führt Konnektivitätsprüfungen durch, einschließlich einer Bootprüfung, bei der die Ausgabe der seriellen Konsole analysiert wird.

gcloud

Wenn Sie eine Compute-Instanz prüfen möchten, zu der Sie keine SSH-Verbindung herstellen können, führen Sie die gcloud CLI-Fehlerbehebung für SSH aus. Dabei werden Konnektivitätsprüfungen und eine Boot-Prüfung durchgeführt:

gcloud compute ssh INSTANCE_NAME --zone=ZONE --troubleshoot

Wenn Sie die Boot-Sequenz direkt prüfen möchten, führen Sie den Boot-Diagnosebefehl aus:

Wenn Sie diesen Befehl verwenden möchten, müssen Sie die Komponente Alphabefehle installiert haben.

gcloud alpha compute diagnose boot INSTANCE_NAME --zone=ZONE

Ersetzen Sie Folgendes:

  • INSTANCE_NAME: der Name der Compute-Instanz.
  • ZONE: Die Zone, die die Compute-Instanz enthält.

Wenn ein Startproblem erkannt wird, wird in der Ausgabe die Ursache genannt und ein Link zur Lösung angegeben. Wenn kein Problem gefunden wird, fahren Sie mit den manuellen Schritten fort.

Ausgabe der seriellen Konsole lesen

Wenn die Tools kein Problem erkennen oder Sie die Ursache bestätigen möchten, lesen Sie die Ausgabe der seriellen Konsole selbst:

Console

  1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

    Zur Seite „VM-Instanzen"

  2. Wählen Sie die Compute-Instanz aus, für die Sie die Ausgabe des seriellen Ports ansehen möchten.

  3. Klicken Sie unter Logs auf Serieller Port 1 (Konsole).

gcloud 

gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE

Ersetzen Sie Folgendes:

  • INSTANCE_NAME: der Name der Compute-Instanz.
  • ZONE: Die Zone, die die Compute-Instanz enthält.

Zum letzten Startvorgang wechseln Die relevanten Zeilen befinden sich in der Regel unmittelbar vor der ersten [FAILED]-Zeile, der Kernel panic-Zeile oder der Notfallaufforderung. Vergleichen Sie die Ergebnisse mit den Signaturen in den folgenden Abschnitten.

Häufige Bootprobleme

In den folgenden Abschnitten werden häufige Bootfehler auf Linux-Compute-Instanzen, ihre Signaturen in der seriellen Konsolenausgabe und Möglichkeiten zur Fehlerbehebung aufgeführt. Für die meisten Lösungen müssen Sie das Bootlaufwerk an eine Rettungs-VM anhängen, wie unter Laufwerk offline reparieren beschrieben.

/etc/fstab-Dateieintrag kann nicht gemountet werden

Symptom:Die Ausgabe der seriellen Konsole enthält Zeilen wie die folgenden, gefolgt von You are in emergency mode:

UUID=1234abcd-... does not exist
Timed out waiting for device /dev/sdb1
mount: special device /dev/sdb1 does not exist
[DEPEND] Dependency failed for /mnt/data.mount

Ursache: Ein Eintrag in /etc/fstab bezieht sich auf ein Gerät oder eine UUID, die nicht mit der Compute-Instanz verbunden ist, oder das Dateisystem kann nicht bereitgestellt werden. Der Dienst systemd stoppt den Startvorgang und wechselt in den Notfallmodus.

Lösung:Korrigieren Sie auf der Notfall-VM den Eintrag in /etc/fstab auf dem bereitgestellten Laufwerk oder entfernen Sie ihn. Eine Anleitung dazu finden Sie unter Startprobleme einer Linux-VM aufgrund von fstab-Fehlern beheben. Informationen zur Bereitstellungsoption, die verhindert, dass ein fehlendes Gerät den Bootvorgang blockiert, finden Sie unter Laufwerk bereitstellen.

GRUB kann seine Konfiguration oder den Kernel nicht laden

Symptom: Der Bootvorgang wird bei einer GRUB-Eingabeaufforderung beendet und die Ausgabe der seriellen Konsole enthält Zeilen wie die folgenden:

error: file '/boot/grub/grub.cfg' not found
error: file '/vmlinuz-6.1.0-18-amd64' not found
error: no such partition
error: no such device
error: unknown filesystem
error: you need to load the kernel first
grub rescue>
Minimal BASH-like line editing is supported

Ursache:Der GRUB-Bootloader kann seine Konfigurationsdatei, seine Module oder den Kernel und die anfängliche RAM-Disk, auf die sich die Konfiguration bezieht, nicht finden. Dieses Problem tritt nach einem fehlgeschlagenen Paket-Upgrade, einer Änderung des Partitionsschemas, einer neu formatierten oder beschädigten /boot-Partition oder einer geklonten Festplatte auf, deren UUIDs des Dateisystems sich geändert haben.

Lösung:Stellen Sie auf der Rettungs-VM das Bootlaufwerk bereit und rufen Sie eine chroot-Umgebung auf, wie unter VM retten beschrieben. Generieren Sie dann die GRUB-Konfigurationsdatei neu, wie unter Bootloader konfigurieren beschrieben. Wenn der Bootloader nicht repariert werden kann, stellen Sie das Laufwerk aus einem Snapshot wieder her.

Die erste RAM-Disk kann das Root-Dateisystem nicht bereitstellen

Symptom:Die Ausgabe der seriellen Konsole enthält Zeilen wie die folgenden:

dracut-initqueue[452]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut: FATAL: ...
Failed to mount /sysroot
ALERT! UUID=1234abcd-... does not exist. Dropping to a shell!
Gave up waiting for root file system device
VFS: Unable to mount root fs on unknown-block(0,0)

Ursache:Die erste RAM-Disk (initramfs) wurde gestartet, aber das Root-Dateisystem konnte nicht gefunden oder bereitgestellt werden. Häufige Ursachen sind ein root=-Kernelparameter oder eine UUID, die nicht mehr mit dem Laufwerk übereinstimmt, ein initramfs-Image, in dem der Treiber für das Laufwerk fehlt, oder ein beschädigtes initramfs-Image. Bei Maschinenreihen, die die NVMe-Laufwerksschnittstelle verwenden, stimmt eine Startkonfiguration, die das Laufwerk mit einem Gerätepfad wie /dev/sda benennt, nicht mehr überein. Verwenden Sie stattdessen die UUID.

Lösung:Prüfen Sie, ob das Root-Dateisystem, nach dem die erste RAM-Disk sucht, auf dem bereitgestellten Laufwerk vorhanden ist. Erstellen Sie dann die erste RAM-Disk für Ihr Betriebssystem neu. Eine Anleitung dazu finden Sie unter Startprobleme einer Linux-VM aufgrund von Kernel Panic beheben und Offline-Festplatte reparieren.

Beschädigung des Dateisystems

Symptom: Die Ausgabe der seriellen Konsole enthält Zeilen wie die folgenden:

Bad magic number in super-block
EXT4-fs error (device sda1): ...
XFS (sda1): Metadata corruption detected
XFS (sda1): log mount/recovery failed
BTRFS error (device sda1): ...
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Ursache:Das Dateisystem auf dem Bootlaufwerk ist beschädigt, in der Regel nach einem nicht ordnungsgemäßen Herunterfahren, einem vollen Laufwerk oder einem E/A-Fehler.

Lösung: Erstellen Sie einen Snapshot des Laufwerks. Prüfen und reparieren Sie dann auf der Notfall-VM das Dateisystem auf dem nicht bereitgestellten Laufwerk, wie unter Ermitteln, warum das Bootlaufwerk nicht gebootet wird beschrieben. Wenn das Dateisystem durch die Prüfung nicht repariert werden kann, stellen Sie das Laufwerk aus einem Snapshot wieder her.

Kernel Panic

Symptom: Die Ausgabe der seriellen Konsole enthält Kernel panic - not syncing:, gefolgt vom Grund, z. B. Attempted to kill init!, Fatal exception, hung_task: blocked tasks, Out of memory, Fatal Machine check oder NMI: Not continuing. Ein beschädigtes Kernel-Image wird mit -- System halted früher beendet.

Ursache:Im Kernel ist ein nicht behebbarer Fehler aufgetreten. Der Grund nach dem Doppelpunkt gibt die Kategorie an: ein abgestürztes init, eine Hardwareprüfung, ein Fehler aufgrund von Speichermangel oder ein beschädigtes Kernel-Image.

Lösung:Setzen Sie die Compute-Instanz zurück. Wenn die Kernel Panic wieder auftritt, lesen Sie den Abschnitt Startprobleme einer Linux-VM aufgrund von Kernel Panic beheben.

SELinux-Richtlinie kann nicht geladen werden

Symptom:Die Ausgabe der seriellen Konsole enthält eine der folgenden Meldungen und der Bootvorgang wird angehalten:

Failed to load SELinux policy
Unable to load SELinux policy

Möglicherweise wird auch Warning -- SELinux targeted policy relabel is required angezeigt. Dies ist kein Fehler: Die Compute-Instanz benennt das Dateisystem um und startet dann von selbst neu.

Ursache:Der SELinux-Richtlinienspeicher auf der Festplatte fehlt oder ist beschädigt oder Dateilabels sind nach einer Wiederherstellung oder einer Offline-Änderung inkonsistent.

Lösung:Markieren Sie auf der Rettungs-VM das bereitgestellte Laufwerk für eine vollständige SELinux-Neukennzeichnung beim nächsten Start oder installieren Sie die SELinux-Richtlinienpakete für Ihr Betriebssystem neu, wenn der Richtlinienspeicher beschädigt ist. Bei auf RHEL basierenden Betriebssystem-Images können Sie die Compute-Instanz starten lassen, während Sie die Richtlinie reparieren. Dazu setzen Sie SELinux in den moderaten Modus, wie unter SELinux in den moderaten Modus ändern beschrieben.

Das System kann den Prozess init nicht starten

Symptom:Die Ausgabe der seriellen Konsole enthält Zeilen wie die folgenden:

Failed to switch root
Target filesystem doesn't have requested /sbin/init
No working init found
run-init: /sbin/init: No such file or directory
/sbin/init: error while loading shared libraries: ...

Ursache:Das Root-Dateisystem wurde bereitgestellt, aber das init-Programm, z. B. systemd, fehlt, ist nicht ausführbar oder hängt von einer fehlenden gemeinsam genutzten Bibliothek ab. Dieses Problem tritt in der Regel nach einem unterbrochenen Paket-Upgrade oder einer unvollständigen Wiederherstellung auf.

Lösung:Geben Sie auf der Rettungs-VM eine chroot-Umgebung ein, wie unter VM retten beschrieben. Prüfen Sie, ob das Programm init vorhanden ist und ob die zugehörigen Bibliotheken intakt sind. Wenn dies nicht der Fall ist, installieren Sie das init-Systempaket mit dem Paketmanager Ihrer Distribution neu.

Notfallmodus und gesperrtes Root-Konto

Symptom:Die Ausgabe der seriellen Konsole endet mit einer der folgenden Meldungen:

You are in emergency mode. After logging in, type "journalctl -xb" to view system logs
Give root password for maintenance (or press Control-D to continue):
Cannot open access to console, the root account is locked.

Ursache: Eine Einheit ist beim Booten fehlgeschlagen und systemd wurde am Notfallziel beendet. Bei von Google bereitgestellten Betriebssystem-Images hat das Root-Konto kein Passwort. Die Notfall-Shell kann daher nicht über die serielle Konsole verwendet werden.

Lösung:In den Zeilen vor dem Namen des Notfall-Prompts wird die fehlerhafte Einheit genannt. Der Fehler wird in der Regel durch eines der folgenden Probleme verursacht:

Beheben Sie die Ursache offline, wie unter Festplatte offline reparieren beschrieben. Versuchen Sie nicht, die Notfall-Shell zu verwenden.

Firmware findet keine bootfähige Festplatte

Symptom:Die Ausgabe der seriellen Konsole enthält vor allen Kernel-Meldungen eine der folgenden Meldungen:

No bootable device.
BdsDxe: failed to load Boot0001
Invalid partition table!
Verification failed: (0x1A) Security Violation

Ursache:Das Bootlaufwerk ist nicht als Bootgerät angehängt, die Partitionstabelle oder der Bootdatensatz ist beschädigt oder bei einer Shielded VM-Instanz mit Secure Boot ist der Bootloader oder Kernel nicht richtig signiert.

Lösung: Prüfen Sie, ob das Laufwerk als Bootlaufwerk der Compute-Instanz angehängt ist. Weitere Informationen finden Sie unter Laufwerke trennen und neu anhängen. Wenn die Partitionstabelle oder der Boot-Datensatz beschädigt ist, reparieren Sie den Bootloader wie unter GRUB kann seine Konfiguration oder den Kernel nicht laden beschrieben. Ein Secure Boot-Verstoß kann nicht durch Bearbeiten des Laufwerks behoben werden. Stellen Sie einen signierten Kernel und Bootloader wieder her oder deaktivieren Sie Secure Boot auf der Compute-Instanz, wie unter Shielded VM-Optionen in einer VM-Instanz ändern beschrieben.

Laufwerk offline reparieren

Die meisten Bootprobleme können nicht innerhalb der Compute-Instanz behoben werden, da die Compute-Instanz nie eine Anmeldeaufforderung erreicht. Hängen Sie stattdessen das Bootlaufwerk an eine temporäre Rettungs-VM an, stellen Sie es bereit, nehmen Sie die Änderung vor und verschieben Sie das Laufwerk zurück. Eine Anleitung finden Sie unter Nicht zugängliche VM wiederherstellen.

Bei den Lösungen in diesem Dokument wird davon ausgegangen, dass das ursprüngliche Bootlaufwerk an eine Rettungs-VM angehängt und auf dieser bereitgestellt ist. Bevor Sie das Laufwerk ändern, erstellen Sie einen Snapshot, damit Sie es wiederherstellen können, falls die Reparatur fehlschlägt. Eine Anleitung finden Sie unter Archiv- und Standard-Snapshots für Laufwerke erstellen.

Compute-Instanz wiederherstellen, wenn das Laufwerk nicht repariert werden kann

Wenn keine der Lösungen funktioniert oder das Dateisystem nicht repariert werden kann, stellen Sie das Bootlaufwerk aus einem Snapshot wieder her oder erstellen Sie eine neue Compute-Instanz aus einem Snapshot oder einem benutzerdefinierten Betriebssystem-Image und verschieben Sie Ihre Daten darauf.

Nächste Schritte