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 résoudre ce problème ?
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.
Solution
Il existe 3 méthodes pour résoudre les problèmes du système d'exploitation.
Important :
Les méthodes 2 et 3 nécessitent un arrêt et un démarrage de l'instance. Soyez conscient des points suivants :
- Les données sont perdues lorsque vous arrêtez l'instance si elle 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 Détermination du type d'appareil racine de votre instance.
- L'arrêt de l'instance peut mettre l'instance hors service si celle-ci fait partie d'un groupe Amazon EC2 Auto Scaling. 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 désactivation dépend des paramètres de protection 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.
Méthode 1 : utilisation d’EC2 Serial Console
Si vous avez activé EC2 Serial Console pour Linux, vous pouvez l'utiliser pour résoudre les problèmes liés aux types d'instance Nitro pris en charge. EC2 Serial Console vous aide à résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH. EC2 Serial Console se connecte à votre instance sans qu'aucune connexion réseau ne soit nécessaire. Vous pouvez accéder à EC2 Serial Console à l'aide de la console Amazon EC2 ou de l'interface de ligne de commande AWS (AWS CLI).
Avant d'utiliser EC2 Serial Console, accordez-lui l'accès au niveau du compte. Créez ensuite des stratégies AWS Identity and Access Management (IAM) accordant l'accès à vos utilisateurs IAM. De même, chaque instance qui utilise EC2 Serial Console doit inclure au moins un utilisateur avec mot de passe. Si votre instance n'est pas accessible et que vous n'avez pas configuré l'accès à EC2 Serial Console, suivez les instructions de la méthode 2. Pour en savoir plus sur la configuration d'EC2 Serial Console pour Linux, consultez Configuration de l'accès à EC2 Serial Console.
Remarque : si vous des erreurs surviennent lors de l'exécution de commandes AWS CLI, vérifiez que vous utilisez la version la plus récente d'AWS CLI.
Méthode 2 : exécution de 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 plus d’informatoions, consultez Comment utiliser EC2Rescue pour Linux pour résoudre les problèmes se produisant au niveau du système d'exploitation ?
Méthode 3 : correction manuelle des 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). Lancez la nouvelle instance EC2 dans la même zone de disponibilité que l'instance affectée. La nouvelle instance devient votre instance de secours.
Vous pouvez également utiliser une instance existante à laquelle vous avez accès, 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 de l’appareil (/dev/xvda ou /dev/sda1) de votre volume racine.
4. Attachez le volume en tant qu’appareil 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 : l’appareil (/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 corrects.
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, vous serez peut-être amené à arrêter ou redémarrer l'instance de secours.
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 donné ici, 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, vous serez peut-être amené à arrêter ou redémarrer l'instance de secours.
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.
Informations connexes
Résoudre les problèmes liés aux instances en cas d'échec de la vérification de l'état
Contenus pertinents
- demandé il y a 4 mois
- demandé il y a 5 mois
- demandé il y a 2 mois
- demandé il y a 3 mois
- demandé il y a 4 mois
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a 9 mois