VM Debian UEFI qui ne boote plus après Move, diagnostic et prévention

Après une migration inter-clusters avec Nutanix Move, plusieurs VM Debian 12 en UEFI s’arrêtent sur « Unable to find a valid boot device » alors que leur disque est intact. Le diagnostic tient en trois commandes au shell EFI, et un grub-install --removable passé avant la migration évite d’y revenir VM par VM.

Le symptôme

Écran de boot AHV, puis le message ci-dessus. Le disque et la partition EFI sont là ; c’est le firmware qui ne sait plus quel chargeur lancer.

Ce que dit Nutanix, ce qu’on a constaté

Côté éditeur, un post de la communauté Nutanix annonce le support des VM UEFI à partir de Move 3.3.0 (prérequis : AOS 5.11 ou plus, VM UEFI compatible AHV). Il ne parle ni de NVRAM ni d’entrées de boot.

Côté terrain, la cause constatée est que les entrées de boot UEFI stockées en NVRAM ne suivent pas la migration. C’est une observation, pas un comportement documenté : aucune page Nutanix trouvée ne décrit cette perte.

Diagnostic au shell EFI

Au boot de la VM, F2 ou Échap pour ouvrir le menu du firmware, puis le shell EFI :

FS0:
ls EFI
\EFI\debian\grubx64.efi

Si la VM démarre en lançant le chargeur à la main, la perte des entrées NVRAM est confirmée.

Si ls EFI est vide, c’est un autre problème : l’OS a été installé en BIOS legacy et la VM est configurée en UEFI à tort. VM éteinte, ce réglage est réversible :

acli vm.update <VM> uefi_boot=false

Le correctif durable

Une fois la VM démarrée, on recrée l’entrée NVRAM, puis on installe aussi le chargeur au chemin de repli :

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian && update-grub
grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable

La seconde commande dépose GRUB dans \EFI\BOOT\BOOTX64.EFI. Le wiki Debian explique que, sans variable de démarrage valide, le firmware cherche un chargeur à ce chemin fixe de l’ESP (\EFI\boot\bootx64.efi sur amd64), celui que tout firmware doit savoir lancer pour démarrer un installeur. La page de manuel de grub-install précise que --removable n’est disponible qu’en EFI.

Le wiki GrubEFIReinstall décrit la même logique pour un firmware qui ne reconnaît que le chemin de repli : copier debian/grubx64.efi vers EFI/boot/bootx64.efi, puis passer l’option debconf à true pour garder ce fichier à jour.

Le préventif

Plutôt que de réparer après coup, la règle retenue est de passer le grub-install --removable sur les VM Debian UEFI avant la migration. Si les entrées NVRAM ne suivent pas, le firmware trouve quand même un chargeur au chemin de repli, et l’on évite une intervention console VM par VM.

Ce qu’il faut retenir

• Après Move AHV vers AHV, des VM Debian 12 UEFI ont perdu leurs entrées NVRAM : observation terrain, non documentée par Nutanix.
• Shell EFI, FS0:, ls EFI, lancement de grubx64.efi : si la VM boote, le diagnostic est fait.
• ls EFI vide signifie une installation legacy : uefi_boot=false, VM éteinte.
• grub-install --removable pose le chargeur au chemin de repli ; activez force_efi_extra_removable pour qu’il reste à jour.
• Faites-le avant la migration, après un snapshot.

In English

After a Move migration from AHV to AHV, some Debian 12 UEFI VMs no longer find a boot device because their NVRAM boot entries are lost, a field observation not documented by Nutanix. Launching grubx64.efi from the EFI shell confirms the diagnosis, grub-install fixes it, and passing –removable before migration avoids repairing VMs one by one.

Sources & vérification

Testé sur : Debian 12 UEFI, migration Move AHV vers AHV

• Debian wiki UEFI wiki.debian.org
• grub-install(8) manpages.ubuntu.com
• Nutanix Move supports UEFI-enabled VMs next.nutanix.com
• Debian wiki GrubEFIReinstall wiki.debian.org
• Expérience directe de l’auteur, en production (versions ci-dessus)

Comment les billets sont vérifiés et corrigés