Partager via


Résoudre les échecs de démarrage UEFI dans les machines virtuelles Linux Azure

S’applique à : ✔️ Machines virtuelles Linux

Note

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.

Les images partenaires Linux dans Place de marché Azure sont étiquetées et configurées pour le démarrage bios 1 et le démarrage UEFI (Unified Extensible Firmware Interface) de génération 2.

Lorsque vous déployez des machines virtuelles Linux de génération 2 dans Azure, vous pouvez rencontrer des échecs de démarrage UEFI. Cet article décrit certains scénarios où des échecs de démarrage UEFI se produisent et fournissent des solutions.

Symptômes

Lorsque vous déployez une machine virtuelle Linux de génération 2 dans Azure, le démarrage échoue et le serveur est inaccessible.

Identifier les erreurs de démarrage UEFI

Vérifiez l’état actuel de votre machine virtuelle à l’aide des diagnostics de démarrage Azure.

La capture d’écran des diagnostics de démarrage montre les messages d’erreur suivants :

  • Erreur 1

    Résumé du démarrage des machines virtuelles

    1. Appareil inconnu
      Le chargeur de démarrage n’a pas chargé un système d’exploitation.
    2. Disque SCSI (0,0)
      Le chargeur de démarrage n’a pas chargé un système d’exploitation.
    3. Disque SCSI (0,1)
      Le chargeur de démarrage n’a pas chargé un système d’exploitation.
    4. Carte réseau (000D3A4D64D)
      Image de démarrage introuvable.

    Aucun système d’exploitation n’a été chargé. Votre machine virtuelle peut être configurée de manière incorrecte. Quittez et reconfigurez votre machine virtuelle ou cliquez sur Redémarrer pour réessayer la séquence de démarrage actuelle.

    Capture d’écran du message d’erreur Hyper-V pour l’image de démarrage UEFI manquante.

  • Erreur 2

    Démarrer PXE sur IPv4

    Capture d’écran de la transition de l’erreur Hyper-V vers le problème de démarrage PXE.

Avant de résoudre le problème

Pour effectuer la réparation de machine virtuelle hors connexion requise pour le scénario 1 : la partition UEFI dans l’image de démarrage est manquante et le scénario 2 : la partition UEFI dans l’image de démarrage est endommagée, vérifiez que vous avez accès à Azure CLI ou à Azure Cloud Shell.

Scénario 1 : la partition UEFI dans l’image de démarrage est manquante

Si la partition du chargeur de démarrage UEFI est manquante ou supprimée, la machine virtuelle Linux de génération 2 échoue au démarrage.

