Installation Linux en échec causé par une scorie GPT

Une installation réussie mais qui refuse de redémarrer

Un après-midi chez des amis, un vieux PC sous Windows 7 ou Vista qui rame depuis des années sur le bureau. Vous proposez de lui donner une seconde vie avec Linux. L'installation se passe bien, vous êtes satisfait. Vous rebootez, tout content… et là, rien. Le PC refuse obstinément de démarrer sur son nouveau système. PXE, menu de boot en boucle, écran noir, ou encore le menu de boot du système qui se présente sans que vous ne parveniez à démarrer sur la distribution Linux, malgré une installation par ailleurs réussie.

Dépité et perplexe, vous proposez à vos amis de rapporter le PC chez vous, pour prendre le temps d'investiguer le problème.

Qu'a-t-il pu se passer ? Dans le cas rencontré ici, la cause était sournoise : le disque avait déjà été utilisé avec une table de partitions GPT (typiquement pour un système avec UEFI), et des signatures résiduelles persistaient en fin de disque. Le firmware les détectait et se comportait en conséquence, même si GParted avait produit et affichait une table MS-DOS propre.

Voici les lignes de commandes qui vous permettront de détecter des informations clés dans le disque de stockage.

1. Détecter les signatures résiduelles

Listez ce que le noyau voit réellement sur le disque, au-delà de ce qu'indique la table de partitions active :

(Remplacez /dev/sdX par votre disque cible, par exemple /dev/sdb.)

Exemple de conflit réel :

La présence simultanée des deux signatures est la source du problème.

2. Diagnostic alternatif avec testdisk

Si vous souhaitez une confirmation visuelle supplémentaire, testdisk permet de voir la situation d'un autre œil. Sa sortie peut révéler explicitement la scorie GPT :

La ligne 1 P EFI GPT confirme la présence de la signature GPT résiduelle. Le Warning: Bad ending head indique que la géométrie CHS lue par testdisk ne correspond pas à l'adressage LBA moderne — ce qui est normal sur un SSD, mais signale ici le conflit.

⚠️ Attention : testdisk est utile pour le diagnostic, mais ne réutilisez pas ses adresses de partitions pour tenter une reconstruction manuelle dans fdisk. Testdisk travaille en géométrie CHS tandis que fdisk utilise le LBA — les adresses ne sont pas directement transposables, et la reconstruction échouera.

3. Supprimer la signature fantôme

Supprimez uniquement la signature GPT via son adresse exacte sur le disque, relevée à l'étape 1, sans toucher aux partitions ni réécrire l'intégralité du disque :

La table dos redevient la seule référence. GParted ne verra plus de partition esp fantôme, et le flag de boot redeviendra un simple indicateur d'amorçage standard.

Vous pouvez relancer sudo wipefs /dev/sdX pour confirmer que la scorie a bien disparu.

4. Vérifier après installation

Une fois l'installation terminée, vérifiez que le système de fichiers est correctement reconnu sur la partition principale :

Réponse correcte : Linux rev 1.0 ext4 filesystem data... — le superbloc est trouvé, la partition est saine.

Réponse incorrecte : data — le superbloc est introuvable, la partition est mal alignée ou mal formatée.

Si la réponse est incorrecte et que la situation ne se résout pas, repartez de zéro avec l'installation : au besoin, effacez et refaites les partitions avec GParted.

Important : après tout changement dans le partitionnement, redémarrez le système avant de lancer l'installation, afin que le noyau prenne bien en compte la nouvelle disposition du disque.

Conclusion

Une scorie GPT est une cause d'échec de boot rare, sournoise et peu documentée. Elle ne laisse aucune trace visible dans GParted, et les symptômes : retours en boucle sur le menu de boot, démarrage du boot sur PXE, écran noir, peuvent faire croire à des dizaines d'autres problèmes.

sudo wipefs permet de la révéler et de l'éliminer de manière ciblée, et sûre.