
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 :
Voici ce que l’on observe :
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,uuidCe qui donne dans notre cas :
| disque | partition | raid | vg group | montage | label | taille | |
|---|---|---|---|---|---|---|---|
| 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 /mntEnsuite on mote une partition EFI
mount /dev/nvme0n1p1 /boot/efiLogiquement à ce stade, il suffirait de mettre à jour grub. Dans mon cas, l’action suivante semble avoir été indispensable :
apt reinstall grub-efi-amd64Ensuite 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/nvme1n1p1Et voilà, on démonte tout, on sort du chroot et on éteint le poste.
umount /mnt/*
exit
haltAvant 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
