Pourquoi mon instance Linux EC2 ne démarre-t-elle pas et passe-t-elle en mode d'urgence ?

Dernière mise à jour : 22/04/2020

Lorsque je démarre mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2), celle-ci passe en mode d'urgence et le processus de démarrage échoue. Ensuite, l'instance est inaccessible. Comment puis-je résoudre ce problème ?

Brève description

Voici les raisons les plus courantes du démarrage d'une instance en mode d'urgence :

  • un noyau corrompu ;
  • des échecs de montage automatique dus à des entrées incorrectes dans le fichier /etc/fstab.

Pour vérifier quel type d'erreur vous concerne, utilisez la sortie de la console de l'instance. Un message d'erreur indiquant une panique du noyau peut s'afficher lorsque le noyau est corrompu. Les erreurs d'échec de dépendance sont quant à elles liées aux problèmes de montage automatique.

Solution

Erreurs de panique du noyau

Les messages d'erreur de panique du noyau apparaissent lorsque le fichier de configuration grub ou initramfs est corrompu. Si le noyau présente une anomalie, la sortie de la console peut afficher le message « Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block (8,1) ».

Pour résoudre les erreurs de panique du noyau :

1.    Restaurez une version antérieure et stable du noyau. Pour savoir comment revenir à 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 ?

2.    Après avoir rétabli une version antérieure du noyau, redémarrez l'instance. Ensuite, corrigez les problèmes du noyau corrompu.

Erreurs d'échec de dépendance

Les échecs de montage automatique dus à des erreurs de syntaxe dans le fichier /etc/fstab peuvent entraîner le passage de l'instance en mode d'urgence. En outre, lorsque le volume Amazon Elastic Block Store (Amazon EBS) répertorié dans le fichier est détaché de l'instance, celle-ci peut démarrer en mode d'urgence. Si l'un de ces problèmes se produit, la sortie de la console affiche ce type de messages :

-------------------------------------------------------------------------------------------------------------------
[[1;33mDEPEND[0m] Dependency failed for /mnt.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
[[1;33mDEPEND[0m]
    Dependency failed for Migrate local... structure to the new structure.
[[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary.
[[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot.
[[1;33mDEPEND[0m]
    Dependency failed for File System Check on /dev/xvdf.
-------------------------------------------------------------------------------------------------------------------

Les messages de journal ci-dessus indiquent que le point de montage /mnt n'a pas pu être monté au cours de la séquence de démarrage.

Pour empêcher la séquence de démarrage de passer en mode d'urgence en raison d'échecs de montage :

  • Ajoutez une option nofail dans le fichier /etc/fstab pour les partitions secondaires (/mnt, dans l'exemple précédent). Lorsque l'option nofail est présente, la séquence de démarrage n'est pas interrompue, même si le montage d'un volume ou d'une partition échoue.
  • Ajoutez 0 comme dernière colonne du fichier /etc/fstab pour le point de montage respectif. L'ajout de la colonne 0 désactive la vérification du système de fichiers, permettant à l'instance de démarrer normalement.

Deux méthodes s'offrent à vous pour corriger le fichier /etc/fstab :

Important :

  • Ces procédures nécessitent l'arrêt et le redémarrage de votre instance EC2. Les données de stockage d'instance qu'elle contient seront perdues. Si tel est le cas de votre instance, ou bien si cette dernière comporte des volumes de stockage d'instance contenant des données, sachez que vous ne pourrez plus y avoir accès. Pour plus d'informations, consultez la section Identification du type de périphérique racine de votre instance.
  • Si votre instance fait partie d'un groupe Auto Scaling Amazon EC2, ou si elle est lancée par des services qui utilisent AWS Auto Scaling, tels qu'Amazon EMR, AWS CloudFormation ou encore AWS Elastic Beanstalk, l'arrêt de l'instance pourrait entraîner sa résiliation. Dans ce scénario, la résiliation de l'instance dépend des paramètres de protection contre la diminution de la taille d'instance pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement de ce dernier avant de suivre 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 au lieu d'une adresse IP publique lors de l'acheminement du trafic externe vers l'instance.

Méthode 1 : Exécuter le document d'automatisation AWSSupport-ExecuteEC2Rescue

Si votre instance est configurée pour AWS Systems Manager, vous pouvez exécuter le document d'automatisation AWSSupport-ExecuteEC2Rescue pour corriger les problèmes de démarrage. Cette méthode ne requiert aucune intervention manuelle. Pour plus d'informations sur l'utilisation du document d'automatisation, consultez la section Procédure : exécuter l'outil EC2Rescue sur les instances inaccessibles.

Méthode 2 : Modifier manuellement le fichier à l'aide d'une instance de secours

1.    Ouvrez la console Amazon EC2.

2.    Dans le volet de navigation, choisissez Instances, puis l'instance qui est passée en mode d'urgence.

3.    Arrêtez l'instance.

4.    Détachez le volume racine Amazon EBS (/dev/xvda ou /dev/sda1) de l'instance arrêtée.

5.    Lancez une nouvelle instance EC2 dans la même zone de disponibilité que l'instance affectée. Cette nouvelle instance devient votre instance de secours.

6.    Attachez le volume racine que vous avez détaché à l'étape 4 à l'instance de secours en tant que périphérique secondaire.

Remarque : vous pouvez utiliser un nom de périphérique différent lors de l'attachement de volumes secondaires.

7.    Connectez-vous à l'instance EC2 en utilisant SSH.

8.    Créez un répertoire de point de montage pour le nouveau volume attaché à l'instance de secours à l'étape 6. Dans l'exemple suivant, le répertoire du point de montage est /mnt/rescue.

$ sudo mkdir /mnt/rescue

9.    Montez le volume dans le répertoire que vous avez créé à l'étape 8.

$ sudo mount /dev/xvdf /mnt/rescue

Remarque : le périphérique (/dev/xvdf, dans l'exemple précédent) peut être attaché à l'instance de secours avec un nom 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.

10.    Une fois le volume monté, exécutez la commande suivante pour ouvrir le fichier /etc/fstab.

$ sudo vi /mnt/rescue/etc/fstab

11.    Si nécessaire, modifiez les entrées du fichier /etc/fstab. L'exemple de sortie suivant indique trois volumes EBS définis avec des UUID, l'option nofail ajoutée pour les deux volumes secondaires et 0 utilisé en tant que dernière colonne de chaque entrée.

------------------------------------------------------------------------------------------
$ cat /etc/fstab
UUID=e75a1891-3463-448b-8f59-5e3353af90ba  /  xfs  defaults,noatime  1  0
UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58  /mnt/rescue  ext4  defaults,noatime,nofail  1  0
UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381  /mnt  ext4  defaults,noatime,nofail  1  0  
------------------------------------------------------------------------------------------

12.    Enregistrez le fichier, puis exécutez la commande umount pour démonter le volume.

$ sudo umount /mnt/rescue

13.    Détachez le volume de l'instance temporaire.

14.    Attachez le volume à l'instance d'origine, puis démarrez l'instance pour vérifier la bonne résolution du problème.


Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d’aide ?