# Problème avec le partitionnement pour BootCamp



## Mister.J (18 Août 2016)

Bonjour,

J'ai récemment tenté d'installer Windows via BootCamp sur mon MacBook Pro sous OS X El Capitan , et le Mac à crashé pendant le partitionnement. 

Résultat, je me retrouve avec 120 GO utilisé dans le vide, et je ne trouve pas de solution pour récupérer cet espace malgré mes recherches Internet. 

Est-ce que quelqu'un pourrait me donner un coup de main SVP?

Si ça peut aider voici le diskutil list:

/dev/disk0 (internal, physical):
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *500.1 GB   disk0
1:                        EFI EFI                     209.7 MB   disk0s1
2:          Apple_CoreStorage Macintosh HD            499.2 GB   disk0s2
3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1 (internal, virtual):
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:                  Apple_HFS Macintosh HD           +378.9 GB   disk1

                                Logical Volume on disk0s2

                                200F35C8-245C-4803-83E4-450801C15281

                                Unlocked Encrypted
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 515FE753-42D5-4B80-B4DF-75AECAB1FD64
   =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         499248103424 B (499.2 GB)
    Free Space:   120018976768 B (120.0 GB)
    |
    +-< Physical Volume DEAA860E-678C-4970-9910-9F71C52BE035
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     499248103424 B (499.2 GB)
    |
    +-> Logical Volume Family 0259BC9A-92F6-4966-89EA-9670939FE041
   ----------------------------------------------------------
        Encryption Type:         AES-XTS
        Encryption Status:       Unlocked
        Conversion Status:       Complete
        High Level Queries:      Fully Secure
        |                        Passphrase Required
        |                        Accepts New Users
        |                        Has Visible Users
        |                        Has Volume Key
        |
        +-> Logical Volume 200F35C8-245C-4803-83E4-450801C15281
            ---------------------------------------------------
            Disk:                  disk1
            Status:                Online
            Size (Total):          378876805120 B (378.9 GB)
            Revertible:            Yes (unlock and decryption required)
            Revert Status:         Reboot required
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS


----------



## macomaniac (18 Août 2016)

Salut *Mister.J
*
Ton cas de figure est une variante assez curieuse (dont je me délecte).

- Tu remarqueras, en effet, que ta partition *2: Apple_CoreStorage Macintosh HD 499.2 GB disk0s2* intrinsèquement parlant a la bonne taille = *499.2 GB* > on en déduit que l'*espace libre* manquant ne lui est pas extérieur.

- C'est à l'intérieur du *Groupe de Volumes Logiques* (impliqué par l'activation de «FileVault» responsable d'un chiffrement) que se situe l'*espace libre* en question > en effet, le *Volume Logique*  exporté *Macintosh HD* de *378.9 GB* est plus petit que le *Volume Physique* (disque dur émulé) importé de *499.2 GB*.​
Il convient donc d'opérer un re-dimensionnement "_endogène_" et pas "_exogène_" du *CoreStorage*. Tu peux tenter en mode live la commande spécifique suivante (copier-coller) :

```
diskutil coreStorage resizeVolume 200F35C8-245C-4803-83E4-450801C15281 0b
```
 qui appelle *diskutil* avec la spécification *coreStorage* et le verbe *resizeVolume* (re-dimensionner le *Volume Logique*) sur la cible de l'*UUID* du *Logical Volume* et avec l'option finale *0b* (*0*_*b*yte) équivalent à dire : "récupérer tout l'espace disponible jusqu'à épuisement du dernier byte" (disponible sur le disque dur émulé du *Physical Volume* - s'entend).

Le succès de cette commande est soumis à une double restriction :

- une vérification d'intégrité du système de fichiers *JHFS+* ancré sur un *dev_node* exporté par le *Volume Logique* va s'opérer en préalable > si le système de fichiers comporte des erreurs  > étant irréparable en situation de gestion d'un volume monté démarré comme ici (car la réparation requiert son démontage) > la commande avortera => le signaler alors.

- la présence d'un chiffrement, qui a tendance à réduire l'élasticité du dispositif du *CoreStorage*.​
=> tu vas bien voir si la commande passe ou non...


----------



## Mister.J (18 Août 2016)

Merci de m'avoir répondu macomaniac j'ai rentré la commande et j'ai obtenu ce résultat :

The Core Storage Logical Volume UUID is 200F35C8-245C-4803-83E4-450801C15281
Started CoreStorage operation
Error: -69674: The provided Core Storage logical volume has an incorrect size; you should run whole-disk repair


----------



## macomaniac (18 Août 2016)

Je me doutais un peu que la commande foirerait en direct.

Donc voici ce que tu vas faire :

*- a)* tu re-démarres en tenant pressées les touches *⌘R* (*cmd R*) en mode *Recovery* (ce qui va permettre de manipuler le système de fichiers terminal *JHFS+*).

