10.14 Mojave Probleme de partition apres clonage SSD

[Membre supprimé 1060554]

Passe une commande :

diskutil list

• et poste le tableau --> que je voie ce qui se passe...

 

[Nas_0]

Passe une commande :

diskutil list

• et poste le tableau --> que je voie ce qui se passe...

Voici:

/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            281.9 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

 

[Membre supprimé 1060554]

Un volume (null) est déclaré monté sur disk2s3 : effectivement on ne voit rien. Passe la commande :

diskutil info disk2s3

• et poste le tableau d'informations --> pour voir s'il y a quelque chose de changé par rapport au précédent ?

 

[Nas_0]

Un volume (null) est déclaré monté sur disk2s3 : effectivement on ne voit rien. Passe la commande :

diskutil info disk2s3

• et poste le tableau d'informations --> pour voir s'il y a quelque chose de changé par rapport au précédent ?

Device Identifier:        disk2s3
   Device Node:              /dev/disk2s3
   Whole:                    No
   Part of Whole:            disk2

   Volume Name:             
   Mounted:                  Yes
   Mount Point:              /Volumes/Untitled

   Partition Type:           Microsoft Basic Data
   File System Personality:  NTFS
   Type (Bundle):            ntfs
   Name (User Visible):      Windows NT File System (NTFS)

   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 USB
   SMART Status:             Not Supported
   Volume UUID:              BCFA8092-87C7-434C-AA28-C3F8CB679B5F
   Disk / Partition UUID:    301CE168-243C-4E09-BBA6-485F6828FB42

   Disk Size:                199.2 GB (199197982720 Bytes) (exactly 389058560 512-Byte-Units)
   Device Block Size:        512 Bytes

   Volume Total Space:       199.2 GB (199197978624 Bytes) (exactly 389058552 512-Byte-Units)
   Volume Used Space:        115.1 MB (115142656 Bytes) (exactly 224888 512-Byte-Units) (0.1%)
   Volume Available Space:   199.1 GB (199082835968 Bytes) (exactly 388833664 512-Byte-Units) (99.9%)
   Allocation Block Size:    4096 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Yes

   Device Location:          External
   Removable Media:          Fixed

 

[Membre supprimé 1060554]

Ceci -->

   Mounted:                  Yes
   Mount Point:              /Volumes/Untitled

• déclare qu'un volume intitulé (par substitut à aucun nom) : Untitled > est actuellement monté dans le répertoire invisible /Volumes (qui est l'espace de montage des volumes externes dans l'OS). Ce volume d'une capacité de 199,2 Go > ne contient actuellement que 115 Mo de données.

Passe la commande :

ls /Volumes

• qui liste les volumes actuellement montés dans le répertoire /Volumes

Poste la liste.

 

[Nas_0]

Ceci -->

   Mounted:                  Yes
   Mount Point:              /Volumes/Untitled

• déclare qu'un volume intitulé (par substitut à aucun nom) : Untitled > est actuellement monté dans le répertoire invisible /Volumes (qui est l'espace de montage des volumes externes dans l'OS). Ce volume d'une capacité de 199,2 Go > ne contient actuellement que 115 Mo de données.

Passe la commande :

ls /Volumes

• qui liste les volumes actuellement montés dans le répertoire /Volumes

Poste la liste.

Voila:

BOOTCAMP    Macintosh HD    Macintosh HD 1    Untitled

 

[Membre supprimé 1060554]

Le volume Untitled est donc bien monté at: /Volumes/Untitled. Passe les commandes :

ls -R /Volumes/Untitled
df -H /Volumes/Untitled

• la 1ère liste récursivement son contenu

• la 2è mesure son occupation

Poste les retours.

 

[Nas_0]

Le volume Untitled est donc bien monté at: /Volumes/Untitled. Passe les commandes :

ls -R /Volumes/Untitled
df -H /Volumes/Untitled

• la 1ère liste récursivement son contenu

• la 2è mesure son occupation

Poste les retours.

$RECYCLE.BIN            System Volume Information
$UGM

/Volumes/Untitled/$RECYCLE.BIN:
S-1-5-21-1956893261-1526230446-3030137657-1005
S-1-5-21-1956893261-1526230446-3030137657-1010
S-1-5-21-2800687128-566568502-1112790091-1000

/Volumes/Untitled/$RECYCLE.BIN/S-1-5-21-1956893261-1526230446-3030137657-1005:
desktop.ini

