Examen des informations de contrôle de statut Récupération des journaux système Résoudre les erreurs du journal système pour les instances Linux Mémoire insuffisante : processus d’arrêt ERROR: échec de mmu_update (échec de la mise à jour de la gestion de la mémoire)Erreur d’E/S (échec du périphérique de stockage en mode bloc)E/S ERROR : ni disque local ni disque distant (périphérique à blocs distribués cassé)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 : aucun fichier ou répertoire de ce type lors de la tentative d'ouverture de /dev » (Kernel et incompatibilité) AMI « FATAL : Impossible de charger /lib/modules" ou "BusyBox" (modules de noyau manquants)ERRORNoyau non valide (noyau EC2 incompatible)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: Impossible de monter le fichier root fs sur un bloc inconnu (incompatibilité du système de fichiers racine)Erreur : Unable to determine major/minor number of root device... (décalage du système de fichiers/périphérique racine)XENBUS: Appareil sans pilote...... 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)GRUBprompt (grubdom>)Affichage de l'interface eth0 : le périphérique eth0 a une MAC adresse différente de celle attendue, ignorée. (MACAdresse codée en dur) Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Arrêt maintenant. (SELinuxmauvaise configuration)XENBUS: délai de connexion aux appareils (délai d'expiration Xenbus)

Résoudre les problèmes des instances Amazon EC2 Linux dont les vérifications d'état ont échoué

Les informations suivantes peuvent vous aider à résoudre les problèmes si la vérification de statut de votre instance Linux échoue. 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 les EC2 instances Amazon.

Sommaire

Examen des informations de contrôle de statut
Récupération des journaux système
Résoudre les erreurs du journal système pour les instances Linux
Mémoire insuffisante : processus d’arrêt
ERROR: échec de mmu_update (échec de la mise à jour de la gestion de la mémoire)
Erreur d’E/S (échec du périphérique de stockage en mode bloc)
E/S ERROR : ni disque local ni disque distant (périphérique à blocs distribués cassé)
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 : aucun fichier ou répertoire de ce type lors de la tentative d'ouverture de /dev » (Kernel et incompatibilité) AMI
« FATAL : Impossible de charger /lib/modules" ou "BusyBox" (modules de noyau manquants)
ERRORNoyau non valide (noyau EC2 incompatible)
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: Impossible de monter le fichier root fs sur un bloc inconnu (incompatibilité du système de fichiers racine)
Erreur : Unable to determine major/minor number of root device... (décalage du système de fichiers/périphérique racine)
XENBUS: Appareil sans pilote...
... 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)
GRUBprompt (grubdom>)
Affichage de l'interface eth0 : le périphérique eth0 a une MAC adresse différente de celle attendue, ignorée. (MACAdresse codée en dur)
Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Arrêt maintenant. (SELinuxmauvaise configuration)
XENBUS: délai de connexion aux appareils (délai d'expiration Xenbus)

Examen des informations de contrôle de statut

Pour étudier les instances défectueuses à l'aide de la EC2 console Amazon

Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/.
Dans le panneau de navigation, choisissez instances, puis sélectionnez votre instance.
Sélectionnez l'onglet État et alarmes pour voir les résultats individuels de toutes les vérifications d'état du système, des vérifications de l'état des instances et des vérifications de EBSstatut des pièces jointes.

Si la vérification du 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.
(Vérifications de l'état de l'instance) Si vous avez changé le type d'instance pour une instance basée sur le système AWS Nitro, les vérifications de statut échouent si vous avez migré depuis une instance qui ne possède pas les pilotes ENA et NVMe pilotes requis. Pour de plus amples informations, veuillez consulter Compatibilité pour modifier le type d’instance.
Pour une instance EBS sauvegardée, arrêtez et redémarrez l'instance. Pour de plus amples informations, veuillez consulter Arrêtez et démarrez les EC2 instances Amazon.
Pour une instance basée sur un magasin d'instances, mettez fin à l'instance et lancez une instance de remplacement. Pour de plus amples informations, veuillez consulter Mettre fin aux EC2 instances Amazon.
Attendez qu'Amazon EC2 résolve le problème.
Contactez AWS Support ou publiez votre problème sur AWS Re:post.
Si votre instance fait partie d'un groupe Auto Scaling :
- (Vérifications de l'état du système et vérifications de l'état des instances) Par défaut, Amazon EC2 Auto Scaling lance automatiquement une instance de remplacement. Pour plus d'informations, consultez Health Checks for Auto Scaling Instances dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.
- (Vérifications de EBS statut jointes) Vous devez configurer Amazon EC2 Auto Scaling pour lancer automatiquement une instance de remplacement. Pour plus d'informations, consultez la section Surveiller et remplacer les instances Auto Scaling par des EBS volumes Amazon altérés dans le manuel Amazon EC2 Auto Scaling User Guide.
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.

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

Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/.
Dans le panneau de navigation, sélectionnez instances, puis choisissez votre instance.
Sélectionnez État de l’instance, puis Redémarrer l’instance. Le redémarrage de votre instance peut prendre quelques minutes.
Vérifiez si le problème existe encore. Dans certains cas, le redémarrage peut résoudre le problème.
Lorsque l’état de l’instance est running, sélectionnez Actions, Surveiller et dépanner, Obtenir le journal système.
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.
Si votre problème n’est pas résolu, vous pouvez le publier sur AWS re:Post.

Résoudre les erreurs du journal système pour les instances Linux

Pour les instances Linux qui ont échoué à une vérification de l'état de l'instance, telle que la vérification de l'accessibilité de l'instance, vérifiez que vous avez suivi les étapes ci-dessus pour récupérer le journal 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: échec de mmu_update (échec de la mise à jour de la gestion de la mémoire)

Device Errors

Erreur d’E/S (échec du périphérique de stockage en mode bloc)
E/S ERROR : ni disque local ni disque distant (périphérique à blocs distribués cassé)

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 : aucun fichier ou répertoire de ce type lors de la tentative d'ouverture de /dev » (Kernel et incompatibilité) AMI
« FATAL : Impossible de charger /lib/modules" ou "BusyBox" (modules de noyau manquants)
ERRORNoyau non valide (noyau EC2 incompatible)

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: Impossible de monter le fichier root fs sur un bloc inconnu (incompatibilité du système de fichiers racine)
Erreur : Unable to determine major/minor number of root device... (décalage du système de fichiers/périphérique racine)
XENBUS: Appareil sans pilote...
... 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

GRUBprompt (grubdom>)
Affichage de l'interface eth0 : le périphérique eth0 a une MAC adresse différente de celle attendue, ignorée. (MACAdresse codée en dur)
Impossible de charger la SELinux politique. L’appareil est en mode d’exécution. Arrêt maintenant. (SELinuxmauvaise configuration)
XENBUS: délai de connexion aux appareils (délai d'expiration 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	Faites ceci
Soutenu EBS par Amazon	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.

Pour ce type d’instance

Faites ceci

Soutenu EBS par Amazon

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: échec de mmu_update (échec de la mise à jour de la gestion de la mémoire)

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
Soutenu EBS par Amazon	Un EBS volume Amazon défaillant
Basée sur le stockage d’instance	Un lecteur physique en échec

Actions suggérées

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	Utilisez la procédure suivante. Arrêtez l’instance. Dissociez le volume. Essayez de récupérer le volume. Note Il est recommandé de prendre régulièrement des photos de vos EBS volumes Amazon. 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 Amazon S3 ou 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.

E/S ERROR : ni disque local ni disque distant (périphérique à blocs distribués cassé)

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
Soutenu EBS par Amazon	Un EBS volume Amazon défaillant
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 AmazonEBS, 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

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	Utilisez un noyau plus récent, GRUB basé ou 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 : 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`.

Soutenu EBS par Amazon

Utilisez un noyau plus récent, GRUB basé ou 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 :

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 : aucun fichier ou répertoire de ce type lors de la tentative d'ouverture de /dev » (Kernel et incompatibilité) 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
Soutenu EBS par Amazon	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 un code AMI qui utilise un noyau plus récent. Mettez fin à l’instance. Démarrez une nouvelle instance à partir de celle 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 EBS racine Amazon n'est pas correctement attaché en tant que /dev/sda1

Actions suggérées

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	Utilisez la procédure suivante. Sélectionnez le ramdisk corrigé pour le EBS volume Amazon. Arrêtez l’instance. Détachez le volume et réparez-le. Attachez le volume à l’instance. Démarrez l’instance. Modifiez le 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-en un nouveau AMI avec le bon ramdisk.

ERRORNoyau non valide (noyau EC2 incompatible)

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
Soutenu EBS par Amazon	Utilisez la procédure suivante. Arrêtez l’instance. Remplacez-le avec un noyau qui fonctionne. Installez un noyau de rechange. Modifiez le 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 un AMI avec le bon noyau. (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	Faites ceci
Soutenu EBS par Amazon	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 le AMI pour utiliser un disque RAM 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 s'avérer problématique sur Amazon, EC2 car une défaillance entraîne généralement l'affichage d'une invite de console interactive qui n'est actuellement pas disponible sur AmazonEC2. 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 EBS volumes Amazon erronés et l'instance de redémarrage. (Facultatif) Demandez une assistance technique pour la récupération des données en utilisant AWS Support.

Pour ce type d’instance

Faites ceci

Soutenu EBS par Amazon

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 le AMI pour utiliser un disque RAM 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 s'avérer problématique sur Amazon, EC2 car une défaillance entraîne généralement l'affichage d'une invite de console interactive qui n'est actuellement pas disponible sur AmazonEC2. 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 EBS volumes Amazon erronés et l'instance de redémarrage.
(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
Soutenu EBS par Amazon	EBSVolume Amazon détaché ou défaillant. Système de fichiers corrompu. Ramdisk et AMI combinaison incompatibles (comme Debian ramdisk avec a). SUSE AMI
Basée sur le stockage d’instance	Un lecteur en échec. Un système de fichiers corrompu. Un disque RAM et une combinaison incompatibles (par exemple, un disque RAM Debian avec un). SUSE AMI

Actions suggérées

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	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.

Pour ce type d’instance

Faites ceci

Soutenu EBS par Amazon

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: Impossible de monter le fichier root fs sur un bloc inconnu (incompatibilité du système de fichiers racine)

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
Soutenu EBS par Amazon	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
Soutenu EBS par Amazon	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	Faites ceci
Soutenu EBS par Amazon	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 le AMI pour résoudre les problèmes de mappage des appareils.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Créez-en un nouveau AMI avec le correctif approprié (cartographiez correctement le périphérique). Mettez fin à l'instance et lancez une nouvelle instance à partir de celle AMI que vous avez créée.

XENBUS: Appareil sans pilote...

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
Soutenu EBS par Amazon	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 le AMI pour résoudre les problèmes de mappage des appareils.
Basée sur le stockage d’instance	Utilisez la procédure suivante. Créez un AMI avec le correctif approprié (cartographiez correctement le périphérique). Mettez fin à l'instance et lancez-en une nouvelle à l'aide de celle 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
Soutenu EBS par Amazon	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.

Pour ce type d’instance

Faites ceci

Soutenu EBS par Amazon

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.

GRUBprompt (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
Soutenu EBS par Amazon	Fichier GRUB de configuration manquant. GRUBImage utilisée incorrecte, le fichier GRUB de configuration attendu se trouve à un autre emplacement. Système de fichiers non pris en charge utilisé pour stocker votre fichier de GRUB configuration (par exemple, pour convertir votre système de fichiers racine en un type non pris en charge par une version antérieure deGRUB).
Basée sur le stockage d’instance	Fichier GRUB de configuration manquant. GRUBImage utilisée incorrecte, le fichier GRUB de configuration attendu se trouve à un autre emplacement. Système de fichiers non pris en charge utilisé pour stocker votre fichier de GRUB configuration (par exemple, pour convertir votre système de fichiers racine en un type non pris en charge par une version antérieure deGRUB).

Actions suggérées

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	Option 1 : modifiez l'instance AMI et relancez-la : Modifiez la source AMI pour créer un fichier de GRUB configuration à 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 effectuez une mise à niveau GRUB si nécessaire. Choisissez l'GRUBimage appropriée (hd0-1er lecteur ou hd00 — 1er lecteur, 1re partition). Mettez fin à l'instance et lancez-en une nouvelle en utilisant celle 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 GRUB de configuration. Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et effectuez une mise à niveau GRUB si nécessaire. Détachez le système de fichiers. Attachez-le à l’instance originale. Modifiez l'attribut du noyau pour utiliser l'GRUBimage appropriée (1er disque ou 1ère partition sur le 1er disque). Démarrez l’instance.
Basée sur le stockage d’instance	Option 1 : modifiez l'instance AMI et relancez-la : Créez le nouveau AMI avec un fichier de GRUB configuration à l'emplacement standard (/boot/grub/menu.lst). Choisissez l'GRUBimage appropriée (hd0-1er lecteur ou hd00 — 1er lecteur, 1re partition). Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et effectuez une mise à niveau GRUB si nécessaire. Mettez fin à l'instance et lancez-en une nouvelle à l'aide de celle 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.

Pour ce type d’instance

Faites ceci

Soutenu EBS par Amazon

Option 1 : modifiez l'instance AMI et relancez-la :

Modifiez la source AMI pour créer un fichier de GRUB configuration à 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 effectuez une mise à niveau GRUB si nécessaire.
Choisissez l'GRUBimage appropriée (hd0-1er lecteur ou hd00 — 1er lecteur, 1re partition).
Mettez fin à l'instance et lancez-en une nouvelle en utilisant celle 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 GRUB de configuration.
Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et effectuez une mise à niveau GRUB si nécessaire.
Détachez le système de fichiers.
Attachez-le à l’instance originale.
Modifiez l'attribut du noyau pour utiliser l'GRUBimage appropriée (1er disque ou 1ère partition sur le 1er disque).
Démarrez l’instance.

Basée sur le stockage d’instance

Option 1 : modifiez l'instance AMI et relancez-la :

Créez le nouveau AMI avec un fichier de GRUB configuration à l'emplacement standard (/boot/grub/menu.lst).
Choisissez l'GRUBimage appropriée (hd0-1er lecteur ou hd00 — 1er lecteur, 1re partition).
Vérifiez que votre version de GRUB prend en charge le type de système de fichiers sous-jacent et effectuez une mise à niveau GRUB si nécessaire.
Mettez fin à l'instance et lancez-en une nouvelle à l'aide de celle 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.

Affichage de l'interface eth0 : le périphérique eth0 a une MAC adresse différente de celle attendue, ignorée. (MACAdresse codée en dur)

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 existe une interface codée en dur MAC dans la configuration AMI

Actions suggérées

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	Effectuez l’une des actions suivantes : Modifiez le AMI pour supprimer le codage en dur et relancer l'instance. Modifiez l'instance pour supprimer l'MACadresse 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 pour supprimer l'MACadresse 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'MACadresse codée en dur. Mettez fin à l’instance et lancez une nouvelle instance.

Pour ce type d’instance

Faites ceci

Soutenu EBS par Amazon

Effectuez l’une des actions suivantes :

Modifiez le AMI pour supprimer le codage en dur et relancer l'instance.
Modifiez l'instance pour supprimer l'MACadresse codée en dur.

Utilisez la procédure suivante.

Arrêtez l’instance.
Détachez le volume racine.
Attachez le volume à une autre instance et modifiez-le pour supprimer l'MACadresse 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'MACadresse codée en dur.
Mettez fin à l’instance et lancez une nouvelle instance.

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

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

SELinuxa é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

Pour ce type d’instance	Faites ceci
Soutenu EBS par Amazon	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. SELinuxDésactivez-le 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 certains systèmes, vous pouvez le désactiver `SELINUX=disabled` en SELinux définissant dans le `/mount_point/etc/sysconfig/selinux` fichier l'emplacement où `mount_point` vous avez monté le volume sur votre instance de restauration. 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.

Soutenu EBS par Amazon

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.
SELinuxDésactivez-le 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 certains systèmes, vous pouvez le désactiver SELINUX=disabled en SELinux définissant dans le /mount_point/etc/sysconfig/selinux fichier l'emplacement où mount_point vous avez monté le volume sur votre instance de restauration.
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: délai de connexion aux appareils (délai d'expiration 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
Soutenu EBS par Amazon	Effectuez l’une des actions suivantes : Modifiez l'instance AMI et 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 le AMI pour utiliser un noyau moderne et lancez une nouvelle instance à l'aide de celui-ciAMI.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

SSHProblèmes liés aux instances Linux

L'instance Linux démarre à partir du mauvais volume