*- b)* tu lances l'«Utilitaire de Disque» et tu sélectionnes dans sa colonne de gauche le volume à la fois _grisé_ (démonté) et _réduit_ (verrouillé par le chiffrement) du *Volume Logique* : *Macintosh HD* > tu vas de là à la barre de menus supérieure du logiciel > _Fichier_ > sous-menu : "_Déverrouiller_" > un panneau de demande de mot-de-passe s'affiche > tape ton mot-de-passe d'ouverture de session dans l'OS > tu vas désormais voir affiché un *Volume Logique Macintosh HD* en pleine taille (déverrouillé) et gras (remonté) qui est désormais manipulable.

*- c)* tu peux faire un _S.O.S._ sur *Macintosh HD* remonté.

*- d)* tu quittes l'«Utilitaire de Disque» > tu vas à la barre supérieure de menus de l'écran > menu : _Utilitaires_ > Terminal > tu passes la commande :

```
diskutil cs list
```
 qui te restitue les identifiants des instances du *CoreStorage* > tu sélectionnes et par *⌘C* tu colles dans le presse-papier l'*UUID* du *Logical Volume Group* tout en haut de l'affiche > tu enchaînes par la commande :

```
fsck_cs -y 515FE753-42D5-4B80-B4DF-75AECAB1FD64
```
 où tu colles à la fin par *⌘V *l'*UUID* du *Groupe de Volumes Logiques* de ton presse-papier.​
=> à toi de dire si le *Volume Logique* a repris sa taille attendue...


----------



## Mister.J (18 Août 2016)

J'obtiens:
unable to examine 515FE753-42D5-B4DF-75AECAB1FD64: No such file or directory


----------



## macomaniac (18 Août 2016)

Alors je te conseille carrément, à partir de la session de ton OS, de désactiver «FileVault» en allant à : _Menu_  > _Préférences Système_ > _Sécurité et condidentialité_ > _FileVault_ > déverrouiller cadenas d'administration > presser le bouton "Désactiver FileVault".

[car la suppression du chiffrement du volume de l'OS implique la déconstruction du format *CoreStorage* et donc la suppresson du dispositif du *Volume Logique* actuellement affecté par une erreur de taille. C'est ce qu'on appelle résoudre une erreur en supprimant le "porteur de l'erreur"... 
	

	
	
		
		

		
			





 ]

Le processus de déchiffrement, après re-démarrage, est lent > ne lance pas de processus lourds dans ta session pour ne pas le ralentir davantage. Le panneau _FileVault_ des _Préférences Système_ affichera une barre de progression > à complétion > *re-démarre* ton Mac pour que le *kernel* enregistre la disparition du *CoreStorage*.

Passe alors un *diskutil list* dans le «Terminal» > qui devrait retourner un partitionnement standard sans problème.

