Démarrage de la machine virtuelle Linux sur le sauvetage de GRUB

S’applique à : ✔️ Machines virtuelles Linux

Remarque

CentOS référencé dans cet article est une distribution Linux et atteint la fin de vie (EOL). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils sur la fin de vie centOS.

Cet article traite de plusieurs conditions pouvant causer des problèmes de sauvetage de GRUB et fournit des conseils de dépannage.

Au cours du processus de démarrage, le chargeur de démarrage tente de localiser le noyau Linux et lui transmet le contrôle du démarrage. Si ce transfert ne peut pas être effectué, la machine virtuelle entre dans une console Grub Rescue. L’invite de la console Grub Rescue ne sera pas affichée dans le journal de la console série Azure. Toutefois, elle apparaît dans la capture d’écran des diagnostics de démarrage Azure.

Identifier le problème de sauvetage de GRUB

Affichez une capture d’écran des diagnostics de démarrage dans la page Diagnostics de démarrage de la machine virtuelle dans le portail Azure. Cette capture d’écran permet de diagnostiquer le problème de Grub Rescue et de déterminer si une erreur de démarrage est à l’origine du problème.

Le texte suivant est un exemple de problème de Grube Rescue :

error: file '/boot/grub2/i386-pc/normal.mod' not found.  
Entering rescue mode...  
grub rescue>

Résoudre le problème de sauvetage de GRUB en mode hors ligne

1. Pour résoudre un problème de sauvetage de GRUB, une machine virtuelle de secours/réparation est nécessaire. À 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 une machine virtuelle de secours manuellement à 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. Identifier le problème de sauvetage de GRUB. Lorsque vous rencontrez l’un des problèmes de sauvetage de GRUB suivants, accédez à la section correspondante pour le résoudre :

   • Erreur : système de fichiers inconnu
   • Erreur 15 : fichier introuvable
   • Erreur : fichier « /boot/grub2/i386-pc/normal.mod » introuvable
   • Erreur : partition non définie
   • Erreur : le symbole « grub_efi_get_secure_boot » est introuvable
   • Autres erreurs de sauvetage de GRUB

3. Une fois que vous avez résolu le problème de sauvetage de GRUB, procédez comme suit :

   1. Démonter la copie des systèmes de fichiers de la machine virtuelle de secours/réparation.

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

   3. Vérifiez si la machine virtuelle peut démarrer. Pour ce faire, examinez la console série Azure ou essayez de vous connecter à la machine virtuelle.

4. Si l’intégralité /boot de la partition ou d’autres contenus importants sont manquants et ne peuvent pas être récupérés, nous vous recommandons de restaurer la machine virtuelle à partir d’une sauvegarde. Pour plus d’informations, consultez l’article Comment restaurer les données de la machine virtuelle Azure dans le portail Azure.

Consultez les sections suivantes pour plus d’informations sur les erreurs, les causes possibles et les solutions.

Remarque

Dans les commandes des sections suivantes, remplacez /dev/sdX par le périphérique de disque de système d’exploitation correspondant.

Réinstaller GRUB et régénérer le fichier de configuration GRUB à l’aide d’Azure Linux Auto Repair

Les scripts ALAR (Azure Linux Auto Repair) font partie de l’extension de réparation de machine virtuelle décrite dans Utiliser Azure Linux Auto Repair (ALAR) pour corriger une machine virtuelle Linux. ALAR couvre l’automatisation de plusieurs scénarios de réparation, y compris les problèmes de sauvetage GRUB.

Les scripts ALAR utilisent l’extension repair-button de réparation pour résoudre les problèmes GRUB en spécifiant --button-command grubfix pour les machines virtuelles de génération 1 ou --button-command efifix pour les machines virtuelles de génération 2. Ce paramètre déclenche la récupération automatisée. Implémentez les commandes suivantes pour automatiser la correction des erreurs GRUB courantes en réinstallant GRUB et en régénérant le fichier de configuration correspondant :

• Machines virtuelles Linux sans UEFI (BIOS basé sur Gen1) :

  az extension add -n vm-repair
  az extension update -n vm-repair
  az vm repair repair-button --button-command 'grubfix' --verbose $RGNAME --name $VMNAME
  

• Machines virtuelles Linux avec UEFI (Gen2) :

  az extension add -n vm-repair
  az extension update -n vm-repair
  az vm repair repair-button --button-command 'efifix' --verbose $RGNAME --name $VMNAME
  

