10.14 Mojave Le disque que vous avez inséré n'est pas lisible par cet ordinateur... ?

Disons que la table de partition GPT a été supprimée sans recréation.

Passe la commande :
Bloc de code:
sudo gpt create /dev/disk2 ; diskutil list /dev/disk2

  • la commande crée une table GPT vide sur le départ du disque > puis affiche la configuration du disque

Poste le retour.
 
Coupe de nouveau la commande. Puis éteins ton G4. Débranche le disque -->

- on ne peut rien faire dans ce dispositif.​

On peut éventuellement tenter encore quelques manipulations le disque branché à ton mini.
 
Est-ce que c'est un SSD 2,5" qui avait été mis dans le mini en remplacement d'un HDD (rotatif) d'origine ?
 
J'en suis toujours à me demander pour quelle raison le bloc logique utilisé pour configurer ce disque a toujours une taille de 4096 octets. Cela tiendrait-il au disque ? - ce qui fait qu'au départ > la table de partition aurait utilisé cette mesure de bloc ? - mais avec une configuration correspondant à Yosemite --> donc une partition EFI de rang 1 de 209,7 Mo (je n'ai jamais constaté de partition EFI de 314 Mo avec les OS anciens).

- tu es sûr que le dernier OS installé était Yosemite (10.10) ? - pas un OS de format apfs (High Sierra ou Mojave) ?​
 
Dernière édition par un modérateur:
Le lien de Moonwalker :coucou: indique que certains disques récents ont une implémentation du bloc en taille de 4096 octets -->

- en se basant sur cette informations > on peut conjecturer que la configuration du disque d'origine (avec l'OS Yosemite) utilisait cette valeur du bloc logique. Mais avec (je présume) la taille classique de 209,7 Mo pour la partition EFI. Ce qui est important pour déterminer le 1er bloc vacant après cette partition > qui est toujours le super-bloc du système de fichiers de la partition qui suit.​

=> on reprendra en se basant sur ces considérations. Je dois m'absenter. Je reviendrai plus tard dans ton fil pour une dernière tentative de restauration de la table GPT d'origine.
 
Tu n'as qu'à rebrancher le disque à ton Mac > repasser la commande :
Bloc de code:
diskutil list

  • et poster le tableau des disques => que je voie l'index du SSD et sa configuration actuelle.
 
Je suis de retour...

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD Photos     999.9 GB   disk0s2

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                 Apple_APFS Container disk2         1000.0 GB  disk1s2

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk2
                                 Physical Store disk1s2
   1:                APFS Volume Macintosh SSD           135.0 GB   disk2s1
   2:                APFS Volume Preboot                 62.7 MB    disk2s2
   3:                APFS Volume Recovery                507.2 MB   disk2s3
   4:                APFS Volume VM                      2.1 GB     disk2s4

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *500.1 GB   disk3
 
Voici le disque -->
Bloc de code:
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *500.1 GB   disk3

  • blanc de configuration. On va admettre en hypothèse que c'est la nature de ce SSD qui impose une valeur du bloc logique de 4096 octets. On conclut de cette hypothèse que cette valeur de bloc a prévalu aussi lors de la configuration du disque sur l'ancien mini.

Cela admis > on a 2 paires de variables à gérer :

- a) la taille de la partition EFI de rang n°1 : 209,7 Mo ou 314,6 Mo ? - la variation de taille de cette partition toujours créée par défaut avec une table GPT --> dépend-elle de la valeur de bloc du disque ? - ou de l'OS installé ?​

- b) le type de la partition OS X de rang n°2 : "Apple_HFS" ou "Apple_CoreStorage" ?​

