Impossible de supprimer partition Bootcamp

swissvb · 11 Décembre 2017

Bonjour à Tous,

Je suis nouveau sur ce forum ; j'ai trouvé les explications de Macomaniac pour Virgile super claires, du coup de je suis lancé pour supprimer la partition Bootcamp.
Pas de souci pour effectuer la commande lors du redémarrage sur la partition de récupération auxiliaire.

- b2) Si c'est le cas chez toi, re-démarre alors par ⌘R sur la partition de récupération auxiliaire Recovery HD et lance l'«Utiltaire de Disque» affiché dans le panneau des 4 Utilitaires OS X => sélectionne dans la colonne de gauche ton volume Mac OS et fais un S.O.S. dessus.

J'ai bien le résultat "le volume Mac OS semble être en bon état".

En revanche, la suite se passage moins bien :

"tu n'as plus qu'à re-démarrer sur ton OS et dans le «Terminal» re-passer la commande b) qui devrait être honorée ce coup-ci.

Voici les commandes passées dans le Terminal après reboot:

diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 2.2 TB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

diskutil cs list
No CoreStorage logical volume groups found

sudo diskutil resizeVolume /dev/disk0s2 0b
..... (checking plein de trucs - tout semble OK)
The volume Macintosh HD appears to be OK
File system check exit code is 0
Resizing
Error: -69742: The requested size change for the target disk or a related disk is too small; please try a different disk or partition, or make a larger change

Quelqu'un a-t-il une idée de ce que je dois faire pour récupérer les 600 GB qu'il me manque ?
Merci d'avance - Swissvb

Membre supprimé 1060554 · 11 Décembre 2017

Salut Swissvb

La commande que tu as passée est valide et le système de fichiers étant sans erreurs --> elle aurait dû passer. Son échec me laisse penser qu'il doit y avoir un problème sous-jacent qui n'apparaît pas dans le tableau des partitions.

Permets-moi une question initiale : quel OS utilises-tu actuellement ?

swissvb · 13 Décembre 2017

macomaniac a dit:
Salut Swissvb

La commande que tu as passée est valide et le système de fichiers étant sans erreurs --> elle aurait dû passer. Son échec me laisse penser qu'il doit y avoir un problème sous-jacent qui n'apparaît pas dans le tableau des partitions.

Permets-moi une question initiale : quel OS utilises-tu actuellement ?

Bonjour Macomaniac,
Je suis sous El Capitan... raison pour laquelle l'assistant Bootcamp ne pouvait pas supprimer la partition Windows.

Deleted member 1099514 · 13 Décembre 2017

Salut

Tu devrais tenter ceci dans le terminal :
diskutil repairDisk disk0
Tu vas avoir un message :
Repairing the partition map might erase disk0s1, proceed? (y/N)
Là tu réponds y
puis faire un
diskutil repairvolume disk0s2
et enfin refaire
diskutil resizevolume disk0s2 0b

Locke · 13 Décembre 2017

swissvb a dit:
Je suis sous El Capitan... raison pour laquelle l'assistant Bootcamp ne pouvait pas supprimer la partition Windows.

Négatif, aucun rapport avec la version de macOS, Assistant Boot Camp n'a jamais posé de problème depuis Lion, tant est-il de n'avoir jamais bidouillé la partition avec Utilitaire de disque. Dès l'instant ou on tente quoi que ce soit avec Utilitaire de disque, il y aura corruption du boot de démarrage.

Membre supprimé 1060554 · 13 Décembre 2017

Le cas de swissvb est intéressant > car il atteste d'une énigme logique.

Le tableau des partitions de son disque est -->

Bloc de code:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            2.2 TB     disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

On voit donc qu'il manque 800 Go qui ont le statut d'espace libre. La première hypothèse qui vient à l'esprit est qu'il s'agissait de la taille d'une ancienne partition BOOTCAMP -->

Bloc de code:

   4:        Microsoft Basic Data BOOTCAMP               800.0 GB   disk0s4

qui s'est trouvée supprimée par l'«Utilitaire de Disque».

La commande passée par swissvb -->

Bloc de code:

sudo diskutil resizeVolume /dev/disk0s2 0b

