Disque externe illisible

Bloc de code:
MacBook-Air-de-Thomas:~ Thomas$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            120.5 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +120.1 GB   disk1
                                 Logical Volume on disk0s2
                                 D8915764-B5D2-43A4-A983-8C55F1165935
                                 Unencrypted
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *3.0 TB     disk2
   1:               Windows_NTFS                         801.6 GB   disk2s1
MacBook-Air-de-Thomas:~ Thomas$
 
Toujours disk2. Passe la commande (copier-coller) :
Bloc de code:
diskutil eraseDisk free null gpt disk2 ; diskutil list disk2

  • ne sois pas "effrayé" par le verbe eraseDisk de cette commande. Car je l'ai accompagné des 2 arguments free null qui se comprennent ainsi : créer une GPT directrice sur les 33 premiers blocs du disque > avec sa sauvegarde sur les 33 derniers (ce qui implique la création automatique d'une partition EFI de 209,7 Mo au rang1) > mais n'inscrire aucun système de fichiers formateur d'une seconde partition ensuite : laisser tout le reste du disque en espace libre (free null).
  • la commande inscrit une GPT + une partition EFI1 de 209,7 Mo > et laisse le reste du disque en espace libre ; puis réaffiche la configuration du DDE

Poste le retour.

Note : j'ai bien compris que l'enjeu d'essayer de remonter le volume originel de 3 To => consiste à récupérer ses données. Sans quoi on ne s'amuserait pas à ces recréations spéculatives.
 
Bloc de code:
MacBook-Air-de-Thomas:~ Thomas$ diskutil eraseDisk free null gpt disk2 ; diskutil list disk2
Started erase on disk2
Unmounting disk
Creating the partition map
Waiting for the disks to reappear
Finished erase on disk2
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
MacBook-Air-de-Thomas:~ Thomas$
 
Note : j'ai bien compris que l'enjeu pour d'essayer de remonter le volume originel de 3 To => consiste à récupérer ses données. Sans quoi on ne s'amuserait pas à ces recréations spéculatives.

Oui, on est bien sur la même longueur d'onde ;)
C'était pour te dire que si tu ne voyais pas d'issue je n'en avais rien à faire du disque en lui-même.
 
Comme tu le vois -->
Bloc de code:
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1

  • passé la partition EFI créée automatiquement au rang1 => tout le reste du disque est en espace libre.

Passe la commande :
Bloc de code:
sudo gpt show disk2

  • qui lit la table GPT juste créée > et affiche la distribution des blocs qu'elle gère

Poste le tableau.
 
Bloc de code:
MacBook-Air-de-Thomas:~ Thomas$ sudo gpt show disk2
Password:
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6         
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  5860123495         
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header
MacBook-Air-de-Thomas:~ Thomas$
 
Oui.

- voici la partition EFI1 -->​
Bloc de code:
         40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

  • elle est canonique dans sa localisation sur les blocs : bloc de tête = n°40 > extension = 409600 blocs (de 512 octets = 209,7 Mo).
  • et ceci -->
Bloc de code:
      409640  5860123495

  • est la bande de blocs laissés libres. Elle démarre au bloc409640 > pour une extension de 5860123495 blocs (de 512 octets = 3000.38 Go). Tes données sont forcément toujours écrites sur ces blocs.