Important

Remplacez le nom $RGNAME du groupe de ressources et le nom $VMNAME de la machine virtuelle en conséquence.

Le script de machine virtuelle de réparation, conjointement avec le script ALAR, crée temporairement un groupe de ressources, une machine virtuelle de réparation et une copie du disque du système d’exploitation de la machine virtuelle affectée. Il réinstalle GRUB, régénère le fichier de configuration GRUB correspondant, puis échange le disque du système d’exploitation de la machine virtuelle rompue avec le disque fixe copié. Enfin, le repair-button script supprime automatiquement le groupe de ressources contenant la machine virtuelle de réparation temporaire.

Réinstaller GRUB et régénérer manuellement le fichier de configuration GRUB

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Le cas échéant, suivez l’étape 1 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour la créer. Montez tous les systèmes de fichiers requis, y compris / et /boot dans la machine virtuelle de secours/réparation, puis entrez l’environnement chroot .

2. Réinstallez GRUB et régénérez le fichier de configuration GRUB correspondant en utilisant l’une des commandes suivantes :

   • RHEL/CentOS/Oracle 7.x/8.x/9.x Machines virtuelles Linux sans UEFI (BIOS basé sur Gen1)

     grub2-install /dev/sdX
     grub2-mkconfig -o /boot/grub2/grub.cfg
     sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
     

   • RHEL/CentOS/Oracle 7.x/8.x/9.x Machines virtuelles Linux avec UEFI (Gen2)

     yum reinstall grub2-efi-x64 shim-x64
     grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
     sed -i 's/hd2/hd0/g' /boot/efi/EFI/redhat/grub.cfg
     

     Si la machine virtuelle exécute CentOS, remplacez redhat par centos dans le fichier grub.cfg dont le chemin d’accès absolu est /boot/efi/EFI/centos/grub.cfg.

   • SLES 12/15 Gen1 et Gen2

     grub2-install /dev/sdX
     grub2-mkconfig -o /boot/grub2/grub.cfg
     sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
     

   • Ubuntu Gen1 et Gen2

     grub-install /dev/sdX
     update-grub
     

3. Passez à l’étape 3 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour échanger le disque de système d’exploitation.

Erreur : système de fichiers inconnu

La capture d’écran suivante affiche le message d’erreur :

Cette erreur peut être associée à l’un des problèmes suivants :

• /boot Corruption du système de fichiers.

  Pour résoudre ce problème, suivez les étapes décrites dans la section Corriger le système de fichiers de démarrage endommagé.

• Le chargeur de démarrage GRUB pointe vers un disque ou une partition non valide.

  Pour résoudre ce problème, réinstallez GRUB et régénérez le fichier de configuration GRUB manuellement.

• Problèmes de table de partition du disque de système d’exploitation en raison d’une erreur humaine.

  Pour résoudre ces problèmes, suivez les étapes décrites dans l’erreur : aucune partition de ce type pour recréer la /boot partition si elle est manquante ou créée de manière incorrecte.

Corriger le système de fichiers de démarrage endommagé

Pour corriger /boot l’altération du système de fichiers, procédez comme suit :

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Le cas échéant, suivez l’étape 1 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour la créer.

2. Reportez-vous à Résoudre les erreurs d’altération du système de fichiers dans Azure Linux pour résoudre les problèmes d’altération dans la partition correspondante /boot .

3. Passez à l’étape 3 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour échanger le disque de système d’exploitation.

Erreur 15 : Fichier introuvable

La capture d’écran suivante affiche le message d’erreur :

Pour résoudre ce problème, procédez comme suit :

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Le cas échéant, suivez l’étape 1 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour la créer. Montez tous les systèmes de fichiers requis, y compris / et /boot dans la machine virtuelle de secours/réparation, puis entrez l’environnement chroot .

2. Inspectez le contenu du /boot système de fichiers et déterminez les éléments manquants.

3. Si le fichier de configuration GRUB est manquant, réinstallez GRUB et régénérez le fichier de configuration GRUB manuellement.

4. Vérifiez que les autorisations de fichier dans le système de /boot fichiers sont OK. Vous pouvez comparer les autorisations en utilisant une autre machine virtuelle exécutant la même version de Linux.

