Share via

La machine virtuelle Linux Azure ne parvient pas à démarrer et entre dans l’interpréteur de commandes d’urgence dracut

  • Article

Remarque

CentOS référencé dans cet article est une distribution Linux qui atteint la fin de vie (EOL). Tenez compte de votre utilisation et planifiez en conséquence. Pour plus d’informations, consultez Guide sur la fin de vie de CentOS.

Cet article fournit des solutions à un problème dans lequel une machine virtuelle Linux Azure ne peut pas démarrer, car le système de fichiers du système d’exploitation n’est pas accessible à partir du disque RAMdisk. La machine virtuelle atterrit dans l’interpréteur de commandes d’urgence dracut.

Conditions préalables

Assurez-vous que la console série est activée et fonctionnelle sur la machine virtuelle Linux.

Comment identifier le problème de démarrage dracut

Pour identifier un problème de démarrage dracut, utilisez le Portail Azure pour afficher la sortie du journal de la console série de la machine virtuelle dans le volet diagnostics de démarrage, le volet de la console série, ou utilisez l’interface CLI AZ.

Toutes les machines virtuelles avec le problème de démarrage atterriront dans l’interpréteur de commandes d’urgence dracut ou initramfs et s’afficheront à la fin du journal de la console série :

  • RHEL/CentOS/SLES/Oracle Linux :

    [  201.935612] dracut-initqueue[455]: Warning: dracut-initqueue timeout - starting timeout scripts
[  201.941153] dracut-initqueue[455]: Warning: Could not boot.
         Starting Setup Virtual Console...
