Résolution des problèmes d’instances avec des contrôles de statut échoués

Les informations suivantes peuvent vous aider à résoudre les problèmes si votre instance échoue à un contrôle de statut. Commencez par déterminer si vos applications présentent des problèmes. Si vous constatez que l’instance n’exécute pas vos applications comme prévu, passez en revue les informations de contrôle de statut et les journaux système.

Pour des exemples de problèmes pouvant entraîner l’échec des vérifications d’état, consultez Contrôles de statut pour vos instances.

Examen des informations de contrôle de statut

Pour enquêter sur les instances dégradées en utilisant la console Amazon EC2

1. Ouvrez la console Amazon EC2 sur https://console.aws.amazon.com/ec2/.

2. Dans le panneau de navigation, choisissez instances, puis sélectionnez votre instance.

3. Dans le volet des détails, sélectionnez Statuts et alarmes pour voir les résultats individuels pour tous les Contrôles de statut de système et Contrôles de statut des instances.

Si un contrôle de statut d’un système a échoué, vous pouvez essayer l’une des options suivantes :

• Créez une alarme de récupération d’instance. Pour plus d’informations, consultez Créer des alarmes qui arrêtent, finissent, redémarrent ou récupèrent une instance.

• Si vous avez changé le type d'instance pour une instance basée sur le système AWS Nitro, les vérifications d'état échouent si vous avez migré depuis une instance qui ne possède pas les pilotes ENA et NVMe requis. Pour plus d’informations, consultez Compatibilité pour modifier le type d’instance.

• Pour une instance qui utilise une AMI basée sur des volumes Amazon EBS, arrêtez et relancez l’instance.

• Pour une instance qui utilise une AMI basée sur le stockage d’instance, arrêtez l’instance et lancez-en une autre.

• Attendez qu’Amazon EC2 résolve le problème.

• Publiez votre problème sur AWS re:Post.

• Si votre instance est dans un groupe Auto Scaling, le service Amazon EC2 Auto Scaling lance automatiquement une instance de remplacement. Pour plus d’informations, consultez Vérification de l’état des instances Auto Scaling dans le Amazon EC2 Auto Scaling Guide de l’utilisateur.

• Récupérez le journal du système et recherchez les erreurs.

Récupération des journaux système

Si un contrôle de statut d’instance échoue, vous pouvez relancer l’instance et récupérer les journaux du système. Les journaux peuvent révéler une erreur que peut vous aider à résoudre le problème. Le redémarrage efface les informations inutiles des journaux.

Pour redémarrer une instance et récupérer le journal du système

1. Ouvrez la console Amazon EC2 sur https://console.aws.amazon.com/ec2/.

2. Dans le panneau de navigation, sélectionnez instances, puis choisissez votre instance.

3. Sélectionnez État de l’instance, puis Redémarrer l’instance. Le redémarrage de votre instance peut prendre quelques minutes.

4. Vérifiez si le problème existe encore. Dans certains cas, le redémarrage peut résoudre le problème.

5. Lorsque l’état de l’instance est running, sélectionnez Actions, Surveiller et dépanner, Obtenir le journal système.

6. Consultez le journal qui apparaît à l’écran et utilisez la liste ci-dessous des déclarations d’erreurs connues du journal du système afin de résoudre votre problème.

7. Si votre problème n’est pas résolu, vous pouvez le publier sur AWS re:Post.

Résolution des problèmes du journal du système pour les instances basées sur Linux

Pour les instances basées sur Linux qui ont échoué à un contrôle de statut d’instance, comme le contrôle d’accessibilité de l’instance, vérifiez que vous avez suivi les étapes ci-dessous pour récupérer le journal du système. La liste suivante contient certaines erreurs communes du journal du système et les actions suggérées que vous pouvez prendre pour résoudre le problème correspondant à chaque erreur.

Memory Errors

• Mémoire insuffisante : processus d’arrêt

• ERROR: mmu_update failed (la mise à jour de la gestion de la mémoire a échoué)

Device Errors

• Erreur d’E/S (échec du périphérique de stockage en mode bloc)

• I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)

Kernel Errors

• request_module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)

• « FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)

• « FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)

• ERROR Invalid kernel (noyau incompatible EC2)

File System Errors

• fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)

• General error mounting filesystems (Montage en échec)

• VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)

• Erreur : Unable to determine major/minor number of root device... (décalage du système de fichiers/périphérique racine)

• XENBUS : Device with no driver...

• ... days without being checked, check forced (Contrôle du système de fichiers nécessaire)

• fsck a échoué à l’état de sortie... (périphérique manquant)

Operating System Errors

• Invite GRUB (grubdom>)

• Mise en service de l’interface eth0 : l’adresse MAC du périphérique eth0 est différente de celle attendue, ignorer. (Adresse MAC codée de manière irréversible)

• Impossible de charger la politique SELinux. L’appareil est en mode d’exécution. Arrêt maintenant. (Erreur de configuration SELinux)

• XENBUS: Timeout connecting to devices (délai d’attente Xenbus)

Mémoire insuffisante : processus d’arrêt

Une out-of-memory erreur est indiquée par une entrée du journal système similaire à celle illustrée ci-dessous.

[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

Cause potentielle

Mémoire épuisée

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Effectuez l’une des actions suivantes : Arrêtez l’instance et modifiez l’instance pour utiliser un type d’instance différent, puis relancez l’instance. Par exemple, un type d’instance plus importante ou optimisée pour la mémoire. Redémarrez l’instance pour la renvoyer vers un statut non-défaillant. Le problème se reproduira probablement à moins que vous ne changiez de type d’instance.
Basée sur le stockage d’instance	Effectuez l’une des actions suivantes : Arrêtez l’instance et lancez une nouvelle instance en spécifiant un type d’instance différent. Par exemple, un type d’instance plus importante ou optimisée pour la mémoire. Redémarrez l’instance pour la renvoyer vers un statut non-défaillant. Le problème se reproduira probablement à moins que vous ne changiez de type d’instance.

ERROR: mmu_update failed (la mise à jour de la gestion de la mémoire a échoué)

Les échecs de la mise à jour de la gestion de la mémoire sont indiqués par une entrée du journal du système qui est similaire à ce qui suit :

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

Cause potentielle

Problème avec Amazon Linux

Action suggérée

Publiez votre problème sur Forums dédiés aux développeurs ou contactez AWS Support.

Erreur d’E/S (échec du périphérique de stockage en mode bloc)

Une erreur d’entrée/sortie est indiquée par une entrée du journal du système qui est similaire à l’exemple suivant :

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

Causes potentielles

Type d’instance	Cause potentielle
Basée sur Amazon EBS	Un volume Amazon EBS en échec
Basée sur le stockage d’instance	Un lecteur physique en échec

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance. Dissociez le volume. Essayez de récupérer le volume. Note Il est recommandé de faire souvent des instantanés de vos volumes Amazon EBS. Cela diminue considérablement le risque de perte de données suite à un échec. Attachez de nouveau le volume à l’instance. Démarrez l’instance.
Basée sur le stockage d’instance	Mettez fin à l’instance et lancez une nouvelle instance. Note Les données ne peuvent pas être récupérées. Récupérez-les grâce aux sauvegardes. Note Il est recommandé d’utiliser soit Amazon S3, soit Amazon EBS pour les sauvegardes. Les volumes de stockage d’instance sont directement reliés aux échecs d’un hôte et d’un disque uniques.

I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)

Une erreur d’entrée/sortie sur le périphérique est indiquée par une entrée du journal du système qui est similaire à l’exemple suivant :

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

Causes potentielles

Type d’instance	Cause potentielle
Basée sur Amazon EBS	Un volume Amazon EBS en échec
Basée sur le stockage d’instance	Un lecteur physique en échec

Action suggérée

Mettez fin à l’instance et lancez une nouvelle instance.

Pour une instance basée sur Amazon EBS, vous pouvez récupérer des données à partir d’un instantané récent en créant une image à partir de celle-ci. Toutes les données ajoutées après l’instantané ne peuvent pas être récupérées.

request_module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous. L’utilisation d’un noyau Linux instable ou ancien (par exemple, 2.6.16-xenU) peut entraîner une condition de boucle interminable au démarrage.

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

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez un noyau plus récent, soit basé sur GRUB ou statique, avec l’une des options suivantes: Option 1 : Arrêtez l’instance et lancez une nouvelle instance en spécifiant les paramètres -kernel et -ramdisk. Option 2 : Arrêtez l’instance. Modifiez les attributs de noyau et de ramdisk pour utiliser un noyau plus récent. Démarrez l’instance.
Basée sur le stockage d’instance	Arrêtez l’instance et lancez une nouvelle instance en spécifiant les paramètres -kernel et -ramdisk.

« FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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!

Causes potentielles

