Beheben von Problemen bei Instances mit nicht bestandenen Statusprüfungen

Die folgenden Informationen können Ihnen helfen, Probleme zu beheben, wenn Ihre Instance eine Statusprüfung nicht besteht. Stellen Sie zunächst fest, ob in Ihren Anwendungen Probleme bestehen. Wenn Sie feststellen, dass die Instance Ihre Anwendung nicht erwartungsgemäß ausführt, gehen Sie die Informationen der Statusprüfung und die Systemprotokolle durch.

Beispiele für Probleme, die dazu führen können, dass Statusprüfungen fehlschlagen, finden Sie unter Statusprüfungen für Ihre Instances.

Informationen der Statusprüfung durchgehen

So untersuchen Sie nicht funktionsfähige Instances mit der Amazon EC2-Konsole

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

2. Klicken Sie im Navigationsbereich auf Instances und wählen Sie anschließend Ihre Instance aus.

3. Wählen Sie im Detailbereich Status und Alarme aus, um die einzelnen Ergebnisse für alle Systemstatusprüfungen und Zustandsprüfungen der Instance zu sehen.

Wenn eine Systemstatusprüfung fehlgeschlagen ist, verwenden Sie eine der folgenden Optionen:

• Erstellen Sie einen Wiederherstellungsalarm für die Instance. Weitere Informationen finden Sie unter Erstellen von Alarmen, mit denen eine Instance angehalten, beendet, neu gestartet oder wiederhergestellt wird.

• Wenn Sie den Instanztyp in eine auf dem AWS Nitro-System aufgebaute Instanz geändert haben, schlagen Statusprüfungen fehl, wenn Sie von einer Instanz migriert haben, die nicht über die erforderlichen ENA- und NVMe-Treiber verfügt. Weitere Informationen finden Sie unter Kompatibilität zum Ändern des Instance-Typs.

• Bei einer Instance, die ein Amazon EBS-gestütztes AMI verwendet, halten Sie die Instance an und starten Sie sie erneut.

• Bei einer Instance, die ein Instance Store-Backed AMI verwendet, beenden Sie die Instance und starten Sie eine Ersatz-Instance.

• Warten Sie, bis Amazon EC2 das Problem behoben hat.

• Poste dein Problem auf AWS re:POST.

• Wenn Ihre Instance eine Auto Scaling-Gruppe ist, startet der Amazon EC2 Auto Scaling-Service automatisch eine Ersatz-Instance. Weitere Informationen finden Sie unter Zustandsprüfungen für Auto Scaling-Instances im Amazon EC2 Auto Scaling-Benutzerhandbuch.

• Rufen Sie das Systemprotokoll ab und prüfen Sie es auf Fehler.

Systemprotokolle abrufen

Wenn eine Instance-Statusprüfung fehlschlägt, können Sie die Instance neu starten und die Systemprotokolle abrufen. Die Protokolle geben Aufschluss, ob ein Fehler vorliegt, was Ihnen bei der Problembehebung helfen kann. Durch den Neustart werden nicht benötigte Informationen in den Protokollen gelöscht.

So starten Sie eine Instance neu und rufen das Systemprotokoll ab

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

2. Klicken Sie im Navigationsbereich auf Instances und wählen Sie Ihre Instance aus.

3. Wählen Sie Instance state (Instance-Status), Reboot instance (Instance neu starten). Es kann einige Minuten dauern, bis Ihre Instance neu gestartet wird.

4. Überprüfen Sie, ob das Problem nach wie vor besteht. In einigen Fällen lässt sich das Problem durch den Neustart lösen.

5. Wenn die Instance im running-Status ist, wählen Sie Actions (Aktionen), Monitor and Troubleshoot (Überwachung und Fehlerbehebung), Get system log (Systemprotokoll abrufen).

6. Sehen Sie sich das Protokoll an, das auf dem Bildschirm angezeigt wird, und greifen Sie zur Problembehebung auf die Liste der bekannten Systemprotokoll-Fehlermeldungen zurück.

7. Wenn Ihr Problem nicht behoben ist, posten Sie es auf AWS re:Post.

Problembehebung bei Systemprotokollfehlern für Linux-basierte Instances

Überprüfen Sie bei Linux-basierten Instances, die eine Instance-Statusprüfung wie die Instance-Erreichbarkeitsprüfung nicht bestanden haben, dass Sie die oben angegebenen Schritte zum Aufrufen des Systemprotokolls ausgeführt haben. Die folgende Liste enthält einige allgemeine Systemprotokollfehler und Vorschläge für Aktionen, die Sie ausführen können, um den jeweiligen Fehler zu beheben.

