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

Me revoilà ! Déjà ? Oui, encore un problème...
Mon but étant de faire un dual boot je dois partitonner mon disque pour cela. J'avais déjà amorcé une tentative mardi qui avait échoué et qui a participé au problème résolut hier. Ce matin j'ai lancé la procédure de partitionnement du FusionCore de 50 Go en MS-DOS(FAT)--> pour du Linux.
Et de nouveau le même problème, voila le screen au moment ou il bloque :
Capture d’écran 2021-06-17 à 19.06.51.png
J'ai donc réitérer la procédure juste au-dessus afin de résoudre le problème. Toutes les commandes me retourne un code d'erreur 0 sauf la dernière :
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 249 199 591 424 to 326 753 361 920 bytes
Copying booter
Error: -69771: The target disk is too small for this 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   disk1s3

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +285.5 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Il faudrait peut être aussi préciser exactement ce que tu as fait avant, non ?
 
On retrouve une erreur de taille interne > la somme des partitions de base (contenant les magasins Physical Volumes) étant de 119,7 Go + 249,2 Go = 368,9 Go > alors que la taille du volume logique exporté (supportant Macintosh SSD) est de 285,5 Go. Ce qui fait que le volume logique est plus petit de 83,4 Go que les magasins physiques.

- il faut savoir que rétrécir un CoreStorage (ici de type Fusion Drive) est une opération complexe qui implique : de rétrécir le volume jhfs+ Macintosh SSD > de rétrécir le volume logique qui le supporte > de rétrécir le magasin physique du HDD (exclusivement) > de rétrécir la partition de disque qui l'inclut. Manifestement chez toi > le volume logique et son volume terminal sont rétrécis > mais ensuite le magasin du HDD et sa partition conservent leur taille de départ sans s'aligner sur le rétrécissement qui a été initié.​

Passe la commande :
Bloc de code:
diskutil cs resizeLV 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE 0b ; diskutil list
  • qui re-dilate le volume logique et son volume supporté à congruence de la taille des magasins primaires du CoreStorage > puis affiche la configuration des disques

Poste le retour intégral de la commande.
 
Merci de ta réponse !
Voila le résultat :
Bloc de code:
The Core Storage Logical Volume UUID is 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
Started CoreStorage operation
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 Logical Volume
Resizing Core Storage Logical Volume structures
Resized Core Storage Logical Volume to 285 487 792 128 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   disk1s3

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +285.5 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Passe la commande :
Bloc de code:
diskutil repairDisk disk1 ; diskutil list
  • qui répare le CoreStorage via une réparation du HDD > puis affiche la configuration des disques

Poste le retour complet.
 
Et voici :
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
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 3 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 disk1
/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                  171.6 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh SSD          +285.5 GB   disk2
                                 Logical Volume on disk0s2, disk1s2
                                 8BBAECF4-6C65-4958-AFE8-77F4B2E92AFE
                                 Unencrypted Fusion Drive
 
Cette fois-ci > il s'avère que la partition CoreStorage du HDD > recelant le magasin de stockage Physical Volume => est bien réduite à 171,6 Go. Additionnée à la partition du SSD recelant l'autre magasin de stockage de 119,7 Go => cela donne donc 291,3 Go de taille des Physical Volumes. En regard > la taille du volume logique portant le volume standard Macintosh SDD => est de 285,5 Go. Un déficit réduit à 5,8 Go qui n'a rien d'anormal ici > car il y a toujours une petite marge d'espace libre dans le Conteneur du CoreStorage.

- on suppose alors qu'une bande de blocs libres a bien été créée en queue de HDD > correspondant à 250,1 Go de taille totale du disque - la somme des partitions existantes = 172,5 Go => 77,6 Go. Passe la commande :​
Bloc de code:
sudo gpt show disk1
  • qui affiche la distribution des blocs du HDD gérée par la GPT d'en-tête du disque

Poste le tableau obtenu.
 
D'accord.
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  335245744      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  335655384    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  336924920  151472215         
  488397135         32         Sec GPT table
  488397167          1         Sec GPT header
 
On voit la bande d'espace libre en queue de disque -->
Bloc de code:
 336924920  151472215
  • elle commence au bloc n°336924920 (1er bloc libre en-dessous de la partition de secours Recovery HD) > et a une extension de 151472215 blocs (de 512 octets standards) = 77,55 Go.

