10.14 Mojave Problème suite à partition / départition de disque

Bien. Passe la commande (copier-coller à rebours) :
Bloc de code: 
asr restore --s /Volumes/"Recovery HD" --t /Volumes/Boot --erase --noprompt ; diskutil list disk1

  • la commande appelle l'exécutable Apple asr (apple_software_restore) > à cloner en mode "copie de blocs" absolue > le volume Recovery HD => sur le volume Boot. Le volume Boot va être reformaté > renommé Recovery HD comme l'original > cloné des écritures de blocs de la partition de ce volume > rendu démarrable à la fin par l'inscription d'un chemin de démarrage sur son en-tête. Il y a 2 passes de clonage : Restoring > Validating > la progression dans chacune indiquée par tranches de 10 %.
  • la configuration du disque du DDE va être réaffichée à la fin

Poste l'ensemble de l'affichage retourné.
 
Voila le retour que j'obtiens :

Bloc de code: 
asr restore --s /Volumes/"Recovery HD" --t /Volumes/Boot --erase --noprompt ; diskutil list disk1
    Validating target...done
    Validating source...done
    Validating sizes...done
    Restoring  ....10....20....30....40....50....60....70....80....90....100
    Verifying  ....10....20....30....40....50....60....70....80....90....100
    Restored target device is /dev/disk1s4.
    Remounting target volume...done
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Macintosh HD            799.8 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:                  Apple_HFS Recovery HD             650.0 MB   disk1s4
 
Hé ! hé ! -->
Bloc de code: 
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:                  Apple_HFS Recovery HD             650.0 MB   disk1s4

  • on voit que la partition nouvellement créée s'est étoffée d'un volume (démarrable) Recovery HD clone de l'original. Elle est listée au rang 4 > mais c'est une fausse apparence qu'on va s'empresser de corriger !

Passe la commande :
Bloc de code: 
diskutil repairDisk disk1 ; diskutil list disk1

  • à validation > une demande de confirmation s'affiche : tape y (yes) et revalide. La commande lance une réparation logicielle totale du disque du HDD > dont une réparation de la GPT (c'est ce qui importe ici) > puis réaffiche la configuration du HDD.

Poste l'ensemble de l'affichage retourné. La partition Apple_HFS Recovery HD devrait avoir permuté de rang avec l'originale > et récupéré le rang 3 en accord avec sa localisation sur les blocs du disque.
 
Jusque là ça fonctionne aussi je crois !

Bloc de code: 
diskutil repairDisk disk1 ; diskutil list disk1
Repairing the partition map might erase disk1s1, proceed? (y/N) y
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 E9AB2027-786F-4BDE-8B78-90E8C9998245
Checking volume
disk1s2: Scan for Volume Headers
disk0s2: Scan for Volume Headers
disk1s2: Scan for Disk Labels
disk0s2: Scan for Disk Labels
Logical Volume Group E9AB2027-786F-4BDE-8B78-90E8C9998245 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no 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 C0E3E8FB-8391-4260-9380-AEEAA02F4531
Load and verify 2557800D-8843-4936-A95B-AE2EEAD4C284
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 E9AB2027-786F-4BDE-8B78-90E8C9998245 appears to be OK
Storage system check exit code is 0
Repairing storage system
Performing fsck_cs -y -x --lv --uuid E9AB2027-786F-4BDE-8B78-90E8C9998245
The volume disk1s2+disk0s2 cannot be repaired when it is in use
Checking volume
disk1s2: Scan for Volume Headers
disk0s2: Scan for Volume Headers
disk1s2: Scan for Disk Labels
disk0s2: Scan for Disk Labels
Logical Volume Group E9AB2027-786F-4BDE-8B78-90E8C9998245 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no 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 C0E3E8FB-8391-4260-9380-AEEAA02F4531
Load and verify 2557800D-8843-4936-A95B-AE2EEAD4C284
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 E9AB2027-786F-4BDE-8B78-90E8C9998245 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/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Macintosh HD            799.8 GB   disk1s2
   3:                  Apple_HFS Recovery HD             650.0 MB   disk1s4
   4:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
 
Hé ! hé ! -->
Bloc de code: 
   3:                  Apple_HFS Recovery HD             650.0 MB   disk1s4
   4:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

  • tu notes la permutation des rangs des partitions : la Apple_HFS qu'on a créée ayant été remontée au rang 3.

----------

