Problème avec le partitionnement pour BootCamp

Mister.J

Membre enregistré
18 Août 2016
9
1
31
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
 
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) :
Bloc de code:
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_byte) é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...
 
Dernière édition par un modérateur:
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
 
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 :
Bloc de code:
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 :
Bloc de code:
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...
 
Dernière édition par un modérateur:
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"...
361608_original.png
]

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...]
 
Dernière édition par un modérateur:
:coucou: Mister.J

Désactiver FileVault : c'était comme trancher le Nœud Gordien faute de parvenir à le dénouer...
361608_original.png


[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 :
Bloc de code:
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 :
Bloc de code:
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 :
Bloc de code:
fsck_hfs -fy /dev/rdisk0s2
càd. appeler l'utilitaire standard filesystem_check spécialisé dans le format hfs avec les 2 options : réparer de force (force) sans demander d'autorisation (yes) > 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 : filesystem_check_corestorage, 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]
 
Dernière édition par un modérateur:
  • J’aime
Réactions: scoliaste