En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation

Comment puis-je récupérer une instance Linux EC2 qui ne démarre pas en raison d'erreurs de disque ?

Lecture de 6 minute(s)
0

Mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) lancée depuis une Amazon Machine Image (AMI) personnalisée présente une erreur de disque.

Brève description

Les erreurs de configuration suivantes dans le fichier fstab entraînent des erreurs de disque pour les instances Amazon EC2 créées à partir d'une AMI personnalisée :

  • ID de périphérique incorrect
  • Nom de chemin incorrect
  • UUID incorrect ou dupliqué

Pour corriger ces erreurs, vous devez accéder au système d'exploitation de l'instance. Si votre instance est inaccessible, utilisez l'une des méthodes suivantes pour y accéder :

  • EC2 Serial Console
  • Une instance de secours pour corriger manuellement les erreurs

Résolution

Utilisez EC2 Serial Console

Si vous avez activé EC2 Serial Console pour Linux, vous pouvez l'utiliser pour résoudre les problèmes des types d'instances basés sur Nitro pris en charge et les instances 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 à EC2 Serial Console, suivez les instructions de la section suivante Utiliser une instance de secours pour corriger manuellement les erreurs. Pour en savoir plus sur la configuration d'EC2 Serial Console, reportez-vous à Configurer l'accès à EC2 Serial Console.

Utilisez une instance de secours pour corriger manuellement les erreurs

Avertissement : La procédure suivante nécessite 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 section Ce qu’il se passe lorsque vous arrêtez une instance.

  1. Utilisez la même AMI que l'instance présentant des erreurs de disque pour lancer une nouvelle instance EC2 dans votre cloud privé virtuel (VPC). Lancez la nouvelle instance dans la même zone de disponibilité que l'instance défaillante. La nouvelle instance devient alors votre instance de secours.Vous pouvez également utiliser une instance existante qui utilise la même AMI et se trouve dans la même zone de disponibilité que votre instance défaillante.

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

  3. Détachez le volume racine 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. Attachez le volume en tant que périphérique secondaire (/dev/sdf) à l'instance de secours.

  5. Utilisez SSH pour vous connecter à votre instance de secours.

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

    $ sudo mkdir /rescue
  7. Montez le volume dans le répertoire :

    $ sudo mount /dev/xvdf1 /rescue

    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 les noms de périphériques appropriés, utilisez la commande lsblk pour afficher les périphériques de disque disponibles ainsi que leurs points de montage.

Puis, remédiez au problème du volume :
Exécutez la commande suivante pour vérifier l'entrée fstab :

$ cat /rescue/etc/fstab

L'exemple suivant d'entrée fstab comporte deux volumes :

UUID=47834bf7-764e-42f9-9507-11a3e70b99de / xfs defaults,noatime 1 1
UUID=1b75bcf4-ee55-428e-8d68-88dca398da01 /test xfs defaults,nofail 0 2

Dans l'entrée fstab, vérifiez les configurations suivantes :

  • L'entrée ne contient pas d'ID de périphériques. Des ID de périphériques incorrects entraînent des problèmes et des incohérences. Il est recommandé d'utiliser des UUID plutôt que des identifiants de périphériques. Si les ID de périphériques figurent dans le fichier, remplacez-les par l'UUID du volume. Exécutez la commande suivante pour trouver le bon UUID :

    lsblk -f
  • Assurez-vous que le chemin d'accès au point de montage est correct et qu'il existe dans le volume.

  • Vérifiez qu'il n'existe aucun UUID dupliqué. Vérifiez également que les volumes supplémentaires de l'instance défaillante n'utilisent pas les mêmes UUID. Pour vérifier les UUID des volumes supplémentaires, utilisez les étapes précédentes pour les associer à l'instance de secours. S'il existe des UUID dupliqués, vous ne pouvez pas monter de volumes. D'ailleurs, vous recevez un message d'erreur similaire au suivant :

    mount: /rescue: wrong fs type, bad option, bad superblock on /dev/xvdg1, missing codepage or helper program, or other error
  • Exécutez la commande suivante pour vérifier l'UUID des volumes associés :

    $ lsblk -f
  • S'il existe des UUID dupliqués, exécutez la commande suivante pour modifier les UUID :

  • Pour les systèmes de fichiers XFS :

    $ sudo xfs_admin -U <unique UUID> /dev/xvdb1
  • Pour les systèmes de fichiers EXT4 :

    $ tune2fs -U random /dev/sdb1
  • Ajoutez également l'option nofail à vos entrées fstab, comme dans l'exemple suivant :

    UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2
  • Remarque : Si vous démarrez votre instance sans que ce volume spécifique soit associé, l'option de montage nofail permet à l'instance de démarrer même en cas d'erreurs de montage. Par exemple, vous pouvez essayer de démarrer l'instance après avoir déplacé le volume vers une autre instance. Les dérivés de Debian, notamment les versions d'Ubuntu antérieures à 16.04, doivent également ajouter l'option de montage nobootwait.

Après avoir corrigé les erreurs, enregistrez le fichier, puis procédez comme suit :

  1. Exécutez la commande umount pour démonter le volume monté.

    $ sudo umount /rescue
  2. Détachez le volume de l’instance temporaire.

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

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an