Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Comment faire en sorte que Windows 11 utilise le GPT Linux existant sur un disque dur externe de 6 To ?

ayi

Mon objectif est d’accéder aux partitions NTFS sur un disque dur externe de 6 To dans Windows 11 qui possède déjà un GPT valide créé sous Linux. Le problème est que Windows 11 monte le disque en utilisant le MBR.
Windows Disk Management et l’utilitaire que j’utilise, Disk Genius, voient tous deux le disque dur comme MBR
J’ai tenté de convertir le MBR en GPT et il semble qu’il essaie de créer un tout nouveau GPT car Disk Genius signale qu’il n’y a pas d’espace pour créer le GPT :
Avant d’aller plus loin, puis-je simplement faire en sorte que Windows 11 lise et utilise le GPT existant que Linux a créé ?
J’ai lu beaucoup d’articles sur la conversion MBR vers GPT et je réalise que ce n’est pas ce que je veux faire - je veux simplement utiliser ce qui existe déjà. Je n’ai pas besoin de créer un nouveau GPT.
Pour être complet, voici à quoi ressemble le GPT sous Linux (la partition de 120 Go que je veux utiliser dans Windows 11 est /dev/sdc14) :
<pre><code class="lang-auto"># fdisk -l /dev/sdc
Disk /dev/sdc: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: USB 3.0 Destop H
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4FBB78E0-201B-4A5B-A745-C0E797DF98D9

Device Start End Sectors Size Type
/dev/sdc1 2048 2099199 2097152 1G EFI System
/dev/sdc2 2099200 63326207 61227008 29.2G Linux filesystem
/dev/sdc3 105269248 149309439 44040192 21G Linux filesystem
/dev/sdc4 168183808 210126847 41943040 20G Linux filesystem
/dev/sdc5 63326208 105269247 41943040 20G Linux filesystem
/dev/sdc6 449202176 465979391 16777216 8G Microsoft basic data
/dev/sdc7 465979392 5860855807 5394876416 2.5T Linux filesystem
/dev/sdc8 5860855808 5860857855 2048 1M Microsoft basic data
/dev/sdc9 5860858456 5938983447 78124992 37.3G Apple APFS
/dev/sdc10 5939245592 9767921663 3828676072 1.8T Apple HFS/HFS+
/dev/sdc11 9768183808 10002558807 234375000 111.8G Apple APFS
/dev/sdc12 10002558808 10393183807 390625000 186.3G Apple APFS
/dev/sdc13 10393184256 11064272895 671088640 320G Linux filesystem
/dev/sdc14 11064272896 11315931135 251658240 120G Microsoft basic data

</code></pre>
Voici le MBR du même disque :
<pre><code class="lang-auto"># fdisk -t dos -l /dev/sdc
Disk /dev/sdc: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: USB 3.0 Destop H
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x8a9e2113

Device Boot Start End Sectors Size Id Type
/dev/sdc1 1 2099199 2099199 1G ee GPT
/dev/sdc2 * 2099200 63326207 61227008 29.2G 83 Linux
/dev/sdc3 105269248 149309439 44040192 21G 83 Linux
/dev/sdc4 168183808 210126847 41943040 20G da Non-FS data

Partition 1 does not start on physical sector boundary.

</code></pre>

ayi_2

Chaque disque GPT possède également une table de partitions MBR, pour des raisons de compatibilité, bien que normalement le MBR d’un tel disque soit censé avoir seulement une seule partition “GPT protective” (code de type 0xEE) qui couvre l’intégralité du disque - ou autant du disque que le MBR peut couvrir, en tout cas - et indique simplement aux anciens logiciels que le disque n’est pas vide ; un système d’exploitation moderne l’ignorerait et ne regarderait que le GPT.
Mais votre disque semble avoir un partitionnement “hybride” où les deux tables de partitions contiennent des informations valides (et contradictoires) - assez étrangement, la partition protective est présente mais a été réduite pour ajouter des éléments à côté - il est donc très possible que Windows et Disk Genius donnent la priorité au MBR par rapport au GPT dans de telles situations.
(En y regardant de plus près, il semble que le MBR soit une ancienne copie du GPT avec seulement les quatre premières partitions présentes, et l’étrange partition protective remplace la partition système EFI. Soit quelqu’un s’est trompé de type de partition - une ESP serait de type 0xEF, pas 0xEE - soit il a délibérément voulu dissimuler l’ESP pour que le firmware l’ignore ?)
Convertir ce MBR en GPT serait l’opposé de ce que vous voulez, puisque cela remplacerait vos partitions GPT valides par des partitions inutiles converties depuis le MBR obsolète, il est donc heureux que cela n’ait pas réussi. (Bien que vous puissiez les récupérer manuellement à partir de la liste dans votre message.)
Au lieu de cela, puisque le MBR contient actuellement des informations inutiles, vous devriez le remplacer par un MBR “protective” standard. La façon la plus simple de le faire est d’utiliser l’outil <code>gdisk</code> (alias “gptfdisk”) depuis Linux :
<ul>
<li>
<code>gdisk /dev/sdc</code> ;
</li>
<li>
Menu principal : <code>x</code> pour entrer dans le menu “Expert” ;
</li>
<li>
Menu Expert : (optionnel) <code>o</code> pour examiner le MBR actuel ;
</li>
<li>
Menu Expert : <code>n</code> pour générer un nouveau MBR protective ;
</li>
<li>
Menu Expert : (optionnel) <code>o</code> pour examiner le MBR nouvellement généré ;
</li>
<li>
Menu Expert : (optionnel) <code>p</code> pour s’assurer que le GPT est toujours là ;
</li>
<li>
Menu Expert : <code>w</code> pour écrire les nouvelles tables de partitions sur le disque.
</li>
</ul>
(Cela pourrait être réalisé avec fdisk, mais nécessiterait plus d’étapes et plus de prudence.)
Le résultat final devrait ressembler exactement à ceci - c’est-à-dire une seule partition aussi grande que possible :
<pre><code class="lang-auto"># fdisk -t dos -l
Device Boot Start End Sectors Size Id Type
/dev/sdc1 1 4294967295 4294967295 2T ee GPT
#

</code></pre>