=> on s'aperçoit qu'il y a 4 configurations à tester : chacun des 2 types avec une EFI de 209,7 Mo > puis les mêmes avec une EFI de 314,6 Mo. Si la taille de la partition EFI est décisive > c'est que le 1er bloc vacant après elle est le bloc de tête de la partition OS X qui suit - aucun bloc libre ne séparant par défaut la partition OS X de la partition EFI qui la précède. On cherche donc à recreér une partition OS X dans le bon type > dont le bloc de tête serait le super-bloc (bloc d'ancrage) du système de fichiers jhfs+ (formateur d'un volume Macintosh HD) - qu'on espère toujours intact sur les blocs.

----------

On va partir sur la configuration qu'impose ton OS Mojave (EFI de 314,6 Mo). Passe la commande :
Bloc de code:
sudo diskutil eraseDisk free null gpt disk3 ; diskutil list disk3 ; sudo gpt show disk3

  • la commande remet une GPT + une seule partition EFI sur le disque > affiche la configuration du SSD > puis le tableau de la distribution de ses blocs.

Poste le retour complet.
 
Bloc de code:
Password:
Started erase on disk3
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Finished erase on disk3
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk3
   1:                        EFI EFI                     314.6 MB   disk3s1
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2          4         Pri GPT table
          6      76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      76806  122019835        
  122096641          4         Sec GPT table
  122096645          1         Sec GPT header
 
On voit que la partition EFI créée par défaut a une taille de 314,6 Mo. Le 1er bloc vacant à la suite est le n°76806 --> on se donne en hypothèse qu'il s'agisse du bloc de tête de la partition OSX qui suit.

Il faut à présent gérer la fin de la partition OS X spéculative > sachant qu'une partition de secours de rang n°3 s'intercale toujours entre la fin de la partition OS X et le début de la GPT secondaire (le backup de la GPT en queue de disque). Le 1er bloc de cette GPT secondaire étant le n° 122096641 --> on sait que la partition de secours s'arrêtait au bloc n°122096640 (ou 122096639 - si un bloc libre de 4096 octets séparait cette partition de secours de la GPT secondaire). Cette dernière incertitude n'aide pas à la manœuvre. On va admettre zéro bloc de séparation en cas de valeur de bloc de 4096 octets.

La taille d'une partition de secours classique est toujours de 650 Mo --> soit exactement 1269536 blocs de 512 octets. Cette extension divisée par 8 pour tenir compte du bloc de 4096 octets => donne exactement 158692 blocs.

La bande d'espace libre actuelle est de 122019835 blocs (4096 octets) - 158692 blocs (partition de secours théorique) => 121861143 blocs de 4096 octets comme taille de la partition OS X (= 974889144 blocs de 512 octets = 499.14 Go). Ce qui me gêne est qu'il s'agisse d'un nombre impair - jamais employé pour une partition qui a toujours une extension paire. On va donc admettre qu'il y a un bloc libre baladeur et réduire la taille de la partition à 121861142 blocs.

----------

Passe la commande (qui tient compte des attendus qui précèdent) :
Bloc de code:
sudo gpt add -b 76806 -s 121861142 -t 48465300-0000-11AA-AA11-00306543ECAC -i 2 disk3 ; diskutil list disk3

  • la commande crée un descripteur GPT de partition telle que : bloc de tête = n° 76806 > extension = 121861142 blocs (de 4096 octets = 499.14 Go) > type = "Apple_HFS" (via l'UUID de ce type - on teste ici le type "Apple_HFS") > rang = n°2 ; puis elle affiche la configuration du SSD

Poste le retour complet.
 
Bloc de code:
Password:
disk3s2 added
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk3
   1:                        EFI EFI                     314.6 MB   disk3s1
   2:                  Apple_HFS                         499.1 GB   disk3s2
 
Cette nouvelle partition créée -->
Bloc de code:
   2:                  Apple_HFS                         499.1 GB   disk3s2

  • dans le type "Apple_HFS" n'apparaît que comme un conteneur de blocs bruts. Aucun volume n'est affiché sur la partition > ce qui montre que : soit le bloc de tête de la partition n'est pas le super-bloc du système de fichiers toujours résident > soit le type "Apple_HFS" de la partition n'est pas le bon > soit le système de fichiers n'est plus résident des blocs (car il y aurait eu reformatage) > soit le système de fichiers existe mais est corrompu. On fait preuve d'optimisme pour l'instant en écartant le 3è et le 4è cas. Il faut donc gérer une variation du type de partition (le seul autre type possible pour un OS Yosemite ayant pu être "Apple_CoreStorage") > puis une variation du bloc de tête.
  • il faut savoir que > quand on recrée un descripteur de partition adéquat > tel que le 1er bloc de la partition récupère le super-bloc d'un système de fichiers toujours résident => alors immédiatement le kernel reprend en charge ce système de fichiers > ce qui redéfinit un volume sur la partition que le kernel remonte. On n'est donc pas dans ce cas de figure ici.
----------

Avant de tester le type "Apple_CoreStorage" de partition pour la même localisation de partition > je te propose quelques explorations annexes.

Passe la commande :
Bloc de code:
diskutil info disk3s2

  • qui affiche un tableau d'informations sur la partition

Poste le retour --> qui saura révéler l'existence d'un système de fichiers s'il y en a toujours un de résident.
 
Bloc de code:
  Device Identifier:         disk3s2
   Device Node:               /dev/disk3s2
   Whole:                     No
   Part of Whole:             disk3

   Volume Name:              
   Mounted:                   No

   Partition Type:            Apple_HFS
   File System Personality:   HFS+
   Type (Bundle):             hfs
   Name (User Visible):       Mac OS Extended
   Journal:                   Unknown (not mounted)
   Owners:                    Disabled

   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  USB
   SMART Status:              Not Supported
   Disk / Partition UUID:     7D33024D-63AB-4915-8FDD-CEA5EC0E49A4
   Partition Offset:          314597376 Bytes (76806 4096-Byte-Device-Blocks)

   Disk Size:                 499.1 GB (499143237632 Bytes) (exactly 974889136 512-Byte-Units)
   Device Block Size:         4096 Bytes

   Volume Total Space:        0 B (0 Bytes) (exactly 0 512-Byte-Units)
   Volume Free Space:         0 B (0 Bytes) (exactly 0 512-Byte-Units)

   Read-Only Media:           No
   Read-Only Volume:          Not applicable (not mounted)

   Device Location:           External
   Removable Media:           Fixed
 
Ces mentions -->
Bloc de code:
   File System Personality:   HFS+
   Type (Bundle):             hfs
   Name (User Visible):       Mac OS Extended
   Journal:                   Unknown (not mounted)
   Owners:                    Disabled

  • paraissent déclarer qu'un système de fichiers existe bien à partir du bloc de tête de la partition > dont la personnalité est hfs+ (Mac OS étendu - non journalisé) > avec désactivation des propriétés. Aucun volume d'un nom donné ne se trouvant formé par ce système de fichiers => ce qui pourrait vouloir dire que ce système de fichiers hfs+ est trop corrompu (par des erreurs graves) pour pouvoir encore définir un volume (montable ou non) sur la partition.

Passe la commande :
Bloc de code:
diskutil veriyVolume disk3s2

  • la commande lance une procédure de vérification du système de fichiers hfs+ > s'il existe bien sur l'en-tête de la partition recréée

Poste l'affichage retourné par la commande.