La vérification du statut de mon instance EC2 Linux a échoué en raison de problèmes liés au système d'exploitation. Comment puis-je résoudre ce problème ?

Date de la dernière mise à jour : 02/06/2020

La vérification du statut de mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) a échoué en raison de problèmes liés au système d'exploitation. Désormais, elle ne démarre pas correctement. Comment résoudre ce problème ?

Brève description

La vérification du statut de votre instance EC2 Linux peut échouer pour les raisons suivantes :

  • Vous avez mis à jour le noyau et ce nouveau noyau n'a pas démarré.
  • Les entrées du système de fichiers dans /etc/fstab sont incorrectes ou le système de fichiers est corrompu.
  • L'instance comporte des configurations réseau incorrectes.

Résolution

Avertissement : avant d'arrêter et de démarrer votre instance, assurez-vous de bien comprendre les informations suivantes :

  • Les données de stockage d'instance sont perdues lorsque vous arrêtez et démarrez une instance. Les données sont perdues lorsque vous arrêtez l'instance si votre instance est basée sur le stockage d'instance ou dispose de volumes de stockage d'instance contenant des données. Pour plus d'informations, consultez la section Identification du type de dispositif racine de votre instance.
  • L'arrêt de l'instance peut mettre l'instance hors service si celle-ci fait partie d'un groupe Auto Scaling d'Amazon EC2. Votre instance peut faire partie d'un groupe Auto Scaling d'AWS si vous l'avez lancée avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk. Dans ce cas, la mise hors service dépend des paramètres de protection des instances définis pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement du groupe avant d'exécuter les étapes de résolution.
  • L'arrêt et le redémarrage de l'instance entraînent la modification de son adresse IP publique. Il est recommandé d'utiliser une adresse IP Elastic, et non publique pour l'acheminement du trafic externe vers votre instance. Si vous utilisez Amazon Route 53, il peut être nécessaire de mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change.
  • L'instance est mise hors service lorsqu'elle est arrêtée si le comportement d'arrêt de l'instance est Mettre hors service. Vous pouvez modifier le comportement d'arrêt de l'instance pour éviter cela.

Exécuter l'outil EC2Rescue pour Linux

EC2Rescue pour Linux automatise le diagnostic et la résolution des problèmes du système d'exploitation sur les instances inaccessibles. Pour en savoir plus, consultez la section Mon instance EC2 Linux ne répond plus ou présente des problèmes au démarrage. Comment puis-je utiliser EC2Rescue pour Linux afin de résoudre les problèmes se produisant au niveau du système d'exploitation ?

Corriger manuellement les erreurs à l'aide d'une instance de secours

1.    Lancez une nouvelle instance EC2 dans votre Virtual Private Cloud (VPC) en utilisant la même Amazon Machine Image (AMI) et dans la même zone de disponibilité que l'instance affectée. Cette nouvelle instance devient votre instance de secours.

Vous pouvez également utiliser une instance existante à laquelle vous pouvez accéder, si elle utilise la même AMI et se trouve dans la même zone de disponibilité que votre instance affectée.

2.    Arrêtez l'instance affectée.

3.    Détachez le volume racine Amazon Elastic Block Store (Amazon EBS) (/dev/xvda ou /dev/sda1) de l'instance affectée. Notez le nom du dispositif (/dev/xvda ou /dev/sda1) de votre volume racine.

4.    Attachez le volume en tant que dispositif secondaire (/dev/sdf) à l'instance de secours.

5.    Connectez-vous à l'instance de secours en utilisant SSH.

6.    Créez un répertoire de point de montage (/rescue) pour le nouveau volume attaché à l'instance de secours :

$ sudo mkdir /rescue

7.    Montez le volume dans le répertoire que vous avez créé à l'étape 6 :

$ sudo mount /dev/xvdf1 /rescue

Remarque : le dispositif (/dev/xvdf1) peut être attaché à l'instance de secours avec un nom de périphérique différent. Utilisez la commande lsblk pour afficher vos périphériques de disque disponibles, ainsi que leurs points de montage, afin de déterminer les noms de périphériques adéquats.

8.    Si vous ne l'avez pas déjà fait, récupérez le journal système de l'instance pour vérifier l'erreur qui s'est produite. Les étapes suivantes dépendent du message d'erreur indiqué dans le journal système. Voici une liste des erreurs courantes qui peuvent entraîner l'échec du contrôle du statut de l'instance. Pour en savoir sur les autres erreurs, consultez la section Résolution des erreurs de journaux système pour les instances basées sur Linux.

Alerte du noyau

Si un message d'erreur Alerte du noyau se trouve dans le journal système, le noyau peut ne pas avoir les fichiers vmlinuz ou initramfs. Les fichiers vmlinuz et initramfs sont nécessaires pour démarrer avec succès.

1.    Exécutez les commandes suivantes :

cd /rescue/boot
ls -l

2.    Vérifiez la sortie pour vous assurer que les fichiers vmlinuz et initramfs correspondant à la version du noyau que vous avez l'intention de démarrer sont bien présents.

L'exemple de sortie suivant concerne une instance Amazon Linux 2 avec la version de noyau 4.14.165-131.185.amzn2.x86_64. Le répertoire /boot comporte les fichiers initramfs-4.14.165-131.185.amzn2.x86_64.img et vmlinuz-4.14.165-131.185.amzn2.x86_64. Par conséquent, il démarrera avec succès.