[[0;32m  OK  [0m] Started Setup Virtual Console.
         Starting Dracut Emergency Shell...
Warning: /dev/mapper/rootvg-rootlv does not exist

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


dracut:/#

  • Ubuntu:

    mdadm: No arrays found in config file or automatically
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/osencrypt does not exist.  Dropping to a shell!


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Résolution des problèmes en ligne

Conseil

Si vous avez une sauvegarde récente de la machine virtuelle, restaurez la machine virtuelle à partir de la sauvegarde pour résoudre le problème de démarrage.

La console série est la méthode la plus rapide pour résoudre les problèmes. Il vous permet de résoudre directement le problème sans avoir à présenter le disque système à une machine virtuelle de récupération. Vérifiez que vous remplissez les conditions préalables nécessaires pour votre distribution. Pour plus d’informations, consultez Console série de machine virtuelle pour Linux.

  1. Identifiez si votre machine virtuelle atterrit dans l’interpréteur de commandes d’urgence.

  2. Essayez de résoudre le problème à l’aide de la console série Azure.

    Remarque

    Tous les problèmes ne peuvent pas être résolus à l’aide de la console série Azure.

    1. Déclenchez Redémarrer la machine virtuelle (en dur) à partir de la console série.
    2. Interrompez votre machine virtuelle dans le menu GRUB avec la touche Échap .
    3. Sélectionnez E pour modifier la première entrée du noyau dans le menu GRUB.
    4. Accédez à la linux16 ligne, puis validez et corrigez la configuration incorrecte du GRUB comme suit :

  3. Après avoir modifié manuellement les paramètres grub, sélectionnez Ctrl+X pour démarrer la machine virtuelle.

    Toute modification effectuée à ce stade est une modification non persistante. Si la machine virtuelle est en mesure de démarrer, résolvez ce problème dans le fichier de configuration GRUB, sinon il se reproduit.

  4. Une fois que la machine virtuelle est de nouveau en ligne, corrigez les problèmes de configuration dans le /etc/default/grub fichier de configuration et mettez à jour la configuration grub. Pour ce faire, consultez Réinstaller GRUB et régénérer le fichier de configuration GRUB.

  5. Redémarrez la machine virtuelle pour vous assurer qu’elle peut démarrer sans intervention manuelle.

Résolution des problèmes hors connexion

Conseil

Si vous avez une sauvegarde récente de la machine virtuelle, restaurez la machine virtuelle à partir de la sauvegarde pour résoudre le problème de démarrage.

  1. Si la console série Azure ne fonctionne pas sur la machine virtuelle spécifique ou n’est pas une option dans votre abonnement, résolvez ce problème à l’aide d’une machine virtuelle de secours/réparation. À l’aide des commandes de réparation de machine virtuelle, créez une machine virtuelle de réparation à laquelle est connectée une copie du disque de système d’exploitation de la machine virtuelle affectée. Montez la copie des systèmes de fichiers du système d’exploitation dans la machine virtuelle de réparation à l’aide de chroot.

    Remarque

    Vous pouvez également créer manuellement une machine virtuelle de secours à l’aide du portail Azure. Pour en savoir plus, consultez l’article Résoudre les problèmes d’une machine virtuelle Linux en connectant le disque du système d’exploitation à une machine virtuelle de récupération à l’aide du portail Azure.

  2. Accédez aux sections suivantes pour résoudre des problèmes spécifiques :

  3. Une fois le problème de démarrage lié à dracut/initramfs résolu, effectuez les actions suivantes :

    1. Quittez chroot.
    2. Démonter la copie des systèmes de fichiers de la machine virtuelle de secours/réparation.
    3. Exécutez la commande az vm repair restore pour remplacer le disque de système d’exploitation réparé par le disque de système d’exploitation d’origine de la machine virtuelle. Pour plus d’informations, consultez l’étape 5 Réparer une machine virtuelle Linux à l’aide des commandes de réparation de machine virtuelle Azure.
    4. Vérifiez si la machine virtuelle peut démarrer. Pour ce faire, examinez la Serial console Azure ou essayez de vous connecter à la machine virtuelle.

Échec du démarrage de la machine virtuelle chiffrée ADE, car VFAT est désactivé

Pour plus d’informations, consultez Échec du démarrage des machines virtuelles chiffrées ADE.

Pilotes Hyper-V manquants

Si les pilotes Hyper-V inclus dans le noyau Linux de toutes les distributions Linux modernes sont désactivés, réactivez-les et régénérez l’image initramfs/initrd. Pour plus d’informations, consultez Scénario 3 : Les autres pilotes Hyper-V sont désactivés.

Si la machine virtuelle est Red Hat et qu’elle est migrée à partir d’un emplacement local, activez les pilotes Hyper-V requis dans l’image initramfs. Pour plus d’informations, consultez Le pilote Hyper-V n’a pas pu être inclus dans le disque RAM initial lors de l’utilisation d’un hyperviseur non Hyper-V.

Configuration incorrecte de GRUB

Le rd.break paramètre force la machine virtuelle à démarrer dans l’interpréteur de commandes d’urgence. Vérifiez que ce paramètre n’est pas codé en dur dans le fichier de configuration GRUB.

Chemin d’accès de l’appareil racine incorrect dans le fichier de configuration GRUB

Vérifiez si le chemin d’accès root=/dev/*** racine dans le fichier de configuration GRUB est correct. Vérifiez que le chemin d’accès de l’appareil approprié est utilisé.

Pendant cette validation, vérifiez les points suivants :

  • Dans les machines virtuelles Ubuntu avec chiffrement du système d’exploitation, vérifiez que le nom de l’appareil est /dev/mapper/osencrypt.
  • Sur les machines virtuelles avec le gestionnaire de volumes logiques (LVM) sur le disque du système d’exploitation, le volume racine est /dev/mapper/rootvg-rootlv. Le même chemin est utilisé dans les machines virtuelles RHEL avec un disque de système d’exploitation ADE chiffré.
  • Assurez-vous qu’aucun nom d’appareil sous la forme de /dev/sdX n’est utilisé, car ils changeront entre les redémarrages et ne sont pas persistants dans Linux. Pour plus d’informations, consultez Résoudre les problèmes liés aux modifications de nom d’appareil de machine virtuelle Linux.
  • Si des UUID sont utilisés, vérifiez que l’UUID du système de fichiers racine approprié est utilisé et que la syntaxe est root=UUID=xxx-yyy-zzz.

Chemin d’accès de l’appareil d’échange incorrect dans le fichier de configuration GRUB

Dans ce scénario, une machine virtuelle ne parvient pas à terminer le processus de démarrage et entre dans l’interpréteur de commandes d’urgence dracut avec une erreur similaire à la suivante :

[  188.000765] dracut-initqueue[324]: Warning: /dev/VG/SwapVol does not exist
         Starting Dracut Emergency Shell...
Warning: /dev/VG/SwapVol does not exist

Le fichier de configuration GRUB dans cet exemple est défini pour charger un volume logique (LV) comme échange avec le paramètre rd.lvm.lv=VG/SwapVol. Toutefois, la machine virtuelle ne parvient pas à localiser cette machine virtuelle pendant le processus de démarrage.

Il est important de noter que l’utilisation d’un appareil d’échange de cette façon dans les machines virtuelles Linux Azure n’est pas recommandée. Pour plus d’informations, consultez Créer un fichier SWAP pour une machine virtuelle Linux Azure.

Pour résoudre ce problème, recherchez le chemin d’échange rd.lvm.lv=VG/SwapVol dans le fichier de configuration GRUB (/etc/default/grub) et supprimez-le. Pour ce faire, utilisez l’une des méthodes suivantes :

Paramètres dupliqués dans le fichier de configuration GRUB

Vérifiez s’il existe des paramètres dupliqués dans le fichier de configuration GRUB :

Endommagement du système de fichiers racine

Lorsque le système de fichiers racine est endommagé, il ne peut pas être monté à partir de l’image initrd/initramfs.

Pour corriger l’endommagement du système de fichiers racine, suivez les instructions fournies dans Résoudre les problèmes de démarrage de machine virtuelle Linux en raison d’erreurs de système de fichiers - Effectuer une réparation du système de fichiers.

Problèmes liés à l’activation LVM

Certains problèmes peuvent se produire lorsque vous accédez au volume physique (PV) LVM, au groupe de volumes (VG) et/ou au volume logique (LV). Ils ne peuvent pas être traités à partir de la console série Azure. Pour les résoudre, utilisez une machine virtuelle de réparation/sauvetage.

  1. Suivez l’étape 1 dans Résolution des problèmes hors connexion.

  2. Pour identifier les problèmes, exécutez les commandes suivantes et examinez les sorties de commande.

    1. Identifiez quel appareil correspond au disque du système d’exploitation et vérifiez s’il est détecté en tant que pv :

      lsblk
pvs

    2. Vérifiez si le rootvg VG est détecté :

      vgs

    3. Vérifiez si la LV est détectée :

      lvs

  3. Résolvez les erreurs LVM courantes suivantes qui provoquent des problèmes d’accès au volume racine :

    • Pv inconnu lorsque la VG rootvg n’a qu’un seul PV (il s’agit de la configuration Azure standard)

      La partition contenant le pv est supprimée, redimensionnée ou créée de manière incorrecte. Pour résoudre ce problème, consultez Partition racine manquante.

    • Pv inconnu lorsque la VG rootvg est modifiée et fractionnée sur plusieurs disques

      Il n’est pas recommandé d’avoir 2 pv dans le groupe de disponibilité virtuel rootvg. Dans ce scénario, le disque de données peut être détaché de la machine virtuelle et les volumes logiques rootvg ne sont plus accessibles. Pour résoudre ce problème, rattachez le disque d’origine à la machine virtuelle et redémarrez-le.

  4. Si le pv est irrécupérable, effectuez une restauration à partir de la sauvegarde.

La partition racine est manquante

Le système de fichiers racine peut être inaccessible en raison de certains problèmes qui se produisent au niveau de la partition pendant les opérations de redimensionnement de partition ou d’autres.

Dans ce scénario, si vous avez documenté la disposition de la table de partition d’origine, avec les secteurs de début et de fin exacts pour chacune des partitions d’origine (et qu’aucune autre modification n’est effectuée sur le système, comme la création de nouveaux systèmes de fichiers), recréez les partitions à l’aide de la même disposition d’origine. Vous pouvez le faire avec des outils tels que fdisk (pour les tables de partition MBR) ou gdisk (pour les tables de partition GPT) pour accéder au système de fichiers inaccessible. Suivez cette opération de récupération à partir d’une machine virtuelle de réparation/sauvetage. Pour plus d’informations, consultez la section Résolution des problèmes hors connexion .

Si cette approche ne fonctionne pas, nous vous recommandons d’effectuer une restauration à partir d’une sauvegarde.

Initrd ou initramfs corruption

L’image initrd/initramfs présente un certain niveau d’altération, ce qui entraîne l’échec du montage du volume racine et du démarrage du processus de démarrage du système d’exploitation.

Pour résoudre ce problème, procédez comme suit à partir de chroot dans une machine virtuelle de réparation/sauvetage :

  1. Suivez l’étape 1 dans Résolution des problèmes hors connexion.
  2. Régénérez manuellement les initramfs manquants.
  3. Redémarrez la machine virtuelle pour vérifier si elle est en mesure de démarrer.

Étapes suivantes

Si l’erreur de démarrage spécifique n’est pas un problème dracut ou initramfs, consultez Résoudre les erreurs de démarrage d’Azure Linux Machines Virtuelles pour obtenir d’autres options de résolution des problèmes.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.