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.