Pour résoudre ce problème, effectuez les étapes suivantes :

  1. Utilisez la commande az vm repair create pour créer une machine virtuelle de réparation. La machine virtuelle de réparation aura une copie du disque du système d’exploitation pour la machine virtuelle non fonctionnelle attachée. Pour plus d’informations, consultez Réparer une machine virtuelle Linux à l’aide des commandes de réparation de machine virtuelle Azure.

  2. Recréez la partition à l’aide des commandes suivantes :

    root@repair-centos7:~# 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): p
    Disk /dev/sdc: 134217728 sectors, 64.0 GiB
    Model: Virtual Disk    
    Sector size (logical/physical): 512/4096 bytes
    Disk identifier (GUID): <Disk GUID>
    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 1019837 sectors (498.0 MiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1         1026048         3123199   1024.0 MiB  0700  
       2         3123200       134215679   62.5 GiB    8E00  
      14            2048           10239   4.0 MiB     EF02  
    
    Command (? for help): n
    Partition number (3-128, default 3): 
    First sector (34-134217694, default = 10240) or {+-}size{KMGTP}: 10240
    Last sector (10240-1026047, default = 1026047) or {+-}size{KMGTP}: 1026047
    Current type is 'Linux filesystem'
    Hex code or GUID (L to show codes, Enter = 8300): ef00
    Changed type of partition to 'EFI System'
    
    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): <Disk GUID>
    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 4029 sectors (2.0 MiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1         1026048         3123199   1024.0 MiB  0700  
       2         3123200       134215679   62.5 GiB    8E00  
       3           10240         1026047   496.0 MiB   EF00  EFI System
      14            2048           10239   4.0 MiB     EF02  
    
    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.
    

    Important

    • Remplacez /dev/sdc par la copie correspondante de l’appareil de disque du système d’exploitation.
    • Le choix du numéro de partition n’a pas d’importance tant que les points de début et de fin du secteur sont corrects. Les points de début et de fin de secteur appropriés sont choisis, car le système d’exploitation est en mesure de déterminer les secteurs manquants.
    • Vérifiez que le secteur de fin n’est occupé par aucune autre partition au sein du disque. Le choix des valeurs par défaut doit suffire ici.

    Les images partenaires Linux Azure ont le numéro de partition, les points de départ du secteur et les points de terminaison de secteur suivants :

    Distribution du système d’exploitation Linux Numéro de partition EFI Début du secteur Fin du secteur
    CentOS 7 15 10240 1024000
    CentOS 8 15 10240 1024000
    Debian 10 15 8192 262143
    Debian 11 15 8192 262143
    RHEL 7 1 2 048 1026047
    RHEL 8 15 10240 1024000
    Oracle Linux 7 15 10240 1024000
    Oracle Linux 8 15 10240 1024000
    Ubuntu 18.04 15 10240 227327
    Ubuntu 20.04 15 10240 227327
    SLES 12 2 6144 1054719
    SLES 15 2 6144 1054719
  3. Une fois la partition recréée, restaurez la machine virtuelle en échangeant le disque du système d’exploitation réparé par le disque du système d’exploitation d’origine de la machine virtuelle à l’aide de la commande az vm repair restore . Pour plus d’informations, consultez l’étape 5 de la réparation d’une machine virtuelle Linux à l’aide des commandes de réparation de machine virtuelle Azure.

Scénario 2 : La partition UEFI dans l’image de démarrage est endommagée

Si la partition de démarrage UEFI est endommagée, la machine virtuelle Linux de génération 2 ne démarre pas. Pour résoudre ce problème, effectuez les étapes suivantes :

  1. Utilisez la commande az vm repair create pour créer une machine virtuelle de réparation. La machine virtuelle de réparation aura une copie du disque du système d’exploitation pour la machine virtuelle non fonctionnelle attachée. Pour plus d’informations, consultez Réparer une machine virtuelle Linux à l’aide des commandes de réparation de machine virtuelle Azure.

  2. Nettoyez la partition endommagée à l’aide des commandes suivantes :

    root@repair-centos7:~# gdisk -l /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.
    Disk /dev/sdc: 134217728 sectors, 64.0 GiB
    Model: Virtual Disk    
    Sector size (logical/physical): 512/4096 bytes
    Disk identifier (GUID): <Disk GUID>
    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 4029 sectors (2.0 MiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1         1026048         3123199   1024.0 MiB  0700  
       2         3123200       134215679   62.5 GiB    8E00  
       3           10240         1026047   496.0 MiB   EF00  EFI System
      14            2048           10239   4.0 MiB     EF02 
    
    root@repair-centos7:~# fsck.vfat -n /dev/sdc3
    fsck.fat 4.1 (2017-01-24)
    0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
     Automatically removing dirty bit.
    Leaving filesystem unchanged.
    /dev/sdc3: 19 files, 1438/63326 clusters
    
    root@repair-centos7:~# fsck.vfat /dev/sdc3
    fsck.fat 4.1 (2017-01-24)
    0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
    1) Remove dirty bit
    2) No action
    ? 1
    Perform changes ? (y/n) y
    /dev/sdc3: 19 files, 1438/63326 clusters
    root@repair-centos7:~# fsck.vfat /dev/sdc3
    fsck.fat 4.1 (2017-01-24)
    /dev/sdc3: 19 files, 1438/63326 clusters
    

    Important

    • Remplacez /dev/sdc par la copie correspondante de l’appareil de disque du système d’exploitation.
    • Effectuez toujours une sauvegarde du disque du système d’exploitation et effectuez une exécution sèche avec l’option avant d’effectuer -n la vérification du système de fichiers mentionnée ci-dessus.
    • La dosfsck commande peut être utilisée pour effectuer la vérification du système de fichiers vfat. Les deux commandes sont identiques. Pour plus d’informations, consultez fsck.vfat.
  3. Une fois la partition nettoyée, restaurez la machine virtuelle en échangeant le disque du système d’exploitation réparé par le disque du système d’exploitation d’origine de la machine virtuelle à l’aide de la commande az vm repair restore . Pour plus d’informations, consultez l’étape 5 de la réparation d’une machine virtuelle Linux à l’aide des commandes de réparation de machine virtuelle Azure.

Scénario 3 : Tout le contenu de la partition /boot est supprimé

Si l’intégralité de la partition /boot ou d’autres contenus importants sont manquants et ne peuvent pas être récupérés, la restauration de la machine virtuelle à partir d’une sauvegarde est la seule option. Pour plus d’informations, consultez Comment restaurer des données de machine virtuelle Azure dans Portail Azure.

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.