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é 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\_update failed (la mise à jour de la gestion de la mémoire a échoué)](#MemoryMMU) + [I/O erreur (panne du périphérique de blocage)](#DeviceBlock) + [I/O ERREUR : ni disque local ni disque distant (périphérique de bloc distribué cassé)](#DeviceDistributed) + [request\_module: 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 du 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 racine... (Incompatibilité du fichier system/device racine)](#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 Hard-coded MAC)](#OpSystemBringing) + [Impossible de charger la politique SELinux. L’appareil est en mode d’exécution. Arrêt maintenant. (Erreur de configuration SELinux)](#OpSystemUnable) + [XENBUS: Timeout connecting to devices (délai d’attente Xenbus)](#OpSystemXenbus) ## 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 à 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 remplacé le type d'[Nitro-based instance par une instance](instance-types.md#instance-hypervisor-type), 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 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](https://repost.aws/) Re:post. + 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 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 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\_update failed (la mise à jour de la gestion de la mémoire a échoué)](#MemoryMMU) **Device Errors** + [I/O erreur (panne du périphérique de blocage)](#DeviceBlock) + [I/O ERREUR : ni disque local ni disque distant (périphérique de bloc distribué cassé)](#DeviceDistributed) **Kernel Errors** + [request\_module: 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 du 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 racine... (Incompatibilité du fichier system/device racine)](#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 Hard-coded MAC)](#OpSystemBringing) + [Impossible de charger la politique SELinux. L’appareil est en mode d’exécution. Arrêt maintenant. (Erreur de configuration SELinux)](#OpSystemUnable) + [XENBUS: Timeout connecting to devices (délai d’attente Xenbus)](#OpSystemXenbus) ## Mémoire insuffisante : processus d’arrêt Une erreur de mémoire insuffisante est indiquée par une entrée dans le journal système similaire à celle indiqué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 | Faites ceci | | --- | --- | | Amazon EBS-backed | 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 [AWS re :Post](https://repost.aws/) ou contactez [Support](https://aws.amazon.com/premiumsupport/). ## I/O erreur (panne du périphérique de blocage) Une input/output erreur est signalée par une entrée de 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 | Type d’instance | Cause potentielle | | --- | --- | | Amazon EBS-backed | 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance.
2. Dissociez le volume.
3. Essayez de récupérer le volume. 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.
4. Re-attach le volume de l'instance.
5. Démarrez l’instance. | | 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 ERREUR : ni disque local ni disque distant (périphérique de bloc distribué cassé) Une input/output erreur sur le périphérique est signalée par une entrée de 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 | Type d’instance | Cause potentielle | | --- | --- | | Amazon EBS-backed | 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 EBS-backed instance Amazon, vous pouvez récupérer les données d'un instantané récent en créant une image à partir de celui-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}} (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 | Pour ce type d’instance | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez un noyau plus récent, GRUB-based soit statique, en utilisant 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 :1. Arrêtez l’instance.
2. Modifiez les attributs de noyau et de ramdisk pour utiliser un noyau plus récent.
3. 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 (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 Noyau et identifiant incompatibles ### Actions suggérées | Pour ce type d’instance | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance.
2. Modifiez la configuration pour utiliser un noyau plus récent.
3. Démarrez l’instance. | | Basée sur le stockage d’instance | Utilisez la procédure suivante.1. Créez une AMI qui utilise un noyau plus récent.
2. Mettez fin à l’instance.
3. Démarrez une nouvelle instance à partir de l’AMI que vous avez créée. | ## « FATAL : Impossible de charger/lib/modules" ou BusyBox "» (modules du 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Sélectionnez ramdisk corrigé pour le volume Amazon EBS.
2. Arrêtez l’instance.
3. Détachez le volume et réparez-le.
4. Attachez le volume à l’instance.
5. Démarrez l’instance.
6. Modifiez l’AMI pour utiliser le ramdisk corrigé. | | Basée sur le stockage d’instance | Utilisez la procédure suivante.1. Arrêtez l’instance et lancez une nouvelle instance avec le bon ramdisk.
2. 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance.
2. Remplacez-le avec un noyau qui fonctionne.
3. Installez un noyau de rechange.
4. Modifiez l’AMI en corrigeant le noyau. | | Basée sur le stockage d’instance | Utilisez la procédure suivante.1. Arrêtez l’instance et lancez une nouvelle instance avec le bon noyau.
2. Créez une AMI avec le noyau correct.
3. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant [Support](https://aws.amazon.com/premiumsupport/). | ## 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 [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 + Il existe un bogue dans les définitions du système de fichiers ramdisk/etc/fstab + Définitions de système de fichiers mal configurées dans/etc/fstab + Missing/failed conduire ### Actions suggérées | Pour ce type d’instance | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l'instance, détachez le volume racine, repair/modify /etc/fstab le volume, attachez le volume à l'instance et démarrez l'instance.
2. Corrigez le disque dur pour inclure le/modifié etc/fstab (le cas échéant).
3. 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.1. Mettez fin à l’instance et lancez une nouvelle instance.
2. Détachez tous les volumes Amazon EBS errants et l’instance redémarré.
3. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant [Support](https://aws.amazon.com/premiumsupport/). | ## 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 | | --- | --- | | Amazon EBS-backed | + 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance.
2. Détachez le volume racine.
3. Attachez le volume racine à une instance connue en fonctionnement.
4. Exécutez le contrôle du système de fichiers (fsck –a /dev/...).
5. Corrigez toutes les erreurs.
6. Détachez le volume de l’instance connue en fonctionnement.
7. Attachez le volume à l’instance arrêtée.
8. Démarrez l’instance.
9. 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 [Support](https://aws.amazon.com/premiumsupport/). | ## 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 (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 | Type d’instance | Cause potentielle | | --- | --- | | Amazon EBS-backed | + 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Effectuez l’une des actions suivantes :+ Arrêtez puis redémarrez l’instance.
+ Modifiez le volume racine pour le connecter au bon endroit de l'appareil, possible/dev/sda1au 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 : Impossible de déterminer major/minor le nombre de périphériques racine... (Incompatibilité du fichier system/device 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance.
2. Dissociez le volume.
3. Corrigez le problème du mappage du périphérique.
4. Démarrez l’instance.
5. 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.1. Créez une nouvelle AMI avec la solution appropriée (mapper le périphérique de stockage en mode bloc correctement).
2. 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance.
2. Dissociez le volume.
3. Corrigez le problème du mappage du périphérique.
4. Démarrez l’instance.
5. 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.1. Créez une AMI avec la solution appropriée (mapper le périphérique de stockage en mode bloc correctement).
2. 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | 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 [Support](https://aws.amazon.com/premiumsupport/). | ## 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 | | --- | --- | | Amazon EBS-backed | + 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Option 1 : Modifiez l’AMI et relancez l’instance :1. Modifiez l'AMI source pour créer un fichier de configuration GRUB à l'emplacement standard (/boot/grub/menu.lst).
2. 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.
3. Choisissez l’image GRUB appropriée, (hd0 - 1er lecteur ou hd00 – 1er lecteur, première partition).
4. Arrêtez l’instance et lancez-en une nouvelle en utilisant l’AMI que vous avez créée.
Option 2 : Corrigez l’instance existante:1. Arrêtez l’instance.
2. Détachez le système de fichiers racine.
3. Attachez le système de fichiers racine à une instance connue en fonctionnement.
4. Montez le système de fichiers.
5. Créez un fichier de configuration GRUB.
6. 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.
7. Détachez le système de fichiers.
8. Attachez-le à l’instance originale.
9. Modifiez l’attribut noyau pour utiliser l’image GRUB appropriée (1er disque ou 1ère partition sur 1er disque).
10. Démarrez l’instance. | | Basée sur le stockage d’instance | Option 1 : Modifiez l’AMI et relancez l’instance :1. Créez la nouvelle AMI avec un fichier de configuration GRUB à l'emplacement standard (/boot/grub/menu.lst).
2. Choisissez l’image GRUB appropriée, (hd0 - 1er lecteur ou hd00 – 1er lecteur, première partition).
3. 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.
4. 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. 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 Hard-coded MAC) 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | 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.1. Arrêtez l’instance.
2. Détachez le volume racine.
3. Attachez le volume à une autre instance et modifiez le volume pour supprimer l’adresse MAC codée en dur.
4. Attachez le volume à l’instance originale.
5. 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | Utilisez la procédure suivante.1. Arrêtez l’instance en échec.
2. Détachez le volume racine de l’instance en échec.
3. Attachez le volume racine à une autre instance Linux en fonctionnement (appelée plus tard instance de récupération).
4. Connectez-vous à l’instance de récupération et montez le volume racine de l’instance en échec.
5. Désactivez SELinux sur le volume racine monté. Ce processus varie selon les distributions Linux ; pour plus d'informations, consultez votre OS-specific documentation. 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.
6. Démontez et détachez le volume racine à partir de l’instance de récupération et attachez-le de nouveau à l’instance originale.
7. Démarrez l’instance. | | Basée sur le stockage d’instance | Utilisez la procédure suivante.1. Mettez fin à l’instance et lancez une nouvelle instance.
2. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant [Support](https://aws.amazon.com/premiumsupport/). | ## 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 (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 + 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 | Faites ceci | | --- | --- | | Amazon EBS-backed | 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. |