Assistance pour réparation de GRUB

Bonjour,
Je précise que je ne suis pas du tout à l'aise non plus avec cette partie Grub2 EFI/BIOS.

Peut être une conséquence d'une mise à jour de Grub sur les dépôts Debian de cette semaine. Je suis également concerné sur certaines machines Debian (mais je n'ai pas reboot en voyant qu'il y avait un problème).

Tout d'abord, avez vous la possibilité de boot avec le noyaux réseau d'OVH ? Cela permettrai de la faire repartir.

De ce que j'en ai compris, le problème est qu'il y a 2 paquets grub installés (EFI et BIOS) alors qu'il n'en faudrait qu'un seul.
Voilà un bon post qui en parle : https://forums.debian.net//viewtopic.php?f=5&t=148816&p=734331

@Sich @janus57 @ChristopheGX @JeanR @Fritz2cat vous n'avez pas été confronté à ce problème cette semaine lors des upgrades Debian ?

avez vous la possibilité de boot avec le noyaux réseau d'OVH ?

Apparemment c'est supprimé pour tout le monde (sans prévenir !)

Cet article peut-il aider ? https://forums.debian.net/viewtopic.php?p=756752

Également pour les machine OVH ou juste SYS ? Son serveur RISE-1 est chez OVH.
Je viens d'ouvrir un ticket CS6283172 chez SYS à ce sujet.

EDIT la réponse :
> Effectivement nous ne proposons plus de boot réseau. Voici la tache travaux en lien avec cette disparition :
> https://bare-metal-servers.1ovhcloud.com/incidents/gz80gt4637n1ovhcloud.com/incidents/gz80gt4637n1