5. Si la partition entière/de démarrage ou d’autres contenus importants sont manquants et ne peuvent être récupérés, il est recommandé de restaurer la machine virtuelle à partir d’une sauvegarde. Pour plus d’informations, consultez l’article Comment restaurer les données de la machine virtuelle Azure dans le portail Azure.

6. Une fois le problème résolu, passez à l’étape 3 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour échanger le disque du système d’exploitation.

Erreur : fichier « /boot/grub2/i386-pc/normal.mod » introuvable

La capture d’écran suivante affiche le message d’erreur :

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Si ce n’est pas le cas, suivez l’étape 1 dans Résoudre le problème de Grub Rescue en mode hors ligne pour en créer une. Montez tous les systèmes de fichiers requis, y compris / et /boot dans la machine virtuelle de secours/réparation, puis entrez l’environnement chroot .

2. Si vous ne parvenez pas à monter le /boot système de fichiers en raison d’une erreur d’altération, corrigez la corruption du système de fichiers /boot.

3. Lorsque vous êtes situé à l’intérieur de chroot, vérifiez le contenu dans le /boot/grub2/i386-pc répertoire. Si le contenu est manquant, copiez le contenu à partir de /usr/lib/grub/i386-pc. Pour ce faire, utilisez les commandes suivantes :

   ls -l /boot/grub2/i386-pc
   cp -rp /usr/lib/grub/i386-pc /boot/grub2
   

4. Si le contenu de la /boot partition est vide, utilisez les commandes suivantes pour la recréer :

   Remarque

   Les étapes suivantes s’appliquent aux machines virtuelles RHEL/CentOS/Oracle 7.x/8.x Linux sans UEFI (BIOS basé sur Gen1).

   1. Sous le processus chroot, réinstallez le grub. Remplacez /dev/sd[X] en conséquence par la copie correspondante du disque du système d’exploitation attaché à la machine virtuelle de réparation/sauvetage :

      grub2-install /dev/sd[X]
      

   2. Vérifiez qu’une /etc/resolv.conf entrée DNS valide est présente pour résoudre le nom du référentiel :

      cat /etc/resolv.conf
      

   3. Réinstallez le noyau :

      yum reinstall $(rpm -qa | grep -i kernel)
      

   4. Créer le fichier grub.cfg :

      grub2-mkconfig -o /boot/grub2/grub.cfg
      sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
      

5. Passez à l’étape 3 de la section Résoudre le problème de sauvetage de GRUB en mode hors ligne pour échanger le disque de système d’exploitation.

Erreur : partition non définie

La capture d’écran suivante affiche le message d’erreur :

Cette erreur se produira avec une machine virtuelle basée sur RHEL (Red Hat, Oracle Linux, CentOS) dans l’un des scénarios suivants :

• La /boot partition est supprimée par erreur.
• La /boot partition est recréée à l’aide des secteurs de début et de fin incorrects.

Solution : recréer la partition /boot

Si la /boot partition est manquante, recréez-la en procédant comme suit :

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Le cas échéant, suivez l’étape 1 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour la créer.

2. Identifiez si la table de partition est créée en tant que type dos ou GPT en utilisant la commande suivante :

   sudo fdisk -l /dev/sdX
   

   • Table de partition dos

     

   • Table de partition GPT

     

3. Si la table de partition est de type DOS, recréez la partition /boot dans les systèmes DOS. Si la table de partition est de type GPT, recréez la partition /boot dans les systèmes GPT.

4. Assurez-vous que le chargeur de démarrage GRUB est installé en utilisant le disque approprié. Vous pouvez suivre les étapes décrites dans Réinstaller GRUB et régénérer manuellement le fichier de configuration GRUB pour l’installer et le configurer.

5. Passez à l’étape 3 de la section Résoudre le problème de sauvetage de GRUB en mode hors ligne pour échanger le disque de système d’exploitation.

Recréer la partition /boot dans les systèmes DOS