uname -r
4.14.165-131.185.amzn2.x86_64

cd /boot; ls -l
total 39960
-rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
drwx------ 5 root root       79 Feb 12 04:08 grub2
-rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
-rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
-rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
-rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
-rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

3.    Si les fichiers initramfs et/ou vmlinuz ne sont pas présents, essayez de démarrer l'instance à l'aide d'un noyau précédent contenant ces deux fichiers. Pour savoir comment démarrer votre instance à l'aide d'un noyau précédent, consultez la section Comment rétablir un noyau stable connu après qu'une mise à jour empêche mon instance Amazon EC2 de redémarrer correctement ?

4.    Exécutez la commande unmount pour démonter le périphérique secondaire à partir de votre instance de secours.

$ sudo umount /rescue

Si le démontage n'aboutit pas, il peut être nécessaire d'arrêter ou de redémarrer l'instance de secours pour effectuer un démontage propre.

5.    Détachez le volume secondaire (/dev/sdf) de l'instance de secours, puis attachez-le à l'instance d'origine en tant que /dev/xvda (volume racine).

6.    Démarrez l'instance, puis vérifiez qu'elle répond.

Pour plus d'informations sur la résolution des erreurs d'alerte du noyau, consultez la section Je reçois une erreur « Panique du noyau » après avoir mis à niveau le noyau ou essayé de redémarrer mon instance EC2 Linux. Comment résoudre ce problème ?

Échec du montage ou de la dépendance

Si vous rencontrez des erreurs telles qu'« Échec du montage » ou « Échec de la dépendance » dans votre journal système, cela signifie que le fichier /etc/fstab peut comporter des entrées de point de montage incorrectes.

1.    Vérifiez que les entrées de point de montage dans /etc/fstab sont correctes. Pour plus d'informations sur la correction des entrées du fichier /etc/fstab, consultez Échecs de montage automatique dus à des entrées incorrectes dans le fichier /etc/fstab de la section Pourquoi mon instance EC2 ne démarre-t-elle pas et passe en mode d'urgence ?

2.    Il est recommandé d'exécuter l'outil fsck ou xfs_repair pour corriger les erreurs de système de fichiers. Si le système de fichiers comporte des incohérences, l'outil fsck ou xfs_repair les corrige.

Remarque : créez une sauvegarde de votre système de fichiers avant d'exécuter l'outil fsck ou xfs_repair.

Exécutez la commande unmount pour démonter votre point de montage avant d'exécuter l'outil fsck ou xfs_repair :

$ sudo umount /rescue

Exécutez l'outil fsk ou xfs_repair, en fonction de votre système de fichiers.

Pour les systèmes de fichiers ext4 :

$ sudo fsck /dev/sdf
fsck from util-linux 2.30.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdf: clean, 11/6553600 files,
459544/26214400 blocks

Pour les systèmes de fichiers XFS :

$ sudo xfs_repair /dev/sdf
xfs_repair /dev/xvdf
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

3.    Détachez le volume secondaire (/dev/sdf) de l'instance de secours, puis attachez-le à l'instance d'origine en tant que /dev/xvda (volume racine).

4.    Démarrez l'instance, puis vérifiez qu'elle répond.

Affichage de l'interface eth0 : échec

Si vous voyez l'erreur « Affichage de l'interface eth0 : échec », vérifiez que le fichier ifcfg-eth0 contient les entrées réseau appropriées. Le fichier de configuration réseau correspondant à l'interface principale, eth0, se trouve à l'emplacement /etc/sysconfig/network-scripts/ifcfg-eth0. Si le nom de périphérique de votre interface principale n'est pas eth0, l'instance comportera un fichier qui commence par ifcfg et est suivi du nom de votre périphérique dans le répertoire /etc/sysconfig/network-scripts.

1.    Exécutez la commande cat pour afficher le fichier de configuration réseau pour l'interface principale eth0.

Voici les entrées appropriées pour le fichier de configuration réseau situé dans /etc/sysconfig/network-scripts/ifcfg-eth0.

Remarque : remplacez eth0 dans la commande suivante par le nom de votre interface principale, si elle est différente.

$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-nw
PERSISTENT_DHCLIENT=yes
RES_OPTIONS="timeout:2 attempts:5"
DHCP_ARP_CHECK=no

2.    Vérifiez que ONBOOT est défini sur yes, comme illustré dans l'exemple précédent. Si ONBOOT n'est pas défini sur yes, eth0 (ou votre interface réseau principale) n'est pas configuré pour être lancé au démarrage.

Pour modifier la valeur ONBOOT :

Ouvrez le fichier dans l'éditeur. Dans l'exemple ci-dessous, l'éditeur vi est utilisé.

$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

Appuyez sur I pour insérer.

Faites défiler le curseur jusqu'à l'entrée ONBOOT, puis remplacez la valeur par yes.

Enregistrez et quittez le fichier en appuyant sur :wq!.

3.    Exécutez la commande unmount pour démonter le périphérique secondaire à partir de votre instance de secours.

$ sudo umount /rescue

Si le démontage n'aboutit pas, il peut être nécessaire d'arrêter ou de redémarrer l'instance de secours pour effectuer un démontage propre.

4.    Détachez le volume secondaire (/dev/sdf) de l'instance de secours, puis attachez-le à l'instance d'origine en tant que /dev/xvda (volume racine).

5.    Démarrez l'instance, puis vérifiez qu'elle répond.