Est-ce qu'une telle taille te conviendrait pour ta partition Linux ?

Note : je dois m'absenter maintenant. Je reprendrai plus tard.
 
Encore une question : faut-il a priori créer une petite partition dédiée au swap > en plus de la partition principale destinée à Linux ?

- si oui : quelle taille pour la partition du swap ?​
 
On peut convertir les 77,55 Go de blocs libres en 2 partitions pour Linux. En créant 2 nouveaux descripteurs de partition dans la table GPT d'en-tête du HDD. Mais pour écrire à la GPT > il faut qu'elle soit désactivée (càd. non prise en charge par le kernel du Système démarré pour montage en volumes des partitions décrites dans la table). Ce qui requiert donc un démarrage indépendant des disques internes. Même un démarrage de secours local impliquerait un montage du volume Recovery HD du HDD.

- préfères-tu démarrer par internet sur l'OS de secours d'usine de ton Mac (Lion) téléchargé en RAM depuis le serveur Apple de récupération ? - ou qu'on clone un volume de secours démarrable sur une clé USB => afin de démarrer le Mac sur ce clone indépendant ?​
Note : créer ainsi les partitions Linux => éviterait de toucher au CoreStorage du Fusion Drive qui dysfonctionne manifestement dès qu'on engage un repartitionnement.
 
D'accord, je crois avoir une session Recovery quand je fais cmd + R au démarrage (j'ai un mac sur High Sierra et non sur Lion). Dans le cas contraire je démarrerais sur internet. Si j'ai bien compris le Linux ne fera pas parti du coreStorage et donc bénéficiera d'une vitesse de lecture écriture plus ou moins élevé en fonction du disque sur lequel on l'installe. Es-ce que réinitialiser le mac serai une option afin de d'éviter ce genre de problème à l'avenir ?
 
Si tu démarres via ⌘R => tu démarres sur l'OS de secours local. Il est recelé dans une image-disque BaseSystem.dmg contenue dans le volume Recovery HD du HDD. Ce genre de démarrage ne permet donc pas une désactivation de la GPT du HDD.

- pour démarrer par internet sur l'OS de secours d'usine (Lion) qui sera porté par une image-disque téléchargée en RAM --> il faut que tu démarres via la combinaison de touches ⌘⌥⇧R (cmd alt maj R).​
- dans le cas de figure d'un Fusion Drive associant SSD & HDD --> tout repartitionnement affecte uniquement le HDD. Ton OS Linux dépendrait donc d'une partition de queue du HDD et n'aurait que le débit permis par ce disque rotatif.​
- je ne perçois pas d'où vient le dysfonctionnement chronique du CoreStorage du Fusion Drive dès qu'un repartitionnement est impliqué. Le disque de 250 Go qui tient lieu de HDD est-il un SSD associé en Fusion Drive au SSD de 121 Go ?​
 
C'est noté.
Non, le disque de 250 Go n'est pas un SSD.
Avant j'avais un dual boot sur le Fusion Drive, ma partition Linux basculait sur le disque SSD ce que me permettait de l'utiliser à son plein potentiel. J'aimerais bien retrouver cette configuration.
 
Tu veux dire que c'est le SDD qui se trouvait repartitionné ? --> si c'était le cas > ton CoreStorage était monté à l'envers > le SSD étant considéré comme disque de stockage ("performance role" = aux) et le HDD comme disque moteur ("performance role" = main). Auquel cas > les performances de Linux devaient être excellentes (SSD) > les performances de macOS médiocres (HDD considéré comme disque moteur donc OS installé basiquement sur ce disque).

- il serait bien sûr possible de supprimer le Fusion Drive > partitionner le SSD en 2 > affecter une partition SSD à Linux > et associer l'autre partition SSD en mode Fusion Drive à la totalité du HDD. Ce qui impliquerait que tu crées un clone de sauvegarde de Macintosh SSD sur un DDE.​
 
Oui mais comme le Mac avait accès au SSD avec le système de tiering depuis Mountain Lion, il gardait des performances acceptables.
Existe t-il à la manière du système de tiering présent sur OS X, un système pour mettre les données le plus fréquemment utilisé sur le SSD à l'échelle des partitions, une sorte de swap ? Imaginons que je démarre avec Linux, la partition Linux sur retrouve sur le SSD et de même avec Mac.
 
Dernière édition par un modérateur: