Warum wechselt meine EC2-Linux-Instance in den Notfallmodus, wenn ich versuche, sie zu starten?

Kurzbeschreibung

Eine Instance kann aus den folgenden Gründen im Notfallmodus gestartet werden:

• Auf der Instance befindet sich ein beschädigter Kernel.
• Aufgrund falscher Einträge in der Datei /etc/fstab treten Fehler beim automatischen Mounten auf.

Um die Art des Fehlers zu überprüfen, sehen Sie sich die Konsolenausgabe der Instance an. Möglicherweise wird in der Konsolenausgabe eine Kernel Panic-Fehlermeldung angezeigt, wenn der Kernel beschädigt ist. Meldungen über fehlgeschlagene Abhängigkeiten werden in der Konsolenausgabe angezeigt, wenn Fehler bei der automatischen Bereitstellung auftreten.

Behebung

Kernel Panic-Fehler

Kernel Panic-Fehlermeldungen treten auf, wenn die Grub-Konfiguration oder die Datei initramfs beschädigt ist. Wenn ein Problem mit dem Kernel besteht, wird möglicherweise der Fehler „Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)“ in der Konsolenausgabe angezeigt.

So beheben Sie Kernel Panic-Fehler:

1.Setzen Sie den Kernel auf einen früheren, stabilen Kernel zurück. Anweisungen zum Hochfahren Ihrer Instance mit einem früheren Kernel finden Sie unter Wie kehre ich zu einem bekannten stabilen Kernel zurück, nachdem ein Update verhindert hat, dass meine Amazon EC2-Instance erfolgreich neu gestartet wird?

2.Nachdem Sie zu einem früheren Kernel zurückgekehrt sind, starten Sie die Instance neu. Korrigieren Sie dann die Probleme mit dem beschädigten Kernel.

Fehler „Abhängigkeit fehlgeschlagen“

Instances wechseln in den Notfallmodus, wenn es aufgrund von Syntaxfehlern in der Datei /etc/fstab zu Fehlern beim automatischen Mounten kommt. Auch wenn das in der Datei aufgeführte Amazon Elastic Block Store (Amazon EBS)-Volume von der Instance getrennt wird, wechselt der Instance-Startvorgang möglicherweise in den Notfallmodus. Wenn eines dieser Probleme auftritt, sieht die Konsolenausgabe in etwa wie folgt aus:

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

Die vorangegangenen Beispielprotokollmeldungen zeigen, dass der /mnt-Mount-Punkt während der Startsequenz nicht gemountet werden konnte.

Um zu verhindern, dass die Startsequenz aufgrund von Mount-Fehlern in den Notfallmodus wechselt, fügen Sie der Datei /etc/fstab Folgendes hinzu.

• Fügen Sie der Datei /etc/fstab für die sekundären Partitionen eine Option nofail hinzu (/mnt, im vorherigen Beispiel). Wenn die Option nofail vorhanden ist, wird die Startsequenz nicht unterbrochen, auch wenn das Mounten eines Volumes oder einer Partition fehlschlägt.
• Fügen Sie 0 als letzte Spalte der Datei /etc/fstab für den jeweiligen Mount-Punkt hinzu. Die Spalte 0 deaktiviert die Dateisystemprüfung und die Instance wird erfolgreich gestartet.

Es gibt drei Methoden, mit denen Sie die Datei /etc/fstab korrigieren können.

Wichtig:

Die Methoden 2 und 3 erfordern einen Stopp und Start der Instance. Beachten Sie Folgendes:

• In Instance-Speicher-Volumes gespeicherte Daten gehen verloren, wenn die Instance gestoppt wird. Stellen Sie sicher, dass Sie eine Sicherungskopie der Daten speichern, bevor Sie die Instance beenden. Im Gegensatz zu EBS-gestützten Volumes sind Instance-Store-Speicher-Volumes kurzlebig und unterstützen keine Datenpersistenz.
• Die statische öffentliche IPv4-Adresse, die Amazon EC2 der Instance beim Start automatisch zugewiesen hat, ändert sich nach dem Stopp und Start. Um eine öffentliche IPv4-Adresse beizubehalten, die sich nicht ändert, wenn die Instance gestoppt wird, verwenden Sie eine Elastic IP-Adresse.

Weitere Informationen finden Sie unter Was passiert, wenn Sie eine Instance stoppen.

Methode 1: Verwenden der seriellen EC2-Konsole

Wenn Sie die serielle EC2-Konsole für Linux aktiviert haben, können Sie sie zur Fehlerbehebung bei unterstützten Nitro-basierten Instance-Typen und Bare-Metal-Instances verwenden. Sie können von der Amazon-EC2-Konsole oder dem AWS Command Line Interface (AWS CLI) auf die serielle Konsole zuzugreifen. Sie benötigen keine funktionierende Verbindung, um eine Verbindung zu Ihrer Instance herzustellen, wenn Sie die serielle EC2-Konsole verwenden.

**Hinweis:**Wenn Sie die serielle EC2-Konsole noch nicht verwendet haben, überprüfen Sie die Voraussetzungen und konfigurieren Sie den Zugriff, bevor Sie versuchen, eine Verbindung herzustellen. Wenn Ihre Instance nicht erreichbar ist und Sie keinen Zugriff auf die serielle Konsole konfiguriert haben, folgen Sie den Anweisungen unter Methode 2 oder Methode 3.

1.Öffnen Sie die Amazon-EC2-Konsole.

2.Wählen Sie Instances aus.

3.Wählen Sie die Instance aus und wählen Sie dann Aktionen, Überwachen und Problembehandlung, Serielle EC2-Konsole, Verbinden.

-oder-

