10.14 Mojave Probleme de partition apres clonage SSD

Nas_0 · 30 Septembre 2018

Bonjour,

Après avoir cloné un disque dur de 500 GB sur un disque 1 TB, je me suis retrouvé avec 500 GB d'espace non alloué car j'ai malheureusement fait un clonage secteur par secteur (j'aurais du faire une image...). Cet espace était invisible sous macOS, j'ai vérifié dans Disk Utility et également exécuté la commande diskutil list, mais elle n'apparaissait nul part malgré la taille de 1 TB du disque bien indiquée. Pour récupérer cet espace inutilisable, j'ai eu la mauvaise idée depuis Windows (le mac avait 2 partition à ce moment la, une partition BOOTCAMP & une partition macOS) d'utiliser un logiciel tiers (EaseUS) pour rendre la partition non allouée active puis la redistribuer à ma partition BOOTCAMP. Sauf que ce programme a déplacé la partie non allouée entre/au milieu de mes partition macOS & BOOTCAMP, et je n'ai pas pu étendre la partition BOOTCAMP entièrement dessus. De ce fait je ne peux plus booter sur ma partition BOOTCAMP (elle ne s'affiche plus au démarrage), ni lire les fichiers qu'il y a dessus depuis macOS. Je me retrouve à la place avec un disque "Untitled" (disk0s3, voir image plus bas) dont je ne peux rien faire

Voici ce qui s'affiche lorsque j’exécute diskutil list :

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_APFS Container disk1         300.7 GB   disk0s2
   3:       Microsoft Basic Data                         199.2 GB   disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +300.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            271.8 GB   disk1s1
   2:                APFS Volume Preboot                 33.2 MB    disk1s2
   3:                APFS Volume Recovery                512.1 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

Et ici dans Disk Utility :

Auriez-vous une solution pour me permettre de récupérer ma partition BOOTCAMP et également l'espace inutilisable (j'ai déjà installé gdisk & également désactivé le SIP car il bloquait certaines commandes) ? Je vous serais très reconnaissant pour toute aide !

Membre supprimé 1060554 · 30 Septembre 2018

Bonsoir Nas

Pour savoir où est située la bande des blocs libres sur le disque > il faut utiliser la commande gpt > mais celle-ci est bloquée (même en simple lecture) si le SIP (protocole de sécurisation) est activé.

Donc passe la commande :

Bloc de code:

csrutil status

qui affiche le statut du SIP

Poste le retour.

Nas_0 · 30 Septembre 2018

macomaniac a dit:
Bonsoir Nas

Pour savoir où est située la bande des blocs libres sur le disque > il faut utiliser la commande gpt > mais celle-ci est bloquée (même en simple lecture) si le SIP (protocole de sécurisation) est activé.

Donc passe la commande :

Bloc de code:

csrutil status

qui affiche le statut du SIP

Poste le retour.

Bonsoir,

Merci pour votre réponse, le SIP est déjà désactivé

Membre supprimé 1060554 · 30 Septembre 2018

Alors passe la commande :

Bloc de code:

sudo gpt show disk0

à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne s'affichant à la frappe - et revalide [indication inutile si tu es familier de sudo]

la commande affiche le tableau de la distribution des blocs du disque : secteur des tables de partitions > partitions > bandes de blocs libres > backup de la GPT

=> poste le tableau.

Nas_0 · 30 Septembre 2018

Merci beaucoup. Voici le tableau:

Bloc de code:

gpt show: disk0: Suspicious MBR at sector 0
       start        size  index  contents
           0           1         MBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6        
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640   587304920      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
   587714560   389058560      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
   976773120   976752015        
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header

Nas_0 · 30 Septembre 2018

macomaniac a dit:
Alors passe la commande :

Bloc de code:

sudo gpt show disk0

à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne s'affichant à la frappe - et revalide [indication inutile si tu es familier de sudo]

la commande affiche le tableau de la distribution des blocs du disque : secteur des tables de partitions > partitions > bandes de blocs libres > backup de la GPT

=> poste le tableau.

Merci beaucoup. Voici le tableau:

Bloc de code:

gpt show: disk0: Suspicious MBR at sector 0
       start        size  index  contents
           0           1         MBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6        
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640   587304920      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
   587714560   389058560      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
   976773120   976752015        
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header

Membre supprimé 1060554 · 30 Septembre 2018

Tu t'aperçois que les 3 partitions décrites dans la GPT : 1 = EFI > 2 = APFS > 3 = Windows --> se trouvent alignées sans espaces libres du bloc n°40 au bloc n° 976773119 -->

Bloc de code:

       40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
   409640   587304920      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
587714560   389058560      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

quant à l'espace libre > il est situé en queue de disque du bloc n° 976773120 au bloc n° 1953525134 -->

Bloc de code:

   976773120   976752015

les 33 blocs que tu vois situés en-dessous constituant l'espace de sauvegarde de la table GPT principale -->

Bloc de code:

  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header

Les 976752015 blocs libres constituent un espace de 500.09 Go. je ne sais pas bien quelles sont tes intentions --> car les possibilités de manœuvre sont restreintes. Tout dépend si tu acceptes de supprimer la partition Windows qui fait tampon ou non...

Nas_0 · 30 Septembre 2018

macomaniac a dit:
Tu t'aperçois que les 3 partitions décrites dans la GPT : 1 = EFI > 2 = APFS > 3 = Windows --> se trouvent alignées sans espaces libres du bloc n°40 au bloc n° 976773119 -->

Bloc de code:

40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 587304920 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC 587714560 389058560 3 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

quant à l'espace libre > il est situé en queue de disque du bloc n° 976773120 au bloc n° 1953525134 -->

Bloc de code:

976773120 976752015

les 33 blocs que tu vois situés en-dessous constituant l'espace de sauvegarde de la table GPT principale -->

Bloc de code:

1953525135 32 Sec GPT table 1953525167 1 Sec GPT header

Les 976752015 blocs libres constituent un espace de 500.09 Go. je ne sais pas bien quelles sont tes intentions --> car les possibilités de manœuvre sont restreintes. Tout dépend si tu acceptes de supprimer la partition Windows qui fait tampon ou non...

Mon objectif est enfaite de récupérer ma partition Windows si possible, et de récupérer l'espace inutilisable sur le disque. Pourriez vous m’éclairer sur ce que veut dire "la partition Windows qui fait tampon" s'il vous plait ?
Concerant la suppression de cette partition, dans le pire des cas je possède un ancien backup de la partition Windows, mais l’idéal serait de conserver la partition actuelle, si c'est possible bien sur

Membre supprimé 1060554 · 30 Septembre 2018

L'actuelle partition Windows n°3 est intercalée entre la partition APFS n°2 (qui exporte le Conteneur disk1 ou espace-disque virtuel) & la bande de blocs libres de queue de disque de 500 Go. On ne peut donc pas récupérer les 500 Go à la partition n°2 APFS > à cause de la partition intercalaire n°2 de Windows. C'était le sens de mon "tampon" : obstacle si tu préfères à une récupération de l'espace libre à la partition APFS.

Il est possible de recréer une partition montant un volume avec la bande des 500 Go de blocs libres de queue de disque (pas de difficulté).

L'actuelle partition Windows ne boote pas pour une raison évidente : elle n'a pas de volume (intitulé BOOTCAMP) défini sur cette partition.

La difficulté que j'ai --> c'est de me représenter exactement l'état initial du disque avant que tu n'utilises le logiciel EaseUS > et ce qu'a fait exactement ce logiciel -->

est-ce que tu as utilisé dd (data_doubler) au départ pour cloner (en mode "copie de blocs") un disque de 500 Go sur ton 1 To ? --> parce que dd convertit alors les 500 Go de blocs excédentaires de la partition de destination par rapport à la partition souce en "null_blocs" (marqués par des *) --> qui n'apparaissent pas comme de l'espace géré par le système de fichiers de la partition qui les contient.

est-ce que les 500 Go de null_blocs étaient situés au départ au-dessus de la partition Windows ? --> ce qui fait que la partition Windows existait au départ (en tant que bootable) sur les 389058560 blocs de queue de disque (juste au-dessus des 33 blocs du backup de la GPT) ? Ton logiciel ayant alors effectué un faux clone de la partition Windows de queue de disque > sur une bande de blocs récupérés des null_blocs juste attenante à la partition APFS ?

=> comme tu le vois > je me demande où était située exactement la partition Windows au départ ? - est-ce que tu as toujours le disque de 500 Go qui a servi de source à ton clonage ?

Nas_0 · 1 Octobre 2018

macomaniac a dit:
L'actuelle partition Windows n°3 est intercalée entre la partition APFS n°2 (qui exporte le Conteneur disk1 ou espace-disque virtuel) & la bande de blocs libres de queue de disque de 500 Go. On ne peut donc pas récupérer les 500 Go à la partition n°2 APFS > à cause de la partition intercalaire n°2 de Windows. C'était le sens de mon "tampon" : obstacle si tu préfères à une récupération de l'espace libre à la partition APFS.

Il est possible de recréer une partition montant un volume avec la bande des 500 Go de blocs libres de queue de disque (pas de difficulté).

L'actuelle partition Windows ne boote pas pour une raison évidente : elle n'a pas de volume (intitulé BOOTCAMP) défini sur cette partition.

La difficulté que j'ai --> c'est de me représenter exactement l'état initial du disque avant que tu n'utilises le logiciel EaseUS > et ce qu'a fait exactement ce logiciel -->

est-ce que tu as utilisé dd (data_doubler) au départ pour cloner (en mode "copie de blocs") un disque de 500 Go sur ton 1 To ? --> parce que dd convertit alors les 500 Go de blocs excédentaires de la partition de destination par rapport à la partition souce en "null_blocs" (marqués par des *) --> qui n'apparaissent pas comme de l'espace géré par le système de fichiers de la partition qui les contient.

est-ce que les 500 Go de null_blocs étaient situés au départ au-dessus de la partition Windows ? --> ce qui fait que la partition Windows existait au départ (en tant que bootable) sur les 389058560 blocs de queue de disque (juste au-dessus des 33 blocs du backup de la GPT) ? Ton logiciel ayant alors effectué un faux clone de la partition Windows de queue de disque > sur une bande de blocs récupérés des null_blocs juste attenante à la partition APFS ?

=> comme tu le vois > je me demande où était située exactement la partition Windows au départ ? - est-ce que tu as toujours le disque de 500 Go qui a servi de source à ton clonage ?

Pour le premier point : j'ai effectivement utilisé dd pour cloner le disque de 500 Go sur le 1 To
Les 500 Go de null_blocs étaient situés après la partition Windows, en queue de disque. Il n'y avait aucune partition séparant Macintosh HD et BOOTCAMP

J'ai encore le disque de 500 Go qui a servi de source au clonage si ça peut aider:

Membre supprimé 1060554 · 1 Octobre 2018

Alors attache ton disque de 500 Go au Mac (boîtier USB par exemple) > et passe les 2 commandes :

Bloc de code:

diskutil list
sudo gpt show disk2

d'après le tableau des disques retournés par la 1ère commmande --> tu peux vérifier si le disque externe de 500 Go est bien disk2 (sinon adapte son n° dans la 2è commande)

Poste les 2 tableaux : disques et distribution des blocs du disque externe --> je verrai en quoi consiste le paradigme qu'a utilisé la commande dd.

Nas_0 · 1 Octobre 2018

macomaniac a dit:
Alors attache ton disque de 500 Go au Mac (boîtier USB par exemple) > et passe les 2 commandes :

Bloc de code:

diskutil list sudo gpt show disk2

d'après le tableau des disques retournés par la 1ère commmande --> tu peux vérifier si le disque externe de 500 Go est bien disk2 (sinon adapte son n° dans la 2è commande)

Poste les 2 tableaux : disques et distribution des blocs du disque externe --> je verrai en quoi consiste le paradigme qu'a utilisé la commande dd.

Bonsoir,

Je ne pouvais pas lancer les commandes lorsque le disque était branché en externe, mais j'avais besoin de Windows, j'ai donc remis l'ancien disque dur de 500 GB dans mon PC et voici ce que donne les commandes :

Bloc de code:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         300.7 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                199.2 GB   disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +300.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            294.6 GB   disk1s1
   2:                APFS Volume Preboot                 29.6 MB    disk1s2
   3:                APFS Volume Recovery                511.8 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

Bloc de code:

gpt show: disk0: Suspicious MBR at sector 0
      start       size  index  contents
          0          1         MBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6        
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  587304920      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  587714560  389058560      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773120         15        
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header

Merci pour votre aide précieuse

Membre supprimé 1060554 · 1 Octobre 2018

En comparant les 2 tableaux de distribution des blocs des disques --> je note que les alignements sont rigoureusement identiques à partir du 1er bloc du disque (bloc 0 qui porte une HMBR = Hybrid_MBR) => jusqu'au bloc de terminaison de la partition n°3 de Windows.

C'est à partir du bloc n° 976773120 seulement (= 1er bloc libre en-dessous de la partition Windows) que l'absence de blocs supplémentaires du disque de 500 Go --> a été dupliquée par dd sous forme de null_blocs = blocs neutralisés de la table de partition sur le disque de 1 To. Ce jusqu'aux 33 blocs de queue de disque où l'on retrouve dans les 2 cas le même alignement qui porte le backup de la GPT.

J'en déduis que l'actuelle partition n°3 Windows ne diffère en rien dans sa description dans la table principale GPT (et présumé-je dans sa description dans la table alternative HMBR du bloc 0 utilisée pour booter Windows-7 en mode Legacy) --> d'un disque à l'autre. La seule différence est la définition d'un volume BOOTCAMP sur la partition n°3 du disque de 500 Go > et son absence sur la partition homologue du disque de 1 To.

Je m'interroge sur les raisons de cette non-définition d'un volume BOOTCAMP sur la partition n°3 du disque de 1 To. En tout cas > grâce à ton comparatif des tableaux gpt --> j'ai une idée parfaitement claire & distincte des alignements de partitions sur les blocs > qui équivaut au constat de leur identité au bloc près d'un disque à l'autre.

Est-ce que ton disque de 1 To (non démarré) peut être attaché en au Mac ?

Nas_0 · 1 Octobre 2018

macomaniac a dit:
En comparant les 2 tableaux de distribution des blocs des disques --> je note que les alignements sont rigoureusement identiques à partir du 1er bloc du disque (bloc 0 qui porte une HMBR = Hybrid_MBR) => jusqu'au bloc de terminaison de la partition n°3 de Windows.

C'est à partir du bloc n° 976773120 seulement (= 1er bloc libre en-dessous de la partition Windows) que l'absence de blocs supplémentaires du disque de 500 Go --> a été dupliquée par dd sous forme de null_blocs = blocs neutralisés de la table de partition sur le disque de 1 To. Ce jusqu'aux 33 blocs de queue de disque où l'on retrouve dans les 2 cas le même alignement qui porte le backup de la GPT.

J'en déduis que l'actuelle partition n°3 Windows ne diffère en rien dans sa description dans la table principale GPT (et présumé-je dans sa description dans la table alternative HMBR du bloc 0 utilisée pour booter Windows-7 en mode Legacy) --> d'un disque à l'autre. La seule différence est la définition d'un volume BOOTCAMP sur la partition n°3 du disque de 500 Go > et son absence sur la partition homologue du disque de 1 To.

Je m'interroge sur les raisons de cette non-définition d'un volume BOOTCAMP sur la partition n°3 du disque de 1 To. En tout cas > grâce à ton comparatif des tableaux gpt --> j'ai une idée parfaitement claire & distincte des alignements de partitions sur les blocs > qui équivaut au constat de leur identité au bloc près d'un disque à l'autre.

Est-ce que ton disque de 1 To (non démarré) peut être attaché en au Mac ?

Il peut être branché au Mac mais je ne sais pourquoi disk utility se fige au lancement et il ne s'affiche pas dans finder (peut-être car les disques sont identiques ?). Cependant les commandes fonctionnent et il s'affiche bien dans dans diskutil list

Membre supprimé 1060554 · 1 Octobre 2018

Le 1 To attaché au Mac > peux-tu passer la commande :

Bloc de code:

diskutil list

et poster le tableau de disques ?

Nas_0 · 1 Octobre 2018

macomaniac a dit:
Le 1 To attaché au Mac > peux-tu passer la commande :

Bloc de code:

diskutil list

et poster le tableau de disques ?

Voici le résultat :

Bloc de code:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         300.7 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                199.2 GB   disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +300.7 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            295.0 GB   disk1s1
   2:                APFS Volume Preboot                 29.6 MB    disk1s2
   3:                APFS Volume Recovery                511.8 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         300.7 GB   disk2s2
   3:       Microsoft Basic Data                         199.2 GB   disk2s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +300.7 GB   disk3
                                 Physical Store disk2s2
   1:                APFS Volume Macintosh HD            271.8 GB   disk3s1
   2:                APFS Volume Preboot                 33.2 MB    disk3s2
   3:                APFS Volume Recovery                512.2 MB   disk3s3
   4:                APFS Volume VM                      2.1 GB     disk3s4

Information importante également, d'après ce que j'ai pu comprendre de vos explications, les tables de partition sont identiques sur les deux disques : cependant avant que je ne puisse plus booter sur Windows, j'ai pu constater dans Disk Management (sous Windows, juste après l'operation d'EaseUS) que la partition BOOTCAMP se situait après l'espace libre, ce qui n'est pas ce qui est indiqué par la table de partition sous macOS (a moins que j'aie mal compris ? corrigez moi si c'est le cas). Au passage la partition non allouée a été transformée en partition active puis formatée en NTFS par EaseUS

Nas_0 · 1 Octobre 2018

macomaniac a dit:
Le 1 To attaché au Mac > peux-tu passer la commande :

Bloc de code:

diskutil list

et poster le tableau de disques ?

D'apres ce que vous avez dit plus haut, est-il possible que la description dans la table alternative HMBR ait été modifiée par les operations d'EaseUS, et serait la raison pour laquelle Windows n'est plus bootable ?

D'ailleurs j'ai aussi eu la mauvaise idée de mettre a jour le Mac (Mojave) juste avant de créer le sujet sur le forum, en me disant que des reparations de la table de partition pourraient être faite lors de l'installation. Avant la mise a jour, Windows était encore bootable mais ne s'affichait plus comme avant qu'EaseUS fasse des changements, c'est a dire que la partition ne portait plus le nom de BOOTCAMP et était illisible sous macOS, ce qui n'était pas le cas avant.

Membre supprimé 1060554 · 2 Octobre 2018

Une partition existe sur un disque par un descripteur de cette partition dans la table de partition de l'en-tête du disque. Ce descripteur définit la localisation de la partition sur les blocs (bloc de départ ou bloc 0 de la partition = n° 587714560 ici & extension en nombre de blocs de la partition = 389058560 ici) > rang de la partition (n°3 ici) > type de la partition (hex code 0700 ou UUID universel EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 ici pour Microsoft Basic Data) > indicateur de caractère démarrable enfin (bootable flag * pour cette partition).

Un volume existe sur une partition > non pas par la description qui en est faite dans la table de partition > mais par un système de fichiers inscrit sur les blocs de la partition à partir d'un bloc privilégié qui est le bloc 0 de la partition : ce bloc 0 constitue le point d'ancrage du système de fichiers et porte son header (ou en-tête). Le système de fichiers définit l'espace des blocs de la partition comme un registre de fichiers lisibles et manipulables > càd. un volume : on dira donc que la structure logique du système de fichiers est la génératrice de la définition d'un volume sur la partition. Pour la partition qui nous occupe > il s'agit d'un système de fichiers Windows_NTFS.

2 conditions logiques doivent donc se trouver réunies pour qu'un volume existe sur une partition --> une description valide de la partition dans la table de partition & un système de fichiers valide inscrit sur les blocs de la partition à partir du point d'ancrage de son bloc 0. Si ces conditions se trouvent réunies > alors -->

dans le temps du boot > le programme interne de boot du Mac (l'EFI) > peut lire le descripteur de la partition dans la table de partition > et adresser le bloc 0 de la partition pour activer le système de fichiers de cette partition > afin de monter le volume défini par le système de fichiers > et aller exécuter le boot_loader du Système recelé dans le volume. C'est ce qu'on peut appeler le pré-démarrage d'un Système par l'EFI.

dans le temps de la session d'utilisateur > le noyau du Système macOS (le kernel) > peut lire le descripteur de la table de partition > activer le système de fichiers de la partition > et prendre en charge le volume défini par le système de fichiers. C'est ce qu'on peut appeler le montage du volume par le kernel.

Membre supprimé 1060554 · 2 Octobre 2018

L'inspection des 2 tables de distribution des blocs du disque source (500 Go) & du disque destination (1 To) --> montre que le partition de rang n°3 du disque de destination se trouve exactement décrite à l'identique de son modèle sur le disque source : localisation sur les blocs > rang > type de partition. Il s'ensuit nécessairement comme conséquence logique que > lorsque le Système macOS de la partition apfs n°2 est démarré > le service (daemon) de cet OS = diskarbitrationd (qui opère la probation des systèmes de fichiers) --> doit pouvoir adresser le bloc n° 0 de la partition n° 3 > pour effectuer la vérification du système de fichiers Windows_NTFS de la partition et > en cas de validation > passer au kernel de macOS la tâche de prendre en charge ("activer") ce système de fichiers en montant le volume qu'il définit sur la partition de référence.

Ce qui n'arrive pas > puisqu'aucun volume du nom de BOOTCAMP ne se trouve assigné sur la partition n°3. C'est donc la probation par diskarbitrationd du système de fichiers Windows_NTFS existant à partir du bloc 0 de la partition --> qui conduit à un déni d'activation par le kernel du système de fichiers --> et par là à l'invalidation de la définition d'un volume montable.

Il faut donc inspecter le système de fichiers résident de la partition n°3 du disque de 1 To à partir du bloc 0. Il est possible que ce système de fichiers ait été corrompu par ton logiciel > et ne passe pas l'épreuve de la probation par diskarbitrationd.

Nas_0 · 2 Octobre 2018

macomaniac a dit:
L'inspection des 2 tables de distribution des blocs du disque source (500 Go) & du disque destination (1 To) --> montre que le partition de rang n°3 du disque de destination se trouve exactement décrite à l'identique de son modèle sur le disque source : localisation sur les blocs > rang > type de partition. Il s'ensuit nécessairement comme conséquence logique que > lorsque le Système macOS de la partition apfs n°2 est démarré > le service (daemon) de cet OS = diskarbitrationd (qui opère la probation des systèmes de fichiers) --> doit pouvoir adresser le bloc n° 0 de la partition n° 3 > pour effectuer la vérification du système de fichiers Windows_NTFS de la partition et > en cas de validation > passer au kernel de macOS la tâche de prendre en charge ("activer") ce système de fichiers en montant le volume qu'il définit sur la partition de référence.

Ce qui n'arrive pas > puisqu'aucun volume du nom de BOOTCAMP ne se trouve assigné sur la partition n°3. C'est donc la probation par diskarbitrationd du système de fichiers Windows_NTFS existant à partir du bloc 0 de la partition --> qui conduit à un déni d'activation par le kernel du système de fichiers --> et par là à l'invalidation de la définition d'un volume montable.

Il faut donc inspecter le système de fichiers résident de la partition n°3 du disque de 1 To à partir du bloc 0. Il est possible que ce système de fichiers ait été corrompu par ton logiciel > et ne passe pas l'épreuve de la probation par diskarbitrationd.

Je vous remercie pour ces explications détaillées, quelle serait donc la marche a suivre afin d'inspecter le système de fichiers et de le réparer ?

10.14 Mojave Probleme de partition apres clonage SSD

Membre actif

Fichiers joints

Membre supprimé 1060554

Invité

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Fichiers joints

Membre supprimé 1060554

Invité

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre actif

Membre supprimé 1060554

Invité

Membre supprimé 1060554

Invité

Membre actif

Sujets similaires