

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Résolution des problèmes liés aux instances Linux d'Amazon EC2 dont les vérifications du statut ont échoué
<a name="TroubleshootingInstances"></a>

Les informations suivantes peuvent vous aider à résoudre les problèmes si votre instance Linux é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 du statut des instances Amazon EC2](monitoring-system-instance-status-check.md).

**Topics**
+ [Examen des informations de contrôle de statut](#InitialSteps)
+ [Récupération des journaux système](#troubleshooting-retrieve-system-logs)
+ [Résolution des problèmes du journal du système pour les instances Linux](#system-log-errors-linux)
+ [Mémoire insuffisante : processus d’arrêt](#MemoryOOM)
+ [ERROR: mmu\$1update failed (la mise à jour de la gestion de la mémoire a échoué)](#MemoryMMU)
+ [Erreur d’E/S (échec du périphérique de stockage en mode bloc)](#DeviceBlock)
+ [I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)](#DeviceDistributed)
+ [request\$1module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)](#KernelLoop)
+ [« FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)](#KernelOld)
+ [« FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)](#KernelMissing)
+ [ERROR Invalid kernel (noyau incompatible EC2)](#KernelInvalid)
+ [fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)](#FilesystemFschk)
+ [General error mounting filesystems (Montage en échec)](#FilesystemGeneral)
+ [VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)](#FilesystemKernel)
+ [Erreur : Impossible de déterminer major/minor le nombre de périphériques racines... (Le fichier racine ne system/device correspond pas)](#FilesystemError)
+ [XENBUS : Device with no driver...](#FilesystemXenbus)
+ [... days without being checked, check forced (Contrôle du système de fichiers nécessaire)](#FilesystemCheck)
+ [fsck a échoué à l’état de sortie... (périphérique manquant)](#FilesystemFschkDied)
+ [Invite GRUB (grubdom>)](#OpSystemGrub)
+ [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)](#OpSystemBringing)
+ [Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Je m'arrête maintenant. (SELinux mauvaise configuration)](#OpSystemUnable)
+ [XENBUS: Timeout connecting to devices (délai d’attente Xenbus)](#OpSystemXenbus)

## Examen des informations de contrôle de statut
<a name="InitialSteps"></a>

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

1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

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

1. Sélectionnez l'onglet **État et alarmes** pour voir les résultats individuels de tous les contrôles d'**état du système, des contrôles**, **statut des instances et des contrôles**, et **statut EBS attachés**.

Si un contrôle de statut a échoué, vous pouvez essayer l’une des options suivantes :
+ Créez une alarme pour récupérer l'instance en réponse à l'échec de la vérification de statut. Pour de plus amples informations, veuillez consulter [Créer des alarmes qui arrêtent, finissent, redémarrent ou récupèrent une instance](UsingAlarmActions.md).
+ (Vérifications de l'état de l'instance) Si vous avez changé le type d'instance pour une [instance basée sur Nitro](instance-types.md#instance-hypervisor-type), les vérifications de statut échouent si vous avez migré depuis une instance qui ne possède pas l'ENA et NVMe les pilotes requis. Pour de plus amples informations, veuillez consulter [Compatibilité pour modifier le type d’instance](resize-limitations.md).
+ Pour une instance avec un volume racine EBS, arrêtez et redémarrez l’instance. Pour de plus amples informations, veuillez consulter [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md).
+ Pour une instance avec un volume racine de stockage d’instances, résiliez l’instance et lancez une instance de remplacement. Pour de plus amples informations, veuillez consulter [Terminez l'instance Amazon EC2](terminating-instances.md).
+ Attendez qu’Amazon EC2 résolve le problème.
+ Contactez Support ou publiez votre problème sur [AWS Re:post](https://repost.aws/).
+ Si votre instance est dans un groupe Auto Scaling :
  + (Contrôles de statut de système et de statut d'instance) Par défaut, Amazon EC2 Auto Scaling lance automatiquement une instance de remplacement. Pour plus d’informations, consultez [Surveillance de l’état pour les instances dans le groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) dans le *Guide de l’utilisateur Amazon EC2 Auto Scaling*.
  + (Vérifications de statut EBS jointes) Vous devez configurer Amazon EC2 Auto Scaling pour lancer automatiquement une instance de remplacement. Pour de plus amples informations, consulter [ Surveiller et remplacer des instances Auto Scaling par des volumes Amazon EBS altérés](https://docs.aws.amazon.com/autoscaling/ec2/userguide/monitor-and-replace-instances-with-impaired-ebs-volumes.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*.
+ Récupérez le journal du système et recherchez les erreurs. Pour de plus amples informations, veuillez consulter [Récupération des journaux système](#troubleshooting-retrieve-system-logs).

## Récupération des journaux système
<a name="troubleshooting-retrieve-system-logs"></a>

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 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

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

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

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

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

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

1. Si votre problème n’est pas résolu, vous pouvez le publier sur [AWS re:Post](https://repost.aws/).

## Résolution des problèmes du journal du système pour les instances Linux
<a name="system-log-errors-linux"></a>

Pour les instances 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](#MemoryOOM)
+ [ERROR: mmu\$1update failed (la mise à jour de la gestion de la mémoire a échoué)](#MemoryMMU)

**Device Errors**
+ [Erreur d’E/S (échec du périphérique de stockage en mode bloc)](#DeviceBlock)
+ [I/O ERROR: neither local nor remote disk (le périphérique de stockage en mode bloc distribué ne fonctionne plus)](#DeviceDistributed)

**Kernel Errors**
+ [request\$1module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)](#KernelLoop)
+ [« FATAL: kernel too old » et « fsck: No such file or directory while trying to open /dev » (décalage entre le noyau et l’AMI)](#KernelOld)
+ [« FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)](#KernelMissing)
+ [ERROR Invalid kernel (noyau incompatible EC2)](#KernelInvalid)

**File System Errors**
+ [fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)](#FilesystemFschk)
+ [General error mounting filesystems (Montage en échec)](#FilesystemGeneral)
+ [VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)](#FilesystemKernel)
+ [Erreur : Impossible de déterminer major/minor le nombre de périphériques racines... (Le fichier racine ne system/device correspond pas)](#FilesystemError)
+ [XENBUS : Device with no driver...](#FilesystemXenbus)
+ [... days without being checked, check forced (Contrôle du système de fichiers nécessaire)](#FilesystemCheck)
+ [fsck a échoué à l’état de sortie... (périphérique manquant)](#FilesystemFschkDied)

**Operating System Errors**
+ [Invite GRUB (grubdom>)](#OpSystemGrub)
+ [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)](#OpSystemBringing)
+ [Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Je m'arrête maintenant. (SELinux mauvaise configuration)](#OpSystemUnable)
+ [XENBUS: Timeout connecting to devices (délai d’attente Xenbus)](#OpSystemXenbus)

## Mémoire insuffisante : processus d’arrêt
<a name="MemoryOOM"></a>

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
<a name="MemoryOOM-potential-cause"></a>

Mémoire épuisée

### Actions suggérées
<a name="MemoryOOM-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## ERROR: mmu\$1update failed (la mise à jour de la gestion de la mémoire a échoué)
<a name="MemoryMMU"></a>

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
<a name="MemoryMMU-potential-cause"></a>

Problème avec Amazon Linux

### Action suggérée
<a name="MemoryMMU-suggested-actions"></a>

Publiez votre problème sur [AWS re :Post](https://repost.aws/) ou contactez [Support](https://aws.amazon.com/premiumsupport/).

## Erreur d’E/S (échec du périphérique de stockage en mode bloc)
<a name="DeviceBlock"></a>

Une input/output erreur est indiquée par une entrée du journal système 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
<a name="DeviceBlock-potential-cause"></a>


| 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
<a name="DeviceBlock-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |   Mettez fin à l’instance et lancez une nouvelle instance.  Les données ne peuvent pas être récupérées. Récupérez-les grâce aux sauvegardes.   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)
<a name="DeviceDistributed"></a>

Une input/output erreur sur le périphérique est indiquée par une entrée du journal système 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
<a name="DeviceDistributed-potential-cause"></a>


| 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
<a name="DeviceDistributed-suggested-actions"></a>

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\$1module: runaway loop modprobe (modprobe en boucle sur le noyau hérité sur des versions Linux plus anciennes)
<a name="KernelLoop"></a>

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

### Actions suggérées
<a name="KernelLoop-suggested-actions"></a>


| 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 : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  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)
<a name="KernelOld"></a>

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 (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!
```

### Causes potentielles
<a name="KernelOld-potential-cause"></a>

Noyau et identifiant incompatibles

### Actions suggérées
<a name="KernelOld-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## « FATAL : Impossible de charger /lib/modules » ou « BusyBox » (modules de noyau manquants)
<a name="KernelMissing"></a>

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
<a name="KernelMissing-potential-cause"></a>

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
<a name="KernelMissing-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## ERROR Invalid kernel (noyau incompatible EC2)
<a name="KernelInvalid"></a>

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
<a name="KernelInvalid-potential-cause"></a>

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
<a name="KernelInvalid-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## fsck : aucun fichier ou répertoire de ce type lors de la tentative d’ouverture... (système de fichiers non trouvé)
<a name="FilesystemFschk"></a>

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
<a name="FilesystemFschk-potential-cause"></a>
+ 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
<a name="FilesystemFschk-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## General error mounting filesystems (Montage en échec)
<a name="FilesystemGeneral"></a>

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
<a name="FilesystemGeneral-potential-cause"></a>


| Type d’instance  | Cause potentielle | 
| --- | --- | 
|  Basée sur Amazon EBS  |   [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |   [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

### Actions suggérées
<a name="FilesystemGeneral-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Essayez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## VFS: Unable to mount root fs on unknown-block (le système de fichiers racine ne correspond pas)
<a name="FilesystemKernel"></a>

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 (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)
```

### Causes potentielles
<a name="FilesystemKernel-potential-cause"></a>


| Type d’instance  | Cause potentielle | 
| --- | --- | 
|  Basée sur Amazon EBS  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Échec du périphérique matériel.  | 

### Actions suggérées
<a name="FilesystemKernel-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Arrêtez l’instance et lancez une nouvelle instance en utilisant un noyau moderne.   | 

## Erreur : Impossible de déterminer major/minor le nombre de périphériques racines... (Le fichier racine ne system/device correspond pas)
<a name="FilesystemError"></a>

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
<a name="FilesystemError-potential-cause"></a>
+ 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
<a name="FilesystemError-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## XENBUS : Device with no driver...
<a name="FilesystemXenbus"></a>

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
<a name="FilesystemXenbus-potential-cause"></a>
+ 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
<a name="FilesystemXenbus-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## ... days without being checked, check forced (Contrôle du système de fichiers nécessaire)
<a name="FilesystemCheck"></a>

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
<a name="FilesystemCheck-potential-cause"></a>

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
<a name="FilesystemCheck-suggested-actions"></a>
+ 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)
<a name="FilesystemFschkDied"></a>

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
<a name="FilesystemFschkDied-potential-cause"></a>
+ 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
<a name="FilesystemFschkDied-suggested-actions"></a>


| 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 : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Essayez une ou plusieurs des solutions suivants pour résoudre le problème : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## Invite GRUB (grubdom>)
<a name="OpSystemGrub"></a>

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
<a name="OpSystem-potential-cause"></a>


| Type d’instance  | Causes potentielles | 
| --- | --- | 
|  Basée sur Amazon EBS  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

### Actions suggérées
<a name="OpSystem-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Option 1 : Modifiez l’AMI et relancez l’instance : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) Option 2 : Corrigez l’instance existante: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Option 1 : Modifiez l’AMI et relancez l’instance : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) Option 2 : Arrêtez l’instance et lancez une nouvelle instance en spécifiant le noyau correct.  Pour récupérer les données de l’instance existante, contactez [Support](https://aws.amazon.com/premiumsupport/).   | 

## 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)
<a name="OpSystemBringing"></a>

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
<a name="OpSystemBringing-potential-cause"></a>

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

### Actions suggérées
<a name="OpSystemBringing-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html) OU Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Je m'arrête maintenant. (SELinux mauvaise configuration)
<a name="OpSystemUnable"></a>

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
<a name="OpSystemUnable-potential-cause"></a>

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
<a name="OpSystemUnable-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Utilisez la procédure suivante. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 

## XENBUS: Timeout connecting to devices (délai d’attente Xenbus)
<a name="OpSystemXenbus"></a>

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

### Causes potentielles
<a name="OpSystemXenbus-potential-cause"></a>
+ 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
<a name="OpSystemXenbus-suggested-actions"></a>


| Pour ce type d’instance  | Faire ceci | 
| --- | --- | 
|  Basée sur Amazon EBS  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 
|  Basée sur le stockage d’instance  |  Effectuez l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)  | 