Code source wiki de Installation Linux en échec causé par une scorie GPT
Modifié par Mélodie le 2026/05/17 03:25
Afficher les derniers auteurs
| author | version | line-number | content |
|---|---|---|---|
| 1 | == Une installation réussie mais qui refuse de redémarrer == | ||
| 2 | |||
| 3 | |||
| 4 | Un après-midi chez des amis, vous examinez 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. | ||
| 5 | |||
| 6 | Dépité et perplexe, vous proposez à vos amis de rapporter le PC chez vous, pour prendre le temps d'investiguer le problème. | ||
| 7 | |||
| 8 | 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. | ||
| 9 | |||
| 10 | Voici les lignes de commandes qui vous permettront de détecter des informations clés dans le disque de stockage. | ||
| 11 | |||
| 12 | |||
| 13 | == 1. Détecter les signatures résiduelles == | ||
| 14 | |||
| 15 | Listez ce que le noyau voit réellement sur le disque, au-delà de ce qu'indique la table de partitions active : | ||
| 16 | |||
| 17 | {{code language="bash"}} | ||
| 18 | sudo wipefs /dev/sdX | ||
| 19 | {{/code}} | ||
| 20 | |||
| 21 | //(Remplacez {{{/dev/sdX}}} par votre disque cible, par exemple {{{/dev/sdb}}}.)// | ||
| 22 | |||
| 23 | Exemple de conflit réel : | ||
| 24 | |||
| 25 | {{code language="none"}} | ||
| 26 | offset type | ||
| 27 | ---------------------------------------------------------------- | ||
| 28 | 0x1fe dos [partition table] | ||
| 29 | 0x1740d55e00 gpt [partition table] ← scorie GPT résiduelle | ||
| 30 | {{/code}} | ||
| 31 | |||
| 32 | La présence simultanée des deux signatures est la source du problème. | ||
| 33 | |||
| 34 | == 2. Diagnostic alternatif avec testdisk == | ||
| 35 | |||
| 36 | 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 : | ||
| 37 | |||
| 38 | {{code language="none"}} | ||
| 39 | TestDisk 7.1, Data Recovery Utility, July 2019 | ||
| 40 | Disk /dev/sdb - 120 GB / 111 GiB - CHS 14593 255 63 | ||
| 41 | Current partition structure: | ||
| 42 | Partition Start End Size in sectors | ||
| 43 | 1 P EFI GPT 0 0 2 14593 80 63 234441647 | ||
| 44 | Warning: Bad ending head (CHS and LBA don't match) | ||
| 45 | No partition is bootable | ||
| 46 | {{/code}} | ||
| 47 | |||
| 48 | 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. | ||
| 49 | |||
| 50 | ⚠️ **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. | ||
| 51 | |||
| 52 | == 3. Supprimer la signature fantôme == | ||
| 53 | |||
| 54 | 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 : | ||
| 55 | |||
| 56 | {{code language="bash"}} | ||
| 57 | sudo wipefs -o 0x1740d55e00 /dev/sdX | ||
| 58 | {{/code}} | ||
| 59 | |||
| 60 | 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. | ||
| 61 | |||
| 62 | Vous pouvez relancer **{{{sudo wipefs /dev/sdX}}}** pour confirmer que la scorie a bien disparu. | ||
| 63 | |||
| 64 | == 4. Vérifier après installation == | ||
| 65 | |||
| 66 | Une fois l'installation terminée, vérifiez que le système de fichiers est correctement reconnu sur la partition principale : | ||
| 67 | |||
| 68 | {{code language="bash"}} | ||
| 69 | sudo file -s /dev/sdX1 | ||
| 70 | {{/code}} | ||
| 71 | |||
| 72 | **Réponse correcte** : {{{Linux rev 1.0 ext4 filesystem data...}}} — le superbloc est trouvé, la partition est saine. | ||
| 73 | |||
| 74 | **Réponse incorrecte** : {{{data}}} — le superbloc est introuvable, la partition est mal alignée ou mal formatée. | ||
| 75 | |||
| 76 | 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. | ||
| 77 | |||
| 78 | **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. | ||
| 79 | |||
| 80 | == Conclusion == | ||
| 81 | |||
| 82 | 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. | ||
| 83 | |||
| 84 | **//{{{sudo wipefs}}}//** permet de la révéler et de l'éliminer de manière ciblée, et sûre. |