Noyau et identifiant incompatibles

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance. Modifiez la configuration pour utiliser un noyau plus récent. Démarrez l’instance.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Créez une AMI qui utilise un noyau plus récent. Mettez fin à l’instance. Démarrez une nouvelle instance à partir de l’AMI que vous avez créée.

« FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

[    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)

Causes potentielles

Une ou plusieurs conditions suivantes peuvent entraîner ce problème :

• Ramdisk manquant

• Modules corrects manquants pour le ramdisk

• Le volume racine Amazon EBS n’est pas attaché correctement en tant que /dev/sda1

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Sélectionnez ramdisk corrigé pour le volume Amazon EBS. Arrêtez l’instance. Détachez le volume et réparez-le. Attachez le volume à l’instance. Démarrez l’instance. Modifiez l’AMI pour utiliser le ramdisk corrigé.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Arrêtez l’instance et lancez une nouvelle instance avec le bon ramdisk. Créez une nouvelle AMI avec le bon ramdisk.

ERROR Invalid kernel (noyau incompatible EC2)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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

Causes potentielles

Une ou deux des conditions suivantes peuvent entraîner ce problème :

• Le noyau fourni n’est pas pris en charge par GRUB

• Le noyau de rechange n’existe pas

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance. Remplacez-le avec un noyau qui fonctionne. Installez un noyau de rechange. Modifiez l’AMI en corrigeant le noyau.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Arrêtez l’instance et lancez une nouvelle instance avec le bon noyau. Créez une AMI avec le noyau correct. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant AWS Support.

fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

		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):

Causes potentielles

• Un bogue existe dans les définitions du système de fichiers ramdisk /etc/fstab

• Définitions du système de fichiers mal configurées dans /etc/fstab

• Lecteur manquant/en échec

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance, détachez le volume racine, réparez/modifiez le volume dans le fichier /etc/fstab, attachez le volume à l’instance et lancez l’instance. Corrigez le ramdisk pour inclure le fichier /etc/fstab modifié (le cas échéant). Modifiez l’AMI pour utiliser un ramdisk plus récent. Le sixième champ de fstab définit les exigences de disponibilité du montage. Une valeur non nulle implique qu’un fsck sera effectué sur ce volume et doit réussir. L’utilisation de ce champ peut être problématique dans Amazon EC2, car un échec entraîne généralement une invite de la console interactive qui n’est actuellement pas disponible dans Amazon EC2. Faites attention avec cette fonction et lisez la page sur la commande man Linux en ce qui concerne fstab.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Mettez fin à l’instance et lancez une nouvelle instance. Détachez tous les volumes Amazon EBS errants et l’instance redémarré. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant AWS Support.

General error mounting filesystems (Montage en échec)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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):

Causes potentielles

Type d’instance	Cause potentielle
Basée sur Amazon EBS	Volume Amazon EBS détaché ou en échec. Système de fichiers corrompu. Décalage de la combinaison de ramdisk et d’AMI (par exemple, ramdisk Debian avec une AMI SUSE).
Basée sur le stockage d’instance	Un lecteur en échec. Un système de fichiers corrompu. Un décalage de la combinaison de ramdisk et d’AMI (par ex., ramdisk Debian avec une AMI SUSE).

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance. Détachez le volume racine. Attachez le volume racine à une instance connue en fonctionnement. Exécutez le contrôle du système de fichiers (fsck –a /dev/...). Corrigez toutes les erreurs. Détachez le volume de l’instance connue en fonctionnement. Attachez le volume à l’instance arrêtée. Démarrez l’instance. Revérifiez le statut de l’instance.
Basée sur le stockage d’instance	Essayez l’une des actions suivantes : Démarrez une nouvelle instance. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant AWS Support.

VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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)

Causes potentielles

Type d’instance	Cause potentielle
Basée sur Amazon EBS	Le périphérique n’est pas attaché correctement. Le périphérique racine n’est pas attaché au bon point périphérique. Le système de fichiers n’est pas au format attendu. Utilisez le noyau hérité (par exemple, 2.6.16-XenU). Mise à jour récente du noyau sur votre instance (mise à jour défaillante ou bogue de mise à jour)
Basée sur le stockage d’instance	Échec du périphérique matériel.

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Effectuez l’une des actions suivantes : Arrêtez puis redémarrez l’instance. Modifiez le volume racine pour l’attacher au bon point périphérique, comme /dev/sda1 au lieu de /dev/sda. Arrêtez et modifiez pour le noyau moderne. Pour plus d’informations sur les bogues de mise à jour connus, consultez la documentation de votre distribution Linux. Modifiez ou réinstallez le noyau.
Basée sur le stockage d’instance	Arrêtez l’instance et lancez une nouvelle instance en utilisant un noyau moderne.