Memory Errors

• Out of memory: kill process

• ERROR: mmu_update failed (Fehler beim Aktualisieren der Speicherverwaltung)

Device Errors

• I/O-Fehler (Blockgerätfehler)

• I/O ERROR: neither local nor remote disk (defektes verteiltes Blockgerät)

Kernel Errors

• request_module: runaway loop modprobe (Endlosschleife des modprobe-Programms auf Legacy-Kerneln älterer Linux-Versionen)

• "FATAL: kernel too old" und "fsck: No such file or directory while trying to open /dev" (fehlende Übereinstimmung zwischen Kernel und AMI)

• „SCHWERWIEGEND: /lib/modules" oder "BusyBox" (Fehlende Kernelmodule) konnten nicht geladen werden

• ERROR Invalid kernel (mit EC2 nicht kompatibler Kernel)

File System Errors

• fsck: No such file or directory while trying to open... (Dateisystem nicht gefunden)

• Allgemeiner Fehler beim Mounten von Dateisystemen (Mountfehler)

• VFS: Unable to mount root fs on unknown-block (fehlende Übereinstimmung des Stammdateisystems)

• Error: Unable to determine major/minor number of root device... (fehlende Übereinstimmung des Stammdateisystems/Geräts)

• XENBUS: Device with no driver...

• ... days without being checked, check forced (Dateisystemprüfung erforderlich)

• fsck died with exit status... (fehlendes Gerät)

Operating System Errors

• GRUB prompt (grubdom>)

• Bringing up interface eth0: Device eth0 has different MAC address than expected, ignoring. (hartcodierte MAC-Adresse)

• Unable to load SELinux Policy. Machine is in enforcing mode. Halting now. (falsche SELinux-Konfiguration)

• XENBUS: Timeout connecting to devices (Xenbus-Timeout)

Out of memory: kill process

Ein out-of-memory Fehler wird durch einen Systemprotokolleintrag angezeigt, der dem unten abgebildeten ähnelt.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879
or a child 
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-
rss:101196kB, file-rss:204kB

Mögliche Ursache

Unzureichender Speicher

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie eine der folgenden Aufgaben aus: Halten Sie die Instance an und ändern Sie sie in einen anderen Instance-Typ. Starten Sie die Instance dann erneut. Verwenden Sie z. B. einen größeren oder speicheroptimierten Instance-Typ. Starten Sie die Instance neu, um sie in einen nicht eingeschränkten Status zu versetzen. Das Problem tritt wahrscheinlich erneut auf, wenn Sie den Instance-Typ nicht ändern.
Instance Store-Backup	Führen Sie eine der folgenden Aufgaben aus: Beenden Sie die Instance und starten Sie eine neue Instance unter Angabe eines anderen Instance-Typs. Verwenden Sie z. B. einen größeren oder speicheroptimierten Instance-Typ. Starten Sie die Instance neu, um sie in einen nicht eingeschränkten Status zu versetzen. Das Problem tritt wahrscheinlich erneut auf, wenn Sie den Instance-Typ nicht ändern.

ERROR: mmu_update failed (Fehler beim Aktualisieren der Speicherverwaltung)

Update-Fehler bei der Speicherverwaltung werden von einem Systemprotokolleintrag ähnlich wie unten dargestellt angegeben:

...
Press `ESC' to enter the menu... 0   [H[J  Booting 'Amazon Linux 2011.09 (2.6.35.14-95.38.amzn1.i686)'


root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /boot/vmlinuz-2.6.35.14-95.38.amzn1.i686 root=LABEL=/ console=hvc0 LANG=

en_US.UTF-8 KEYTABLE=us

initrd /boot/initramfs-2.6.35.14-95.38.amzn1.i686.img

ERROR: mmu_update failed with rc=-22

Mögliche Ursache

Problem mit Amazon Linux

Vorgeschlagene Aktion

Posten Sie Ihr Problem im Developer Forum oder wenden Sie sich an den AWS Support.

I/O-Fehler (Blockgerätfehler)

Ein Ein-/Ausgabefehler wird von einem Systemprotokolleintrag ähnlich wie im folgenden Beispiel dargestellt angegeben:

[9943662.053217] end_request: I/O error, dev sde, sector 52428288
[9943664.191262] end_request: I/O error, dev sde, sector 52428168
[9943664.191285] Buffer I/O error on device md0, logical block 209713024
[9943664.191297] Buffer I/O error on device md0, logical block 209713025
[9943664.191304] Buffer I/O error on device md0, logical block 209713026
[9943664.191310] Buffer I/O error on device md0, logical block 209713027
[9943664.191317] Buffer I/O error on device md0, logical block 209713028
[9943664.191324] Buffer I/O error on device md0, logical block 209713029
[9943664.191332] Buffer I/O error on device md0, logical block 209713030
[9943664.191339] Buffer I/O error on device md0, logical block 209713031
[9943664.191581] end_request: I/O error, dev sde, sector 52428280
[9943664.191590] Buffer I/O error on device md0, logical block 209713136
[9943664.191597] Buffer I/O error on device md0, logical block 209713137
[9943664.191767] end_request: I/O error, dev sde, sector 52428288
[9943664.191970] end_request: I/O error, dev sde, sector 52428288
[9943664.192143] end_request: I/O error, dev sde, sector 52428288
[9943664.192949] end_request: I/O error, dev sde, sector 52428288
[9943664.193112] end_request: I/O error, dev sde, sector 52428288
[9943664.193266] end_request: I/O error, dev sde, sector 52428288
...

Mögliche Ursachen

Instance-Typ	Mögliche Ursache
Amazon EBS-gestützt	Ein ausgefallenes Amazon EBS-Volume
Instance Store-Backup	Ein ausgefallenes physisches Laufwerk

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Trennen Sie das Volume ab. Versuchen Sie, das Volume wiederherzustellen. Anmerkung Es hat sich bewährt, häufig Snapshots von Amazon EBS-Volumes zu erstellen. Dadurch wird das Risiko von Datenverlusten aufgrund eines Ausfalls erheblich gesenkt. Fügen Sie das Volume der Instance wieder an. Starten Sie die Instance.
Instance Store-Backup	Beenden Sie die Instance und starten Sie eine neue Instance. Anmerkung Die Daten können nicht wiederhergestellt werden. Führen Sie eine Wiederherstellung anhand von Datensicherungen durch. Anmerkung Es hat sich bewährt, entweder Amazon S3 oder Amazon EBS für Datensicherungen zu verwenden. Ausfälle von einzelnen Hosts und Datenträgern wirken sich direkt auf Instance-Speicher-Volumes aus.

I/O ERROR: neither local nor remote disk (defektes verteiltes Blockgerät)

Ein Ein-/Ausgabefehler auf dem Gerät, der von einem Systemprotokolleintrag ähnlich wie im folgenden Beispiel dargestellt angegeben wird:

...
block drbd1: Local IO failed in request_timer_fn. Detaching...

Aborting journal on device drbd1-8.

block drbd1: IO ERROR: neither local nor remote disk

Buffer I/O error on device drbd1, logical block 557056

lost page write due to I/O error on drbd1

JBD2: I/O error detected when updating journal superblock for drbd1-8.

Mögliche Ursachen

Instance-Typ	Mögliche Ursache
Amazon EBS-gestützt	Ein ausgefallenes Amazon EBS-Volume
Instance Store-Backup	Ein ausgefallenes physisches Laufwerk

Vorgeschlagene Aktion

Beenden Sie die Instance und starten Sie eine neue Instance.

Bei einer Amazon EBS-gestützten Instance können Sie Daten anhand eines aktuellen Snapshots wiederherstellen, indem Sie ein Image davon erstellen. Alle Daten, die nach dem Snapshot hinzugefügt wurden, können nicht wiederhergestellt werden.

request_module: runaway loop modprobe (Endlosschleife des modprobe-Programms auf Legacy-Kerneln älterer Linux-Versionen)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben. Die Verwendung eines instabilen oder alten Linux-Kernels (z. B. 2.6.16-xenU) kann beim Startup eine Endlosschleife verursachen.

Linux version 2.6.16-xenU ([e-mail]) (gcc version 4.0.1 
20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007

BIOS-provided physical RAM map:

 Xen: 0000000000000000 - 0000000026700000 (usable)

0MB HIGHMEM available.
...

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Verwenden Sie einen neueren Kernel, entweder GRUB-basiert oder statisch, indem Sie eine der folgenden Optionen auswählen: Option 1: Beenden Sie die Instance und starten Sie eine neue Instance unter Angabe der Parameter -kernel und -ramdisk. Option 2: Halten Sie die Instance an. Ändern Sie die Attribute "kernel" und "ramdisk" und legen Sie sie auf einen neueren Kernel fest. Starten Sie die Instance.
Instance Store-Backup	Beenden Sie die Instance und starten Sie eine neue Instance unter Angabe der Parameter -kernel und -ramdisk.

"FATAL: kernel too old" und "fsck: No such file or directory while trying to open /dev" (fehlende Übereinstimmung zwischen Kernel und AMI)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

Linux version 2.6.16.33-xenU ([e-mail]) 
(gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #2 SMP Wed Aug 15 17:27:36 SAST 2007
...
FATAL: kernel too old
Kernel panic - not syncing: Attempted to kill init!

Mögliche Ursachen

Kernel und Land des Benutzers sind nicht kompatibel.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Ändern Sie die Konfiguration zur Verwendung eines neueren Kernels. Starten Sie die Instance.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Erstellen Sie ein AMI, das einen neueren Kernel verwendet. Beenden Sie die Instance. Starten Sie eine neue Instance mit dem AMI, das Sie erstellt haben.

„SCHWERWIEGEND: /lib/modules" oder "BusyBox" (Fehlende Kernelmodule) konnten nicht geladen werden

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

[    0.370415] Freeing unused kernel memory: 1716k freed 
Loading, please wait...
WARNING: Couldn't open directory /lib/modules/2.6.34-4-virtual: No such file or directory
FATAL: Could not open /lib/modules/2.6.34-4-virtual/modules.dep.temp for writing: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
Couldn't get a file descriptor referring to the console
Begin: Loading essential drivers... ...
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Done.
Begin: Waiting for root file system... ...
Done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
ALERT! /dev/sda1 does not exist. Dropping to a shell!


BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu5) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Mögliche Ursachen

Dieses Problem kann durch einen oder mehrere der folgenden Zustände verursacht werden:

• Fehlende Ramdisk

• Fehlende korrekte Module von der Ramdisk

• Amazon EBS-Stamm-Volume nicht korrekt als angefüg /dev/sda1

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Wählen Sie die korrigierte Ramdisk für das Amazon EBS-Volume aus. Halten Sie die Instance an. Trennen Sie das Volume und reparieren Sie es. Fügen Sie das Volume der Instance an. Starten Sie die Instance. Ändern Sie das AMI so, dass die korrigierte Ramdisk verwendet wird.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Beenden Sie die Instance und starten Sie eine neue Instance mit der korrekten Ramdisk. Erstellen Sie ein neues AMI mit der korrekten Ramdisk.

ERROR Invalid kernel (mit EC2 nicht kompatibler Kernel)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

...
root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /vmlinuz root=/dev/sda1 ro

initrd /initrd.img

ERROR Invalid kernel: elf_xen_note_check: ERROR: Will only load images 
built for the generic loader or Linux images
xc_dom_parse_image returned -1

Error 9: Unknown boot failure

  Booting 'Fallback'
  
root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /vmlinuz.old root=/dev/sda1 ro

Error 15: File not found

Mögliche Ursachen

Dieses Problem kann durch einen oder beide der folgenden Zustände verursacht werden:

• Der bereitgestellte Kernel wird von GRUB nicht unterstützt.

• Der Fallback-Kernel ist nicht vorhanden.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Tauschen Sie sie durch einen funktionierenden Kernel aus. Installieren Sie einen Fallback-Kernel. Ändern Sie das AMI, indem Sie den Kernel korrigieren.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Beenden Sie die Instance und starten Sie eine neue Instance mit dem korrekten Kernel. Erstellen Sie ein AMI mit dem korrekten Kernel. (Optional) Wenden Sie sich an den , um technische Unterstützung zur Datenwiederherstellung zu erhalten AWS Support.

fsck: No such file or directory while trying to open... (Dateisystem nicht gefunden)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

		Welcome to Fedora 
		Press 'I' to enter interactive startup.
Setting clock : Wed Oct 26 05:52:05 EDT 2011 [  OK  ]

Starting udev: [  OK  ]

Setting hostname localhost:  [  OK  ]

No devices found
Setting up Logical Volume Management: File descriptor 7 left open
  No volume groups found
[  OK  ]

Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 
/dev/sda1: clean, 82081/1310720 files, 2141116/2621440 blocks
[/sbin/fsck.ext3 (1) -- /mnt/dbbackups] fsck.ext3 -a /dev/sdh 
fsck.ext3: No such file or directory while trying to open /dev/sdh

/dev/sdh: 
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[FAILED]


*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to continue):

Mögliche Ursachen

• In den Ramdisk-Dateisystemdefinitionen "/etc/fstab" liegt ein Fehler vor.

• Die Dateisystemdefinitionen in "/etc/fstab" sind falsch konfiguriert.

• Das Laufwerk fehlt/ist fehlerhaft.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an, trennen Sie das Stamm-Volume, reparieren/ändern Sie das Volume bzw. ändern Sie etc/fstab für das Volume, fügen Sie der Instance das Volume an und starten Sie die Instance. Korrigieren Sie die Ramdisk, sodass die geänderte Datei "/etc/fstab" enthalten ist (falls zutreffend). Ändern Sie das AMI zur Verwendung einer neueren Ramdisk. Das sechste Feld in der fstab-Datei definiert die Verfügbarkeitsanforderungen für das Mounting. Ein Wert ungleich null impliziert, dass ein fsck-Befehl für dieses Volume ausgeführt wird und erfolgreich beendet werden muss. Die Verwendung dieses Felds kann in Amazon EC2 problematisch sein, da ein Ausfall in der Regel zu einer interaktiven Konsoleneingabeaufforderung führt, die derzeit in Amazon EC2 nicht verfügbar ist. Verwenden Sie dieses Feature mit Bedacht und lesen Sie den Abschnitt über die fstab-Datei im Linux-Handbuch.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Beenden Sie die Instance und starten Sie eine neue Instance. Trennen Sie fehlerhafte Amazon EBS-Volumes und die Neustart-Instance. (Optional) Wenden Sie sich an den , um technische Unterstützung zur Datenwiederherstellung zu erhalten AWS Support.

Allgemeiner Fehler beim Mounten von Dateisystemen (Mountfehler)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

Loading xenblk.ko module 
xen-vbd: registered block device major 8

Loading ehci-hcd.ko module
Loading ohci-hcd.ko module
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0

Loading mbcache.ko module
Loading jbd.ko module
Loading ext3.ko module
Creating root device.
Mounting root filesystem.
kjournald starting.  Commit interval 5 seconds

EXT3-fs: mounted filesystem with ordered data mode.

Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
mountall:/proc: unable to mount: Device or resource busy
mountall:/proc/self/mountinfo: No such file or directory
mountall: root filesystem isn't mounted
init: mountall main process (221) terminated with status 1

General error mounting filesystems.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and re-try.
Press enter for maintenance
(or type Control-D to continue):

Mögliche Ursachen

Instance-Typ	Mögliche Ursache
Amazon EBS-gestützt	Das Amazon EBS-Volume wurde getrennt oder ist ausgefallen. Das Dateisystem ist beschädigt. Die Ramdisk- und AMI-Kombination stimmt nicht überein (z. B. Debian-Ramdisk mit einem SUSE-AMI).
Instance Store-Backup	Das Laufwerk ist ausgefallen. Ein Dateisystem ist beschädigt. Die Ramdisk- und AMI-Kombination stimmt nicht überein (z. B. Debian-Ramdisk mit einem SUSE-AMI).

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Trennen Sie das Stamm-Volume. Fügen Sie das Stamm-Volume einer funktionierenden Instance an. Führen Sie eine Dateisystemprüfung aus (fsck -a /dev/...). Beheben Sie vorhandene Fehler. Trennen Sie das Volume von der funktionierenden Instance. Fügen Sie das Volume der angehaltenen Instance an. Starten Sie die Instance. Prüfen Sie den Status der Instance erneut.
Instance Store-Backup	Führen Sie einen der folgenden Schritte aus: Starten Sie eine neue Instance. (Optional) Wenden Sie sich an den , um technische Unterstützung zur Datenwiederherstellung zu erhalten AWS Support.

VFS: Unable to mount root fs on unknown-block (fehlende Übereinstimmung des Stammdateisystems)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

Linux version 2.6.16-xenU ([e-mail]) (gcc version 4.0.1 
 20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
...
Kernel command line:  root=/dev/sda1 ro 4
...
Registering block device major 8
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Mögliche Ursachen

Instance-Typ	Mögliche Ursache
Amazon EBS-gestützt	Das Gerät ist nicht ordnungsgemäß angefügt. Das Stammgerät wurde nicht am korrekten Gerätepunkt angefügt. Das Dateisystem hat nicht das erwartete Format. Es wurde ein Legacy-Kernel (z. B. 2.6.16-XenU) verwendet. Ein aktuelles Kernel-Update Ihrer Instance wurde fehlerhaft ausgeführt oder enthält einen Fehler.
Instance Store-Backup	Das Hardware-Gerät ist ausgefallen.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie eine der folgenden Aufgaben aus: Halten Sie die Instance an und starten Sie sie neu. Ändern Sie das Stamm-Volume und fügen Sie es am richtigen Gerätepunkt an, möglicherweise "/dev/sda1" statt "/dev/sda". Halten Sie das Gerät an und ändern Sie es auf einen aktuellen Kernel. Bekannte Fehler beim Update finden Sie in der Dokumentation Ihrer Linux-Verteilung. Ändern Sie den Kernel oder installieren Sie ihn neu.
Instance Store-Backup	Beenden Sie die Instance und starten Sie eine neue Instance mit einem aktuellen Kernel.

Error: Unable to determine major/minor number of root device... (fehlende Übereinstimmung des Stammdateisystems/Geräts)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

...
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/vbd/2048
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Initializing network drop monitor service
Freeing unused kernel memory: 508k freed
:: Starting udevd...
done.
:: Running Hook [udev]
:: Triggering uevents...<30>udevd[65]: starting version 173
done.
Waiting 10 seconds for device /dev/xvda1 ...
Root device '/dev/xvda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/xvda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[ramfs /]#

Mögliche Ursachen

• Der virtuelle Blockgerättreiber fehlt oder ist falsch konfiguriert.

• Es liegt eine Gerätenummerierungskollision vor (sda statt xvda oder sda statt sda1).

• Der falsche Instance-Kernel wurde ausgewählt.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Trennen Sie das Volume ab. Beheben Sie das Gerätezuweisungsproblem. Starten Sie die Instance. Ändern Sie das AMI, um die Gerätezuweisungsprobleme zu beheben.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Erstellen Sie ein neues AMI mit der entsprechenden Fehlerbehebung (weisen Sie das Blockgerät korrekt zu). Beenden Sie die Instance und starten Sie eine neue Instance mit dem AMI, das Sie erstellt haben.

XENBUS: Device with no driver...

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

XENBUS: Device with no driver: device/vbd/2048
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Initializing network drop monitor service
Freeing unused kernel memory: 508k freed
:: Starting udevd...
done.
:: Running Hook [udev]
:: Triggering uevents...<30>udevd[65]: starting version 173
done.
Waiting 10 seconds for device /dev/xvda1 ...
Root device '/dev/xvda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/xvda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[ramfs /]#

Mögliche Ursachen

• Der virtuelle Blockgerättreiber fehlt oder ist falsch konfiguriert.

• Es liegt eine Gerätenummerierungskollision vor (sda statt xvda).

• Der falsche Instance-Kernel wurde ausgewählt.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Trennen Sie das Volume ab. Beheben Sie das Gerätezuweisungsproblem. Starten Sie die Instance. Ändern Sie das AMI, um die Gerätezuweisungsprobleme zu beheben.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Erstellen Sie ein AMI mit der entsprechenden Fehlerbehebung (weisen Sie das Blockgerät korrekt zu). Beenden Sie die Instance und starten Sie eine neue Instance mit dem AMI, das Sie erstellt haben.

... days without being checked, check forced (Dateisystemprüfung erforderlich)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

...
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 
/dev/sda1 has gone 361 days without being checked, check forced

Mögliche Ursachen

Der Zeitpunkt der Dateisystemprüfung ist überschritten; eine Dateisystemprüfung wird erzwungen.

Vorgeschlagene Aktionen

• Warten Sie, bis die Dateisystemprüfung abgeschlossen ist. Eine solche Prüfung kann je nach Größe des Stammdateisystems einige Zeit in Anspruch nehmen.

• Ändern Sie Ihre Dateisysteme, um die Erzwingung der Dateisystemprüfung (fsck) mit tune2fs oder mit für Ihr Dateisystem geeigneten Tools zu entfernen.

fsck died with exit status... (fehlendes Gerät)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

Cleaning up ifupdown....
Loading kernel modules...done.
...
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.16.2
/sbin/fsck.xfs: /dev/sdh does not exist
fsck died with exit status 8
[31mfailed (code 8).[39;49m

Mögliche Ursachen

• Die Ramdisk sucht nach einem fehlenden Laufwerk.

• Die Konsistenzprüfung des Dateisystems wurde erzwungen.

• Das Laufwerk ist ausgefallen oder wurde getrennt.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie einen oder mehrere der folgenden Schritte aus, um das Problem zu lösen: Halten Sie die Instance an und fügen Sie das Volume einer vorhandenen, aktuell ausgeführten Instance an. Führen Sie Konsistenzprüfungen manuell aus. Korrigieren Sie die Ramdisk, sodass sie relevante Dienstprogramme umfasst. Ändern Sie Parameter zur Optimierung des Dateisystems, um Konsistenzanforderungen zu entfernen (nicht empfohlen).
Instance Store-Backup	Führen Sie einen oder mehrere der folgenden Schritte aus, um das Problem zu lösen: Bündeln Sie die Ramdisk mit den richtigen Tools neu. Ändern Sie Parameter zur Optimierung des Dateisystems, um Konsistenzanforderungen zu entfernen (nicht empfohlen). Beenden Sie die Instance und starten Sie eine neue Instance. (Optional) Wenden Sie sich an den , um technische Unterstützung zur Datenwiederherstellung zu erhalten AWS Support.

GRUB prompt (grubdom>)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

    GNU GRUB  version 0.97  (629760K lower / 0K upper memory)

       [ Minimal BASH-like line editing is supported.   For

         the   first   word,  TAB  lists  possible  command

         completions.  Anywhere else TAB lists the possible

         completions of a device/filename. ]

grubdom> 

Mögliche Ursachen

Instance-Typ	Mögliche Ursachen
Amazon EBS-gestützt	Die GRUB-Konfigurationsdatei fehlt. Es wird ein falsches GRUB-Image verwendet, sodass die GRUB-Konfigurationsdatei an einem anderen Speicherort erwartet wird. Es wird ein nicht unterstütztes Dateisystem zum Speichern Ihrer GRUB-Konfigurationsdatei verwendet (Ihr Stammdateisystem wird z. B. in einen Typ konvertiert, der von einer früheren GRUB-Version nicht unterstützt wird).
Instance Store-Backup	Die GRUB-Konfigurationsdatei fehlt. Es wird ein falsches GRUB-Image verwendet, sodass die GRUB-Konfigurationsdatei an einem anderen Speicherort erwartet wird. Es wird ein nicht unterstütztes Dateisystem zum Speichern Ihrer GRUB-Konfigurationsdatei verwendet (Ihr Stammdateisystem wird z. B. in einen Typ konvertiert, der von einer früheren GRUB-Version nicht unterstützt wird).

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Option 1: Ändern Sie das AMI und starten Sie die Instance neu: Ändern Sie das Quell-AMI, um eine GRUB-Konfigurationsdatei am Standardspeicherort zu erstellen (/boot/grub/menu.lst). Überprüfen Sie, dass Ihre GRUB-Version den zugrunde liegenden Dateisystemtyp unterstützt, und upgraden Sie GRUB, falls erforderlich. Wählen Sie das geeignete GRUB-Image aus ("hd0-1st drive" oder "hd00 – 1st drive, 1st partition"). Beenden Sie die Instance, und starten Sie eine neue Instance mit dem AMI, das Sie erstellt haben. Option 2: Reparieren Sie die vorhandene Instance: Halten Sie die Instance an. Trennen Sie das Stammdateisystem. Fügen Sie das Stammdateisystem einer funktionierenden Instance an. Mounten Sie das Dateisystem. Erstellen Sie eine GRUB-Konfigurationsdatei. Überprüfen Sie, dass Ihre GRUB-Version den zugrunde liegenden Dateisystemtyp unterstützt, und upgraden Sie GRUB, falls erforderlich. Trennen Sie das Dateisystem. Fügen Sie es der ursprünglichen Instance an. Ändern Sie das Kernel-Attribut zur Verwendung des entsprechenden GRUB-Images ("hd0-1st drive" oder "hd00 – 1st drive, 1st partition"). Starten Sie die Instance.
Instance Store-Backup	Option 1: Ändern Sie das AMI und starten Sie die Instance neu: Erstellen Sie das neue AMI mit einer GRUB-Konfigurationsdatei am Standardspeicherort (/boot/grub/menu.lst). Wählen Sie das geeignete GRUB-Image aus ("hd0-1st drive" oder "hd00 – 1st drive, 1st partition"). Überprüfen Sie, dass Ihre GRUB-Version den zugrunde liegenden Dateisystemtyp unterstützt, und upgraden Sie GRUB, falls erforderlich. Beenden Sie die Instance und starten Sie eine neue Instance mit dem AMI, das Sie erstellt haben. Option 2: Beenden Sie die Instance und starten Sie eine neue Instance unter Angabe des korrekten Kernels. Anmerkung Wenden Sie sich an den AWS Support, um Daten von der vorhandenen Instance wiederherzustellen.

Bringing up interface eth0: Device eth0 has different MAC address than expected, ignoring. (hartcodierte MAC-Adresse)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

... 
Bringing up loopback interface:  [  OK  ]

Bringing up interface eth0:  Device eth0 has different MAC address than expected, ignoring.
[FAILED]

Starting auditd: [  OK  ]

Mögliche Ursachen

In der AMI-Konfiguration ist eine hartcodierte MAC-Schnittstelle enthalten.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie eine der folgenden Aufgaben aus: Ändern Sie das AMI, um die Hartcodierung zu entfernen, und starten Sie die Instance neu. Ändern Sie die Instance, um die hartcodierte MAC-Adresse zu entfernen. ODER Führen Sie die folgenden Schritte aus: Halten Sie die Instance an. Trennen Sie das Stamm-Volume. Fügen Sie das Volume einer anderen Instance an und ändern Sie das Volume, um die hartcodierte MAC-Adresse zu entfernen. Fügen Sie das Volume der ursprünglichen Instance an. Starten Sie die Instance.
Instance Store-Backup	Führen Sie eine der folgenden Aufgaben aus: Ändern Sie die Instance, um die hartcodierte MAC-Adresse zu entfernen. Beenden Sie die Instance und starten Sie eine neue Instance.

Unable to load SELinux Policy. Machine is in enforcing mode. Halting now. (falsche SELinux-Konfiguration)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

audit(1313445102.626:2): enforcing=1 old_enforcing=0 auid=4294967295
Unable to load SELinux Policy. Machine is in enforcing mode. Halting now.
Kernel panic - not syncing: Attempted to kill init!

Mögliche Ursachen

SELinux wurde versehentlich aktiviert:

• Der bereitgestellte Kernel wird von GRUB nicht unterstützt.

• Der Fallback-Kernel ist nicht vorhanden.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie die folgenden Schritte aus: Halten Sie die ausgefallene Instance an. Trennen Sie die ausgefallene Instance vom Stamme-Volume. Fügen Sie das Stamm-Volume einer anderen, aktuell ausgeführten Linux-Instance an (diese wird nachfolgend als Wiederherstellungs-Instance bezeichnet). Stellen Sie eine Verbindung mit der Wiederherstellungs-Instance her und mounten Sie das Stamm-Volume der ausgefallenen Instance. Deaktivieren Sie SELinux auf dem gemounteten Stamm-Volume. Dieser Prozess ist je nach Linux-Verteilung unterschiedlich. Weitere Informationen finden Sie in der betriebssystemspezifischen Dokumentation. Anmerkung In einigen Systemen deaktivieren Sie SELinux, indem Sie SELINUX=disabled in der /mount_point/etc/sysconfig/selinux-Datei festlegen, wobei mount_point der Punkt ist, an dem Sie das Volume auf Ihrer Wiederherstellungs-Instance gemountet haben. Heben Sie die Bereitstellung des Stamm-Volumes auf, trennen Sie es von der Wiederherstellungs-Instance und fügen Sie es der ursprünglichen Instance wieder an. Starten Sie die Instance.
Instance Store-Backup	Führen Sie die folgenden Schritte aus: Beenden Sie die Instance und starten Sie eine neue Instance. (Optional) Wenden Sie sich an den , um technische Unterstützung zur Datenwiederherstellung zu erhalten AWS Support.

XENBUS: Timeout connecting to devices (Xenbus-Timeout)

Dieser Zustand wird von einem Systemprotokoll ähnlich wie unten dargestellt angegeben.

Linux version 2.6.16-xenU ([e-mail]) (gcc version 4.0.1 
20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
...
XENBUS: Timeout connecting to devices!
...
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Mögliche Ursachen

• Das Blockgerät ist nicht mit der Instance verbunden.

• Die Instance verwendet einen alten Instance-Kernel.

Vorgeschlagene Aktionen

Für diesen Instance-Typ	Vorgehensweise
Amazon EBS-gestützt	Führen Sie eine der folgenden Aufgaben aus: Ändern Sie das AMI und die Instance, um einen aktuellen Kernel zu verwenden, und starten Sie die Instance neu. Starten Sie die Instance neu.
Instance Store-Backup	Führen Sie eine der folgenden Aufgaben aus: Beenden Sie die Instance. Ändern Sie das AMI, um einen aktuellen Kernel zu verwenden, und starten Sie eine neue Instance mit dem geänderten AMI.