Un peu de toilettage à présent. Passe la commande :
Bloc de code: 
diskutil eraseVolume free null disk1s3 ; diskutil list disk1

  • qui supprime la partition de secours originale (type Apple_Boot) > puis réaffiche la configuration du HDD

Poste le retour.
 
La suppression a fonctionné également.

Bloc de code: 
diskutil eraseVolume free null disk1s3 ; diskutil list disk1
Started erase on disk1s3 Recovery HD
Unmounting disk
Finished erase on disk1
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Macintosh HD            799.8 GB   disk1s2
   3:                  Apple_HFS Recovery HD             650.0 MB   disk1s4
 
On continue dans la cosmétique. Passe d'abord la commande :
Bloc de code: 
diskutil umount force disk1s4

  • qui démonte de force le volume Recovery HD
  • si tu obtiens bien en retour un :
Bloc de code: 
Volume Recovery HD on disk1s4 force-unmounted

  • alors enchaîne par la commande (copier-coller à rebours) :
Bloc de code: 
asr adjust --t /dev/disk1s4 --settype "Apple_Boot" ; diskutil list disk1

  • la commande appelle encore l'utilitaire asr > avec une option non documentée : le changement de type de la partition de secours créée > de "Apple_HFS"=> à "Apple_Boot" comme requis > puis réaffiche la configuration du HDD

Poste l'ensemble de l'affichage retourné.
 
J'obtiens le retour suivant :

Bloc de code: 
diskutil umount force disk1s4
Volume Recovery HD on disk1s4 force-unmounted
asr adjust --t /dev/disk1s4 --settype "Apple_Boot" ; diskutil list disk1
Fsck /dev/disk1s4 ....10....20....30....40....50....60....70....80....90....100
Adjust completed successfully
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Macintosh HD            799.8 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s4
 