était parfaitement adaptée à ce cas de figure. Cette commande de re-dimensionnement lance en préalable une vérification d'intégrité du système de fichiers jhfs+ de la partition disk0s2 bénéficiaire --> voici le bilan obtenu :

Bloc de code:

The volume Macintosh HD appears to be OK
File system check exit code is 0

le système de fichiers jhfs+ étant avéré sans erreurs --> la commande s'est trouvée engagée > et aurait dû passer en récupérant les 800 Go d'espace libre situé présumablement en-dessous de la partition disk0s3 Recovery HD.

Eh bien ! surprise : pas du tout --> il obient ce message d'erreur :

Bloc de code:

Error: -69742: The requested size change for the target disk or a related disk is too small; please try a different disk or partition, or make a larger change

Il est bien connu que l'existence d'une partition disk0s3 (Recovery HD) en intercalaire > n'est pas un obtacle à la récupération d'une bande d'espace libre située en queue de disque > car le programme diskutil a la capacité de cloner cette partition de secours à la fin du disque > de supprimer l'original intercalé en disk0s3 > et donc d'étirer le système de fichiers jhfs+ de la partition disk0s2 à la bande d'espace libre désormais limitrophe de la fin de la partition disk0s2.

Or l'erreur retournée ici est typique d'une situation dans laquelle aucun espace libre d'une taille suffisante n'est disponible en-dessous de la partition ciblée comme bénéficiaire (disk0s2). Comment est-ce possible > puisqu'il existe bel et bien 800 Go de blocs libres sur le disque ?

Je vois 2 possibilités théoriques pour rendre compte de cette passionnante petite énigme :

a) la bande d'espace libre de 800 Go n'existe pas en-dessous de la partition de secours disk0s3 (queue de disque) > mais en-dessous de la partition système de l'EFI disk0s1 et donc en-dessus de la partition disk0s2 ciblée comme bénéficiaire.

=> cette hypothèse est limpide (forcément cet espace du dessus ne peut pas être récupéré à la partition du-dessous) > mais absurde si les 800 Go correspondent bien à une ancienne partition BOOTCAMP : comment aurait-elle été située en 1ère position avant la partition de macOS ? - cela dit : on a déjà tout vu en matière de partitionnement tordu.

b) la bande d'espace libre de 800 Go existe bien en-dessous de la partition de secours disk0s3 (queue de disque) > mais si cette bande n'est pas détectée comme espace libre disponible > ce serait parce que, suite à un incident logique, la partition disk0s3 Recovery HD n'est pas strictement accollée à la partition disk0s2 Macintosh HD. Il y aurait alors une petite bande de blocs libres entre la queue de la partition disk0s2 et le départ de la partition disk0s3 --> ce qui aurait pour effet de désolidariser la partition disk0s3 de la disk0s2. Conséquence : les seuls blocs libres que pourrait récupérer le système de fichiers jhfs+ de la partition disk0s2 > constitueraient une bande d'espace libre trop petite en taille (entre la disk0s2 et la disk0s3) pour qu'un re-dimensionnement soit honoré.

=> cette hypothèse est tordue (intellectuellement parlant) > mais elle parvient à rendre compte d'un échec du re-dimensionnement même si les 800 Go de blocs d'espace libre existent bien en-dessous de la disk0s3.

Ces élucubrations effectuées --> je pense que passer la commande :

Bloc de code:

sudo gpt show /dev/disk0

servira de juge de paix entre ces hypothèses plaidant chacune pour son bon droit. Car le tableau de la distribution numérique des blocs du disque va être retourné > et il sautera forcément aux yeux où est situé la grande bande de blocs libres (en haut ou en bas du disque ?) et s'il existe une petite bande de blocs libres ou aucune entre les 2 GPT part et 3 GPT part.

=> tu n'as qu'à poster ce tableau ici, swissvb.

swissvb · 13 Décembre 2017

macomaniac a dit:
Le cas de swissvb est intéressant > car il atteste d'une énigme logique.

Le tableau des partitions de son disque est -->

Bloc de code:

/dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *3.0 TB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_HFS Macintosh HD 2.2 TB disk0s2 3: Apple_Boot Recovery HD 650.0 MB disk0s3