1. Recréez la /boot partition à partir d’une machine virtuelle de secours/réparation à l’aide de la commande suivante :

   sudo fdisk /dev/sdX
   

   Utilisez les valeurs par défaut dans le Premier et le Dernier secteur, ainsi que le type de partition (83). Vérifiez que la /boot table de partitions est marquée comme pouvant être démarrée à l’aide de l’option a dans l’outil fdisk , comme indiqué dans la sortie suivante :

   sudo fdisk /dev/sdc
   
   The device presents a logical sector size that is smaller than
   the physical sector size. Aligning to a physical sector (or optimal
   I/O) size boundary is recommended, or performance may be impacted.
   Welcome to fdisk (util-linux 2.23.2).
   
   Changes will remain in memory only, until you decide to write them.
   Be careful before using the write command.
   
   Command (m for help): n
   Partition type:
      p   primary (1 primary, 0 extended, 3 free)
      e   extended
   Select (default p): p
   Partition number (1,3,4, default 1): 1
   First sector (2048-134217727, default 2048):
   Using default value 2048
   Last sector, +sectors or +size{K,M,G} (2048-2099199, default 2099199):
   Using default value 2099199
   Partition 1 of type Linux and of size 1 GiB is set
   
   Command (m for help): t
   Partition number (1,2, default 2): 1
   Hex code (type L to list all codes): 83
   Changed type of partition 'Linux' to 'Linux'
   
   Command (m for help): a
   Partition number (1,2, default 2): 1
   
   Command (m for help): p
   
   Disk /dev/sdc: 68.7 GB, 68719476736 bytes, 134217728 sectors
   Units = sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 4096 bytes
   I/O size (minimum/optimal): 4096 bytes / 4096 bytes
   Disk label type: dos
   Disk identifier: 0x000b7179
   
   Device Boot      Start         End      Blocks   Id  System
   /dev/sdc1   *        2048     2099199     1048576   83  Linux
   /dev/sdc2         2099200   134217727    66059264   8e  Linux LVM
   
   Command (m for help): w
   The partition table has been altered!
   
   Calling ioctl() to re-read partition table.
   

2. Après avoir recréé la partition manquante /boot , vérifiez si le /boot système de fichiers est détecté. Normalement, une entrée s’affiche pour /dev/sdX1 (la partition /boot manquante).

   sudo blkid /dev/sdX1
   

   sudo blkid /dev/sdc1
   /dev/sdc1: UUID="<UUID>" TYPE="ext4"
   

3. Si le /boot système de fichiers n’est pas visible après blkid avoir recréé la partition, cela signifie que les /boot données n’existent plus. Vous devez recréer le /boot système de fichiers (en utilisant le même format UUID et le même format de système de fichiers que celui de l’entrée /etc/fstab/boot ), puis restaurer son contenu à partir d’une sauvegarde.

Recréer la partition /boot dans les systèmes GPT

1. Recréez la /boot partition à partir d’une machine virtuelle de secours/réparation à l’aide de la commande suivante :

   sudo gdisk /dev/sdX
   

   Utilisez les valeurs par défaut dans le Premier et le Dernier secteur, ainsi que le type de partition (8300), comme illustré dans la sortie suivante :

   sudo gdisk /dev/sdc
   GPT fdisk (gdisk) version 1.0.3
   
   Partition table scan:
     MBR: protective
     BSD: not present
     APM: not present
     GPT: present
   
   Found valid GPT with protective MBR; using GPT.
   
   Command (? for help): n
   Partition number (1-128, default 1): 1
   First sector (34-134217694, default = 1026048) or {+-}size{KMGTP}:
   Last sector (1026048-2050047, default = 2050047) or {+-}size{KMGTP}:
   Current type is 'Linux filesystem'
   Hex code or GUID (L to show codes, Enter = 8300):
   Changed type of partition to 'Linux filesystem'
   
   Command (? for help): p
   Disk /dev/sdc: 134217728 sectors, 64.0 GiB
   Model: Virtual Disk
   Sector size (logical/physical): 512/4096 bytes
   Disk identifier (GUID): 6D915856-445A-4513-97E4-C55F2E1AD6C0
   Partition table holds up to 128 entries
   Main partition table begins at sector 2 and ends at sector 33
   First usable sector is 34, last usable sector is 134217694
   Partitions will be aligned on 2048-sector boundaries
   Total free space is 6076 sectors (3.0 MiB)
   
   Number  Start (sector)    End (sector)  Size       Code  Name
      1         1026048         2050047   500.0 MiB   8300  Linux filesystem
      2         2050048       134215679   63.0 GiB    8E00
     14            2048           10239   4.0 MiB     EF02
     15           10240         1024000   495.0 MiB   EF00  EFI System Partition
   
   Command (? for help): w
   
   Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
   PARTITIONS!!
   
   Do you want to proceed? (Y/N): Y
   OK; writing new GUID partition table (GPT) to /dev/sdc.
   Warning: The kernel is still using the old partition table.
   The new table will be used at the next reboot or after you
   run partprobe(8) or kpartx(8)
   The operation has completed successfully.
   

