10.14 Mojave Probleme de partition apres clonage SSD

Est-ce que tu peux revenir dans ta session régulière de Macintosh HD > passer une commande :
Bloc de code: 
diskutil list

  • et poster le tableau ?
 
macomaniac a dit:
Passe la commande :
Bloc de code: 
df -H

  • qui mesure l'occupation des volumes

Poste le tableau.
Cliquez pour agrandir...
Voila:
Bloc de code: 
Filesystem      Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1    301G   275G    24G    93% 1574828 9223372036853200979    0%   /
devfs           197k   197k     0B   100%     667                   0  100%   /dev
/dev/disk1s4    301G   1.1G    24G     5%       1 9223372036854775806    0%   /private/var/vm
map -hosts        0B     0B     0B   100%       0                   0  100%   /net
map auto_home     0B     0B     0B   100%       0                   0  100%   /home
/dev/disk0s3    199G   1.7G   197G     1%   20569           192867323    0%   /Volumes/Untitled
/dev/disk0s4    198G   157G    41G    80% 1106555            40445833    3%   /Volumes/BOOTCAMP 1
/dev/disk2s2     60G   157M    60G     1%      86          4294967193    0%   /Volumes/BOOT
/dev/disk2s3    3.5G   1.3G   2.2G    37%   50549          4294916730    0%   /Volumes/OS X Base System
 
Voici la nouvelle partition -->
Bloc de code: 
/dev/disk0s4    198G   157G    41G    80% 1106555            40445833    3%   /Volumes/BOOTCAMP 1

  • tu remarques qu'elle affiche un volume monté BOOTCAMP contenant 157 Go de données. C'est la preuve indubitable qu'on a récupéré le système de fichiers NTFS cloné en bas de disque > par une description de partition dont le bloc 0 est bien le "super-bloc" portant le header de ce système de fichiers. Avec les autres paramètres du descripteur (extension en blocs > type > rang) --> le kernel a instantanément remonté le volume BOOTCAMP sur la partition.
  • évidemment > tant qu'une table de partition HMBR > décrivant en mode MBR cette nouvelle partition > n'aura pas été recréée sur le bloc 0 du disque (afin de permettre un boot en mode Legacy) --> jamais tu ne pourras escompter démarrer l'OS du volume BOOTCAMP de bas de disque.

Comme il se fait (trop) tard pour moi --> je te propose de poursuivre demain les opérations (récupération de l'espace libre de 500 Go > recréation d'une HMBR).
 
  • J’aime
Réactions: litobar71
macomaniac a dit:
Voici la nouvelle partition -->
Bloc de code: 
/dev/disk0s4    198G   157G    41G    80% 1106555            40445833    3%   /Volumes/BOOTCAMP 1

  • tu remarques qu'elle affiche un volume monté BOOTCAMP contenant 157 Go de données. C'est la preuve indubitable qu'on a récupéré le système de fichiers NTFS cloné en bas de disque > par une description de partition dont le bloc 0 est bien le "super-bloc" portant le header de ce système de fichiers. Avec les autres paramètres du descripteur (extension en blocs > type > rang) --> le kernel a instantanément remonté le volume BOOTCAMP sur la partition.
  • évidemment > tant qu'une table de partition HMBR > décrivant en mode MBR cette nouvelle partition > n'aura pas été recréée sur le bloc 0 du disque (afin de permettre un boot en mode Legacy) --> jamais tu ne pourras escompter démarrer l'OS du volume BOOTCAMP de bas de disque.
