Wie behebe ich eine EC2-Linux-Instance, die die Instance-Statusprüfung aufgrund von Betriebssystemproblemen nicht bestanden hat?
Meine Linux-Instance von Amazon Elastic Compute Cloud (Amazon EC2) hat die Instance-Statusüberprüfung aufgrund von Problemen mit dem Betriebssystem nicht bestanden. Jetzt lässt sie sich nicht mehr erfolgreich hochfahren.
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.
Lösung
Es gibt drei Methoden zum Beheben von Betriebssystemproblemen.
Wichtig: Einige der folgenden Verfahren erfordern das Stoppen der Instanz. 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 Volumes, die von Amazon Elastic Block Store (Amazon EBS) unterstützt werden, sind Instance-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.
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 stellt eine Verbindung zu Ihrer Instance her, ohne dass eine funktionierende Netzwerkverbindung erforderlich ist. 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, stellen Sie sicher, dass Sie die Voraussetzungen überprüfen und den Zugriff konfigurieren, bevor Sie versuchen, eine Verbindung herzustellen.
Wenn Ihre Instance nicht erreichbar ist und Sie den Zugriff auf die serielle Konsole nicht konfiguriert haben, folgen Sie den Anweisungen unter Ausführen des ** EC2Rescue-Tools für Linux** oder Verwenden einer Rescue-Instance. Informationen zur Konfiguration der seriellen EC2-Konsole für Linux finden Sie unter Konfiguration des Zugriffs auf die serielle EC2-Konsole.
Hinweis: Wenn Sie beim Ausführen von AWS-CLI-Befehlen Fehler erhalten, stellen Sie sicher, dass Sie die neueste Version der 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?
Manuelles Korrigieren von Fehlern mithilfe einer Rescue-Instance
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 Root-Volume des Amazon Elastic Block Store (Amazon EBS) (/dev/xvda oder /dev/sda1) von Ihrer beeinträchtigten Instance. Notieren Sie den Gerätenamen (/dev/xvda oder /dev/sda1) 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 mithilfe von 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 Beheben von Systemprotokollfehlern für Linux-basierte Instances.
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, wird also erfolgreich hochfahren.
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/oder vmlinuz nicht vorhanden sind, versuchen Sie, die Instance mit einem früheren Kernel hochzufahren, der diese beiden Dateien enthält. 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?
4.Führen Sie den Befehl unmount aus, um das sekundäre Gerät von Ihrer Rescue-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 den sekundäre Datenträger (/dev/sdf) von der Rescue-Instance und schließen Sie ihn als /dev/xvda (Root-Datenträger) an die ursprüngliche Instance an.
6.Starten Sie die Instance und vergewissern Sie sich, dass die Instance reagiert.
Weitere 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?
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. Informationen zur Korrektur der Einträge in der Datei /etc/fstab finden Sie im Abschnitt Automatische Mount-Fehler aufgrund falscher Einträge im Datei-Abschnitt /etc/fstab unter Warum fährt meine EC2-Instance nicht hoch und wechselt in den Notfallmodus?
2.Es hat sich bewährt, das Tool fsck oder xfs_repair auszuführen, um alle Dateisystemfehler zu korrigieren. Wenn es Unstimmigkeiten im Dateisystem gibt, korrigiert das Tool fsck oder xfs_repair diese.
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 je nach Dateisystem das Tool fsk oder xfs_repair aus.
Für ext4-Dateisysteme:
$ 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ür XFS-Dateisysteme:
$ 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 den sekundäre Datenträger (/dev/sdf) von der Rescue-Instance und schließen Sie ihn als /dev/xvda (Root-Datenträger) an die ursprüngliche Instance an.
4.Starten Sie die Instance und vergewissern Sie sich, dass die Instance reagiert.
Aufruf der Schnittstelle eth0: fehlgeschlagen
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 lautet, gibt es eine Datei, die mit ifcfg beginnt und auf die der Name Ihres Geräts folgt. 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 dieser sich unterscheidet.
$ 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 yes gesetzt ist, wie im vorherigen Beispiel gezeigt. Wenn ONBOOT nicht auf yes gesetzt ist, ist eth0 (oder Ihre primäre Netzwerkschnittstelle) nicht so konfiguriert, dass sie beim Hochfahren angezeigt wird.
Gehen Sie folgendermaßen vor, um den ONBOOT-Wert zu ändern:
Öffnen Sie 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.
Speichern und beenden Sie die Datei, indem Sie auf :wq! drücken
3.Führen Sie den Befehl unmount aus, um das sekundäre Gerät von Ihrer Rescue-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 ermöglichen.
4.Trennen Sie den sekundäre Datenträger (/dev/sdf) von der Rescue-Instance und schließen Sie ihn als /dev/xvda (Root-Datenträger) an die ursprüngliche Instance an.
5.Starten Sie die Instance und vergewissern Sie sich, dass die Instance reagiert
Ähnliche Informationen
Probleme bei Instances mit fehlgeschlagenen Statusüberprüfungen beheben
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 10 Monaten
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 9 Monaten