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

Kurzbeschreibung

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

• Auf der Instance befindet sich ein beschädigter Kernel, der einen Kernel Panic-Fehler verursacht.
• Es gibt Fehler beim automatischen Einbinden aufgrund falscher Einträge in der Datei /etc/fstab, die zu Dependency failed-Fehlern führen.

Überprüfe die Konsolenausgabe der Instance, um die Art des Fehlers zu ermitteln.

Lösung

Kernel Panic-Fehler

Wenn es ein Problem mit dem Kernel gibt, erhältst du eine Fehlermeldung ähnlich dem folgenden Beispiel:

„Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)“

Kernel Panic-Fehler treten auf, wenn die Grub-Konfiguration oder die Datei initramfs beschädigt ist. Gehe wie folgt vor, um dieses Problem zu beheben:

1. Setze den Kernel auf einen früheren, stabilen Kernel zurück.
2. Boote die Instance neu.
3. Korrigiere die in der Fehlermeldung aufgeführten Probleme auf dem beschädigten Kernel.

Fehler „Dependency failed“

Dependency failed-Fehler treten auf, wenn Syntaxfehler in der Datei /etc/fstab zu Fehlern beim automatischen Einbinden führen. Der Fehler tritt auch auf, wenn das in der Datei aufgeführte Amazon Elastic Block Store (Amazon EBS)-Volume von der Instance getrennt wird. Du erhältst eine Fehlermeldung ähnlich dem folgenden Beispiel:

„[[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.“

Im vorherigen Beispiel konnte der Bereitstellungspunkt /mnt während der Boot-Sequenz nicht eingebunden werden. Um sicherzustellen, dass die Boot-Sequenz aufgrund von Bereitstellungsfehlern nicht in den Notfallmodus wechselt, füge der Datei /etc/fstab die folgenden Konfigurationen hinzu:

• Eine nofail-Option für die sekundären Partitionen, z. B. /mnt.
  Hinweis: Die Option nofail stellt sicher, dass die Boot-Sequenz nicht unterbrochen wird, selbst wenn das Einbinden eines Volumes oder einer Partition fehlschlägt.
• Eine 0, die die Dateisystemprüfung deaktiviert, ist die letzte Spalte in der Datei für den Bereitstellungspunkt.

Um die Datei /etc/fstab zu aktualisieren, verwende die serielle EC2-Konsole, führe die AWSSupport-ExecuteEC2Rescue-Automatisierung aus oder verwende eine Rettungs-Instance, um die Datei manuell zu bearbeiten.

Wichtig: Bevor du die Instance anhältst und startest, gehe wie folgt vor:

• Erstelle eine Sicherungskopie des EBS-Volumes.
  Hinweis: Wenn die Instance vom Instance-Speicher unterstützt wird oder über Instance-Speicher-Volumes verfügt, die Daten enthalten, löscht Amazon EC2 die Daten, wenn du die Instance anhältst.
• Stelle das Verhalten beim Herunterfahren der Instance auf Stopp ein, um sicherzustellen, dass die Instances nicht beendet werden, wenn du sie anhältst.

Hinweis: Wenn du eine Instance anhältst und startest, ändert sich die öffentliche IP-Adresse der Instance. Es empfiehlt sich, beim Weiterleiten von externem Datenverkehr an die Instance eine Elastic-IP-Adresse anstelle einer öffentlichen IP-Adresse zu verwenden. Weitere Informationen findest du unter Stoppen und Starten von Amazon EC2-Instances.

Verwendung der seriellen EC2-Konsole
Wichtig: Du musst die Instance nicht anhalten und starten, wenn du die serielle EC2-Konsole verwendest.

Wenn du die serielle EC2-Konsole für Linux aktiviert hast, kannst du sie zur Fehlerbehebung bei unterstützten Nitro-basierten Instance-Typen und unterstützten Bare-Metal-Instances verwenden. Du benötigst keine funktionierende Verbindung, um eine Verbindung zur Instance herzustellen, wenn du die serielle EC2-Konsole verwendest. Stelle eine Verbindung zur seriellen EC2-Konsole her und ändere dann die Datei /etc/fstab.

Wenn du die serielle EC2-Konsole noch nicht verwendet hast, stelle sicher, dass du die Voraussetzungen erfüllst. Wenn die Instance nicht erreichbar ist und du den Zugriff auf die serielle Konsole noch nicht konfiguriert hast, kannst du die serielle EC2-Konsole nicht verwenden, um die Datei /etc/fstab zu korrigieren.

Das AWSSupport-ExecuteEC2Rescue-Automatisierungsdokument ausführen

Voraussetzungen: Stelle sicher, dass du über die erforderlichen AWS Identity and Access Management (IAM, Identitäts- und Zugriffsmanagement)-Berechtigungen verfügst, um AWSSupport-ExecuteEC2Rescue zu verwenden.

Führe das AWSSupport-ExecuteEC2Rescue-Automatisierungsdokument aus, um Boot-Probleme automatisch zu korrigieren. Weitere Informationen findest du unter Ausführen des EC2Rescue-Tools auf nicht erreichbaren Instances.

Verwenden einer Rettungs-Instance, um die Datei manuell zu bearbeiten

Führe die folgenden Schritte aus:

1. Öffne die Amazon-EC2-Konsole.

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

3. Halte die Instance an.

4. Trenne das Amazon EBS-Root-Volume /dev/xvda or /dev/sda1 von der angehaltenen Instance.

5. Starte eine Rettungs-Instance in derselben Availability Zone wie die angehaltene Instance.

6. Füge das Root-Volume als sekundäres Gerät an die Rettungs-Instance an.
   Hinweis: Du kannst unterschiedliche Gerätenamen verwenden, wenn du sekundäre Volumes anfügst.

7. Verwende SSH, um eine Verbindung zur Rettungs-Instance herzustellen.

8. Um ein Bereitstellungspunkt-Verzeichnis für das neue Volume zu erstellen, das du an die Rettungs-Instance angefügt hast, führe den folgenden Befehl aus:

   sudo mkdir /mnt/rescue

   Hinweis: Ersetze /mnt/rescue durch dein Bereitstellungspunkt-Verzeichnis.

9. Führe den folgenden Befehl aus, um den Namen und die Partition des Blockgeräts zu ermitteln:

   [root ~]$ lsblk

   Beispielausgabe:

   NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
   xvda    202:0    0    8G  0 disk
   └─xvda1 202:1    0    8G  0 part /
   xvdf    202:80   0  101G  0 disk
   └─xvdf1 202:81   0  101G  0 part

10. Führe den folgenden Befehl aus, um das Volume im Bereitstellungspunkt-Verzeichnis einzubinden:

sudo mount -o nouuid /dev/xvdf1 /mnt/rescue

Hinweis: Ersetze /dev/xvdf1 durch deinen Gerätenamen. Führe den folgenden Befehl aus, um die Datei /etc/fstab zu öffnen:

sudo vi /mnt/rescue/etc/fstab

12. Bearbeite die Einträge in /etc/fstab. Das folgende Beispiel zeigt zwei Amazon EBS-Volumes, die mit UUIDs definiert sind. Beiden sekundären Volumes wurde die Option nofail hinzugefügt 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=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  

13. Speichere die Datei und führe dann den folgenden Befehl aus, um das Einbinden des Volumes aufzuheben:

sudo umount /mnt/rescue

14. Trenne das Volume von der Rettungs-Instance.
15. Füge das Volume an die Original-Instance an.
16. Um zu bestätigen, dass du die Instance booten kannst, starte die Instance.