Wählen Sie die Instance aus und wählen Sie dann Verbinden, Serielle EC2-Konsole, Verbinden.

Ein Terminalfenster im Browser wird geöffnet.

4.Drücken Sie die Eingabetaste. Wenn Sie mit der seriellen Konsole verbunden sind, erscheint eine Anmeldeaufforderung. Wenn der Bildschirm weiterhin schwarz bleibt, verwenden Sie die folgenden Informationen, um Probleme mit der Verbindung zur seriellen Konsole zu beheben:

• **Stellen Sie sicher, dass Sie den Zugriff auf die serielle Konsole konfiguriert haben.**Weitere Informationen finden Sie unter Zugriff auf die serielle EC2-Konsole konfigurieren.

• **Verwenden Sie SysRq, um eine Verbindung zur seriellen Konsole herzustellen.**SysRq benötigt keine Verbindung über den browserbasierten Client. Weitere Informationen finden Sie unter Problembehandlung Ihrer Linux-Instance mit SysRq.

• **Starten Sie Getty neu.**Wenn Sie SSH-Zugriff auf Ihre Instance haben, stellen Sie über SSH eine Verbindung zu Ihrer Instance her und starten Sie Getty mit dem folgenden Befehl neu.

  [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0

• **Starten Sie Ihre Instance neu.**Sie können Ihre Instance mithilfe von SysRq, der EC2-Konsole oder der AWS-CLI neu starten. Weitere Informationen finden Sie unter Problembehandlung Ihrer Linux-Instance mithilfe von SysRq oder Starten Sie Ihre Instance neu.

5.Geben Sie bei der Anmeldeaufforderung den Benutzernamen des passwortbasierten Benutzers ein, den Sie zuvor eingerichtet haben, und drücken Sie dann die Eingabetaste.

6.Geben Sie in der Passwort-Eingabeaufforderung das Passwort ein, und drücken Sie dann die Eingabetaste.

Sie sind jetzt bei der Instance angemeldet und können die serielle EC2-Konsole zur Fehlerbehebung verwenden.

Sie können die Verbindung auch mit Ihrem eigenen Schlüssel und einem SSH-Client herstellen.

Weitere Informationen zur Verwendung der seriellen EC2-Konsole finden Sie unter Herstellen einer Verbindung zur seriellen EC2-Konsole.

Methode 2: Führen Sie das AWSSupport-ExecuteEC2Rescue-Automatisierungsdokument aus

Wenn Ihre Instance für AWS Systems Manager konfiguriert ist, können Sie das AWSSupport-ExecuteEC2Rescue-Automatisierungsdokument ausführen, um Startprobleme zu korrigieren. Manuelles Eingreifen ist bei Verwendung dieser Methode nicht erforderlich. Informationen zur Verwendung des Automatisierungsdokuments finden Sie unter Ausführen des EC2Rescue-Tools auf nicht erreichbaren Instances.

Methode 3: Bearbeiten Sie die Datei manuell mithilfe einer Rettungs-Instance

1.Öffnen Sie die Amazon-EC2-Konsole.

2.Wählen Sie Instances und dann die Instance aus, die sich im Notfallmodus befindet.

3.Stoppen Sie die Instance.

4.Trennen Sie das Amazon EBS-Root-Volume (/dev/xvda oder /dev/sda1) von der gestoppten Instance.

5.Starten Sie eine neue EC2-Instance in derselben Availability Zone, in der sich die beeinträchtigte Instance befindet. Die neue Instance wird zu Ihrer Rettungs-Instance.

6.Schließen Sie das Root-Volume, das Sie in Schritt 4 getrennt haben, als sekundäres Gerät an die Rettungs-Instance an.

**Hinweis:**Sie können beim Anschließen sekundärer Volumes unterschiedliche Gerätenamen verwenden.

7.Stellen Sie über SSH eine Verbindung zu Ihrer Rettungs-Instance her.

8.Erstellen Sie ein Mount-Punkt-Verzeichnis für das neue Volume, das Sie in Schritt 6 an die Rettungs-Instance angehängt haben. Im folgenden Beispiel ist das Mounting-Punkt-Verzeichnis /mnt/rescue.

$ sudo mkdir /mnt/rescue

9.Mounten Sie den Datenträger in dem Verzeichnis, das Sie in Schritt 8 erstellt haben.

$ sudo mount /dev/xvdf /mnt/rescue

Hinweis:Das Gerät (/dev/xvdf, im vorherigen Beispiel) ist möglicherweise mit einem anderen Gerätenamen an die Rettungs-Instance angehängt. Verwenden Sie den Befehl lsblk, um Ihre verfügbaren Festplattengeräte zusammen mit ihren Mount-Punkten anzuzeigen und die richtigen Gerätenamen zu ermitteln.

10.Nachdem das Volume gemountet ist, führen Sie den folgenden Befehl aus, um die Datei /etc/fstab zu öffnen.

$ sudo vi /mnt/rescue/etc/fstab

11.Bearbeiten Sie die Einträge in /etc/fstab nach Bedarf. Die folgende Beispielausgabe zeigt drei EBS-Volumes, die mit UUIDs definiert sind, wobei die Option nofail für beide sekundären Volumes hinzugefügt wurde, und eine 0 als letzte Spalte für jeden Eintrag.

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.Speichern Sie die Datei und führen Sie dann den Befehl umount aus, um das Mounten des Volumes zu beenden.

$ sudo umount /mnt/rescue

13.Trennen Sie das Volume von der temporären Instance.

14.Hängen Sie das Volume an die ursprüngliche Instance an und starten Sie dann die Instance, um zu bestätigen, dass sie erfolgreich gestartet wurde.