Problembehandlung bei Amazon EC2 Linux-Instances mit fehlgeschlagenen Statusprüfungen - Amazon Elastic Compute Cloud
Informationen der Statusprüfung durchgehenSystemprotokolle abrufenBeheben Sie Systemprotokollfehler für Linux-InstancesOut of memory: kill processERROR: mmu_update ist fehlgeschlagen (Aktualisierung der Speicherverwaltung fehlgeschlagen)I/O-Fehler (Blockgerätfehler)I/OERROR: weder lokale noch externe Festplatte (defektes verteiltes Blockgerät)request_module: runaway loop modprobe (Endlosschleife des modprobe-Programms auf Legacy-Kerneln älterer Linux-Versionen)„FATAL: Kernel zu alt“ und „fsck: Keine solche Datei oder kein solches Verzeichnis beim Versuch, /dev zu öffnen“ (Kernel und AMI Mismatch) "FATAL: /lib/modules" oder "BusyBox" (Fehlende Kernelmodule) konnten nicht geladen werdenERRORUngültiger Kernel (EC2inkompatibler Kernel)fsck: No such file or directory while trying to open... (Dateisystem nicht gefunden)Allgemeiner Fehler beim Mounten von Dateisystemen (Mountfehler)VFS: Root-FS konnte nicht auf einem unbekannten Block gemountet werden (Root-Dateisystem stimmt nicht überein)Error: Unable to determine major/minor number of root device... (fehlende Übereinstimmung des Stammdateisystems/Geräts)XENBUS: Gerät ohne Treiber...... days without being checked, check forced (Dateisystemprüfung erforderlich)fsck died with exit status... (fehlendes Gerät)GRUBEingabeaufforderung (grubdom>)Schnittstelle eth0 aufrufen: Gerät eth0 hat eine andere MAC Adresse als erwartet und wird ignoriert. (Hartcodierte Adresse) MAC Die SELinux Richtlinie konnte nicht geladen werden. Machine is in enforcing mode. Halting now. (SELinuxFehlkonfiguration)XENBUS: Timeout bei der Verbindung zu Geräten (Xenbus-Timeout)

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Problembehandlung bei Amazon EC2 Linux-Instances mit fehlgeschlagenen Statusprüfungen

Die folgenden Informationen können Ihnen bei der Behebung von Problemen helfen, wenn Ihre Linux-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 Statuschecks für EC2 Amazon-Instances.

Inhalt

Informationen der Statusprüfung durchgehen

Um beeinträchtigte Instances mithilfe der EC2 Amazon-Konsole zu untersuchen

  1. Öffnen Sie die EC2 Amazon-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 den Tab Status und Alarme, um die einzelnen Ergebnisse aller Systemstatusprüfungen, Instance-Statusprüfungen und EBSAttached-Statuschecks zu sehen.

Wenn eine Statusüberprüfung fehlgeschlagen ist, können Sie eine der folgenden Optionen ausprobieren:

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 EC2 Amazon-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.

Beheben Sie Systemprotokollfehler für Linux-Instances

Vergewissern Sie sich bei Linux-Instances, die eine Instanzstatusprüfung nicht bestanden haben, z. B. die Erreichbarkeitsprüfung der Instanz, dass Sie die oben genannten Schritte zum Abrufen des Systemprotokolls befolgt 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

Device Errors

Kernel Errors

File System Errors

Operating System Errors

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

Von Amazon EBS unterstützt

Führen Sie eine der folgenden Aktionen 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 ist fehlgeschlagen (Aktualisierung der Speicherverwaltung fehlgeschlagen)

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

Von Amazon EBS unterstützt

Ein ausgefallenes EBS Amazon-Volume

Instance Store-Backup

Ein ausgefallenes physisches Laufwerk

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Trennen Sie das Volume ab.

  3. Versuchen Sie, das Volume wiederherzustellen.

    Anmerkung

    Es empfiehlt sich, häufig Snapshots Ihrer EBS Amazon-Volumes zu erstellen. Dadurch wird das Risiko von Datenverlusten aufgrund eines Ausfalls erheblich gesenkt.

  4. Fügen Sie das Volume der Instance wieder an.

  5. 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 empfiehlt sich, entweder Amazon S3 oder Amazon EBS für Backups zu verwenden. Ausfälle von einzelnen Hosts und Datenträgern wirken sich direkt auf Instance-Speicher-Volumes aus.