Comme il se fait (trop) tard pour moi --> je te propose de poursuivre demain les opérations (récupération de l'espace libre de 500 Go > recréation d'une HMBR).
Cliquez pour agrandir...
macomaniac a dit:
Voici la nouvelle partition -->
Bloc de code: 
/dev/disk0s4    198G   157G    41G    80% 1106555            40445833    3%   /Volumes/BOOTCAMP 1

  • tu remarques qu'elle affiche un volume monté BOOTCAMP contenant 157 Go de données. C'est la preuve indubitable qu'on a récupéré le système de fichiers NTFS cloné en bas de disque > par une description de partition dont le bloc 0 est bien le "super-bloc" portant le header de ce système de fichiers. Avec les autres paramètres du descripteur (extension en blocs > type > rang) --> le kernel a instantanément remonté le volume BOOTCAMP sur la partition.
  • évidemment > tant qu'une table de partition HMBR > décrivant en mode MBR cette nouvelle partition > n'aura pas été recréée sur le bloc 0 du disque (afin de permettre un boot en mode Legacy) --> jamais tu ne pourras escompter démarrer l'OS du volume BOOTCAMP de bas de disque.
Comme il se fait (trop) tard pour moi --> je te propose de poursuivre demain les opérations (récupération de l'espace libre de 500 Go > recréation d'une HMBR).
Cliquez pour agrandir...
D'accord merci beaucoup pour ton temps et tes explications, à demain
 
Le marrant est que tu avais 2 partitions Windows -->

  • l'originale décrite dans la GPT au rang n°3 (avant la bande de blocs libres de 500 Go) > mais plus dans la HMBR du bloc 0 > et vidée de son contenu (je ne sais par l'effet de quelle opération)
  • le clone créé par EaseUS en queue de disque (après une bande de blocs libres de 500 Go) > enregistré dans la HMBR du bloc 0 > mais non décrit dans la GPT principale

Il a fallu supprimer la HMBR du bloc 0 > pour la reconvertir à une PMBR ne décrivant aucune partition --> afin de pouvoir réécrire des descripteurs dans la GPT. On a donc actuellement 2 partitions Windows décrites dans la GPT aux rangs n°3 & n°4 (séparées par 500 Go de blocs libres) : l'originale vide de fichiers recensés dans son système de fichiers NTFS > son clone plein de fichiers recensés dans son système de fichiers NTFS.

Récupérer l'espace libre via la suppression de la partition Windows de rang n°3 est chose aisée. Rendre de nouveau démarrable la partition Windows de bas de disque qui redeviendra une partition de rang n°3 après suppression de l'autre --> me paraît très problématique. Mais chaque chose en son temps...

Tu n'auras qu'à faire signe ici lorsque tu seras disponible...
 
  • J’aime
Réactions: litobar71
macomaniac a dit:
Le marrant est que tu avais 2 partitions Windows -->

  • l'originale décrite dans la GPT au rang n°3 (avant la bande de blocs libres de 500 Go) > mais plus dans la HMBR du bloc 0 > et vidée de son contenu (je ne sais par l'effet de quelle opération)
  • le clone créé par EaseUS en queue de disque (après une bande de blocs libres de 500 Go) > enregistré dans la HMBR du bloc 0 > mais non décrit dans la GPT principale
Il a fallu supprimer la HMBR du bloc 0 > pour la reconvertir à une PMBR ne décrivant aucune partition --> afin de pouvoir réécrire des descripteurs dans la GPT. On a donc actuellement 2 partitions Windows décrites dans la GPT aux rangs n°3 & n°4 (séparées par 500 Go de blocs libres) : l'originale vide de fichiers recensés dans son système de fichiers NTFS > son clone plein de fichiers recensés dans son système de fichiers NTFS.

Récupérer l'espace libre via la suppression de la partition Windows de rang n°3 est chose aisée. Rendre de nouveau démarrable la partition Windows de bas de disque qui redeviendra une partition de rang n°3 après suppression de l'autre --> me paraît très problématique. Mais chaque chose en son temps...

Tu n'auras qu'à faire signe ici lorsque tu seras disponible...
Cliquez pour agrandir...
Bonsoir Macomaniac,

Je suis prêt pour la suite !
 
  • J’aime
Réactions: litobar71
Me voici.

Passe une commande :
Bloc de code: 
diskutil list

  • et poste le tableau des disques -- que je l'aie sous les yeux ici sans avoir à tourner de pages.
 
macomaniac a dit:
Me voici.