On voit donc qu'il manque 800 Go qui ont le statut d'espace libre. La première hypothèse qui vient à l'esprit est qu'il s'agissait de la taille d'une ancienne partition BOOTCAMP -->

Bloc de code:

4: Microsoft Basic Data BOOTCAMP 800.0 GB disk0s4

qui s'est trouvée supprimée par l'«Utilitaire de Disque».

La commande passée par swissvb -->

Bloc de code:

sudo diskutil resizeVolume /dev/disk0s2 0b

était parfaitement adaptée à ce cas de figure. Cette commande de re-dimensionnement lance en préalable une vérification d'intégrité du système de fichiers jhfs+ de la partition disk0s2 bénéficiaire --> voici le bilan obtenu :

Bloc de code:

The volume Macintosh HD appears to be OK File system check exit code is 0

le système de fichiers jhfs+ étant avéré sans erreurs --> la commande s'est trouvée engagée > et aurait dû passer en récupérant les 800 Go d'espace libre situé présumablement en-dessous de la partition disk0s3 Recovery HD.

Eh bien ! surprise : pas du tout --> il obient ce message d'erreur :

Bloc de code:

Error: -69742: The requested size change for the target disk or a related disk is too small; please try a different disk or partition, or make a larger change

Il est bien connu que l'existence d'une partition disk0s3 (Recovery HD) en intercalaire > n'est pas un obtacle à la récupération d'une bande d'espace libre située en queue de disque > car le programme diskutil a la capacité de cloner cette partition de secours à la fin du disque > de supprimer l'original intercalé en disk0s3 > et donc d'étirer le système de fichiers jhfs+ de la partition disk0s2 à la bande d'espace libre désormais limitrophe de la fin de la partition disk0s2.

Or l'erreur retournée ici est typique d'une situation dans laquelle aucun espace libre d'une taille suffisante n'est disponible en-dessous de la partition ciblée comme bénéficiaire (disk0s2). Comment est-ce possible > puisqu'il existe bel et bien 800 Go de blocs libres sur le disque ?

Je vois 2 possibilités théoriques pour rendre compte de cette passionnante petite énigme :

a) la bande d'espace libre de 800 Go n'existe pas en-dessous de la partition de secours disk0s3 (queue de disque) > mais en-dessous de la partition système de l'EFI disk0s1 et donc en-dessus de la partition disk0s2 ciblée comme bénéficiaire.

=> cette hypothèse est limpide (forcément cet espace du dessus ne peut pas être récupéré à la partition du-dessous) > mais absurde si les 800 Go correspondent bien à une ancienne partition BOOTCAMP : comment aurait-elle été située en 1ère position avant la partition de macOS ? - cela dit : on a déjà tout vu en matière de partitionnement tordu.

b) la bande d'espace libre de 800 Go existe bien en-dessous de la partition de secours disk0s3 (queue de disque) > mais si cette bande n'est pas détectée comme espace libre disponible > ce serait parce que, suite à un incident logique, la partition disk0s3 Recovery HD n'est pas strictement accollée à la partition disk0s2 Macintosh HD. Il y aurait alors une petite bande de blocs libres entre la queue de la partition disk0s2 et le départ de la partition disk0s3 --> ce qui aurait pour effet de désolidariser la partition disk0s3 de la disk0s2. Conséquence : les seuls blocs libres que pourrait récupérer le système de fichiers jhfs+ de la partition disk0s2 > constitueraient une bande d'espace libre trop petite en taille (entre la disk0s2 et la disk0s3) pour qu'un re-dimensionnement soit honoré.

=> cette hypothèse est tordue (intellectuellement parlant) > mais elle parvient à rendre compte d'un échec du re-dimensionnement même si les 800 Go de blocs d'espace libre existent bien en-dessous de la disk0s3.

Ces élucubrations effectuées --> je pense que passer la commande :

Bloc de code:

sudo gpt show /dev/disk0

servira de juge de paix entre ces hypothèses plaidant chacune pour son bon droit. Car le tableau de la distribution numérique des blocs du disque va être retourné > et il sautera forcément aux yeux où est situé la grande bande de blocs libres (en haut ou en bas du disque ?) et s'il existe une petite bande de blocs libres ou aucune entre les 2 GPT part et 3 GPT part.

=> tu n'as qu'à poster ce tableau ici, swissvb.

Effectivement, c'est un peu tordu car Botcamp a été réinstallé par un partenaire Apple car le disque de 3 TB n'était pas supporté officiellement par l'utilitaire Bootcamp sur une ancienne version de MacOSX, upgradée depuis.

Voici le résultat pour mettre tout le monde d'accord !

Bloc de code:

sudo gpt show /dev/disk0

Password:

      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  1565566936        

  1565976576  4293287016      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC

  5859263592     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

  5860533128           7        

  5860533135          32         Sec GPT table

  5860533167           1         Sec GPT header

Il semble qu'il y aie des trous... comme dans l'Emmental (et pas dans le Gruyère) !

Membre supprimé 1060554 · 13 Décembre 2017

C'était donc mon hypothèse a) qui tenait la corde.

Tu as une bande de 1565566936 blocs libres (= 801,5 Go) entre la partition n°1 = EFI et la partition n°2 = Macintosh HD. En-dessous de la paire de partitions n°2 (Macintosh HD) et n° 3 (Recovery HD) --> tu n'as que 7 blocs libres.

Pour voir ce qu'il est possible de faire > passe la commande :

Bloc de code:

df -H /

qui retourne la mesure des espaces : total > libre > occupé du volume Macintosh HD démarré

Poste ici ce petit tableau.

swissvb · 13 Décembre 2017

macomaniac a dit:
C'était donc mon hypothèse a) qui tenait la corde.

Tu as une bande de 1565566936 blocs libres (= 801,5 Go) entre la partition n°1 = EFI et la partition n°2 = Macintosh HD. En-dessous de la paire de partitions n°2 (Macintosh HD) et n° 3 (Recovery HD) --> tu n'as que 7 blocs libres.

Pour voir ce qu'il est possible de faire > passe la commande :

Bloc de code:

df -H /

qui retourne la mesure des espaces : total > libre > occupé du volume Macintosh HD démarré

Poste ici ce petit tableau.

Voila !

Bloc de code:

iMac-2:~ swissvb$ df -H /

Filesystem     Size   Used  Avail Capacity   iused    ifree %iused  Mounted on
/dev/disk0s2   2.2T   2.0T   156G    93% 498492830 38168045   93%   /

Membre supprimé 1060554 · 13 Décembre 2017

Tu as 2 To de données dans le volume Macintosh HD.

Est-ce que tu as une sauvegarde complète de ces données : clone ou TM ?

swissvb · 13 Décembre 2017

Oui ! Time Capsule

Membre supprimé 1060554 · 13 Décembre 2017

J'ai posé cette question parce que : il est théoriquement possible de recréer une partition de 800 Go (avec un volume) qui précéderait l'actuelle partition Macintosh HD. Mais impossible de cloner 2 To de ses données dans les 800 Go du volume de la partition de tête. Et impossible aussi d'agrandir la partition Macintosh HD en direction du haut - comme tu l'as déjà vu.

Est-ce que tu tiens à récupérer un volume Macintosh HD de 3 To ? - si oui > il est clair qu'il faut, à partir d'un démarrage externe, effacer le disque de 3 To entier > recréer un seul volume de 3 To > remettre l'OS et tes données dans ce volume.

swissvb · 13 Décembre 2017

OK ! Merci Macomaniac.
Je vais connecter le disque TimeCapsule en cable réseau pour permettre une restauration rapide.
- a bientôt !

Membre supprimé 1060554 · 13 Décembre 2017

Il faut que tu effaces le disque complet du Mac > pour exporter un volume de 3 To > avant la récupération.

Si tu avais eu seulement dans les 700 Go de données dans le volume Macintosh HD > j'aurais pu te faire recréer une partition et un volume à partir des 800 Go de blocs libres > puis clonage du volume Macintosh HD dans le nouveau volume > effacement de Macintosh HD > récupération de cet espace à la nouvelle partition de tête et à son volume. À l'arrivée : un volume de 3 To avec des données identiques à avant. Mais avec 2 To de données --> aucune chance !

Goromata · 9 Janvier 2018

Bonjour,

Je me permets de remonter ce sujet car j'ai également un problème de suppression de ma partition bootcamp.
Depuis la mise à jour Fall creator update windows 10, l'option pour supprimer la partition Bootcamp n'apparait plus dans l'assistant.

J'ai donc supprimé les deux partitions via les commandes (disk1s4 et disk1s5) puis lors de la réallocation de l'espace libéré sur disk1s2 (Apple_CoreStorage Macintosh HD) j'ai le message d'erreur suivant :

Bloc de code:

Volume format does not support resizing

Ai-je choisi le bon disk pour la réallocation ? Ou dois-je choisir le disk2 ?
Je dois dire qu'avec le fusion Drive, je suis un peu perdu.

Concernant les commandes, voici le résultat du début avant effacement :

diskutil list

Bloc de code:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            121.0 GB   disk0s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage Macintosh HD            2.5 TB     disk1s2
   3:                 Apple_Boot Recovery HD             650.1 MB   disk1s3
   4:         Microsoft Reserved                         16.8 MB    disk1s4
   5:                  Apple_HFS BOOTCAMP                455.4 GB   disk1s5
/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +2.7 TB     disk2
                                 Logical Volume on disk0s2, disk1s2
                                 4EEB7324-1058-4529-ABDE-E049DECDC0C4
                                 Unencrypted Fusion Drive

diskutil cs list

Bloc de code:

CoreStorage logical volume groups (1 found) | +-- Logical Volume Group 0315AAF8-5CDD-4A4D-B7FB-DEE520401027 ========================================================= Name: Macintosh HD Status: Online Size: 2665186861056 B (2.7 TB) Free Space: 0 B (0 B) | +-< Physical Volume 870797D4-A1E6-4D53-AA6B-C0AFC4666F0F | ---------------------------------------------------- | Index: 0 | Disk: disk0s2 | Status: Online | Size: 120988852224 B (121.0 GB) | +-< Physical Volume 2FA555F6-7A1C-4876-9883-EAC7BCDA0013 | ---------------------------------------------------- | Index: 1 | Disk: disk1s2 | Status: Online | Size: 2544198008832 B (2.5 TB) | +-> Logical Volume Family B2FD8F76-E6D2-45D6-890D-DFC4F11D9593 ---------------------------------------------------------- Encryption Type: None | +-> Logical Volume 4EEB7324-1058-4529-ABDE-E049DECDC0C4 --------------------------------------------------- Disk: disk2 Status: Online Size (Total): 2658999992320 B (2.7 TB) Revertible: No LV Name: Macintosh HD Volume Name: Macintosh HD Content Hint: Apple_HFS LVG Type: Fusion, Sparse

Et ceux d'après effacement :

diskutil list

Bloc de code:

/dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *121.3 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_CoreStorage Macintosh HD 121.0 GB disk0s2 3: Apple_Boot Boot OS X 134.2 MB disk0s3 /dev/disk1 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *3.0 TB disk1 1: EFI EFI 209.7 MB disk1s1 2: Apple_CoreStorage Macintosh HD 2.5 TB disk1s2 3: Apple_Boot Recovery HD 650.1 MB disk1s3 /dev/disk2 (internal, virtual): #: TYPE NAME SIZE IDENTIFIER 0: Apple_HFS Macintosh HD +2.7 TB disk2 Logical Volume on disk0s2, disk1s2 4EEB7324-1058-4529-ABDE-E049DECDC0C4 Unencrypted Fusion Drive

diskutil cs list

Bloc de code:

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0315AAF8-5CDD-4A4D-B7FB-DEE520401027
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         2665186861056 B (2.7 TB)
    Free Space:   0 B (0 B)
    |
    +-< Physical Volume 870797D4-A1E6-4D53-AA6B-C0AFC4666F0F
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     120988852224 B (121.0 GB)
    |
    +-< Physical Volume 2FA555F6-7A1C-4876-9883-EAC7BCDA0013
    |   ----------------------------------------------------
    |   Index:    1
    |   Disk:     disk1s2
    |   Status:   Online
    |   Size:     2544198008832 B (2.5 TB)
    |
    +-> Logical Volume Family B2FD8F76-E6D2-45D6-890D-DFC4F11D9593
        ----------------------------------------------------------
        Encryption Type:         None
        |
        +-> Logical Volume 4EEB7324-1058-4529-ABDE-E049DECDC0C4
            ---------------------------------------------------
            Disk:                  disk2
            Status:                Online
            Size (Total):          2658999992320 B (2.7 TB)
            Revertible:            No
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS
            LVG Type:              Fusion, Sparse

Après effacement, les volumes effacés n'apparaissent plus. Quelle est la marche à suivre pour récupérer mon espace manquant ? :O

PS: je suis sous El Capitan. Toutes mes données sont sauvegardées donc pas de souci si il faut tout effacer.

Merci beaucoup de votre aide

Membre supprimé 1060554 · 9 Janvier 2018

Bonjour Goromata

Goromata a dit:
pas de souci si il faut tout effacer.

On ne devrait pas avoir à en arriver là.

Suite à ta suppression des 2 partitions disk1s4 et disk1s5 -->

Bloc de code:

3:                 Apple_Boot Recovery HD             650.1 MB   disk1s3
4:         Microsoft Reserved                         16.8 MB    disk1s4

leur espace existe bien évidemment toujours au même endroit du disque > càd. en queue du HDD disk1 > simplement cette existence est constituée actuellement de blocs libres (free_space) hors partitionnement.

Dans la mesure où il s'agit de récupérer cet espace de blocs libres à un volume (Macintosh HD) qui est l'hôte d'un système de stockage CoreStorage - et chez toi un CoreStorage important 2 magasins de stockage physique Physical Volumes puisque tu as un Fusion Drive ou CoreStorage associatif --> alors la commande de re-dimensionnement valide doit adresser le Logical Volume unique exporté par le CoreStorage.