2. Vérifiez si le /boot système de fichiers est détecté par le système à l’aide de la commande suivante :

   sudo blkid /dev/sdX1
   

   Vous devez être en mesure de voir une entrée pour /dev/sdX1 (la partition manquante /boot ).

   sudo blkid /dev/sdc1
   /dev/sdc1: UUID="<UUID>" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="<PARTUUID>"
   

3. Si le /boot système de fichiers n’est pas visible après avoir recréé la partition, cela signifie que les /boot données n’existent plus. Vous devez recréer le /boot système de fichiers (en utilisant le même UUID que dans l’entrée /etc/fstab/boot ), puis restaurer son contenu à partir d’une sauvegarde.

Erreur : le symbole « grub_efi_get_secure_boot » est introuvable

La capture d’écran suivante affiche le message d’erreur :

La version 4.12.14 du noyau Linux (utilisée dans SLES 12 SP5) ne prend pas en charge l’option démarrage sécurisé. Par conséquent, si le démarrage sécurisé est activé pendant le déploiement de la machine virtuelle (autrement dit, le champ Type de sécurité est défini sur Machines virtuelles de lancement approuvées), la machine virtuelle génère l’erreur de démarrage sécurisé via la console lorsque vous essayez de commencer par utiliser cette version du noyau SUSE sur une image de machine virtuelle Gen2.

Solution

Pour résoudre cette erreur de démarrage, procédez comme suit :

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Le cas échéant, suivez l’étape 1 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour la créer. Montez tous les systèmes de fichiers requis, y compris / et /boot, puis entrez l’environnement chroot .

2. Exécutez la commande YaST suivante dans l’environnement chroot :

   yast2 bootloader
   

3. Décochez le « x » de l’option Activer la prise en charge du démarrage sécurisé, puis sélectionnez F10 pour enregistrer la modification.

   

4. Passez à l’étape 3 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour échanger le disque de système d’exploitation.

Autres erreurs de sauvetage GRUB

La capture d’écran suivante affiche le message d’erreur :

Ce type d’erreur se déclenche dans l’un des scénarios suivants :

• Le fichier de configuration GRUB est manquant.
• Une configuration incorrecte de GRUB est utilisée.
• La /boot partition ou son contenu sont manquants.

Pour résoudre cette erreur, procédez comme suit :

1. Vérifiez si une machine virtuelle de secours/réparation a été créée. Le cas échéant, suivez l’étape 1 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour la créer. Montez tous les systèmes de fichiers requis, y compris / et /boot, puis entrez l’environnement chroot .

2. Vérifiez que le /etc/default/grub fichier de configuration est configuré. Les images Azure Linux approuvées disposent déjà des configurations requises. Si vous souhaitez en savoir plus, consultez les articles suivants :

   • Accès au GRUB dans RHEL
   • Accès au GRUB dans CentOS
   • Accès au GRUB dans Ubuntu
   • Accès au GRUB dans SUSE SLES
   • Accès au GRUB dans Oracle Linux

3. Réinstallez GRUB et régénérez le fichier de configuration GRUB manuellement.

   Remarque

   Si le fichier manquant est /boot/grub/menu.lst, cette erreur concerne les versions antérieures du système d’exploitation (RHEL 6.x, Centos 6.x et Ubuntu 14.04). La version 1 de GRUB étant utilisée dans ces systèmes, les commandes sont différentes. Cet article ne traite pas de la version 1 de GRUB.

4. Si la partition entière /boot est manquante, suivez les étapes décrites dans Erreur : aucune partition de ce type.

5. Une fois le problème résolu, passez à l’étape 3 de la section Résoudre le problème de Grub Rescue en mode hors ligne pour échanger le disque du système d’exploitation.

Prochaines étapes

Si l’erreur particulière de démarrage ne consiste pas en un problème de sauvetage de GRUB, reportez-vous à l’article Résoudre les erreurs de démarrage des machines virtuelles Azure Linux pour obtenir plus d’options de dépannage.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

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.