La question (l'unique question) est de déterminer quel de bloc de tête attribuer à une partition de rang2 via un descripteur GPT. Car il faut à toute force que le bloc de tête assigné à la nouvelle partition => coïncide avec le "super-bloc" du système de fichiers NTFS qu'on suppose toujours inscrit sur les blocs. "Super-bloc" = bloc où ce système de fichiers a son header (son bloc d'initialisation ou d'ancrage. Son bloc 0 de système de fichiers).

- à cette seule condition que le super-bloc du NTFS soit le bloc de tête de la partition redéfinie via un descripteur => le kernel (moteur logique de l'OS démarré) pourra activer le NTFS et monter le volume qu'il forme.​

D'accord pour la "théorie" ?
 
Alors voici un dilemme -->

- quand la partition à créer après la partition EFI est de type "Apple" => j'ai constaté que son bloc de tête était toujours canoniquement le 1er bloc libre après la fin de la partition EFI. Donc toujours le n°409640 (pour une computation en blocs de 512 octets).​
- mais j'ai fait l'expérience tout à l'heure avec l'Utilitaire de disque de Mountain Lion => de configurer le disque d'une clé USB de 128 Go en table GPT x type Windows_NTFS (avec un format NTFS de système de fichiers) => j'ai constaté que la partition2 (après l'EFI) avait été créée après un tampon de 2008 blocs libres (de 512 octets = 1,02 Mo). Ce qui donne un bloc de tête411648. Je en sais pas si ce décalement du bloc de tête est canonique pour la création d'une partition de type Windows_NTFS après la partition1 EFI.​

=> on pourrait donc envisager 2 scénarios : a) recréer un descripteur GPT assignant le bloc409640 en bloc de tête d'une partition de type "Windows_NTFS" > et si aucun volume n'est par là remonté (signe que le bloc n°409640 n'est pas le super-bloc du NTFS toujours inscrit sur les blocs) : b) recréer un descripteur GPT assignant le bloc411648 en bloc de tête d'une partition de type "Windows_NTFS" et croiser les doigts.

D'accord ?
 
  • J’aime
Réactions: litobar71 et Vinzzz25
Ok, présenté comme tel ça me paraît être le maximum que nous pouvons faire.

Tu veux commencer par le résultat de ton expérience : bloc n°411648 ; ou par la théorie avec le premier bloc libre : n° 409640 ?
 
On va commencer par le bloc canonique n° 409640 => ainsi : en cas d'échec => il y aura toujours espoir que le n° 411648 fonctionne.

- passe la commande (copier-coller) :​
Bloc de code:
sudo gpt add -b 409640 -s 5860123488 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -i 2 disk2 ; diskutil list disk2

  • la commande crée un descripteur GPT de partition telle que : bloc de tête = n° 409640 > extension = 5860123488 blocs (de 512 octets = 3000,38 Go - j'ai défalqué 7 blocs pour ménager le tampon de 7 blocs libres canonique séparant la queue de la dernière partition du header de la GPT secondaire de fin de disque) > type = "Windows_NTFS" (via son UUID universel de type = EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) > rang = n°2 ; puis affiche la configuration du DDE

Poste le retour.
 
Bloc de code:
MacBook-Air-de-Thomas:~ Thomas$ sudo gpt add -b 409640 -s 5860123488 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -i 2 disk2 ; diskutil list disk2
Password:
disk2s2 added
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk2
   1:                        EFI                         209.7 MB   disk2s1
   2:       Microsoft Basic Data                         3.0 TB     disk2s2
MacBook-Air-de-Thomas:~ Thomas$
 
Comme tu peux le voir -->
Bloc de code:
   2:       Microsoft Basic Data                         3.0 TB     disk2s2

  • partition de 3 To gérés. Type Microsoft Basic Data (j'ai constaté que le même UUID de type valait comme Mirosoft Basic Data ou Windows_NTFS). Mais aucun volume redéfini sur la partition. Donc le bloc409640 de tête de la partition n'a pas récupéré le super-bloc du ntfs.

On tente l'autre scénario ?
 
Passe d'abord la commande :
Bloc de code:
sudo gpt remove -i 2 disk2

  • qui supprime le descripteur2 dans la GPT

Poste le retour.
 
Bloc de code:
MacBook-Air-de-Thomas:~ Thomas$ sudo gpt remove -i 2 disk2
Password:
disk2s2 removed
MacBook-Air-de-Thomas:~ Thomas$
 
Descripteur supprimé (donc partition supprimée). On tente avec le bloc spéculatif n° 411648.

- passe la commande (copier-coller) :​
Bloc de code:
sudo gpt add -b 411648 -s 5860121480 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -i 2 disk2 ; diskutil list disk2

  • la commande crée un descripteur GPT de partition telle que : bloc de tête = n° 411648 > extension = 5860121480 blocs (de 512 octets = 3000,38 Go - j'ai défalqué 2015 blocs pour ménager le tampon de 1031 Ko de blocs libres séparant la queue de la dernière partition du header de la GPT secondaire de fin de disque - ce d'après l'expérience faite sur ma clé USB) > type = "Windows_NTFS" (via son UUID universel de type = EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) > rang = n°2 ; puis affiche la configuration du DDE

Poste le retour.
 
Bloc de code:
MacBook-Air-de-Thomas:~ Thomas$ sudo gpt add -b 411648 -s 5860121480 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -i 2 disk2 ; diskutil list disk2
Password:
disk2s2 added
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk2
   1:                        EFI                         209.7 MB   disk2s1
   2:       Microsoft Basic Data                         3.0 TB     disk2s2
MacBook-Air-de-Thomas:~ Thomas$

Échec ...