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

Lecture de 8 minute(s)
0

Lorsque je démarre mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2), elle passe en mode d'urgence et le processus de démarrage échoue. L'instance est alors inaccessible.

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, regardez le résultat de la console de l'instance. Un message d'erreur kernel panic peut s'afficher dans le résultat de la console si le noyau est endommagé. Les messages d’échec de dépendance apparaissent dans le résultat de la console en cas d'échec du montage automatique.

Résolution

Erreurs Kernel panic

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

Pour corriger les erreurs Kernel panic :

1.    Revenez à un noyau stable précédent. Pour obtenir des instructions sur la façon de revenir à un noyau précédent, reportez-vous à 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 ?

2.    Une fois que vous êtes revenu à un noyau précédent, redémarrez l'instance. Corrigez ensuite les problèmes liés au noyau endommagé.

Erreurs d'échec de dépendance

Les instances passent en mode d'urgence en cas d'échec du montage automatique 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, le résultat 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 ceci 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 :

  • Les données contenues dans les volumes de stockage d'instances sont perdues lors de l'arrêt de l'instance. Assurez-vous de faire une sauvegarde des données avant d'arrêter l'instance. 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 si l'instance est arrêtée, utilisez une adresse IP Elastic.

Pour en savoir plus, reportez-vous à Que se passe-t-il lorsque vous arrêtez une instance.

Méthode 1 : Utilisez 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 à EC2 Serial Console à partir de la console Amazon EC2 ou de l'interface de ligne de commande AWS (AWS CLI). Vous n'avez pas besoin d'une connexion active pour vous connecter à votre 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 votre instance est inaccessible et que vous n'avez pas configuré l'accès à EC2 Serial Console, 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 résolution des problèmes, 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é à EC2 Serial Console, une invite de connexion apparaît. Si l'écran reste noir, utilisez les informations suivantes pour résoudre les problèmes de connexion à EC2 Serial Console :

5.    Lorsque l'invite de connexion s'affiche, saisissez le nom d'utilisateur de l'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 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 à Se connecter à EC2 Serial Console.

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. Aucune intervention manuelle n'est requise lors de l'utilisation de cette méthode. Pour en savoir plus sur l'utilisation du document d'automatisation, reportez-vous à Exécuter l'outil EC2Rescue sur des instances inaccessibles.

Méthode 3 : Modifier manuellement le 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 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 à votre instance de secours en utilisant 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 associé à l'instance avec un nom de périphérique 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 bons noms de périphériques.

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ésassociez le volume de l'instance temporaire.

14.    Associez le volume à l'instance d'origine, puis démarrez l'instance pour vérifier qu'elle démarre correctement.

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