Erreur : Unable to determine major/minor number of root device... (décalage du système de fichiers/périphérique racine)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

...
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 /]#

Causes potentielles

• Pilote du périphérique de stockage en mode bloc virtuel manquant ou configuré de façon incorrecte

• Conflit de l’énumération du périphérique (sda versus xvda ou sda au lieu de sda1)

• Choix incorrect du noyau de l’instance

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance. Dissociez le volume. Corrigez le problème du mappage du périphérique. Démarrez l’instance. Modifiez l’AMI pour traiter les problèmes du mappage du périphérique.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Créez une nouvelle AMI avec la solution appropriée (mapper le périphérique de stockage en mode bloc correctement). Arrêtez l’instance et lancez une nouvelle instance à partir de l’AMI que vous avez créée.

XENBUS : Device with no driver...

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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 /]#

Causes potentielles

• Pilote du périphérique de stockage en mode bloc virtuel manquant ou configuré de façon incorrecte

• Conflit de l’énumération du périphérique (sda versus xvda)

• Choix incorrect du noyau de l’instance

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance. Dissociez le volume. Corrigez le problème du mappage du périphérique. Démarrez l’instance. Modifiez l’AMI pour traiter les problèmes du mappage du périphérique.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Créez une AMI avec la solution appropriée (mapper le périphérique de stockage en mode bloc correctement). Arrêtez l’instance et lancez une nouvelle instance en utilisant l’AMI que vous avez créée.

... days without being checked, check forced (Contrôle du système de fichiers nécessaire)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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

Causes potentielles

La durée de contrôle du système de fichiers est dépassée ; un contrôle du système de fichiers est en train d’être forcé.

Actions suggérées

• Patientez jusqu’à ce que le contrôle du système de fichiers se termine. Un contrôle de système de fichiers peut prendre longtemps en fonction de la taille du système de fichiers racine.

• Modifiez vos systèmes de fichiers pour supprimer l’application du contrôle du système de fichiers (fsck) en utilisant tune2fs ou des outils appropriés pour votre système de fichiers.

fsck a échoué à l’état de sortie... (périphérique manquant)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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

Causes potentielles

• Ramdisk à la recherche d’un lecteur manquant

• Contrôle de cohérence forcé du système de fichiers

• Lecteur en échec ou détaché

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Essayez une ou plusieurs des solutions suivants pour résoudre le problème : Arrêtez l’instance, attachez le volume à une instance existante en cours d’exécution. Exécutez manuellement des contrôles de cohérence. Corrigez le ramdisk pour inclure les utilitaires pertinents. Modifiez les paramètres de réglage du système de fichiers pour supprimer les exigences de cohérence (non recommandé).
Basée sur le stockage d’instance	Essayez une ou plusieurs des solutions suivants pour résoudre le problème : Regrouper le ramdisk avec les bons outils. Modifiez les paramètres de réglage du système de fichiers pour supprimer les exigences de cohérence (non recommandé). Mettez fin à l’instance et lancez une nouvelle instance. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant AWS Support.

Invite GRUB (grubdom>)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

    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> 

Causes potentielles

