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

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.

Trois méthodes s'offrent à vous pour corriger le fichier /etc/fstab.

Important :

Les méthodes 2 et 3 nécessitent un arrêt et un démarrage de l'instance. Soyez conscient des points suivants :

• Si votre instance est basée sur le stockage d'instance ou si des volumes de stockage d'instance contiennent des données, les données sont perdues lorsque l'instance est arrêtée. Pour plus d'informations, consultez Déterminer le type de périphérique racine de votre instance.
• Si votre instance fait partie d'un groupe Amazon EC2 Auto Scaling, l'arrêt de l'instance peut la résilier. Les instances lancées avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling AWS. 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 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. Lorsque vous acheminez du trafic externe vers votre instance, il est recommandé d'utiliser une adresse IP Elastic plutôt qu'une adresse IP publique.

Méthode 1 : Utiliser EC2 Serial Console

Si vous avez activé EC2 Serial Console pour Linux, vous pouvez l'utiliser pour dépanner les 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. En outre, chaque instance qui utilise la console série 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 plus d'informations sur la configuration d'EC2 Serial Console pour Linux, consultez la section Configurer l'accès à EC2 Serial Console.

Remarque : en cas d'erreurs lors de l'exécution des commandes depuis AWS CLI, assurez-vous d'utiliser la version la plus récente.

Méthode 2 : 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 3 : 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 sélectionnez 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 corrects.

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.

---