/Volumes/Untitled/$RECYCLE.BIN/S-1-5-21-1956893261-1526230446-3030137657-1010:
desktop.ini

/Volumes/Untitled/$RECYCLE.BIN/S-1-5-21-2800687128-566568502-1112790091-1000:
desktop.ini

/Volumes/Untitled/System Volume Information:
IndexerVolumeGuid        klmeta.dat
MountPointManagerRemoteDatabase    tracking.log
WPSettings.dat

Et

Filesystem     Size   Used  Avail Capacity iused     ifree %iused  Mounted on
/dev/disk2s3   199G   115M   199G     1%      43 194417073    0%   /Volumes/Untitled

 

[Membre supprimé 1060554]

Je pense que le logiciel que tu as utilisé a effacé les données de l'ancien volume BOOTCAMP. Il n'y a plus que les bribes que tu vois listées : autant dire rien.

Question : tu as toujours les données du volume BOOTCAMP du disque de 500 Go. Il démarre bien celui-là si tu mets le disque en interne au Mac ?

 

[Nas_0]

Je pense que le logiciel que tu as utilisé a effacé les données de l'ancien volume BOOTCAMP. Il n'y a plus que les bribes que tu vois listées : autant dire rien.

Question : tu as toujours les données du volume BOOTCAMP du disque de 500 Go. Il démarre bien celui-là si tu mets le disque en interne au Mac ?

Oui j'ai toujours les données du volume BOOTCAMP du disque de 500 Go, il démarre bien. Cependant ce n'est pas le logiciel qui a efface les données (si elles ont été effacées) mais la mise a jour vers Mojave. Car avant de mettre a jour le PC, j'avais encore accès a la partition Windows meme si elle ne s'affichait pas correctement sous MacOS : elle s'affichait comme actuellement "Untitled", le meme espace libre & utilisé sur le disque et également meme identifier (disk0s3)

 

[Membre supprimé 1060554]

Voici ce qui serait possible :

• supprimer l'actuelle partition ex-Windows qui ne recèle plus de données exploitables.

• recréer en bas de disque une partition d'un nombre de blocs strictement équivalent > même type.

• récupérer au Conteneur apfs tout l'espace libre intercalaire (500 Go) > ce qui règlerait cette question

• cloner en mode "copie de blocs" via dd > la partition BOOTCAMP valide > dans la partition d'égale taille créée en queue du disque de 1 To. Cela devrait recréer le système de fichiers NTFS et un volume BOOTCAMP avec les données.

• recréer (si requis) une HMBR sur le bloc 0 du 1 To --> afin que le volume BOOTCAMP recréé soit bootable en mode Legacy (question : l'OS contenu est-il Windows-7 ?)

=> qu'est-ce que tu en penses ?

 

[Nas_0]

Voici ce qui serait possible :

• supprimer l'actuelle partition ex-Windows qui ne recèle plus de données exploitables.

• recréer en bas de disque une partition d'un nombre de blocs strictement équivalent > même type.

• récupérer au Conteneur apfs tout l'espace libre intercalaire (500 Go) > ce qui règlerait cette question

• cloner en mode "copie de blocs" via dd > la partition BOOTCAMP valide > dans la partition d'égale taille créée en queue du disque de 1 To. Cela devrait recréer le système de fichiers NTFS et un volume BOOTCAMP avec les données.

• recréer (si requis) une HMBR sur le bloc 0 du 1 To --> afin que le volume BOOTCAMP recréé soit bootable en mode Legacy (question : l'OS contenu est-il Windows-7 ?)

=> qu'est-ce que tu en penses ?

Je pense qu'il n'y a pas d'autre solution de toute façon, mais juste avant de faire ça j'aimerais faire une image de mon disque 1 To actuel dans le cas ou je pourrais récupérer les données sous un autre Windows avec des commandes fdisk (on ne sait jamais, ça ne marchera certainement pas mais j'aimerais tenter le coup). Une fois l'image backup faite demain je ferais signe. Merci encore pour votre aide vous m'avez également appris beaucoup de choses

 

[Nas_0]

Voici ce qui serait possible :

• supprimer l'actuelle partition ex-Windows qui ne recèle plus de données exploitables.

• recréer en bas de disque une partition d'un nombre de blocs strictement équivalent > même type.

• récupérer au Conteneur apfs tout l'espace libre intercalaire (500 Go) > ce qui règlerait cette question

• cloner en mode "copie de blocs" via dd > la partition BOOTCAMP valide > dans la partition d'égale taille créée en queue du disque de 1 To. Cela devrait recréer le système de fichiers NTFS et un volume BOOTCAMP avec les données.

• recréer (si requis) une HMBR sur le bloc 0 du 1 To --> afin que le volume BOOTCAMP recréé soit bootable en mode Legacy (question : l'OS contenu est-il Windows-7 ?)

=> qu'est-ce que tu en penses ?

Bonjour Macomaniac,

Cela fait quelques jours que je n'ai pas pu revenir sur le problème. Tu as probablement oublié le sujet entre temps, mais si tu as le temps de relire, voici un point de ce que j'ai fait et découvert entre temps:

• Les données de la partition Windows n'ont pas été perdues, depuis un autre ordinateur j'ai lancé depuis un utilitaire un scan de partitions "perdues" dans l'espace non alloué : et effectivement la partition BOOTCAMP s'y trouvait et l'espace utilisé ainsi que la taille du disque indiqués étaient corrects. On peut donc en déduire que si BOOTCAMP ne s'affiche pas et n'est pas bootable c'est simplement car les données se trouvent dans la partie non allouée, et non à coté de la partition macOS. Question, sauriez vous par quelles commandes il serait possible de repérer des données sur une partition non allouée comme le font les utilitaires ?? car je ne trouve aucune information là dessus j'en suis très curieux
  
• Ensuite j'ai tenté une manip avec gdisk, j'ai crée une nouvelle table MBR hybride en suivant ces étapes:
  

  r <enter>
  
  h <enter>
  
  3 <enter> /* pour ajouter la 3ème partition de disk0 (qui s'affichait "Microsoft Basic Data" dans diskutil list) car elle semblait etre la partition BOOTCAMP. Mais je pense avoir fait une erreur en faisant cela car il y a normalement 4 partitions dans une configuration dual boot BOOTCAMP ?? */
  
  <enter> accept the default MBR hex code of 07
  
  y <enter> set the bootable flag
  
  n <enter> do not protect more partitions
  
  o < enter> print (display) the MBR
  
  w <enter>

Depuis cette manip, un Windows s'affiche dans les boot en maintenant alt/option, mais au démarrage il s'affiche "no operating system" : ce qui est normal car à cet emplacement il n'y a qu'une partition vide formatée en NTFS, donc juste un système de fichier sans OS. Comme je l'ai dit plus haut BOOTCAMP se trouve dans la partie non allouée donc cette manip était inutile, et il faudra certainement refaire une table de partition correcte après avoir résolu le problème

Ensuite concernant les tables de partition, voila mon hypothèse : lorsque le logiciel (EaseUS) a placé la partie non allouée au milieu puis décalé BOOTCAMP, les bonnes modifications ont été faites sur la table MBR, et c'est pour cela que Windows était encore bootable (meme si il était au mauvais endroit). Or la table GPT prise en compte sous macOS est restée inchangée, c'est pour cela que les tables de partition sont identique sur le disque de 500 GB et sur celui de 1 TB. Puis en mettant à jour vers Mojave, la table MBR modifiée par EaseUS a été remise à l'identique avec la GPT et c'est cela qui a rendu la partition Windows invisible

Que penses-tu de cette hypothèse ?? Au passage je tenais encore à te remercier pour ta grande aide

 

[Membre supprimé 1060554]

lorsque le logiciel (EaseUS) a placé la partie non allouée au milieu puis décalé BOOTCAMP, les bonnes modifications ont été faites sur la table MBR, et c'est pour cela que Windows était encore bootable (meme si il était au mauvais endroit). Or la table GPT prise en compte sous macOS est restée inchangée

• la "partie non allouée" désigne le free_space : l'espace de blocs libres. On sait que d'après la table GPT cet espace libre de 500 Go se trouve assigné en queue de disque > en-dessous de la partition n°3 de type Microsoft_Basic_Data. Or ce que tu dis est que le logiciel EaseUS aurait déplacé la partition Microsoft_Basic_Data en queue de disque > de manière à ce que l'espace libre de 500 Go se trouve en position intercalaire entre la partition de type apfs et la partition de type Microsoft_Basic_Data.

• ce déplacement aurait été enregistré dans la table de partition HMBR du bloc 0 > mais le logiciel EaseUS n'aurait pas modifié par contre la description de la partition Microsoft_Basic_Data dans la GPT. Aussi la GPT décrirait-elle à la localisation inchangée (juste en-dessous de la partition n°2 de type apfs) --> une partition fantôme > puisque les blocs correspondants seraient des blocs libres exempts de système de fichiers.

• c'est sur les 199 Go de derniers blocs du disque (abstraction fait des 33 terminaux dédiés à la sauvegarde de la GPT) --> que la partition de type Microsoft_Basic_Data existerait actuellement. Càd. le système de fichiers ntfs générateur d'un volume BOOTCAMP + les écritures des fichiers sur les blocs suivants. Emplacement désigné par la table GPT comme de l'espace libre > sans description d'une partition.

----------

 

[Membre supprimé 1060554]

• il faudrait donc supprimer dans la GPT le descripteur actuel de la partition de type Microsoft_Basic_Data qui lui assigne un emplacement où n'existe plus de système de fichiers ni d'écritures sur les blocs. Et recréer un descripteur d'une partition de type Microsoft_Basic_Data située sur les 199 Go de derniers blocs du disque.

• la difficulté de cette opération consiste à récupérer dans le nouveau descripteur de la GPT le bloc initial de la partition déplacée par EaseUS. En effet > dans une partition > le 1er bloc dit "bloc 0" de cette partition --> a un statut absolument privilégié : c'est un "super_bloc" sur lequel se trouve inscrit le header (ou en-tête) du système de fichiers. Càd. l'ancrage ou point origine du système de fichiers générateur d'un volume sur l'espace de la partition. C'est à la condition de récupérer en bloc de tête d'une nouvelle description le bloc 0 du système de fichiers ntfs déplacé par le logiciel EaseUS > que le système de fichiers ntfs peut redéfinir un volume BOOTCAMP. C'est la condition formelle d'activation d'un système de fichiers : que son bloc 0 soit absolument le bloc inscrit à la limite initiale d'une description de partition.

• il est possible > après suppression de l'actuel descripteur n°3 de la table GPT (lequel décrirait une partition là où n'existe que de l'espace libre) > de créer / décréer une suite de nouveaux descripteurs au rang n°3 dans la GPT d'une partition de 199 Go située en queue de disque > en faisant varier le bloc de tête de la partition décrite --> afin de vérifier si une de ces descriptions parvient à récupérer en bloc initial le bloc 0 du système de fichiers ntfs déplacé. Alors > le volume BOOTCAMP se trouverait redéfini et remonté sur la partition.

=> à toi de dire ce que tu penses de cette nouvelle interprétation de ma part > et si ça te paraît correspondre à ce qu'a fait ton logiciel ?

 

[Nas_0]

• il faudrait donc supprimer dans la GPT le descripteur actuel de la partition de type Microsoft_Basic_Data qui lui assigne un emplacement où n'existe plus de système de fichiers ni d'écritures sur les blocs. Et recréer un descripteur d'une partition de type Microsoft_Basic_Data située sur les 199 Go de derniers blocs du disque.

• la difficulté de cette opération consiste à récupérer dans le nouveau descripteur de la GPT le bloc initial de la partition déplacée par EaseUS. En effet > dans une partition > le 1er bloc dit "bloc 0" de cette partition --> a un statut absolument privilégié : c'est un "super_bloc" sur lequel se trouve inscrit le header (ou en-tête) du système de fichiers. Càd. l'ancrage ou point origine du système de fichiers générateur d'un volume sur l'espace de la partition. C'est à la condition de récupérer en bloc de tête d'une nouvelle description le bloc 0 du système de fichiers ntfs déplacé par le logiciel EaseUS > que le système de fichiers ntfs peut redéfinir un volume BOOTCAMP. C'est la condition formelle d'activation d'un système de fichiers : que son bloc 0 soit absolument le bloc inscrit à la limite initiale d'une description de partition.

• il est possible > après suppression de l'actuel descripteur n°3 de la table GPT (lequel décrirait une partition là où n'existe que de l'espace libre) > de créer / décréer une suite de nouveaux descripteurs au rang n°3 dans la GPT d'une partition de 199 Go située en queue de disque > en faisant varier le bloc de tête de la partition décrite --> afin de vérifier si une de ces descriptions parvient à récupérer en bloc initial le bloc 0 du système de fichiers ntfs déplacé. Alors > le volume BOOTCAMP se trouverait redéfini et remonté sur la partition.

=> à toi de dire ce que tu penses de cette nouvelle interprétation de ma part > et si ça te paraît correspondre à ce qu'a fait ton logiciel ?

Bonsoir Macomaniac,


Je pense que c'est exactement ce qu'a fait le logiciel, tu as très bien interprété la situation. Par contre un détail sur la partition "fantome" (je ne sais pas si c'est important) : il y a actuellement des fichiers dessus (je n'ai mis aucun fichier moi même), je pense qu'ils ont été crées lors du formatage NTFS mais je ne suis pas sur:


Ensuite pour pouvoir créer le nouveau descripteur au rang n°3 dans la GPT, le logiciel scannant les partitions perdues indique les LBA entre lesquels se trouve la partition perdue, nous pourrons donc créer ce descripteur du premier coup (l'autre partition nommée BOOTCAMP sur l'image en dessous est la partition "fantome", je l'avais renommée dans Disk Utility seulement pour me repérer dans mes tests en croyant que Windows y était) :

 

[Membre supprimé 1060554]

Donc la partition commencerait au bloc n° 1565388800 > et se terminerait au bloc n° 1952516610.

• bloc n°1565388800 - n° 587714560 = une extension de 977674240 blocs = 500.56 Go --> on obtient donc bien 500 Go en intercalaires.

• bloc n° 1952516610 - n° 1565388800 = une extension de 387127810 blocs = 198.20 Go. Or la partition originale avait une extension de blocs de 389058560 = 199.19 Go.

• en corollaire > le bloc où commence la sauvegarde de la GPT en bas de disque est le n° 1953525135. 1953525135 - 1952516610 = 1008525 blocs libres entre la fin de la partition BOOTCAMP déplacée et l'en-tête de la GPT secondaire. Il y a donc un espace libre de 516,36 Mo entre la fin de la partition BOOTCAMP déplacée et la GPT secondaire. D'habitude > on laisse 7 blocs libres seulement.

- question : est-ce que la partition BOOTCAMP clonée en bas de disque démarrait ?

 

[Nas_0]

Donc la partition commencerait au bloc n° 1565388800 > et se terminerait au bloc n° 1952516610.

• bloc n°1565388800 - n° 587714560 = une extension de 977674240 blocs = 500.56 Go --> on obtient donc bien 500 Go en intercalaires.

• bloc n° 1952516610 - n° 1565388800 = une extension de 387127810 blocs = 198.20 Go. Or la partition originale avait une extension de blocs de 389058560 = 199.19 Go.

• en corollaire > le bloc où commence la sauvegarde de la GPT en bas de disque est le n° 1953525135. 1953525135 - 1952516610 = 1008525 blocs libres entre la fin de la partition BOOTCAMP déplacée et l'en-tête de la GPT secondaire. Il y a donc un espace libre de 516,36 Mo entre la fin de la partition BOOTCAMP déplacée et la GPT secondaire. D'habitude > on laisse 7 blocs libres seulement.

- question : est-ce que la partition BOOTCAMP clonée en bas de disque démarrait ?

Si tu parles bien de la partition "perdue" (celle encadrée en rouge sur le screenshot) , elle démarrait bien avant que je mette à jour le mac oui

 

[Membre supprimé 1060554]

Alors il y a moyen > sans même toucher à la partition n°3 actuelle --> de créer un descripteur de partition n°4 dans la GPT en reprenant les marques de la partition qui avait été clonée en bas de disque.

Comme il faut pour cela démonter tous les volumes du disque et donc démarrer sur un volume indépendant du disque interne --> il serait peut-être plus commode de créer un clone d'OS de secours démarrable sur une clé USB > plutôt que de démarrer par internet ? -->

• qu'est-ce que tu en penses ?

 

[Nas_0]

Alors il y a moyen > sans même toucher à la partition n°3 actuelle --> de créer un descripteur de partition n°4 dans la GPT en reprenant les marques de la partition qui avait été clonée en bas de disque.

Comme il faut pour cela démonter tous les volumes du disque et donc démarrer sur un volume indépendant du disque interne --> il serait peut-être plus commode de créer un clone d'OS de secours démarrable sur une clé USB > plutôt que de démarrer par internet ? -->

• qu'est-ce que tu en penses ?

Oui ça serait le mieux, je crée la clé de suite