Comment résoudre un problème d'instance Linux EC2 qui a échoué à la vérification de l'état de l'instance en raison de problèmes liés au système d'exploitation ?
La vérification de l'état de l'instance de mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) a échoué en raison de problèmes liés au système d'exploitation. Depuis, l’instance ne parvient pas à démarrer correctement.
Brève description
Votre instance Linux EC2 peut échouer à la vérification de l'état de l'instance pour les raisons suivantes :
- Vous avez mis à jour le noyau et le 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 endommagé.
- Certaines configurations réseau de l'instance sont incorrectes.
Résolution
Important : certaines des procédures suivantes nécessitent que vous arrêtiez l'instance. Lorsque vous arrêtez une instance, les données stockées dans des volumes de stockage d'instances sont perdues. Veillez donc à enregistrer une sauvegarde des données avant d'arrêter l'instance. Contrairement aux volumes basés sur Amazon Elastic Block Store (Amazon EBS), les volumes du stockage d'instances sont éphémères et ne prennent pas en charge la persistance des données. Pour en savoir plus, consultez la page Arrêt et démarrage des instances Amazon EC2.
L'adresse IPv4 publique statique qu'Amazon EC2 attribue automatiquement à l'instance change après l'arrêt et le démarrage. Pour conserver une adresse IPv4 publique qui ne change pas lorsque l'instance est arrêtée, utilisez une adresse IP Elastic.
Remarque : les méthodes suivantes emploient des exemples basés sur Amazon Linux 2. Cependant, ces concepts s'appliquent aux distributions Linux en général. Si vous disposez d'une distribution Linux autre qu'Amazon Linux 2, les commandes, les chemins et les sorties peuvent varier.
Utilisation de l'EC2 Serial Console pour les instances Linux
Si vous avez activé l'EC2 Serial Console pour les instances Linux, vous pouvez l'utiliser pour résoudre les problèmes liés aux types d'instances basées sur Nitro pris en charge et les instances de matériel nu. Cette console vous permet de résoudre les problèmes de démarrage, mais aussi les problèmes de configuration SSH et réseau. Elle peut se connecter à votre instance sans disposer d’une connexion réseau fonctionnelle. Pour accéder à la console série, utilisez la console Amazon EC2 ou l'interface de la ligne de commande AWS (AWS CLI).
Si vous utilisez l’EC2 Serial Console pour la première fois, vérifiez les conditions requises et configurez son accès avant de vous connecter.
Si votre instance est inaccessible et que vous n'avez pas configuré l'accès à la console série, consultez la section Exécution de l'outil EC2Rescue pour Linux. Vous pouvez également utiliser une instance de secours. Pour configurer l'EC2 Serial Console pour les instances Linux, consultez la page Configuration de l'accès à l’EC2 Serial Console.
Remarque : si des erreurs surviennent lorsque vous exécutez des commandes AWS CLI, consultez la page Correction des erreurs liées à AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.
Exécution de l'outil EC2Rescue pour Linux
EC2Rescue pour Linux diagnostique et dépanne automatiquement les systèmes d'exploitation sur les instances inaccessibles. Pour en savoir plus, consultez la page Comment utiliser EC2Rescue pour Linux pour résoudre les problèmes au niveau du système d'exploitation ?
Utilisation d’une instance de secours pour corriger manuellement les erreurs
-
Lancez une nouvelle instance EC2 dans votre cloud privé virtuel (VPC). Utilisez la même Amazon Machine Image (AMI) et la même zone de disponibilité que l'instance défaillante. La nouvelle instance devient votre instance de secours.
Vous pouvez également utiliser une instance existante. L'instance existante doit utiliser la même AMI et se trouver dans la même zone de disponibilité que votre instance défaillante.
-
Détachez le volume racine Amazon EBS (/dev/xvda ou /dev/sda1) de votre instance défaillante. Notez le nom de périphérique de votre volume racine.
-
Attachez le volume en tant que périphérique secondaire (/dev/sdf) à l'instance de secours.
-
Créez un répertoire de points de montage (/rescue) pour le nouveau volume associé à l'instance de secours :
$ sudo mkdir /rescue -
Montez le volume dans le nouveau répertoire :
$ sudo mount /dev/xvdf1 /rescueSi vous recevez un message d'erreur, tel que « Wrong Fs type or UUID duplicate, Superblock is missing or badblock found », consultez la page Pourquoi ne puis-je pas monter mon volume Amazon EBS ?
Remarque : le périphérique (/dev/xvdf1) peut être associé à l'instance de secours avec un nom de périphérique différent. Pour déterminer le nom exact du périphérique, exécutez la commande lsblk afin d'afficher vos périphériques de disque disponibles ainsi que leurs points de montage.
-
Si ce n'est pas déjà fait, récupérez le journal système de l'instance pour vérifier l'erreur. Les étapes suivantes dépendent du message d'erreur répertorié dans le journal système.
Vous trouverez ci-dessous une liste d’erreurs courantes à l'origine de l'échec de la vérification de l'état de l'instance. Pour obtenir d'autres erreurs, consultez la page Résolution des erreurs de journal système pour les instances basées sur Linux.
Résolution d’erreurs de type « panique du noyau »
Si une erreur de type Panique du noyau apparaît dans le journal système, il est possible que le noyau ne contienne pas les fichiers vmlinuz ou initramfs. Les fichiers vmlinuz et initramfs sont nécessaires pour assurer un démarrage sans échec.
-
Exécutez les commandes suivantes :
cd /rescue/boot ls -l -
Vérifiez la sortie pour déterminer s'il existe des fichiers vmlinuz et initramfs correspondant à la version du noyau que vous souhaitez démarrer.
L'exemple de sortie suivant concerne une instance Amazon Linux 2 dont la version du noyau est 4.14.165-131.185.amzn2.x86_64. Le répertoire /boot contient les fichiers initramfs-4.14.165-131.185.amzn2.x86_64.img et vmlinuz-4.14.165-131.185.amzn2.x86_64 pour un démarrage sans échec.
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 -
Si les fichiers initramfs et vmlinuz ne sont pas présents, vous pouvez démarrer l'instance à l’aide d’un noyau plus ancien qui contient les deux fichiers. Pour obtenir des instructions, consultez la page Comment rétablir un noyau stable connu lorsqu'une mise à jour empêche mon instance Amazon EC2 de redémarrer correctement ?
-
Exécutez la commande umount pour démonter le périphérique secondaire sur votre instance de secours :
$ sudo umount /rescueSi l'opération de démontage échoue, il est possible que vous deviez arrêter ou redémarrer l'instance de secours pour procéder à un démontage net.
-
Détachez le volume secondaire (/dev/sdf) de l'instance de secours. Attachez-le ensuite à l’instance d’origine en tant que /dev/xvda (volume racine).
-
Démarrez l'instance, puis vérifiez si elle est réactive.
Pour en savoir plus sur la résolution des erreurs de panique du noyau, consultez la page Pourquoi le message d'erreur « Panique du noyau » s'affiche-t-il après la mise à niveau du noyau ou le redémarrage de mon instance Linux EC2 ?
Résolution de problèmes liés à l'échec du montage ou à l'échec de la dépendance
L’apparition d’erreurs de type « Failed to mount » ou « Dependency failed » dans votre journal système indique que le fichier /etc/fstab contient des entrées de point de montage incorrectes.
-
Vérifiez que les entrées du point de montage sont correctes dans le fichier /etc/fstab. Pour corriger les entrées du fichier /etc/fstab, consultez la page Pourquoi mon instance Linux EC2 passe-t-elle en mode d'urgence lorsque j'essaie de la démarrer ?
-
Il est recommandé d'exécuter l'outil fsck ou xfs_repair pour corriger toute incohérence au niveau du système de fichiers.
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 umount pour démonter votre point de montage avant d'exécuter l'outil fsck ou xfs_repair :
$ sudo umount /rescueExécutez l'outil fsck ou xfs_repair, selon votre système de fichiers.
Pour les systèmes de fichiers ext4, exécutez la commande suivante :
$ 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 blocksPour les systèmes de fichiers XFS, exécutez la commande suivante :
$ 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 -
Détachez le volume secondaire (/dev/sdf) de l'instance de secours. Attachez-le ensuite à l’instance d’origine en tant que /dev/xvda (volume racine).
-
Démarrez l'instance, puis vérifiez si elle est réactive.
Résolution de l’erreur « interface eth0: failed »
Vérifiez que le fichier ifcfg-eth0 contient les entrées réseau correctes. Le fichier de configuration réseau correspondant à l'interface principale, eth0, se trouve dans /etc/sysconfig/network-scripts/ifcfg-eth0. Si le nom de périphérique de votre interface principale n'est pas eth0, le nom du fichier commence par ifcfg et est suivi du nom de l'appareil. Le fichier se trouve dans le répertoire /etc/sysconfig/network-scripts de l'instance.
-
Exécutez la commande cat pour afficher le fichier de configuration réseau de l'interface principale eth0.
Voici les entrées correctes pour le fichier de configuration réseau situé dans /etc/sysconfig/network-scripts/ifcfg-eth0.
Remarque : si nécessaire, remplacez eth0 dans la commande suivante par le nom de votre interface principale.
$ 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 -
Vérifiez que ONBOOT est défini sur yes. Si ONBOOT n'est pas défini sur yes, eth0 (ou votre interface réseau principale) ne sera pas configuré pour s'afficher au démarrage.
Pour modifier la valeur ONBOOT, commencez par ouvrir le fichier dans un éditeur. Cet exemple utilise l'éditeur vi :
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0Appuyez sur I pour procéder à l'insertion.
Faites défiler le curseur jusqu'à l'entrée ONBOOT, puis remplacez la valeur par yes.
Pour enregistrer et quitter le fichier, appuyez sur :wq!
-
Exécutez la commande umount pour démonter le périphérique secondaire sur votre instance de secours :
$ sudo umount /rescueSi l'opération de démontage échoue, il se peut que vous deviez arrêter ou redémarrer l'instance de secours pour lancer un démontage net.
-
Détachez le volume secondaire (/dev/sdf) de l'instance de secours. Attachez-le ensuite à l’instance d’origine en tant que /dev/xvda (volume racine).
-
Démarrez l'instance, puis vérifiez si elle est réactive.
Informations connexes
Pourquoi mon instance Linux EC2 est-elle injoignable et ses vérifications d'état échouent-elles?
Résoudre les problèmes liés aux instances dont les vérifications d'état ont échoué
Contenus pertinents
- demandé il y a un an
- demandé il y a 8 mois
- demandé il y a un mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans