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 ?

Lecture de 10 minute(s)
0

Mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) a échoué à la vérification de l'état de l'instance en raison de problèmes liés au système d'exploitation. Maintenant, elle ne démarre pas 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

Il existe trois méthodes pour résoudre les problèmes liés au système d'exploitation.

Important : certaines des procédures suivantes nécessitent l'arrêt de l'instance. Les données stockées dans les volumes de stockage de l'instance sont perdues lorsque l'instance est arrêtée. Veillez à effectuer 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'instance sont éphémères et ne prennent pas en charge la persistance des données.

L'adresse IPv4 publique statique qu'Amazon EC2 a attribuée automatiquement à l'instance lors du lancement ou du démarrage 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.

Pour en savoir plus, consultez la page Que se passe-t-il lorsque vous arrêtez une instance ?

Utiliser 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 de configuration réseau et SSH. Elle se connecte à votre instance sans nécessiter de connexion réseau fonctionnelle. Vous pouvez utiliser la console Amazon EC2 ou l'interface de la ligne de commande AWS (AWS CLI) pour accéder à EC2 Serial Console.

Si vous utilisez l'EC2 Serial Console pour la première fois, veillez à vérifier les prérequis et à configurer l'accès avant d'essayer de vous connecter.

Si votre instance est inaccessible et que vous n'avez pas configuré l'accès à la console de série, procédez comme indiqué dans la section Exécuter l'outil EC2Rescue pour Linux ou Utiliser une instance de secours. Pour en savoir plus sur la configuration de l'EC2 Serial Console pour les instances Linux, consultez la page Configurer l'accès à l'EC2 Serial Console.

Remarque : si des erreurs surviennent lors de l'exécution des commandes AWS CLI, vérifiez que vous utilisez la version la plus récente d'AWS CLI.

Exécuter 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 ?

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

1.    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.

2.    Arrêtez l'instance défaillante.

3.    Dissociez le volume racine Amazon Elastic Block Store (Amazon EBS) (/dev/xvda ou /dev/sda1) de votre instance défaillante. Notez le nom du périphérique (/dev/xvda ou /dev/sda1) de votre volume racine.

4.    Associez le volume en tant que périphérique secondaire (/dev/sdf) à l'instance de secours.

5.    Connectez-vous à votre instance de secours via SSH.

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

$ sudo mkdir /rescue

7.    Montez le volume dans le nouveau répertoire :

$ sudo mount /dev/xvdf1 /rescue

Si vous recevez un message d'erreur, tel que Type Fs erroné ou UUID en double, superbloc manquant ou bloc défectueux trouvé, 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.

8.    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 des erreurs courantes à l'origine de l'échec de la vérification de l'état de l'instance. Pour d'autres erreurs, consultez la page Résolution des erreurs de journal système pour les instances basées sur Linux.

Panique du noyau

Si un message Panique du noyau apparaît dans le journal système, cela signifie que le noyau ne contient peut-être pas les fichiers vmlinuz ou initramfs. Les fichiers vmlinuz et initramfs sont nécessaires pour démarrer correctement.

1.    Exécutez les commandes suivantes :

cd /rescue/boot
ls -l

2.    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. Il démarrera donc correctement.

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 en utilisant un noyau précédent contenant les deux fichiers. Afin d'obtenir des instructions pour démarrer votre instance à l'aide d'un noyau précédent, consultez la page Comment puis-je revenir à un noyau stable connu après qu'une mise à jour a empêché mon instance Amazon EC2 de redémarrer correctement ?

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

$ sudo umount /rescue

Si l'opération de démontage échoue, il se peut que vous deviez arrêter ou redémarrer l'instance de secours pour procéder à un démontage net.

5.    Dissociez le volume secondaire de l'instance de secours (/dev/sdf), puis associez le volume à l'instance d'origine en tant que /dev/xvda (volume racine).

6.    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 ?

Échec du montage ou de dépendance

Lorsque des erreurs telles que « Échec du montage » ou « Échec de dépendance » apparaissent dans votre journal système, cela indique que le fichier /etc/fstab contient des entrées de point de montage incorrectes.

1.    Vérifiez que les entrées du point de montage sont correctes dans le fichier /etc/fstab. Pour en savoir plus sur la correction des entrées du fichier /etc/fstab, consultez la section Échec du montage automatique en raison d'entrées incorrectes dans le fichier /etc/fstab de la page Pourquoi mon instance Linux EC2 passe-t-elle en mode d'urgence lorsque j'essaie de la démarrer ?

2.    Il est recommandé d'exécuter l'outil fsck ou xfs_repair pour corriger les erreurs du système de fichiers. S'il existe des incohérences dans le système de fichiers, 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 fsck 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.    Dissociez le volume secondaire de l'instance de secours (/dev/sdf), puis associez le volume à l'instance d'origine en tant que /dev/xvda (volume racine).

4.    Démarrez l'instance, puis vérifiez si elle est réactive.

L'affichage de l'interface eth0 a échoué

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, il existe un fichier qui commence par ifcfg, suivi du nom de votre périphérique. Le fichier se trouve dans le répertoire /etc/sysconfig/network-scripts de l'instance.

1.    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 : remplacez eth0 dans la commande suivante par le nom de votre interface principale, s'il est différent.

$ 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 oui, comme indiqué dans l'exemple précédent. Si ONBOOT n'est pas défini sur oui, eth0 (ou votre interface réseau principale) n'est pas configuré pour s'afficher au démarrage.

Pour modifier la valeur ONBOOT :

Ouvrez le fichier dans un éditeur. Dans cet exemple, l'éditeur vi est utilisé.

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

Appuyez sur I pour procéder à l'insertion.

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

Enregistrez et quittez le fichier en appuyant sur :wq!

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

$ sudo umount /rescue

Si l'opération de démontage échoue, il se peut que vous deviez arrêter ou redémarrer l'instance de secours pour permettre un démontage net.

4.    Dissociez le volume secondaire de l'instance de secours (/dev/sdf), puis associez le volume à l'instance d'origine en tant que /dev/xvda (volume racine).

5.    Démarrez l'instance, puis vérifiez si elle est réactive.

Informations connexes

Pourquoi mon instance Linux EC2 est-elle inaccessible et échoue-t-elle à l'un de ses contrôles de statut ou aux deux ?

Résoudre les problèmes liés à un échec des vérifications de statut

Pourquoi mon instance Linux ne démarre-t-elle pas après que j'ai remplacé son type par un type d'instance basé sur Nitro ?

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 8 mois