Etat initial

  • Une distribution proxmox en version 8.2 sur un serveur dédié rise d’OVH,
  • Action : mise à jour ordinaire du système pour passer en 8.4. La mise à jour comprend des nouveaux kernels. Tous se passe bien et le serveur est redémarré,
  • Observation : le serveur ne démarre pas.

En activant la fonction de console KVM dans la capture ci dessous :

OVH, accès à la console KVM
Ludovic Lestrat

Voici ce que l’on observe :

Echec de démarrage, console grub
Ludovic Lestrat

On observe apres la fenetre du boot manager rpfind, en boot PXE, le passage à notre sereur dédié.
Et là, la console grub s’affiche directement et il ne se passe plus rien.

Diagnostic

Après quelques recherches sur le web, il apparaît que c’est le boot UEFI qui coince, pourquoi ?
Allons plus loin sur l’analyse.

Pour intervenir, il va falloir booter en mode rescue comme expliqué dans cet article.

Comment sont structurés nos partitions pour voir quelle est la partition de boot

lsblk -o name,mountpoint,label,size,uuid

Ce qui donne dans notre cas :

disquepartitionraidvg groupmontagelabeltaille
nvme1n1 894.3G
nvme1n1p1 EFI_SYSPART 511M
nvme1n1p2 md2 1G
md2 /boot boot 1022M
nvme1n1p3 md3 20G
md3 / root 20G
nvme1n1p4 [SWAP] swap-nvme0n1p4 1G
nvme1n1p5 md5 871.8G
md5 871.6G
md5 871.6G
vg-data /var/lib/vz var-lib-vz 871.6G
nvme1n1p6 config-2 2M
nvme0n1 894.3G
nvme0n1p1 EFI_SYSPART 511M
nvme0n1p2 md2 1G
md2 /boot boot 1022M
nvme0n1p3 md3 20G
md3 / root 20G
vme0n1p4 [SWAP] swap-nvme0n1p4 1G
nvme0n1p5 md5 871.8G
md5 871.6G
md5 871.6G
vg-data /var/lib/vz var-lib-vz 871.6G

La on commence à comprendre ou est le loup. Nous avons un raid1 en place avec deux disques SSD (nvme0n1 et nvme1n1) et la partition de boot est en mode raid également, par contre l’EFI ne semble pas en mode raid entre les deux disques.

Il semblerait qu’au moment de l’installation du nouveau kernel, l’ecriture dans la partition EFI n’est pas été synchrone mais affecté à un seul disque.
Pour en savoir plus, c’est expliqué ici.

L’objectif va donc être de synchroniser les 2 partitions EFI des deux disques.

Intervention

Par rapport à l’article ci-précédemment cité, nous avons une petite subtilité en plus, le répertoire « /boot » est sur une partition à part (ici « /dev/md2 ») et non sur la partition système (« /dev/md3 »).

Voici la suite des actions à entreprendre.
Les seules partitions que nous voulons resynchroniser, c’est les « EFI_SYSPART », du coup nous n’allons pas arrêter les raid car nous n’allons pas les manipuler.

Montage des partitions et chrootage :

mount /dev/md3 /mnt/
mount /dev/md2 /mnt/boot
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

Ensuite on mote une partition EFI

mount /dev/nvme0n1p1 /boot/efi

Logiquement à ce stade, il suffirait de mettre à jour grub. Dans mon cas, l’action suivante semble avoir été indispensable :

apt reinstall grub-efi-amd64

Ensuite mise à jour de grub :

grub-install
update-grub

Il est possible que vous receviez le message suivant :
grub-install.real : warning : EFI variables are not supported on this system..
Mais cela n’a pas été bloquant pour ma part

Maintenant, nous allons monter l’autre partition EFI_SYSPART pour la synchroniser :

mkdir /mnt/nvme1n1p1
mount /dev/nvme1n1p1 /mnt/nvme1n1p1/
rsync -av /boot/efi /mnt/nvme1n1p1

Et voilà, on démonte tout, on sort du chroot et on éteint le poste.

umount /mnt/*
exit
halt

Avant de redémarrer le serveur, pensez bien dans la webconsole d’OVH à basculer de mode rescue à boot normal.
Si tout va bien, çà devrait redémarrer comme il faut.

Références :
https://wiki.csnu.org/index.php/OVH_:_serveur_bloqu%C3%A9_au_prompt_GRUB_EFI
https://support.us.ovhcloud.com/hc/en-us/articles/115001754490-How-to-activate-and-use-rescue-mode
https://forum.proxmox.com/threads/grub-install-error-while-upgrading-from-proxmox-8-to-9.169343/
https://pve.proxmox.com/wiki/Recover_From_Grub_Failure
https://help.ovhcloud.com/csm/fr-public-cloud-compute-repairing-grub-bootloader?id=kb_article_view&sysparm_article=KB0051070