[Je pense que le plantage de ton Mac en plein re-partitionnement d'un *CoreStorage Chiffré* a suscité des erreurs d'espace dans le *Groupe de Volumes Logiques* qu'il vaut mieux récupérer via un déchiffrement > lequel a pour corollaire régulier la suppression du *CoreStorage* avec retour à un système de fichiers *JHFS+* standard sur la partition *disk0s2 Macintosh HD*.

J'ajoute que, si tu cherches à repartitionner cette partition pour installer Windows sur une partition *disk0s4* créée _ad hoc_ par l'«Assistant BootCamp» > l'existence d'un *CoreStorage Chiffré* sur la partition de l'OS est le plus sûr moyen de faire échouer ce processus...]


----------



## Mister.J (19 Août 2016)

Désactiver FileVault a très bien marché merci de ton aide macomaniac.


----------



## macomaniac (19 Août 2016)

*Mister.J*

Désactiver FileVault : c'était comme trancher le _Nœud Gordien_ faute de parvenir à le dénouer... 
	

	
	
		
		

		
		
	


	




[MODE: DEBRIEFING]
La commande que je t'avais donnée à passer dans le «Terminal» de la *Recovery* - je m'avise après coup qu'il y manquait la mention de l'option : *--uuid* avant l'énoncé de l'*UUID* du *Logical Volume Group* > elle aurait donc dû être :

```
fsck_cs -y --uuid 515FE753-42D5-4B80-B4DF-75AECAB1FD64
```
 pour être acceptée. Mais je me demande si, rectifiée, elle aurait eu un effet réparateur.

Intrigué par le cas de figure que tu as soumis > je me suis amusé à convertir la partition de mon OS «El Capitan», gérée au départ par un banal système de fichiers *JHFS+*, au format *CoreStorage* (non chiffré). Cela opéré > comme l'espace de cette partition était de *100 Go* et la taille des données de simplement *47 Go* > j'ai passé une commande de rétrécissement du *Volume Logique* à l'intérieur du *Groupe de Volumes Logiques* de ce *CoreStorage* à une taille de *70 Go* > de manière à générer "intra_muros" (du périmètre du *CoreStorage*) un espace_libre de *30 Go*.

Le rétrécissement interne d'un *Volume Logique CoreStorage* est d'une lenteur fastidieuse, même sur un SSD : il a fallu presque une demi-heure pour que l'opération se complète. À l'arrivée, j'avais donc une partition *disk0s2 El Capitan* de *100 Go*, avec un *Groupe de Volumes Logiques* de *100 Go* aussi, dont le dispositif était : *Physical Volume* (disque dur émulé importé sur l'espace de la partition d'accueil) = *100 Go* > *Volume Logique* (exporté à partir du *Physical Volume*) = *70 Go* > il y avait donc *30 Go* d'espace-disque virtuel du *Physical Volume* inemployé.

J'ai donc passé une commande (en mode "_live_" : l'OS *El Capitan* dépendant du *Volume Logique* démarré) de re-dilatation du *Volume Logique* analogue à celle que je t'avais donnée :

```
diskutil CoreStorage resizeVolume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 0b
```
 et en une poignée de secondes le *Volume Logique* de *70 Go* est revenu à une taille de *100 Go* congruente du *Physical Volume* lui servant de disque-support.

De ce succès (dans mon cas) et de cet échec (dans ton cas) > se laisse déduire l'interprétation suivante : de l'espace libre intra-*CoreStorage* n'est récupérable par une commande formelle de dilatation du *Volume Logique*, que s'il s'est agi à l'origine d'une opération formelle de retaillage dûment enregistrée dans les "*headers*" (en-têtes) du *CoreStorage* ; mais si l'espace libre en question est survenu par accident de re-partitionnement (comme dans ton cas de figure) > alors il co-existe avec une erreur de statut du *Volume Logique* (qui a des chances d'impliquer une erreur du système de fichiers *JHFS+* amarré sur lui à un *dev node*). Aucune commande formelle de re-dimensionnement interne n'est susceptible d'être acceptée, car le *Volume Logique* est invalide.

[tu as eu de la chance, je pense, de pouvoir encore démarrer sur ce volume de taille invalide sans plantage.]

Dans de telles conditions > je pense qu'il faut directement tenter de réparer le dispositif logique du *CoreStorage* > ce à partir d'un Système autonome : celui de la *Recovery*. Il doit suffire de tenter un :

```
fsck_hfs -fy /dev/rdisk0s2
```
 càd. appeler l'utilitaire standard *f*ile*s*ystem_*c*hec*k* spécialisé dans le format *hfs* avec les 2 options : réparer de force (*f*orce) sans demander d'autorisation (*y*es) > car cet utilitaire a été "étoffé" pour gérer le format *CoreStorage* quand il enveloppe le système de fichiers *JHFS+* impliqué (j'ai l'impression que l'utilitaire spécialisé *fsck_cs* : *f*ile*s*ystem_*c*hec*k*_*c*ore*s*torage, créé en même temps que le format *CoreStorage* à l'époque de «Lion 10.7», est un programme "bidonné"). Dommage dans ton cas de n'avoir pas pu constater l'issue produite par cette commande de réparation.

Noter que le _S.O.S._ que j'avais préconisé dans l'«Utilitaire de Disque» (après remontage du *Volume Logique* déverrouillé) est une manière graphique de lancer la commande *fsck_hfs* > vérifier à la suite par un *diskutil cs list* la taille du *Volume Logique* aurait permis de vérifier si une commande de réparation produit l'effet escompté.

Sinon : opérer une réversion du *CoreStorage* est la solution radicale (et lorsqu'il y a chiffrement, déclencher la désactivation de FileVault opère corrélativement cette réversion) --> c'est ce qui a bien marché chez toi.
[/MODE]


----------