Passe une commande :
Bloc de code: 
diskutil list

  • et poste le tableau des disques -- que je l'aie sous les yeux ici sans avoir à tourner de pages.
Cliquez pour agrandir...
Et voici mon cher macomaniac :
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 Untitled                199.2 GB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                198.2 GB   disk0s4

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

J'ai re-changé le nom de la partition "fantome" par "Untitled" pour éviter la confusion. Le "vrai" BOOTCAMP" est le seul BOOTCAMP
 
Alors je pense que l'opération "récupération d'espace" peut être effectuée. Tu passes les commandes :
Bloc de code: 
diskutil eraseVolume free null disk0s3
diskutil ap resizeContainer disk1 0b

  • la 1ère supprime la partition "fantôme"
  • la 2è récupère l'ensemble des blocs libres disponibles en-dessous --> à la partition du dessus (disk0s2) & au Conteneur disk1 qu'elle exporte

Poste l'affichage retourné par la 2è : il arrive que la commande de récupération d'espace libre à un Conteneur apfs avorte (pour diverses raisons).
 
macomaniac a dit:
Alors je pense que l'opération "récupération d'espace" peut être effectuée. Tu passes les commandes :
Bloc de code: 
diskutil eraseVolume free null disk0s3
diskutil ap resizeContainer disk1 0b

  • la 1ère supprime la partition "fantôme"
  • la 2è récupère l'ensemble des blocs libres disponibles en-dessous --> à la partition du dessus (disk0s2) & au Conteneur disk1 qu'elle exporte
Poste l'affichage retourné par la 2è : il arrive que la commande de récupération d'espace libre à un Conteneur apfs avorte (pour diverses raisons).
Cliquez pour agrandir...
Après la première commande, le nom du disk0s2 a changé en :
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: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               300.7 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                198.2 GB   disk0s4

Et la seconde commande retourne une erreur :
Bloc de code: 
Started APFS operation
Error: -69846: Unrecognized file system
 
Je pensais que tu utilisais le Terminal du volume Macintosh HD démarré - tu étais démarré sur une session de secours et tu utilisais son Terminal ?
 
Et la session est toujours ouverte ?

- dans ce type de description d'une partition -->
Bloc de code: 
   2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               300.7 GB   disk0s2

  • l'emploi d'un pseudo-UUID : FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF signifie que le type de la partition a été corrompu (il devrait être libellé : Apple_APFS). Je ne vois pas en quoi une commande de suppression d'une partition étrangère (comme celle de ma 1ère commande) --> pourrait affecter le type d'une autre partition.
  • ce problème de corruption du type d'une partition > se règle très bien avec la commande gpt (après un démarrage sur un Système indépendant - comme celui qu'on avait créé sur ta clé USB)

Si ta session est toujours ouverte > passe la commande :
Bloc de code: 
sudo gpt show /dev/disk0

  • qui affiche la disribution des blocs et les types des partitions

Poste ce tableau.
 
macomaniac a dit:
Et la session est toujours ouverte ?

- dans ce type de description d'une partition -->
Bloc de code: 
   2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               300.7 GB   disk0s2

  • l'emploi d'un pseudo-UUID : FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF signifie que le type de la partition a été corrompu (il devrait être libellé : Apple_APFS). Je ne vois pas en quoi une commande de suppression d'une partition étrangère (comme celle de ma 1ère commande) --> pourrait affecter le type d'une autre partition.
  • ce problème de corruption du type d'une partition > se règle très bien avec la commande gpt (après un démarrage sur un Système indépendant - comme celui qu'on avait créé sur ta clé USB)
Si ta session est toujours ouverte > passe la commande :
Bloc de code: 
sudo gpt show /dev/disk0

  • qui affiche la disribution des blocs et les types des partitions

Poste ce tableau.
Cliquez pour agrandir...
Voila le retour :
Bloc de code: 
gpt show: /dev/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 - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
   587714560   977674240        
  1565388800   387127810      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  1952516610     1008525        
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header
 