J'ai contrôlé sur un dédié chez OVH et effectivement il n'y a plus de netboot non plus :(

@Artimox
Pouvez vous regarder si vous avez un dossier /sys/firmware/efi ? (sur la partition monté en chroot)
Si c'est le cas (vous bootez avec EFI) pouvez vous regarder si vous avez le paquet grub-efi-amd64 qui est installé ?

j'ai eu des erreurs récemment oui, j'ai refais des grub-install sur à peu près toutes les partitions et tous les disques par sécurité.
J'avoue ne pas avoir tenté de redémarrer un serveur pour le moment....
Oui ça me stress à mort... Oui j'ai horreur de toucher à ça, à chaque fois c'est des emm...

Bonjour,

Il manque le montage et le chroot en effet, voici ce que visiblement tu dois faire:
mkdir /mnt/root
mount /dev/md126 /mnt/root
mount /dev/sdb1 /mnt/root/boot
mount /dev/md127 /var/lib/vz
mount --bind /dev /mnt/root/dev
mount --bind /proc /mnt/root/proc
mount --bind /sys /mnt/root/sys
chroot /mnt/root

Ensuite tu pourras faire l'installation de ton grub ou l'update

Bon courage
Captainadmin

Sur une machine (pas encore prodée) qui boot en UEFI avec Debian11, j'upgrade et j'ai eu j'ai eu

> mdadm: /dev/md does not appear to be an md device
> grub-install: error: ioctl RAID_VERSION error: Inappropriate ioctl for device.
> dpkg: error processing package grub-cloud-amd64 (--configure):
> installed grub-cloud-amd64 package post-installation script subprocess returned error exit status 1
> Errors were encountered while processing:
> grub-cloud-amd64

j'ai fait un
apt install grub-efi-amd64

il demande si il doit garder le fichier de conf actuel ou de prendre le nouveau fichier du maintener, j'ai bien sur choisis de conserver le fichier.

reboot OK.

Me reste une dizaines de machines (Debian 10) en boot BIOS et où l'upgrade de Grub ne sait pas ou s'installer....
Je déteste ça aussi.

Bonjour,

OS installed by OVHcloud : proxmox6_64

arf c'est partir avec un handicap, sur proxmox OVH fait une installation "non standard" et non supporté par proxmox officiellement.

Là perso sur un promxox 7 via installé via l'ISO officiel (vive ZFS), sur un serveur OVH (SYS-1-SSD-32), pas eu de question lors de la mise à jour de grub.
Et il viens de reboot parfaitement.

Cordialement, janus57

Bonjour à tous,

Déjà merci à tous pour vos réponses si rapides, ça fait plaisir de voir une communauté aussi réactive. J'ai pu régler le problème tout seul le temps qu'OVH valide mon message et le poste sur le forum ^^'

Je reviens donc simplement pour expliquer comment j'ai fait pour réparer le GRUB :

1. Booter sur le système de secours (`rescue64-pro`)
2. Il y a deux disques (`sda` et `sdb`) parce qu'il y a un RAID, mais du coup pas la peine d'utiliser `mdadm` sur le système rescue parce que le RAID est déjà monté avec 2 partitions : `md126` et `md127`. En regardant la taille de ces deux partitions on peut se rendre compte que `md127` est la partition de données principale (`/var/lib/vz` qui est une partition classique de Proxmox) et `md126` la partition de l'OS Proxmox.
3. Je me suis basé sur la doc suivante : https://docs.ovh.com/fr/public-cloud/repairing-the-grub-bootloader/
Avec quelques ajouts spécifiques à ma situation

```
# Monter la partition contenant l'OS
mount /dev/md126 /mnt

# Cette étape j'ai pas vraiment compris mais ça a l'air important :D
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev

# Changer la racine actuelle par celle de l'OS que vous venez de monter
# et lancez un bash
chroot /mnt /bin/bash
```

Ensuite j'ai voulu suivre le tuto mais il y avait un cas particulier, je n'étais pas en boot classique mais en EFI. Pour s'en rendre compte, il suffit de vérifier que le dossier suivant est présent :
```
ls -l /sys/firmware/efi/
```

Du coup, il manquait une étape :
```
# Sortir du chroot
exit

# Monter la partition de boot pour la réparer
mount /dev/sdb1 /mnt/boot/efi
```

Pour savoir que c'était la partition `sdb1` on regarde non seulement la taille mais on peut aussi voir que c'est une partition boot avec un système de fichier `fat16` grâce à des commandes comme :
```
parted -l
```

Ensuite :
```
# Croûte à nouveau
chroot /mnt /bin/bash

# Réparer le grub
grub-install /dev/sdb
update-grub
```

Je ne sais pas si c'était nécessaire mais étant donné qu'il y avait 2 disques, je me suis dit que j'allais aussi le faire pour `sda`. Du coup (je ne sais pas si on pouvait faire sans) :
```
exit
umount /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
chroot /mnt /bin/bash
grub-install /dev/sda
update-grub
```

ET VOILA ! Ensuite, j'ai modifié la méthode de boot de mon serveur vers "booter sur disque dur", puis j'ai redémarré et c'était bon.

Merci encore à tous, je pense que la méthode de @JeanR doit fonctionner étant donné qu'elle est équivalente.

N'hésitez pas à me corriger si j'ai dit des bêtises ou des imprécisions et j'espère que mon message pourra aider quelques personnes un peu perdues comme moi.

Félicitations et surtout merci pour ce retour très complet.
Les problèmes d'amorçage sont une vraie galère et c'est tjrs pénible à gérer.
Si quelqu'un a besoin d'aide il aura toutes les infos avec votre retour.

Merci pour ce retour.

En effet ici c'est propre et bien documenté, je t'avais envoyé les info de tête alors ca donnait moins envie.

Bon courage

Un grand merci pour ce partage...

J'ai essayé la manipulation mais cela ne veut toujours pas fonctionné : J'ai remplacé dans votre code md126 par md2 c'est bien ça je pense ? merci beaucoup de votre aide

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 3.7T 0 disk
├─sdb4 8:20 0 511M 0 part
├─sdb2 8:18 0 19.5G 0 part
│ └─md2 9:2 0 19.5G 0 raid1 /
├─sdb3 8:19 0 3.6T 0 part
│ └─md3 9:3 0 3.6T 0 raid1
└─sdb1 8:17 0 511M 0 part /boot/efi
sdc 8:32 0 3.7T 0 disk
├─sdc2 8:34 0 19.5G 0 part
│ └─md2 9:2 0 19.5G 0 raid1 /
├─sdc3 8:35 0 3.6T 0 part
│ └─md3 9:3 0 3.6T 0 raid1
├─sdc1 8:33 0 511M 0 part
└─sdc4 8:36 0 511M 0 part
sda 8:0 0 3.7T 0 disk
├─sda4 8:4 0 511M 0 part
├─sda2 8:2 0 19.5G 0 part
│ └─md2 9:2 0 19.5G 0 raid1 /
├─sda3 8:3 0 3.6T 0 part
│ └─md3 9:3 0 3.6T 0 raid1
└─sda1 8:1 0 511M 0 part /boot/efi

un grand MERCI aussi, ça nous a sorti une épine du pied !!!