OVH : serveur bloqué au prompt GRUB EFI

Cela peut se produire après une mise à jour, du fait de la manière dont est installé les distributions OVH EFI dans le cadre d'un raid software.
OVH créé en effet une première partition sur chaque disque contenant une amorce EFI de grub. Néanmoins, quand vous avez un raid software, une seule de ces partitions est montée dans /boot/efi et est donc mise à jour. Les autres partitions EFI se retrouvent alors avec des informations obsolètes ne permettant potentiellement plus le démarrage du serveur. Ensuite, tout dépend de quel disque sera sollicité en premier lors du démarrage.

L'architecture de boot OVH est la suivante :

• L'EFI du serveur est configuré pour démarrer en PXE dans tous les cas. Cela permet le fonctionnement du rescue également.
• le PẌE charge rEFInd qui, sur chaque partition EFI, recherche un fichier .efi bootable. S'il en trouve un, il le démarre.

La solution triviale pour réparer le démarrage est de resynchroniser les différentes partitions EFI de vos disques. Le problème suivant est que, en général à ce stade, vous ne saurez plus quelle partition était montée lors de la mise à jour. Il faut donc remonter le système en rescue, mettre à jour l'une des partitions EFI, puis synchroniser les autres avec celle-ci.
Je prend ici l'exemple d'un serveur avec 4 disques.

Réparation

Rebootez le serveur en rescue.

Arrêtez les raids actifs :

mdadm --stop /dev/mdX

Remontez le raid qui contient la partition root. Par défaut chez OVH pour un système EFI, c'est md2 qui relie les partitions sd[a-z]2.

mdadm --assemble /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2

Montez la partition root puis chrootez dedans :

mount /dev/md2 /mnt/
mount -o bind /proc /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /sys /mnt/sys
chroot /mnt

Nous allons ensuite mettre à jour l'une des partitions EFI.

mount /dev/sda1 /boot/efi/
update-grub
grub-install

Il faut ensuite synchroniser les 3 autres partitions.

mkdir /mnt/sdb /mnt/sdc /mnt/sdd
mount /dev/sdb1 /mnt/sdb
mount /dev/sdc1 /mnt/sdc
mount /mnt/sdd1 /mnt/sdd
rsync -av /boot/efi/ /mnt/sdb/
rsync -av /boot/efi/ /mnt/sdc/
rsync -av /boot/efi/ /mnt/sdd/
umount /mnt/*

Vous pouvez ensuite quitter le chroot et redémarrer en mode normal :

exit
umount /boot/efi/
umount /mnt/dev/pts
umount /mnt/*
umount /mnt/
reboot

Éviter l'erreur à l'avenir

Si vous utilisez Proxmox, un outil est fournit, permettant de garder automatiquement ces partitions synchronisées : proxmox-boot-tool
Cette solution présente deux défauts :

• elle utilise systemd-boot à la place de grub. Ce n'est donc plus la configuration de grub qu'il faudra modifier mais celle de proxmox-boot-tool et de systemd-boot.
• l'outil force l'ordre de démarrage de l'UEFI pour prioriser les disques. Cela empêchera votre serveur de démarrer en PXE, qui est par exemple nécessaire chez OVH pour démarrer en mode rescue.

Je déconseille vivement cette solution si vous êtes chez OVH à cause du dernier défaut qui empêchera l'accès au mode rescue

Pour l'utiliser, il faut ajouter chaque partition EFI à la base de donnée de proxmox-boot-tool :

umount /boot/efi/
proxmox-boot-tool init /dev/sda1
proxmox-boot-tool init /dev/sdb1
proxmox-boot-tool init /dev/sdc1
proxmox-boot-tool init /dev/sdd1
mount /boot/efi/

Ensuite, à chaque mise à jour impliquant le kernel, la commande proxmox-boot-tool refresh sera lancée automatiquement et elle s'occupera de synchroniser les 4 partitions.