Supprimer GRUB, sans tuer la table de partitions

Cet article a été publié il y a 6 ans 4 mois 2 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Ça fait un bout de temps que je gardais cette bidouille dans les cartons. Avant d’installer mon micro serveur et d’investir dans un NAS, à mon arrivée dans mon appartement j’avais recyclé mon vieux laptop Acer, précédemment libéré sous Manjaro, en serveur perso, sur lequel j’avais branché un disque dur externe pour disposer d’un stockage un peu plus conséquent. Et à l’occasion d’un reboot à distance, ce disque dur m’a posé quelques problèmes.

MBR mon amour

Le disque dur externe n’était en fait rien de plus qu’un ancien disque dur, le dernier en date que j’avais monté dans mon laptop HP (avant le Acer donc), qui a eu l’occasion d’accueillir ArchLinux quelques temps avant la reconversion. Ce disque dur avait donc vu son MBR accueillir GRUB. Lors des formatages qui ont suivi en tant que disque dur externe, ce MBR n’a jamais été réinitialisé.

Hors, lors d’un redémarrage suite à une série de mises à jour, le laptop a tenté de démarrer sur ce disque USB. Il a identifié GRUB, qui s’est alors mis à chercher, d’après ses paramètres, une partition qui n’existe pas, et donc le serveur échoue à démarrer.

De l’art de supprimer les bons blocs

Attention : Ce MBR n’a de sens qu’avec l’ancien modèle de partitions dit « msdos ». Les disques récents, en particulier les plus volumineux, utilisent le format GPT décrit évidemment de manière différente. Les manipulations que je présente ici concernent uniquement le format « msdos ».

Donc, le MBR et la table de partitions sont décrits dans les 512 premiers blocs octets du disque. Ici, c’est grâce à dd qu’on va opérer sur le disque. Après avoir branché votre disque, et identifié son nom (/dev/hdX dans mon cas, le disque étant un IDE), on commence par sauvegarder ces fameux 512 premiers blocs octets en cas de besoin :

Ensuite, on a plusieurs choix. Soit on souhaite repartir complètement de zéro, et on supprime le contenu des 512 blocs octets en question :

Il faudra ensuite un outil tiers (cfdisk, parted…) pour recréer une table de partitions et ensuite les partitions recherchées; soit on veut conserver la table de partitions, et là, il faut soit tout supprimer et restaurer uniquement les blocs octets nécessaires, à savoir les 64 blocs qui la décrive :

Soit ne supprimer que les 446 premiers blocs octets :

Et normalement, ça devrait cuire. Si jamais vous avez un souci et que ne voyez plus vos partitions, vous pouvez toujours restaurer l’image entière, ce qui permettra dans un premier temps de récupérer les infos et d’analyser plus posément ce qui a déconné.

Et pour les nouvelles technos ?

Il serait intéressant également de s’attarder sur les disques plus récents qui utilisent des blocs de 4ko au lieu de 512 et qui exploitent le format GPT. Avis aux bonnes volontés 🙂