10.13 High Sierra Diskutil list : en apprendre un peu plus...

Ah : super ! Donc passe directement la commande :
Bloc de code:
sudo gpt show disk1
  • [au cas où : à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide]
  • la commande affiche la distribution des blocs gérés par la GPT en : secteur de boot des tables de partition > partitions > bandes d'espace libre > sauvegarde finale de la GPT

Poste le tableau obtenu.
 
Note : je ne m'attendais pas à un tel parcours du combattant truffé de pièges inexplicables.
On a une véritable Odyssée !
Bloc de code:
      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  314020216      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  314429856    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  315699392  172697743         
  488397135         32         Sec GPT table
  488397167          1         Sec GPT header
 
Tu vois ici la bande d'espace libre -->
Bloc de code:
  315699392  172697743
  • elle commence au bloc n°315699392 (1er bloc libre après la partition de secours Recovery HD) > et a une extension de 172697743 blocs (de 512 octets standards) = 88,42 Go. Donc la récupération de cet espace libre devrait fonctionner.

Mais voici que je viens de m'aviser d'une anomalie. Si tu scrutes la dernière configuration des disques (simplifiée par mézigues) -->
Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER

   2:          Apple_CoreStorage Fusion                  119.7 GB   disk0s2

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
 
   2:          Apple_CoreStorage Fusion                  173.2 GB   disk1s2

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +235.0 GB   disk2
  • tu t'aperçois que les 2 partitions basiques du Fusion Drive > recelant chacune un magasin de stockage Physical Volume > font : 119,7 Go + 173,2 Go = 292,9 Go. Or le volume logique Macintosh SSD exporté par ces 2 magasins => ne fait que 235 Go. Il y a donc un déficit de taille de 57,9 Go qui montre que le CoreStorage est toujours affecté par une erreur de taille (taille du volume logique collectif trop petite par rapport à la somme des tailles des magasins physiques).

J'en conclus que le CoreStorage est toujours bancal > et c'est ça qui invalide la récupération d'espace. De 2 choses l'1 ici : soit l'erreur est réelle > et il faut la réparer ; soit l'erreur est virtuelle --> ce qui voudrait dire que le kernel (le moteur logique du Système démarré) > kernel qui gère le montage des volumes à partir de la lecture des tables de partition => garderait en mémoire le 1er montage du CoreStorage sans s'être mis à jour des manipulations qu'on a faites.

Test de cette 2è possibilité. Redémarre une fois. De retour dans ta session > poste le retour d'une commande :
Bloc de code:
diskutil list
  • qu'on voie si le kernel se serait mis à jour d'un CoreStorage modifié.
 
Dernière édition par un modérateur:
Je vais tester.
Je tient à préciser que l'opération faite hier de partitionnement de 40 ne répondait plus et au bout de 5 heures j'ai du me résoudre à la stopper de force.

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Fusion                  119.7 GB   disk0s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Fusion                  160.8 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +235.0 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Il y a donc une erreur interne bien réelle au CoreStorage. On reprend les réparations de disques > sur les 2 disques cette fois-ci.

- passe les commandes (l'une après l'autre) :​
Bloc de code:
diskutil repairDisk disk0
diskutil repairDisk disk1
  • en validant chaque fois avec y à la demande de confirmation

Poste les 2 retours.
 
Les voici :
Bloc de code:
Started partition map repair on disk0
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk0s3
Verifying file system
Volume is already unmounted
Performing fsck_hfs -fn -x /dev/rdisk0s3
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Boot OS X appears to be OK
File system check exit code is 0
Restoring the original state found as unmounted
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Verifying storage system
Performing fsck_cs -n -x --lv --uuid 7149EC05-0B70-4E3F-B82B-DCCA62909791
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 7149EC05-0B70-4E3F-B82B-DCCA62909791 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 79 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 8 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 906D3996-5E23-490F-8FBA-CF079ED8C3C1
Load and verify 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 7149EC05-0B70-4E3F-B82B-DCCA62909791 appears to be OK
Storage system check exit code is 0
Repairing storage system
Performing fsck_cs -y -x --lv --uuid 7149EC05-0B70-4E3F-B82B-DCCA62909791
The volume disk0s2+disk1s2 cannot be repaired when it is in use
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 7149EC05-0B70-4E3F-B82B-DCCA62909791 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 79 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 906D3996-5E23-490F-8FBA-CF079ED8C3C1
Load and verify 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 7149EC05-0B70-4E3F-B82B-DCCA62909791 appears to be OK
Storage system check exit code is 0
The partition map appears to be OK
Finished partition map repair on disk0
Bloc de code:
Started partition map repair on disk1
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk1s3
Verifying file system
Volume is already unmounted
Performing fsck_hfs -fn -x /dev/rdisk1s3
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Recovery HD appears to be OK
File system check exit code is 0
Restoring the original state found as unmounted
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Verifying storage system
Performing fsck_cs -n -x --lv --uuid 7149EC05-0B70-4E3F-B82B-DCCA62909791
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 7149EC05-0B70-4E3F-B82B-DCCA62909791 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 79 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 1 newer non-checkpoint transaction
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 906D3996-5E23-490F-8FBA-CF079ED8C3C1
Load and verify 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 7149EC05-0B70-4E3F-B82B-DCCA62909791 appears to be OK
Storage system check exit code is 0
Repairing storage system
Performing fsck_cs -y -x --lv --uuid 7149EC05-0B70-4E3F-B82B-DCCA62909791
The volume disk0s2+disk1s2 cannot be repaired when it is in use
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 7149EC05-0B70-4E3F-B82B-DCCA62909791 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 79 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 1 newer non-checkpoint transaction
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify 906D3996-5E23-490F-8FBA-CF079ED8C3C1
Load and verify 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 7149EC05-0B70-4E3F-B82B-DCCA62909791 appears to be OK
Storage system check exit code is 0
The partition map appears to be OK
Finished partition map repair on disk1
 
