Pourquoi mon instance Linux EC2 passe-t-elle en mode d’urgence lorsque j’essaie de la démarrer ?

Brève description

Une instance peut démarrer en mode d’urgence pour les raisons suivantes :

• L’instance contient un noyau endommagé.
• Le montage automatique échoue en raison d’entrées incorrectes dans le fichier /etc/fstab.

Pour vérifier le type d’erreur, examinez les données de sortie de la console de l’instance. Si le noyau est endommagé, le message d’erreur panique du noyau peut s’afficher dans la sortie de la console. En cas d’échec du montage automatique, les messages d’échec de dépendance apparaissent dans la sortie de la console.

Résolution

Erreurs de panique du noyau

Des messages d’erreur de panique du noyau apparaissent lorsque le fichier de configuration grub ou le fichier initramfs est endommagé. En cas de problème avec le noyau, le message d’erreur suivant peut s’afficher « Panique du noyau - pas de synchronisation : VFS : Impossible de monter la racine fs sur un bloc inconnu (8,1) » dans la sortie de la console.

Pour corriger les erreurs de panique du noyau, procédez comme suit :

1.    Rétablissez le noyau à son état stable précédent. Pour obtenir des instructions sur la façon de rétablir l’état précédent du noyau, reportez-vous à Comment puis-je rétablir le noyau à un état stable connu après qu’une mise à jour a empêché mon instance Amazon EC2 de redémarrer correctement ?

2.    Une fois le noyau revenu à son état précédent, redémarrez l’instance. Corrigez ensuite les problèmes liés au noyau endommagé.

Erreurs d’échec de dépendance

En cas d’échec du montage automatique, les instances passent en mode d’urgence en raison d’erreurs de syntaxe dans le fichier /etc/fstab. De même, si le volume Amazon Elastic Block Store (Amazon EBS) répertorié dans le fichier est détaché de l’instance, le processus de démarrage de l’instance peut passer en mode d’urgence. Si l’un de ces problèmes survient, la sortie de la console se présente comme suit :

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

L’exemple de messages de journal précédent indique que le point de montage /mnt n’a pas pu être monté pendant la séquence de démarrage.

Pour empêcher la séquence de démarrage d’entrer en mode d’urgence en raison d’échecs de montage, ajoutez ce qui suit au fichier /etc/fstab.

• 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 correspondant. La colonne 0 désactive la vérification du système de fichiers et l’instance démarre correctement.

Vous pouvez utiliser trois méthodes pour corriger le fichier /etc/fstab.

Important :

les méthodes 2 et 3 requièrent l’arrêt et le démarrage de l’instance. Tenez compte des points suivants :

• Lorsque l’instance est arrêtée, les données contenues dans les volumes de stockage d’instances sont perdues. Avant d’arrêter l’instance, assurez-vous donc d’enregistrer une sauvegarde des données. Contrairement aux volumes basés sur EBS, les volumes de stockage d’instances 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 retenir une adresse IPv4 publique qui ne change pas lorsque l’instance est arrêtée, utilisez une adresse IP Elastic.

Pour en savoir plus, reportez-vous à Ce qu’il se passe lorsque vous arrêtez une instance.

Méthode 1 : utilisation d’EC2 Serial Console

Si vous avez activé EC2 Serial Console pour Linux, vous pouvez l’utiliser pour dépanner les types d’instances basés sur Nitro pris en charge et les instances matériel nu. Vous pouvez accéder la console de série à partir de la console Amazon EC2 ou de l’interface de la ligne de commande AWS (AWS CLI). Vous n’avez pas besoin d’une connexion active pour vous connecter à l’instance lorsque vous utilisez EC2 Serial Console.

Remarque : si vous n’avez jamais utilisé EC2 Serial Console, assurez-vous de vérifier les prérequis et de configurer l’accès avant d’essayer de vous connecter. Si l’instance est inaccessible et que vous n’avez pas configuré l’accès à la console de série, suivez les instructions de la méthode 2 ou de la méthode 3.

1.    Ouvrez la console Amazon EC2.

2.    Choisissez Instances.

3.    Sélectionnez l’instance, puis choisissez Actions, Surveillance et dépannage, EC2 Serial Console, Se connecter.

-ou-

Sélectionnez l’instance, puis choisissez Se connecter, EC2 Serial Console, Se connecter.

Une fenêtre de terminal s’ouvre alors dans le navigateur.

4.    Appuyez sur Entrée. Si vous êtes connecté à la console série, une invite de connexion apparaît. Si l’écran reste noir, utilisez les informations suivantes pour résoudre les problèmes de connexion à la console série :

• Vérifiez que vous avez configuré l’accès à la console série. Pour en savoir plus, reportez-vous à Configurer l’accès à EC2 Serial Console.

• Utilisez SysRq pour vous connecter à la console série. SysRq ne requiert pas de connexion par le biais du client basé sur le navigateur. Pour en savoir plus, reportez-vous à Résolution de problèmes liés à une instance Linux à l’aide de SysRq.

• Redémarrez getty. Si vous disposez d’un accès SSH à l’instance, connectez-vous à l’instance via SSH, puis redémarrez getty en exécutant la commande suivante.

  [ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0

• Redémarrez l’instance. Vous pouvez redémarrer l’instance à l’aide de SysRq, de la console EC2 ou de l’AWS CLI. Pour en savoir plus, reportez-vous à Résolution de problèmes liés à une instance Linux à l’aide de SysRq ou Redémarrage d’une instance.

5.    Lorsque l’invite de connexion s’affiche, saisissez le nom d’utilisateur basé sur le mot de passe que vous avez configuré précédemment, puis appuyez sur Entrée.

6.    Lorsque l’invite de connexion par Mot de passe s’affiche, saisissez le mot de passe, puis appuyez sur Entrée.

Vous êtes désormais connecté à l’instance et pouvez utiliser EC2 Serial Console pour la résolution des problèmes.

Vous pouvez également vous connecter à l’aide de votre propre clé et d’un client SSH.

Pour en savoir plus sur l’utilisation d’EC2 Serial Console, reportez-vous à Connexion à EC2 Serial Console.

Méthode 2 : exécution du 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. L’utilisation de cette méthode ne requiert aucune intervention manuelle. Pour en savoir plus sur l’utilisation du document d’automatisation, reportez-vous à Exécution de l’outil EC2Rescue sur des instances inaccessibles.

Méthode 3 : modification manuelle du fichier à l’aide d’une instance de secours

1.    Ouvrez la console Amazon EC2.

2.    Choisissez Instances, puis sélectionnez l’instance 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 défaillante. La nouvelle instance devient alors votre instance de secours.

6.    Associez 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 différents noms de périphériques lorsque vous connectez des volumes secondaires.

7.    Connectez-vous à l’instance de secours via SSH.

8.    Créez un répertoire de points de montage pour le nouveau volume que vous avez associé à 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 avec un nom de périphérique différent. Pour déterminer le nom exact du périphérique, utilisez la commande lsblk permettant d’afficher les périphériques de disque disponibles et leurs points de montage.

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

$ sudo vi /mnt/rescue/etc/fstab

11.    Modifiez les entrées dans /etc/fstab selon vos besoins. L’exemple de sortie suivant montre trois volumes EBS définis avec des UUID, l’option nofail ajoutée pour les deux volumes secondaires et un 0 comme dernière colonne pour 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 qu’elle démarre correctement.