gparted, fdisk et df ne sont pas d'accord

Bonjour,

Version courte: J’ai un disque GPT avec la MBR de protection (premiers 512 octets) en mauvais état, ce qui rend confus gparted (et peut-être fdisk). Pour une utilisation normale tout va bien, mais je préférerais nettoyer ça, des idées?

Version (très) longue:

Je voulais récemment tester Qubes via le live usb. Je branche donc ma clé usb sur mon ordi, ouvre gparted pour regarder ce qu’il y a dessus (ça fait plusieurs mois que je ne l’ai pas utilisé) et je vois un disque d’installation Linux Mint sur sdc. Pour me rafraîchir un peu la mémoire je regarde rapidement mes deux disques internes (sda et sdb) et me rends compte que mon disque de donnée (sdb) ressemble aussi à un disque d’installation Linux Mint (avec une version un peu plus récente) qui prends tout l’espace!

Là, j’ai un gros doute parce que je suis sûr que j’ai bien des données dessus que j’ai utilisé récemment et que mon dernier dd foireux remonte à plus longtemps que ça. Je vérifie donc avec fdisk -l qui m’indique presque ce à quoi je m’attends: deux partitions de taille raisonnables, sauf qu’elles sont toutes les deux marqués comme Microsoft basic data alors qu’il y a probablement une partition linux dans le lot. Je monte alors les deux partitions avec mount pour regarder ce qu’il y a dedans et me sens particulièrement con en me rendant compte qu’une des deux est en fait mon /home. Étant quasiment sûr que mon /home est du ext4, je fais un dd -T qui m’indique bien du ext4.

Pour résumer:

• gparted m’indique que sdb est une partition iso9660 avec le label Linux Mint 18.1 Cinnamon 64-bit d’un peu plus de 900Go.
• fdisk -l m’indique que sdb est un disk gpt avec une partition sdb1 d’environ 100Go et une partition sdb2 d’environ 800Go toutes deux de type Microsoft basic data.
• df -T m’indique que sdb1 est une partition ext4 d’environ 100Go et sdb2 est une partition fuseblk (probablement ntfs) d’environ 800Go.

Vu que mon /home (sdb1) fonctionne parfaitement bien et que ma partition windows aussi, je suppose que gparted est dans les choux pour une raison inconnue. Si ma mémoire est bonne, c’est que j’ai fait un dd foireux d’une install Mint sur mon disk sdb et que j’ai eu de la chance d’avoir mon /home à la fin de mon disque¹ (qui devait alors être sdb2). J’ai alors utilisé un outils de récupération de partition qui a scanné le disque à la recherche d’une partition ext4 pour la restaurer. J’ai ensuite dû recréer la partition ntfs pour Windows (mais je ne me souviens pas de comment j’ai fait).

Étant curieux, j’ai copié le début de mon disque sdb pour le regarder avec hexdump. J’ai regarder un peu la page wikipedia de GPT pour essayer de comprendre. Les 512 premiers octets qui correspondent au MBR de protection ont l’air de contenir le MBR de l’iso Mint², la suite qui correspond au header GPT a le bon début EFI PART. Un peu plus tard (offset 0x8000) je vois des trucs qui sont liés à la partition de l’iso Mint Linux Mint 18.1 Cinnamon 64-bit. Sachant que fdisk -l m’indique que le début de ma partition Windows est à 0x800, je suppose que c’est juste des restes de données qui n’ont pas encore étés écrasés.

Tout ça pour dire que l’en-tête de mon disque à l’air d’être dans un état assez improbable, ce qui déroute gparted. Est-ce que vous savez s’il y a moyen de nettoyer un peu ça? Vu que le header GPT est probablement bon vu que mes deux partitions fonctionnent à merveille sur leur systèmes respectifs, je suppose qu’il n’y a que la MBR de protection qui est "cassé".

Salut,

Je ne peux pas répondre pour gparted, mais pour fdisk, il est normal que tu aies un résultat non attendu, ce dernier ne supportant pas les partitions GPT. Je ne sais pas comment le MBR est lié avec les partitions GPT, mais peut-être pourrais-tu essayer de recréer la table à la main en te basant sur les limites réelles de tes deux partitions ?

Précision à propos de ce que dit mon VDD, pour les partitions GPT, il faut utiliser gdisk en lieu et place de fdisk.

Je ne sais pas comment le MBR est lié avec les partitions GPT

C’est juste pour des questions de rétro-compatibilité, en pratique en s’en fout pas mal.

En fait, j’ai surtout l’impression que le problème de l’OP vient du fait qu’il boote probablement en compatibilité MBR sur son ISO, et gparted doit, pour une raison étrange, partir du principe que le reste des disques sont aussi MBR, d’où les étrangetés qu’il affiche qui doivent venir des fausses informations que contient le MBR de protection. Je serais toi, je ne me préoccuperais pas de ce problème, ça n’a aucune importance.

J’ai essayer gdisk qui indique qu’il n’y a aucune erreur et qui indique aussi les mêmes info que fdisk.

Comme dit adri1, ça n’a pas forcément une grande importance, sauf si j’ai envie de faire des modifications sur les partitions de mon disque, auquel cas je ne pourrais pas utiliser gparted. Par contre, je suis quasiment sûr que mon Archlinux boot en UEFI (mais l’iso Mint qui a été écrite par erreur sur le disque est très certainement en compatibilité MBR).