Repasse un :
Bloc de code:
diskutil list
  • et poste le retour => qu'on voie s'il y a un changement (j'en doute).
 
Je ne crois pas :
Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Fusion                  119.7 GB   disk0s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Fusion                  160.8 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +235.0 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Changement nul. il doit falloir réparer les disques à partir d'un démarrage indépendant permettant le démontage des volumes.

- quel est l'OS actuellement installé ? - de quelle année est ton Mac ?​
 
Bon : tu dois pouvoir démarrer par internet aussi.

- avant d'effectuer cette manœuvre > passe la commande :​
Bloc de code:
diskutil cs resizeLV 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE 0b ; diskutil list
  • la commande tente de dilater le volume logique à l'intérieur du Conteneur CoreStorage => pour qu'il devienne congruent de la somme des tailles des magasins physiques des 2 partitions de base - puis ré-affiche la configuration des disques

Poste le retour.
 
Après l'effort, le réconfort.
Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Fusion                  119.7 GB   disk0s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Fusion                  160.8 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +274.6 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Le volume logique (disque virtuel exporté des 2 magasins physiques et portant le volume terminal Macintosh SSD) => est passé de 235 Go => 274,6 Go. Gain : 41,6 Go.

- bon. On tente de valoriser ce succès. Repasse la commande récupératrice d'espace libre externe au CoreStorage cette fois :​
Bloc de code:
diskutil cs resizeStack 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE 0b ; diskutil list
  • et poste le retour complet.
 
C'est bon !
Bloc de code:
The Core Storage Logical Volume UUID is 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
Started CoreStorage operation
Checking prerequisites for resizing Logical-Physical volume stack
Growing Logical-Physical volume stack
Verifying file system
Volume could not be unmounted
Using live mode
Performing fsck_hfs -fn -l -x /dev/rdisk2
Performing live verification
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Macintosh SSD appears to be OK
File system check exit code is 0
Restoring the original state found as mounted
Growing Core Storage Physical Volume from 160 778 350 592 to 249 199 591 424 bytes
Copying booter
Growing disk partition
Modifying partition map
Growing Core Storage data structures
Resizing Core Storage Physical Volume structures
Resized Core Storage Physical Volume to 249 199 591 424 bytes
Growing Logical Volume
Resizing Core Storage Logical Volume structures
Resized Core Storage Logical Volume to 363 041 390 592 bytes
Growing file system
Finished CoreStorage operation
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *120.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Fusion                  119.7 GB   disk0s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Fusion                  249.2 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s4

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +363.0 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Ah ! enfin...

- une histoire de fous (en résumé). La réparation du CoreStorage via la réparation logique du HDD => n'avait pas réussi à redilater le volume logique dans le Conteneur CoreStorage à congruence des tailles des magasins physiques des partitions. Tu es le 1er (sur les forums MacGé) pour qui une commande de dilatation spécifique du volume logique ait fonctionné. Ce qui a été la clé de la récupération de l'espace libre externe de queue de HDD.​

Content pour toi !
 
  • J’aime
Réactions: Invité
J'ai eu beaucoup de chance alors ! Un grand merci à toi encore une fois !
J'ai une dernière question car je n'ai pas envie de refaire planter mon OS : comment je peux partitionner mon disque pour éviter les plantages du CoreStorage ? Et peux-tu me confirmer que je dois bien partitionner le FusionDrive et non pas le Macintosh SSD ?
 
Dernière édition par un modérateur:
Le Fusion Drive est réparé. Il devrait supporter désormais un repartitionnement régulier pour créer une partition en fin de HDD. Via l'Utilitaire de disque ou le terminal.
 
Belle aventure !!!
Pleine d'imprévus et qui se finit bien :cool:
 
  • J’aime
Réactions: Random_error