I/OERROR: weder lokale noch externe Festplatte (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

Von Amazon EBS unterstützt

Ein ausgefallenes EBS Amazon-Volume

Instance Store-Backup

Ein ausgefallenes physisches Laufwerk

Vorgeschlagene Aktion

Beenden Sie die Instance und starten Sie eine neue Instance.

Für eine von Amazon EBS unterstützte Instance können Sie Daten aus einem aktuellen Snapshot wiederherstellen, indem Sie daraus ein Image 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 (builder@xenbat.amazonsa) (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

Von Amazon EBS unterstützt

Verwenden Sie einen neueren Kernel, entweder GRUB basiert oder statisch, und verwenden Sie eine der folgenden Optionen:

Option 1: Beenden Sie die Instance und starten Sie eine neue Instance unter Angabe der Parameter -kernel und -ramdisk.

Option 2:

  1. Halten Sie die Instance an.

  2. Ändern Sie die Attribute "kernel" und "ramdisk" und legen Sie sie auf einen neueren Kernel fest.

  3. 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 zu alt“ und „fsck: Keine solche Datei oder kein solches Verzeichnis beim Versuch, /dev zu öffnen“ (Kernel und AMI Mismatch)

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

Linux version 2.6.16.33-xenU (root@dom0-0-50-45-1-a4-ee.z-2.aes0.internal) 
(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

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Ändern Sie die Konfiguration zur Verwendung eines neueren Kernels.

  3. Starten Sie die Instance.

Instance Store-Backup

Führen Sie die folgenden Schritte aus:

  1. Erstellen Sie einenAMI, der einen neueren Kernel verwendet.

  2. Beenden Sie die Instance.

  3. Starten Sie eine neue Instanz von der, die AMI Sie erstellt haben.

"FATAL: /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

  • EBSAmazon-Root-Volume nicht korrekt angehängt als /dev/sda1

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Wählen Sie die korrigierte Ramdisk für das EBS Amazon-Volume aus.

  2. Halten Sie die Instance an.

  3. Trennen Sie das Volume und reparieren Sie es.

  4. Fügen Sie das Volume der Instance an.

  5. Starten Sie die Instance.

  6. Ändern Sie dieAMI, um die korrigierte Ramdisk zu verwenden.

Instance Store-Backup

Führen Sie die folgenden Schritte aus:

  1. Beenden Sie die Instance und starten Sie eine neue Instance mit der korrekten Ramdisk.

  2. Erstellen Sie eine neue AMI mit der richtigen Ramdisk.

ERRORUngültiger Kernel (EC2inkompatibler 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 mitgelieferte Kernel wird nicht unterstützt von GRUB

  • Der Fallback-Kernel ist nicht vorhanden.

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Tauschen Sie sie durch einen funktionierenden Kernel aus.

  3. Installieren Sie einen Fallback-Kernel.

  4. Ändern Sie das, AMI indem Sie den Kernel korrigieren.

Instance Store-Backup

Führen Sie die folgenden Schritte aus:

  1. Beenden Sie die Instance und starten Sie eine neue Instance mit dem korrekten Kernel.

  2. Erstellen Sie einen AMI mit dem richtigen Kernel.

  3. (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

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. 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.

  2. Korrigieren Sie die Ramdisk, sodass die geänderte Datei "/etc/fstab" enthalten ist (falls zutreffend).

  3. Ändern Sie denAMI, um eine neuere Ramdisk zu verwenden.

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 problematisch seinEC2, da ein Fehler in der Regel zu einer interaktiven Konsolenaufforderung führt, die derzeit bei Amazon nicht verfügbar istEC2. 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:

  1. Beenden Sie die Instance und starten Sie eine neue Instance.

  2. Trennen Sie alle fehlerhaften EBS Amazon-Volumes und starten Sie die Instance neu.

  3. (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

Von Amazon EBS unterstützt

  • Abgetrenntes oder ausgefallenes EBS Amazon-Volume.

  • Das Dateisystem ist beschädigt.

  • Ramdisk und AMI Kombination stimmen nicht überein (z. B. Debian-Ramdisk mit a). SUSE AMI

Instance Store-Backup

  • Das Laufwerk ist ausgefallen.

  • Ein Dateisystem ist beschädigt.

  • Eine Ramdisk und eine Kombination aus Ramdisk und Kombination (zum Beispiel eine Debian-Ramdisk mit a). SUSE AMI

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Trennen Sie das Stamm-Volume.

  3. Fügen Sie das Stamm-Volume einer funktionierenden Instance an.

  4. Führen Sie eine Dateisystemprüfung aus (fsck -a /dev/...).

  5. Beheben Sie vorhandene Fehler.

  6. Trennen Sie das Volume von der funktionierenden Instance.

  7. Fügen Sie das Volume der angehaltenen Instance an.

  8. Starten Sie die Instance.

  9. 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: Root-FS konnte nicht auf einem unbekannten Block gemountet werden (Root-Dateisystem stimmt nicht überein)

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

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (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

Von Amazon EBS unterstü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

Von Amazon EBS unterstützt

Führen Sie eine der folgenden Aktionen 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

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Trennen Sie das Volume ab.

  3. Beheben Sie das Gerätezuweisungsproblem.

  4. Starten Sie die Instance.

  5. Ändern Sie dasAMI, um Probleme mit der Gerätezuordnung zu beheben.

Instance Store-Backup

Führen Sie die folgenden Schritte aus:

  1. Erstellen Sie ein neues Gerät AMI mit dem entsprechenden Fix (blockiertes Gerät korrekt zuordnen).

  2. Beenden Sie die Instanz und starten Sie eine neue Instanz von der, die AMI Sie erstellt haben.

XENBUS: Gerät ohne Treiber...

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

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Trennen Sie das Volume ab.

  3. Beheben Sie das Gerätezuweisungsproblem.

  4. Starten Sie die Instance.

  5. Ändern Sie dasAMI, um Probleme mit der Gerätezuordnung zu beheben.

Instance Store-Backup

Führen Sie die folgenden Schritte aus:

  1. Erstellen Sie eine AMI mit dem entsprechenden Fix (Gerät korrekt zuordnen).

  2. Beenden Sie die Instanz und starten Sie eine neue Instanz mit der von AMI Ihnen erstellten.

... 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

Von Amazon EBS unterstü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.

GRUBEingabeaufforderung (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

Von Amazon EBS unterstützt

  • Fehlende GRUB Konfigurationsdatei.

  • Es wurde GRUB ein falsches Bild verwendet. Die GRUB Konfigurationsdatei wird an einem anderen Speicherort erwartet.

  • Nicht unterstütztes Dateisystem, das zum Speichern Ihrer GRUB Konfigurationsdatei verwendet wurde (z. B. bei der Konvertierung Ihres Root-Dateisystems in einen Typ, der von einer früheren Version von GRUB nicht unterstützt wird).

Instance Store-Backup

  • Fehlende GRUB Konfigurationsdatei.

  • Es wurde GRUB ein falsches Bild verwendet. Die GRUB Konfigurationsdatei wird an einem anderen Speicherort erwartet.

  • Nicht unterstütztes Dateisystem, das zum Speichern Ihrer GRUB Konfigurationsdatei verwendet wurde (z. B. bei der Konvertierung Ihres Root-Dateisystems in einen Typ, der von einer früheren Version von GRUB nicht unterstützt wird).

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Option 1: Ändern Sie die Instance AMI und starten Sie sie neu:

  1. Ändern Sie die QuelleAMI, um eine GRUB Konfigurationsdatei am Standardspeicherort (/boot/grub/menu.lst) zu erstellen.

  2. Stellen Sie sicher, dass Ihre Version von den zugrunde liegenden Dateisystemtyp GRUB unterstützt, und führen Sie gegebenenfalls ein Upgrade durch. GRUB

  3. Wählen Sie das entsprechende GRUB Image aus (hd0-1. Laufwerk oder hd00 — erstes Laufwerk, 1. Partition).

  4. Beenden Sie die Instance und starten Sie eine neue mit derAMI, die Sie erstellt haben.

Option 2: Reparieren Sie die vorhandene Instance:

  1. Halten Sie die Instance an.

  2. Trennen Sie das Stammdateisystem.

  3. Fügen Sie das Stammdateisystem einer funktionierenden Instance an.

  4. Mounten Sie das Dateisystem.

  5. Erstellen Sie eine GRUB Konfigurationsdatei.

  6. Stellen Sie sicher, dass Ihre Version von den zugrunde liegenden Dateisystemtyp GRUB unterstützt, und führen GRUB Sie gegebenenfalls ein Upgrade durch.

  7. Trennen Sie das Dateisystem.

  8. Fügen Sie es der ursprünglichen Instance an.

  9. Ändern Sie das Kernel-Attribut so, dass das entsprechende GRUB Image verwendet wird (1. Festplatte oder 1. Partition auf erster Festplatte).

  10. Starten Sie die Instance.

Instance Store-Backup

Option 1: Ändern Sie die Instanz AMI und starten Sie sie neu:

  1. Erstellen Sie die neue Datei AMI mit einer GRUB Konfigurationsdatei am Standardspeicherort (/boot/grub/menu.lst).

  2. Wählen Sie das entsprechende GRUB Image aus (hd0-1. Laufwerk oder hd00 — 1. Laufwerk, 1. Partition).

  3. Stellen Sie sicher, dass Ihre Version von den zugrunde liegenden Dateisystemtyp GRUB unterstützt, und führen Sie gegebenenfalls ein Upgrade GRUB durch.

  4. Beenden Sie die Instance und starten Sie eine neue Instance mit der von AMI Ihnen erstellten.

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.

Schnittstelle eth0 aufrufen: Gerät eth0 hat eine andere MAC Adresse als erwartet und wird ignoriert. (Hartcodierte Adresse) MAC

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 Konfiguration gibt es eine hartcodierte Schnittstelle MAC AMI

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Führen Sie eine der folgenden Aktionen aus:

  • Ändern Sie dasAMI, um die Hardcodierung zu entfernen und die Instance neu zu starten.

  • Ändern Sie die Instanz, um die MAC hartcodierte Adresse zu entfernen.

ODER

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die Instance an.

  2. Trennen Sie das Stamm-Volume.

  3. Hängen Sie das Volume an eine andere Instance an und ändern Sie das Volume, um die hartcodierte MAC Adresse zu entfernen.

  4. Fügen Sie das Volume der ursprünglichen Instance an.

  5. Starten Sie die Instance.

Instance Store-Backup

Führen Sie eine der folgenden Aktionen aus:

  • Ändern Sie die Instanz, um die hartcodierte MAC Adresse zu entfernen.

  • Beenden Sie die Instance und starten Sie eine neue Instance.

Die SELinux Richtlinie konnte nicht geladen werden. Machine is in enforcing mode. Halting now. (SELinuxFehlkonfiguration)

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

SELinuxwurde irrtümlich aktiviert:

  • Der mitgelieferte Kernel wird nicht unterstützt von GRUB

  • Der Fallback-Kernel ist nicht vorhanden.

Vorgeschlagene Aktionen

Für diesen Instance-Typ Vorgehensweise

Von Amazon EBS unterstützt

Führen Sie die folgenden Schritte aus:

  1. Halten Sie die ausgefallene Instance an.

  2. Trennen Sie die ausgefallene Instance vom Stamme-Volume.

  3. Fügen Sie das Stamm-Volume einer anderen, aktuell ausgeführten Linux-Instance an (diese wird nachfolgend als Wiederherstellungs-Instance bezeichnet).

  4. Stellen Sie eine Verbindung mit der Wiederherstellungs-Instance her und mounten Sie das Stamm-Volume der ausgefallenen Instance.

  5. SELinuxAuf dem bereitgestellten Root-Volume deaktivieren. Dieser Prozess ist je nach Linux-Verteilung unterschiedlich. Weitere Informationen finden Sie in der betriebssystemspezifischen Dokumentation.

    Anmerkung

    Auf einigen Systemen deaktivieren Sie, SELinux indem Sie SELINUX=disabled in der /mount_point/etc/sysconfig/selinux Datei angeben, wo sich der Speicherort mount_point befindet, an dem Sie das Volume auf Ihrer Wiederherstellungsinstanz bereitgestellt haben.

  6. 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.

  7. Starten Sie die Instance.

Instance Store-Backup

Führen Sie die folgenden Schritte aus:

  1. Beenden Sie die Instance und starten Sie eine neue Instance.

  2. (Optional) Wenden Sie sich an den , um technische Unterstützung zur Datenwiederherstellung zu erhalten AWS Support.

XENBUS: Timeout bei der Verbindung zu Geräten (Xenbus-Timeout)

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

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (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

Von Amazon EBS unterstützt

Führen Sie eine der folgenden Aktionen aus:

  • Ändern Sie die AMI AND-Instance so, dass sie einen modernen Kernel verwendet, 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 denAMI, um einen modernen Kernel zu verwenden, und starten Sie mit diesem AMI eine neue Instance.