Type d’instance	Causes potentielles
Basée sur Amazon EBS	Fichier de configuration GRUB manquant. Mauvaise image GRUB utilisée ; fichier de configuration GRUB attendu à un emplacement différent. Système de fichiers non pris en charge utilisé pour stoker votre fichier de configuration GRUB (par exemple, en transformant votre système de fichiers racine en un type qui n’est pas pris en charge par une version plus récente de GRUB).
Basée sur le stockage d’instance	Fichier de configuration GRUB manquant. Mauvaise image GRUB utilisée ; fichier de configuration GRUB attendu à un emplacement différent. Système de fichiers non pris en charge utilisé pour stoker votre fichier de configuration GRUB (par exemple, en transformant votre système de fichiers racine en un type qui n’est pas pris en charge par une version plus récente de GRUB).

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Option 1 : Modifiez l’AMI et relancez l’instance : Modifiez l’AMI source pour créer un fichier de configuration GRUB à l’emplacement standard (/boot/grub/menu.lst). Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et mettez à niveau GRUB si nécessaire. Choisissez l’image GRUB appropriée, (hd0 - 1er lecteur ou hd00 – 1er lecteur, première partition). Arrêtez l’instance et lancez-en une nouvelle en utilisant l’AMI que vous avez créée. Option 2 : Corrigez l’instance existante: Arrêtez l’instance. Détachez le système de fichiers racine. Attachez le système de fichiers racine à une instance connue en fonctionnement. Montez le système de fichiers. Créez un fichier de configuration GRUB. Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et mettez à niveau GRUB si nécessaire. Détachez le système de fichiers. Attachez-le à l’instance originale. Modifiez l’attribut noyau pour utiliser l’image GRUB appropriée (1er disque ou 1ère partition sur 1er disque). Démarrez l’instance.
Basée sur le stockage d’instance	Option 1 : Modifiez l’AMI et relancez l’instance : Créez la nouvelle AMI avec un fichier de configuration GRUB à l’emplacement standard (/boot/grub/menu.lst). Choisissez l’image GRUB appropriée, (hd0 - 1er lecteur ou hd00 – 1er lecteur, première partition). Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et mettez à niveau GRUB si nécessaire. Arrêtez l’instance et lancez une nouvelle instance en utilisant l’AMI que vous avez créée. Option 2 : Arrêtez l’instance et lancez une nouvelle instance en spécifiant le noyau correct. Note Pour récupérer les données de l’instance existante, contactez AWS Support.

Mise en service de l’interface eth0 : l’adresse MAC du périphérique eth0 est différente de celle attendue, ignorer. (Adresse MAC codée de manière irréversible)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

... 
Bringing up loopback interface:  [  OK  ]

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

Starting auditd: [  OK  ]

Causes potentielles

Il s’agit d’une interface MAC codée en dur dans la configuration d’AMI

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Effectuez l’une des actions suivantes : Modifiez l’AMI pour supprimer le codage en dur et relancez l’instance. Modifiez l’instance pour supprimer l’adresse MAC codée en dur. OU Utilisez la procédure suivante. Arrêtez l’instance. Détachez le volume racine. Attachez le volume à une autre instance et modifiez le volume pour supprimer l’adresse MAC codée en dur. Attachez le volume à l’instance originale. Démarrez l’instance.
Basée sur le stockage d’instance	Effectuez l’une des actions suivantes : Modifiez l’instance pour supprimer l’adresse MAC codée en dur. Mettez fin à l’instance et lancez une nouvelle instance.

Impossible de charger la politique SELinux. L’appareil est en mode d’exécution. Arrêt maintenant. (Erreur de configuration SELinux)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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!

Causes potentielles

SELinux a été activé par erreur :

• Le noyau fourni n’est pas pris en charge par GRUB

• Le noyau de rechange n’existe pas

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Utilisez la procédure suivante. Arrêtez l’instance en échec. Détachez le volume racine de l’instance en échec. Attachez le volume racine à une autre instance Linux en fonctionnement (appelée plus tard instance de récupération). Connectez-vous à l’instance de récupération et montez le volume racine de l’instance en échec. Désactivez SELinux sur le volume racine monté. Ce processus varie selon les distributions Linux. Pour plus d’informations, consultez la documentation spécifique à votre système d’exploitation. Note Sur certaines systèmes, vous désactivez SELinux en réglant SELINUX=disabled dans le fichier /mount_point/etc/sysconfig/selinux où mount_point est l’emplacement où vous avez monté le volume sur votre instance de récupération. Démontez et détachez le volume racine à partir de l’instance de récupération et attachez-le de nouveau à l’instance originale. Démarrez l’instance.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Mettez fin à l’instance et lancez une nouvelle instance. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant AWS Support.

XENBUS: Timeout connecting to devices (délai d’attente Xenbus)

Cette condition est indiquée par une entrée du journal du système qui est similaire à celle indiquée ci-dessous.

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.

Causes potentielles

• Le périphérique de stockage en mode bloc n’est pas connecté à l’instance

• Cette instance utilise un ancien noyau de l’instance

Actions suggérées

Pour ce type d’instance	Faire ceci
Basée sur Amazon EBS	Effectuez l’une des actions suivantes : Modifiez l’AMI et l’instance pour utiliser un noyau moderne et relancez l’instance. Redémarrez l’instance.
Basée sur le stockage d’instance	Effectuez l’une des actions suivantes : Mettez fin à l’instance. Modifiez l’AMI pour utiliser un noyau moderne et lancez une nouvelle instance en utilisant cette AMI.