C'est donc une commande de re-dimensionnement non pas standard (valide uniquement si le volume-cible dépend d'un format jhfs+ simple) > mais spécifique (valide si le volume-cible dépend d'un système de stockage CoreStorage).

La commande valide a donc la syntaxe générale suivante :

Bloc de code:

diskutil coreStorage resizeStack LV_UUID 0b

diskutil est appelé > avec la spécificité coreStorage (l'abréviation cs est aussi valide) > le verbe spécialisé resizeStack (redimensionner la pile logique du CoreStorage) qui remplace ici le verbe standard resizeVolume (valide uniquement si le volume-cible dépend d'un système de fichiers jhfs+ courant) > l'UUID du Logical Volume du CoreStorage comme désignation de la cible > enfin 0b comme mention de taille (= 0_byte qui s'interprète : "récupérer tout l'espace libre disponible en-dessous sans excepter aucun byte).

Cette syntaxe générale appliquée à ton cas devient la commande :

Bloc de code:

diskutil coreStorage resizeStack 4EEB7324-1058-4529-ABDE-E049DECDC0C4 0b

où comme tu le vois tu ne fais que remplacer ma variable LV_UUID par l'UUID réel du Logical Volume = 4EEB7324-1058-4529-ABDE-E049DECDC0C4

Cette commande induit une opération logique véritablement complexe : l'étirement de la partition disk1s2 du HDD & concomitamment l'étirement du Physical Volume inscrit sur cette partition > l'étirement du Logical Volume exporté à partir des 2 magasins de stockage physique & l'étirement du système de fichiers jhfs+ accroché au dev node (point de montage) du Logical Volume - le tout en mode "live" (le volume Macintosh HD démarré maintenu monté). Il y a une segmentation temporelle des 2 paires de redimensionnement : la paire "physique" (partition - physical volume) et la paire "logique" (logical volume - jhfs+).

La commande peut se trouver avortée pour plusieurs raisons à cause de cette complexité logicielle. Mais l'étonnant est le très petit nombre de cas où le re-dimensionnement avorte.

[Le CoreStorage est un des grands titres de gloire de l'ingéniérie Apple. Une création absolue qui remonte à l'OS «Lion 10.7» (l'OS de toutes les innovations - injustement décrié) publié en Juillet 2011. Préparatoire dans le concerpt du système de stockage par Conteneur apfs. Quand on pense que tout ce que Microsoft avait à proposer en concurrence était un Windows-7 qui bootait de façon désuète en mode Legacy (BIOS --> MBR) : ça donne envie de rigoler rétrospectivement.]

Goromata · 9 Janvier 2018

Bonjour macomaniac,

Merci infiniment pour cette réponse si rapide et détaillée ! Le problème est maintenant réglé. Très impressionnant :O
Je te suis également très très reconnaissant pour ta pédagogie, je comprends mieux la subtilité du Fusion Drive maintenant.

Bloc de code:

The Core Storage Logical Volume UUID is 4EEB7324-1058-4529-ABDE-E049DECDC0C4
Started CoreStorage operation
Checking prerequisites for resizing Logical-Physical volume stack
Growing Logical-Physical volume stack
Verifying file system
Using live mode
Performing live verification
Checking Journaled HFS Plus volume
Checking catalog file
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Macintosh HD appears to be OK
The volume Macintosh HD appears to be OK
File system check exit code is 0
Growing Core Storage Physical Volume from 2544198008832 to 2999733108736 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 2999733108736 bytes
Growing Logical Volume
Resizing Core Storage Logical Volume structures
Resized Core Storage Logical Volume to 3114535092224 bytes
Growing file system
Finished CoreStorage operation

Encore merci pour ton aide !

ledabou47 · 20 Mars 2018

voici ce que me donne la commande :

Bloc de code:

The Core Storage Logical Volume UUID is 08BC6C2F-8A23-4C7D-B3E1-10C0F61ED8FC
Started CoreStorage operation
Checking prerequisites for resizing Logical-Physical volume stack
Growing Logical-Physical volume stack
Verifying file system
Using live mode
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 multi-linked directories
Incorrect number of directory hard links
Checking volume bitmap
Checking volume information
The volume Macintosh HD was found corrupt and needs to be repaired
File system check exit code is 8
Error: -69845: File system verify or repair failed

xxjanotxx · 27 Novembre 2018

Bonjour,

J'ai le même problème... Les explications de Macomaniac sont très clair mais je but quand même.
Je suis sur MacBook Air 2014.
J'ai bien réussi à supprimer la partition bootcamp mais je n'arrive pas à la "réalouer" à 120Go
Apres avoir effectué la commande "diskutil list" je ne peut pas effectuer la commande "sudo diskutil resizeVolume /dev/disk0s2 0b"
le message "/dev/disk0s2 is an APFS Physical Store (use "diskutil apfs resizeContainer" instead to resize)" apparait.

De plus, je ne peut pas effectuer l'autre commande "diskutil cs list"
un autre message apparait "No CoreStorage logical volume groups found"

merci de votre aide

Membre supprimé 1060554 · 27 Novembre 2018

Tu as une partition résiduelle bloquante (n°3) + il faut adapter la commande au nouveau type d'objet = une partition receveuse de type apfs.

Ce qui nous donne (copier-coller) -->

Bloc de code:

diskutil eraseVolume free null disk0s3 ; diskutil ap resizeContainer disk1 0b ; diskutil list

cette commande concaténée : supprime la partition 3 > récupère tout l'espade libre au Conteneur apfs et à sa partition de base 2 > réaffiche le tableau des disques

Poste l'ensemble de l'affichage retourné en copier-coller (pas de capture) > mais en veillant à faire ton coller dans une fenêtre de code par le précédé suivant -->

dans la page de ce fil de MacGé > presse le bouton

ici :

menu  : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

Impossible de supprimer partition Bootcamp

Membre enregistré

Membre supprimé 1060554

Invité

Membre enregistré

Deleted member 1099514

Invité

What am I doing here?

Membre supprimé 1060554

Invité

Membre enregistré

Membre supprimé 1060554

Invité

Membre enregistré

Membre supprimé 1060554

Invité

Membre enregistré

Membre supprimé 1060554

Invité

Membre enregistré

Membre supprimé 1060554

Invité

Membre enregistré

Membre supprimé 1060554

Invité

Membre enregistré

Membre enregistré

Membre enregistré

Fichiers joints

Membre supprimé 1060554

Invité

Sujets similaires