Configuration finalisée ! -->
Bloc de code: 
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s4

  • l'index d'appareil disk1s4 est une simple résilience dans le kernel (qui a chargé initialement ainsi la partition et n'en démord pas => ce qui n'a strictement aucune importance : c'est le rang dans la table de partition qui importe). La partition créée a le bon volume > le bon rang > le bon type > la bonne localisation sur les blocs.
  • ce qu'une commande va mettre sous les yeux. Passe la commande :
Bloc de code: 
gpt show disk1

  • et poste le tableau de la distribution des blocs du HDD
 
En effet, ça colle :

Bloc de code: 
gpt show disk1
       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  1562026496      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  1562436136     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1563705672   389819463        
  1953525135          32         Sec GPT table
  1953525167           1         Sec GPT header
 
Comme tu peux le voir ici -->
Bloc de code: 
  1562436136     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1563705672   389819463

  • on a réussi à permuter les localisations de la partition de secours (3) et de la bande de blocs libres. Une nécessité logique > car une partition "Apple_CoreStorage" requiert rigoureusement l'existence d'une partition booter (type "Apple_Boot") à coller sans aucun bloc de séparation sa propre limite inférieure --> pour pouvoir récupérer de l'espace libre > qui doit être situé à son tour en-dessous du booter.
----------

On va s'engager pour terminer dans l'opération de récupération de l'espace libre. Mais un système de stockage CoreStorage a ses susceptibilités (on lui a ici "fabriqué un booter a posteriori") : il faut donc passer encore au cran supérieur.

Passe d'abord la commande :
Bloc de code: 
diskutil cs list

  • qui affiche le tableau détaillé du CoreStorage du Fusion Drive

Poste ce tableau.
 
Le tableau du CoreStorage donne ça :

Bloc de code: 
diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group E9AB2027-786F-4BDE-8B78-90E8C9998245
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         827308732416 B (827.3 GB)
    Free Space:   249856 B (249.9 KB)
    |
    +-< Physical Volume 5D3A5542-0617-4B85-8C42-2F16A863C3E5
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     27551166464 B (27.6 GB)
    |
    +-< Physical Volume 2FBA5CA2-5877-4B5B-B9A7-824BCD159FAC
    |   ----------------------------------------------------
    |   Index:    1
    |   Disk:     disk1s2
    |   Status:   Online
    |   Size:     799757565952 B (799.8 GB)
    |
    +-> Logical Volume Family C0E3E8FB-8391-4260-9380-AEEAA02F4531
        ----------------------------------------------------------
        Encryption Type:         None
        |
        +-> Logical Volume 2557800D-8843-4936-A95B-AE2EEAD4C284
            ---------------------------------------------------
            Disk:                  disk3
            Status:                Online
            Size (Total):          826392838144 B (826.4 GB)
            Revertible:            No
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS
            LVG Type:              Fusion, Sparse
 
Chaque partition Apple_CoreStorage des 2 disques contient un magasin de stockage primaire appelé Physical Volume. Les 2 en association --> exportent un espace-disque virtuel commun : un Logical Volume > sur lequel monte le volume classique Macintosh HD.

Ceci -->
Bloc de code: 
    +-< Physical Volume 2FBA5CA2-5877-4B5B-B9A7-824BCD159FAC

  • est le Physical Volume inscrit dans la partition Apple_CoreStorage du HDD. On va tenter de le dilater séparément > pour lui faire absorber les blocs d'espace libre situés sous la partition Apple_CoreStorage du HDD > en-dessous du booter Recovery HD. Ce > sans changement logique de la taille du Logical Volume exporté > ni du volume Macintosh HD monté dessus.

Passe la commande (copier-coller à rebours) :
Bloc de code: 
diskutil coreStorage resizePV 2FBA5CA2-5877-4B5B-B9A7-824BCD159FAC 0b

  • la commande dilate le Physical Volume seul du HDD > aux blocs libres situés en-dessous du booter

Poste l'affichage d'ensemble : tout se joue sur cette commande. Elle affecte séparativement le PV du HDD > pour ne pas "déclencher la susceptibilité" globale du CoreStorage du Fusion Drive > dans sa relation avec un booter fabriqué de toutes pièces et qui est le pivot d'un repartitionnement.
 
Au moins, il ne semble pas y avoir eu d'erreur :

Bloc de code: 
coreStorage resizePV 2FBA5CA2-5877-4B5B-B9A7-824BCD159FAC 0b
Started CoreStorage operation
Growing Core Storage Physical Volume from 799 757 565 952 to 999 345 127 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 999 345 127 424 bytes
Finished CoreStorage operation
 
Le redimensionnement du Physical Volume est acquis. Avant de compléter l'opération > passe la commande informative :
Bloc de code: 
diskutil list disk1

  • et poste le tableau de la configuration du DDE.
 
Yeaaaah :

Bloc de code: 
diskutil list disk1
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Macintosh HD            999.3 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
 
La partition disk1s2 (avec le Physical Volume inclus) a bien été redilatée à 999 Go par absoption des blocs libres.

Reste à dilater en rapport > le disque virtuel du Logical Volume > et le volume Macintosh HD perché dessus. Passe la commande (copier-coller à rebours) :
Bloc de code: 
diskutil coreStorage resizeLV 2557800D-8843-4936-A95B-AE2EEAD4C284 0b

  • la commande dilate le Logical Volume (et le volume Macintosh HD monté sur cet espace-disque virtuel) => à la taille constituée par la somme des tailles actuelles des Physical Volumes

Poste l'affichage retourné.
 
Le retour donne ceci :

Bloc de code: 
diskutil coreStorage resizeLV 2557800D-8843-4936-A95B-AE2EEAD4C284 0b
The Core Storage Logical Volume UUID is 2557800D-8843-4936-A95B-AE2EEAD4C284
Started CoreStorage operation
Verifying file system
Volume was successfully unmounted
Performing fsck_hfs -fn -x /dev/rdisk3
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 HD 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 1 025 980 628 992 bytes
Growing file system
Finished CoreStorage operation
 
Parfait : opération accomplie.

Passe une dernière commande :
Bloc de code: 
diskutil list

  • et poste le tableau des disques qui va mettre le résultat sous les yeux.
 

Sujets similaires

U
macOS Ventura Modifier taille partition
Réponses
2
Affichages
603
macOS
ubuubu
U
B
macOS Monterey souci suite à restauration Time Machine
Réponses
18
Affichages
1K
macOS
bil36
B
Aski
macOS Ventura No CoreStorage logical volume groups found
Réponses
6
Affichages
452
macOS
Locke
Locke
J
10.13 High Sierra Permission denied en essayant d'installer High Sierra depuis une clef USB
Réponses
12
Affichages
1K
macOS
jackoup
J
Vinzzz25
iMac [SSD] X10 Pro n'apparait pas comme SSD [après effacement du disque - partitionnage - Mac OS Étendu (HFS+)]
Réponses
8
Affichages
882
Accessoires Mac
Vinzzz25
Vinzzz25
Haut Bas
Back