Wie behebe ich eine EC2-Linux-Instance, die die Instance-Statusprüfung aufgrund von Betriebssystemproblemen nicht bestanden hat?

Kurzbeschreibung

Ihre EC2-Linux-Instance kann möglicherweise die Instance-Statusüberprüfung aus folgenden Gründen nicht bestehen:

• Sie haben den Kernel aktualisiert und der neue Kernel ist nicht hochgefahren.
• Die Dateisystemeinträge in /etc/fstab sind falsch oder das Dateisystem ist beschädigt.
• Es gibt falsche Netzwerkkonfigurationen auf der Instance.

Behebung

Wichtig: Einige der folgenden Verfahren erfordern, dass Sie die Instance stoppen. Wenn Sie eine Instance stoppen, verlieren Sie Daten, die auf Instance-Speicher-Volumes gespeichert sind. Speichern Sie eine Sicherungskopie der Daten, bevor Sie die Instance stoppen. Im Gegensatz zu Volumes, die von Amazon Elastic Block Store (Amazon EBS) unterstützt werden, sind Instance-Speicher-Volumes kurzlebig und unterstützen keine Datenpersistenz. Weitere Informationen finden Sie unter Stoppen und Starten von Amazon EC2-Instances.

Die statische öffentliche IPv4-Adresse, die Amazon EC2 der Instance beim Start automatisch zuweist, ändert sich nach dem Stoppen und Starten. Um eine öffentliche IPv4-Adresse beizubehalten, die sich nicht ändert, wenn die Instance gestoppt wird, verwenden Sie eine Elastic-IP-Adresse.

Hinweis: Die folgenden Methoden verwenden Beispiele, die auf Amazon Linux 2 basieren. Diese Konzepte gelten jedoch für Linux-Distributionen allgemein. Wenn Sie eine andere Linux-Distribution als Amazon Linux 2 haben, können die Befehle, Pfade und Ausgaben variieren.

Verwenden der seriellen EC2-Konsole für Linux-Instances

Wenn Sie die serielle EC2-Konsole für Linux-Instances aktiviert haben, können Sie sie zur Fehlerbehebung bei unterstützten Nitro-basierten Instance-Typen und Bare-Metal-Instances verwenden. Die serielle Konsole hilft Ihnen beim Beheben von Problemen bei Startvorgängen, Netzwerkkonfigurationen und SSH-Konfigurationen. Die serielle Konsole kann eine Verbindung zu Ihrer Instance ohne eine funktionierende Netzwerkverbindung herstellen. Verwenden Sie die Amazon EC2-Konsole oder die AWS Command Line Interface (AWS CLI), um auf die serielle Konsole zuzugreifen.

Wenn Sie die serielle EC2-Konsole zum ersten Mal verwenden, überprüfen Sie die Voraussetzungen und konfigurieren Sie den Zugriff, bevor Sie eine Verbindung herstellen.

Wenn Ihre Instance nicht erreichbar ist und Sie den Zugriff auf die serielle Konsole nicht konfiguriert haben, lesen Sie den Abschnitt Das Tool EC2Rescue for Linux ausführen. Oder siehe Verwenden einer Rettungs-Instance. Zur Konfiguration der seriellen EC2-Konsole für Linux-Instances, siehe Konfiguration des Zugriffs auf die serielle EC2-Konsole.

**Hinweis:**Wenn Sie beim Ausführen von Befehlen im AWS CLI Fehlermeldungen erhalten, finden Sie weitere Informationen unter Beheben von Fehlern im AWS CLI. Stellen Sie außerdem sicher, dass Sie die neueste Version von AWS CLI verwenden.

Ausführen des Tools EC2Rescue für Linux

EC2Rescue für Linux diagnostiziert Betriebssysteme auf nicht erreichbaren Instances automatisch und behebt Fehler. Weitere Informationen finden Sie unter Wie verwende ich EC2Rescue für Linux, um Probleme auf Betriebssystemebene zu beheben?

Verwenden einer Rettungs-Instance, um Fehler manuell zu korrigieren

1. Starten Sie eine neue EC2-Instance in Ihrer Virtual Private Cloud (VPC). Verwenden Sie dasselbe Amazon Machine Image (AMI) in derselben Availability Zone wie die beeinträchtigte Instance. Die neue Instance wird zu Ihrer Rescue-Instance.

   Oder verwenden Sie eine bestehende Instance. Die vorhandene Instance muss dasselbe AMI verwenden und sich in derselben Availability Zone befinden wie Ihre beeinträchtigte Instance.

2. Stoppen Sie die beeinträchtigte Instance.

3. Trennen Sie das Amazon EBS-Root-Volume (/dev/xvda oder /dev/sda1) von der beeinträchtigten Instance. Notieren Sie sich den Gerätenamen Ihres Root-Volumes.

4. Schließen Sie den Datenträger als sekundäres Gerät (/dev/sdf) an die Rescue-Instance an.

5. Stellen Sie über SSH eine Verbindung zu Ihrer Rescue-Instance her.

6. Erstellen Sie ein Mount-Point-Verzeichnis (/rescue) für den neuen an die Rescue-Instance angeschlossenen Datenträger:

   $ sudo mkdir /rescue

7. Mounten Sie das Volume in das neue Verzeichnis:

   $ sudo mount /dev/xvdf1 /rescue

   Wenn Sie eine Fehlermeldung wie „Falscher Fs-Typ oder UUID-Duplikat, Superblock fehlt oder Badblock gefunden“ erhalten, finden Sie weitere Informationen unter Warum kann ich mein Amazon EBS-Volume nicht mounten?

   Hinweis: Das Gerät (/dev/xvdf1) ist möglicherweise mit einem anderen Gerätenamen an die Rescue-Instance angeschlossen. Verwenden Sie den Befehl lsblk, um Ihre verfügbaren Festplattengeräte zusammen mit ihren Mountpunkten anzuzeigen und die richtigen Gerätenamen zu ermitteln.

8. Rufen Sie das Systemprotokoll der Instance ab, falls Sie dies noch nicht getan haben, um zu überprüfen, welcher Fehler aufgetreten ist. Die nächsten Schritte hängen von der im Systemprotokoll aufgeführten Fehlermeldung ab.

   Im Folgenden finden Sie eine Liste häufiger Fehler, die dazu führen können, dass die Instance-Statusüberprüfung fehlschlägt. Weitere Fehler finden Sie unter Problembehandlung bei Systemprotokollfehlern für Linux-basierte Instances.

Problembehandlung bei „Kernel-Panic“

Wenn eine Fehlermeldung vom Typ Kernel Panic im Systemprotokoll auftaucht, verfügt der Kernel möglicherweise nicht über die Dateien vmlinuz oder initramfs. Die Dateien vmlinuz und initramfs sind erforderlich, um erfolgreich hochzufahren.

1. Führen Sie die folgenden Befehle aus:

   cd /rescue/boot
   ls -l

2. Überprüfen Sie die Ausgabe, um sicherzustellen, dass die Dateien vmlinuz und initramfs vorhanden sind, die der Kernelversion entsprechen, die Sie hochfahren möchten.

   Das folgende Ausgabebeispiel bezieht sich auf eine Instance mit Amazon Linux 2 mit der Kernel-Version 4.14.165-131.185.amzn2.x86_64. Das Verzeichnis /boot enthält die Dateien initramfs-4.14.165-131.185.amzn2.x86_64.img und vmlinuz-4.14.165-131.185.amzn2.x86_64, um erfolgreich hochzufahren.

   uname -r
   4.14.165-131.185.amzn2.x86_64
   
   cd /boot; ls -l
   total 39960
   -rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
   drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
   drwx------ 5 root root       79 Feb 12 04:08 grub2
   -rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
   -rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
   -rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
   -rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
   -rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

3. Wenn die Dateien initramfs und vmlinuz nicht vorhanden sind, fahren Sie die Instance mit einem früheren Kernel hochzufahren, der diese beiden Dateien enthält. Für Anweisungen, siehe Wie kehre ich zu einem bekannten stabilen Kernel zurück, nachdem ein Update verhindert hat, dass meine Amazon EC2-Instance erfolgreich neu gestartet wird?

4. Führen Sie den Befehl unmount aus, um das sekundäre Gerät von Ihrer Rettungs-Instance zu trennen:

   $ sudo umount /rescue

   Wenn der Unmount-Vorgang nicht erfolgreich ist, müssen Sie möglicherweise die Rescue-Instance beenden oder neu starten, um eine saubere Deinstallation zu ermöglichen.

5. Trennen Sie das sekundäre Volume (/dev/sdf) von der Rettungs-Instance. Hängen Sie es dann als /dev/xvda (Root-Volume) an die ursprüngliche Instance an.

6. Starten Sie die Instance und vergewissern Sie sich, dass die Instance reagiert.

Mehr Informationen zum Beheben von Kernel-Panic-Fehlern finden Sie unter Warum wird nach dem Upgrade des Kernels oder dem Neustart meiner EC2-Linux-Instance ein „Kernel-Panic“-Fehler angezeigt?

Problembehandlung bei „Fehler beim Mounten“ oder „Abhängigkeit fehlgeschlagen“

Wenn Sie in Ihrem Systemprotokoll Fehler wie „Fehler beim Mounten“ oder „Abhängigkeit fehlgeschlagen“ sehen, enthält die Datei /etc/fstab möglicherweise falsche Mountpunkt-Einträge.

1. Stellen Sie sicher, dass die Mountpunkt-Einträge in /etc/fstab korrekt sind. Zum Korrigieren der /etc/fstab-Dateieinträge, siehe Warum wechselt meine EC2-Linux-Instance in den Notfallmodus, wenn ich versuche, sie zu starten?

2. Es hat sich bewährt, das Tool fsck oder xfs_repair auszuführen, um Inkonsistenzen im Dateisystem zu korrigieren.

   Hinweis: Erstellen Sie eine Sicherungskopie Ihres Dateisystems, bevor Sie das Tool fsck oder xfs_repair ausführen.

   Führen Sie den Befehl unmount aus, um Ihren Mointpunkt zu entfernen, bevor Sie das Tool fsck oder xfs_repair ausführen:

   $ sudo umount /rescue

   Führen Sie auf der Basis Ihres Dateisystems das Tool fsk oder xfs_repair aus.

   Führen Sie für ext4-Dateisysteme den folgenden Befehl aus:

   $ sudo fsck /dev/sdf
   fsck from util-linux 2.30.2
   e2fsck 1.42.9 (28-Dec-2013)
   /dev/sdf: clean, 11/6553600 files,
   459544/26214400 blocks

   Führen Sie für XFS-Dateisysteme den folgenden Befehl aus:

   $ sudo xfs_repair /dev/sdf
   xfs_repair /dev/xvdf
   Phase 1 - find and verify superblock...
   Phase 2 - using internal log
           - zero log...
           - scan filesystem freespace and inode maps...
           - found root inode chunk
   Phase 3 - for each AG...
           - scan and clear agi unlinked lists...
           - process known inodes and perform inode discovery...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
           - process newly discovered inodes...
   Phase 4 - check for duplicate blocks...
           - setting up duplicate extent list...
           - check for inodes claiming duplicate blocks...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
   Phase 5 - rebuild AG headers and trees...
           - reset superblock...
   Phase 6 - check inode connectivity...
           - resetting contents of realtime bitmap and summary inodes
           - traversing filesystem ...
           - traversal finished ...
           - moving disconnected inodes to lost+found ...
   Phase 7 - verify and correct link counts...
   done

3. Trennen Sie das sekundäre Volume (/dev/sdf) von der Rettungs-Instance. Hängen Sie es dann als /dev/xvda (Root-Volume) an die ursprüngliche Instance an.

4. Starten Sie die Instance und vergewissern Sie sich, dass die Instance reagiert.

Problembehandlung bei „interface eth0: failed“

Stellen Sie sicher, dass die Datei ifcfg-eth0 die richtigen Netzwerkeinträge enthält. Die Netzwerkkonfigurationsdatei, die der primären Schnittstelle eth0 entspricht, befindet sich unter /etc/sysconfig/network-scripts/ifcfg-eth0. Wenn der Gerätename Ihrer primären Schnittstelle nicht eth0 ist, beginnt der Dateiname mit ** ifcfg**, gefolgt vom Gerätenamen. Die Datei befindet sich im Verzeichnis /etc/sysconfig/network-scripts auf der Instance.

1. Führen Sie den Befehl cat aus, um die Netzwerkkonfigurationsdatei für die primäre Schnittstelle eth0 anzuzeigen.

   Im Folgenden sind die korrekten Einträge für die Netzwerkkonfigurationsdatei in /etc/sysconfig/network-scripts/ifcfg-eth0 aufgeführt.

   Hinweis: Ersetzen Sie eth0 im folgenden Befehl durch den Namen Ihrer primären Schnittstelle, falls notwendig.

   $ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
   DEVICE=eth0
   BOOTPROTO=dhcp
   ONBOOT=yes
   TYPE=Ethernet
   USERCTL=yes
   PEERDNS=yes
   DHCPV6C=yes
   DHCPV6C_OPTIONS=-nw
   PERSISTENT_DHCLIENT=yes
   RES_OPTIONS="timeout:2 attempts:5"
   DHCP_ARP_CHECK=no

2. Stellen Sie sicher, dass ONBOOT auf ja gesetzt ist. Wenn ONBOOT nicht auf yes gesetzt ist, ist eth0 (oder Ihre primäre Netzwerkschnittstelle) nicht so konfiguriert, dass sie beim Hochfahren angezeigt wird.

   Um den Wert ONBOOT zu ändern, öffnen Sie zuerst die Datei in einem Editor. In diesem Beispiel wird der vi-Editor verwendet:

   $ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

   Drücken Sie I zum Einfügen.

   Scrollen Sie mit dem Cursor zum Eintrag ONBOOT und ändern Sie dann den Wert in yes.

   Um die Datei zu speichern und zu beenden, drücken Sie :wq!

3. Führen Sie den Befehl unmount aus, um das sekundäre Gerät von Ihrer Rettungs-Instance zu trennen:

   $ sudo umount /rescue

   Wenn der Unmount-Vorgang nicht erfolgreich ist, müssen Sie möglicherweise die Rescue-Instance stoppen oder neu starten, um eine saubere Deinstallation zu initiieren.

4. Trennen Sie das sekundäre Volume (/dev/sdf) von der Rettungs-Instance. Hängen Sie es dann als /dev/xvda (Root-Volume) an die ursprüngliche Instance an.

5. Starten Sie die Instance und vergewissern Sie sich, dass die Instance reagiert.

Ähnliche Informationen

Warum ist meine EC2 Linux-Instance nicht erreichbar und besteht eine oder beide Statusprüfungen nicht?

Fehlerbehebung bei Instances mit fehlgeschlagenen Statusüberprüfungen

Warum fährt meine Linux-Instance nicht hoch, nachdem ich ihren Typ in einen Nitro-basierten Instance-Typ geändert habe?