Le type de la partition est bien annoncé corrompu -->
Bloc de code: 
      409640   587304920      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

  • par contre > la partition fantôme a bien été supprimée. Tout cela me laisse penser qu'il y a eu une espèce d'« effet collatéral » sur le descripteur de l'apfs dans la table GPT. Il sera alors bon de le recréer de neuf. Chose super aisée > puisqu'on connaît son super-bloc (bloc 0 de la partition portant le header intouché de l'apfs) = le n° 409640 & son extension = 587304920 blocs.
  • il serait donc bon ensuite d'effectuer une réparation de la table GPT qui m'a l'air bien "sensible" à des "effets papillon"...

As-tu toujours ta clé de démarrage avec son volume RECUP ?
 
macomaniac a dit:
Le type de la partition est bien annoncé corrompu -->
Bloc de code: 
      409640   587304920      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

  • par contre > la partition fantôme a bien été supprimée. Tout cela me laisse penser qu'il y a eu une espèce d'« effet collatéral » sur le descripteur de l'apfs dans la table GPT. Il sera alors bon de le recréer de neuf. Chose super aisée > puisqu'on connaît son super-bloc (bloc 0 de la partition portant le header intouché de l'apfs) = le n° 409640 & son extension = 587304920 blocs.
  • il serait donc bon ensuite d'effectuer une réparation de la table GPT qui m'a l'air bien "sensible" à des "effets papillon"...
As-tu toujours ta clé de démarrage avec son volume RECUP ?
Cliquez pour agrandir...
Oui j'ai toujours la clé
 
Alors la clé attachée > redémarre > choisis le volume RECUP > démarre dessus.

Quand tu as l'écran des 4 Utilitaires macOS > lance le Terminal > passe la commande :
Bloc de code: 
diskutil list

  • et poste le tableau --> que j'avise le rendu du disque à partir de ce démarrage...
 
macomaniac a dit:
Alors la clé attachée > redémarre > choisis le volume RECUP > démarre dessus.

Quand tu as l'écran des 4 Utilitaires macOS > lance le Terminal > passe la commande :
Bloc de code: 
diskutil list

  • et poste le tableau --> que j'avise le rendu du disque à partir de ce démarrage...
Cliquez pour agrandir...
Voila le tableau:
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: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               300.7 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                198.2 GB   disk0s3

/dev/disk1 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *64.0 GB    disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS BOOT                    60.0 GB    disk1s2
   3:                  Apple_HFS OS X Base System        3.5 GB     disk1s3

/dev/disk2 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +5.2 MB     disk2

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk3

/dev/disk4 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk4

/dev/disk5 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk5

/dev/disk6 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk6

/dev/disk7 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk7

/dev/disk8 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk8

/dev/disk9 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +12.6 MB    disk9

/dev/disk10 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +4.2 MB     disk10

/dev/disk11 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk11

/dev/disk12 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk12

/dev/disk13 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk13

/dev/disk14 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk14

/dev/disk15 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +1.0 MB     disk15

/dev/disk16 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk16

/dev/disk17 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +6.3 MB     disk17

/dev/disk18 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +524.3 KB   disk18

/dev/disk19 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            untitled               +2.1 MB     disk19
 
Jolie corruption du type de la partition (dans son descripteur GPT).


Alors passe la commande préliminaire -->
Bloc de code: 
diskutil umountDisk force disk0

  • qui démonte de force les volumes du disk0 et par là désactive la GPT

Poste le retour.
 

Sujets similaires

O
macOS Monterey Aide Fusion Partitions
Réponses
8
Affichages
1K
macOS
Locke
Locke
U
macOS Ventura Modifier taille partition
Réponses
2
Affichages
1K
macOS
ubuubu
U
Aski
macOS Ventura No CoreStorage logical volume groups found
Réponses
6
Affichages
859
macOS
Locke
Locke
B
macOS Monterey souci suite à restauration Time Machine
Réponses
20
Affichages
2K
macOS
Ahiqar
A
C
Partition effacée et plus reconnue
Réponses
11
Affichages
1K
macOS
Sly54
Sly54
Haut Bas