Vous utilisez un navigateur non à jour ou ancien. Il ne peut pas afficher ce site ou d'autres sites correctement. Vous devez le mettre à jour ou utiliser un navigateur alternatif.
Récupérer l'espace libre sur la partition principale
J'ai un soucis avec mon Disk utility, j'ai supprimé ma partition bootcamp et je voudrais récupérer l'espace sur ma partition mac sauf que Disk utility ne me le permet pas, je ne peut pas étirer ma partition:
Je ne peut même pas créer une nouvelle partition sur l'espace libre, je peux transformer l'espace libre en un type de partition mais après avoir appliqué rien n'apparait...
J'ai tenté de passer par le terminal avec la commande diskutil resizevolume et voilà ce que j'obtiens:
J'ai aussi tenté avec le Disk utility et le terminal en démarrant en mode restoration mais c'est pareil...
mimi n'a pas un Fusion Drive (qui solidarise 2 disques physiques distincts : un SSD et un HDD), mais un format CoreStorage simple sur la partition /dev/disk0s2 de son seul disque interne (= /dev/disk0), càd. celle où est installé l'OS. Le /dev/disk1 n'est pas un disque physique séparé, c'est la façon dont le Volume Logique exporté par le CoreStoragese trouve identifié couramment.
Lorsque un tel format CoreStorage se trouve greffé sur la partition de l'OS, celle-ci s'en trouve verrouillée en taille, et il est impossible de la dilater par absorption de l'espace correspondant à une partition extérieure (qui ici, suite à sa suppression du partitionnement, a été viré au statut de free_space = espace libre hors partitionnement actuel). L'«Utilitaire de Disque» n'est donc pas à incriminer : le programme diskutil qu'il pilote graphiquement (et qui peut être aussi invoqué dans le «Terminal» par une commande diskutil resizeVolume comme évoqué) ne peut rien, dans ses verbes d'opération standard, face au format CoreStorage, qui relève d'un régime spécial.
Ce format CoreStorage n'est pas tombé du ciel : soit l'OS actuellement installé est «Yosemite», et ça fait partie d'un "dommage collatéral" de son instalaltion (l'installateur de «Yosemite» exécute fréquemment l'instruction de générer un format CoreStorage sur la partition-cible de l'installation en préalable à cette installation) ; soit, quelque soit l'OS actuellement installé, le chiffrement «FileVault-2» du volume de l'OS a été activé, et l'instauration d'un format CoreStorage sur la partition /dev/disk0s2 de l'OS est alors la condition formelle de la possibilité d'exécuter le chiffrement.
Quel que soit l'acte de naissance de l'actuel CoreStorage, la suppression de ce format est la condition sine qua non de la possibilité de réabsorber le free_space (correspondant à l'ancienne partition_BootCamp) au volume de l'OS), car seul le format standard jhfs+ = Mac OS étendu (journalisé)est un format de fichiers "extensible" (NB. si un format CoreStorage sur la partition de l'OS n'interdit pas dans le sens de l'aller son re-partitionnement par l'«Assistant BootCamp» afin de créer à l'extérieur un volume dédié à l'installation de «Windows» ; par contre, l'opération inverse, dans le sens du retour, d'une récupération de l'espace de cette partition à celle de l'OS est bloquée par le CoreStorage : il y a asymétrie dans la gestion du partitionnement).
Mais pour ce qui est de la modalité de cette suppression, elle est soit directement possible non destructivement pour le volume de l'OS et ses données, soit impossible non destructivement en fonction des paramètres internes du Groupe de Volumes Logiques généré par le CoreStorage.
Pour le savoir, mimi, de ta session d'OS habituelle, va à : Applications/Utilitaires pour lancer le «Terminal» et passe la commande :
Bloc de code:
diskutil cs list
afin d'obtenir l'affichage du tableau du Groupe de Volumes Logiques : CoreStorage --> est-ce que tu peux en faire un copier-coller ici? Les informations qui s'y trouvent décident si une suppression directe non destructive du volume de l'OS est envisageable (ou s'il faut recourir à des voies détournées)...
Hello, merci pour ta réponse très instructive, j'ai fini par trouver le moyen de récupérer mon espace libre, je suis passé par une installe d'un bootcamp, après être arrivé au moment de l'installation windows où l'on choisi sur quelle partition installer le système, j'ai crée une partition sur mon espace libre et ai redémarré sous OSX, j'ai relancé l'assistant bootcamp et ai pu supprimé l'installation de windows, l'assistant à ensuite étendu la partition OSX à la partition créer par l'installation windows, donc mon ancien espace libre!
Pou info, voici le résultat de la commande diskutil cs list maintenant:
La mention : Revertible : yes (no decryption required) (dans le dernier § décrivant le Logical Volume) indique que le CoreStorage est supprimable non destructivement pour le volume de l'OS et ses données. Comme il n'y a pas chiffrement, c'est que l'activation de «FileVault-2» n'a pas été l'initiatrice du CoreStorage --> l'OS installé doit donc être «Yosemite» et c'est une instruction interne du Programme d'Installation qui a généré ce format. Étant réversible, je conjecture qu'il s'est agi de la mise-à-niveau d'un OS précédemment installé sur la partition : «Mavericks» peut-être?
Au cas, mimi, où tu voudrais te débarrasser de ce format, tu peux le faire en mode live depuis la session de ton OS démarré. Il te suffit dans le «Terminal» de saisir :
[c'est l'UUID de 34 caractères alpha-numériques du Volume Logique tout en bas du tableau] et ↩︎ puis mot-de-passe admin tapé à l'aveugle - aucun caractère ne se montrant à la frappe - à la demande de password et ↩︎ --> le volume de l'OS va être restitué à un format standard jhfs+ non destructivement. Re-démarrer le Mac après la complétion de l'opération.
Mais je vois que tu a résolu ton problème tout seul en recréant un volume à partir de ton free_space, puis en réactivant la fonction de suppression de la partition dédiée à Windows de l'Assistant BootCamp --> que tu aies réussi, alors même qu'un format CoreStorage était greffé sur la partition de l'OS est une première sur ce forum, car jusqu'ici les fils exposant le même problème initial que le tien attestaient de l'incapacité de l'«Assistant BootCamp» à réallouer à la partition de l'OS l'espace de la partition dédiée à Windows que l'utilisateur souhaitait supprimer - dès lors qu'un format CoreStorage était présent sur la partition de l'OS.
☞ Faut-il y avoir l'effet d'une mise-à-jour récente du programme de l'«Assistant BootCamp»? Ce serait ma conjecture...
Grand merci, Jean, pour cette fine pioche : cette page explorant des options supplémentaires dans la commande diskutil coreStorage
Par-delà la ligne de crête du "documenté", voici que se découvre un horizon nouveau : la terra incognita du CoreStorage non documenté...
Chaque jour espérant des lendemains épiques L'azur phosphorescent de la mer des Tropiques Enchantait leur sommeil d'un mirage doré
Ou, penchés à l'avant des blanches caravelles, Ils regardaient monter dans un ciel ignoré Du fond de l'océan des étoiles nouvelles...
--------------------
La commande : diskutil coreStorage resizeVolume, voire diskutil coreStorage resizeStack, notamment, semble avoir fait partie dès l'origine (la création du format CoreStorage avec l'OS «Lion 10.7») des fonctionnalités du programme diskutil à l'insu des utilisateurs s'alignant sur la documentation du man correspondant. Commandes expressives d'un état de fait : le caractère intrinsèquement extensible du CoreStorage (à l'instar du format standard jhfs+) depuis le départ.
Et pourtant... Pourtant, en effet, l'expérience des utilisateurs qui, après avoir créé une partition "au-delà" du CoreStorage via l'«Assistant BootCamp» afin d'y installer Windows, souhaitaient supprimer cette partition et en réintégrer l'espace-disque à celle de la partition de l'OS supportant le format CoreStorage a régulièrement témoigné d'un échec de l'«Assistant BootCamp» à opérer cette "marche-arrière" --> ce qui donnait à penser que le format CoreStorage verrouillait en taille la partition de l'OS - du moins dans le sens rétrograde d'une dilatation par intégration de l'espace-disque d'une autre venant après elle.
La manipulation de mimi témoigne dans ce contexte d'une première : la capacité de l'«Assistant BootCamp» pour la première fois à réintégrer une ex-partition Windows créée hors CoreStorage à la partition de l'OS supportant le format CoreStorage.
Je conjecture alors ce qui suit : le logiciel «Assistant BootCamp» a dû être mis-à-jour récemment dans sa capacité à passer une commande de type : diskutil coreStorage resizeVolume sur la partition CoreStorage de l'OS - fonctionnalité qui n'était pas à sa disposition antérieurement. Cette extension de fonctionnalité est-elle spécifique du seul «Assistant BootCamp» de «Yosemite» - et peut-être même bien plus : du seul «Assistant BootCamp» de «Yosemite 10.10.3» ? Il est trop tôt pour se prononcer, faute de retours d'expérience suffisants. En tout cas, ma conjecture serait que l'«Assistant BootCamp» vient de recevoir en dotation récemment une des commandes non documentées de diskutil coreStorage qui pré-existaient dès le départ, mais dont il n'avait pas la disposition.
--------------------
Puisque je suis lancé (et que le problème de ce fil a été résolu par mimi qui devrait s'octroyer à lui-même la meilleure réponse et par là passer son fil en Résolu tout en gagnant 1 point bien mérité au score des Trophées pour son intitiative pionnière ) - alors je veux faire part d'un scoop minuscule qui concerne toujours le programme diskutil pris cette fois dans son mode standard (et non spécifique du CoreStorage).
Sur le disque d'un Mac exempt de format CoreStorage, présentant un partitionnement classique : /dev/disk0s1 = EFI --> /dev/disk0s2 = OSX --> /dev/disk0s3 = Recovery HD ; il arrivait que des utilisateurs créent une partition supplémentaire : /dev/disk0s4 afin d'y installer une distribution de Linux. Lorsque, lassés de l'expérience, ils demandaient à l'«Utilitaire de Disque» une ré-intégration de la partition /dev/disk0s4 = Linux à la partition /dev/disk0s2 = OSX sans s'être avisés qu'il existait une partition intermédiaire /dev/disk0s3 = Recovery HD, ce en commençant par supprimer la partition /dev/disk0s4 = Linux ce qui la virait au statut d'espace libre, pour ensuite étendre la partition de l'OS à tout l'espace disponible --> l'«Utilitaire de Disque» déclenchait une succession de commandes de type : diskutil eraseVolume Free Space Untitled /dev/disk0s4 --> diskutil resizeVolume /dev/disk0s2 R dont l'effet désastreux était de "sucrer" la partition /dev/disk0s3 = Recovery HD qui se trouvait sur le chemin en la supprimant carrément, comme si elle avait fait partie elle aussi de l'espace libre disponible.
Eh bien! Je viens de faire une expérience inédite (que j'ai réitérée avec succès) par rapport à cet état de choses "classique", toujours en utilisant le mode graphique de l'«Utilitaire de Disque» et ce en mode live (de la session de l'OS démarré) --> en ayant créé une partition /dev/disk0s4 = vide sur le disque de mon Mac, j'ai supprimé ensuite cette partition (--> virement au statut free space = espace libre) pour ensuite étirer le volume de l'OS (la partition /dev/disk0s2 = Yosemite) afin de lui faire reprendre l'ensemble du free space --> la bourde n'intervient plus : il n'y a plus sucrage de la «Recovery HD» interposée, mais vers la fin de l'affichage verbose déroulant décrivant les opérations, intervient pour la 1ère fois la mention : Mise à jour de l'emplacement de la partition de secours.
Il semble bien que l'«Utilitaire de Disque» se trouve doté tout récemment d'une nouvelle fonctionnalité : invoquer une commande diskutil resizeVolume qui soit non-destructive de la partition de la «Recovery HD» lorsque celle-ci se trouve en position d'interception du free space à récupérer suite à la suppression d'une partition au-delà d'elle dans l'ordre numérique des devices. Cette nouveauté date apparemment de la MÀJ 10.10.3 de «Yosemite» --> s'agit-il alors, comme dans le cas de l'«Assistant BootCamp» ci-dessus, d'une dotation fonctionnelle, nouvelle pour le logiciel, mais se bornant à invoquer une option de commande qui préexistait déjà en non documenté en ce qui concerne le programme diskutil? Possible, s'il n'y a pas eu mise-à-jour du programme diskutil lui-même...
--------------------
Si invoquer la commande diskutil resizeVolume équivalait jusqu'ici à "sucrer" la «Recovery HD» en position intercalaire en cas de récupération d'un free space issu de la suppression d'une partition au-delà d'elle ; il est alors compréhensible que l'«Assistant BootCamp» n'ait pas été doté de la fonctionnalité non documentée équivalente dans le contexte spécial d'un format CoreStorage sur la partition de l'OS : diskutil coreStorage resizeVolume, car son activation aurait équivalu à "sucrer" là aussi la «Recovery HD» intercalaire.
Il est conjecturable que les 2 mises-à-jour aient été concomitantes : fonctionnalité nouvelle d'une Mise à jour de l'emplacement de la partition de secours qui évite de sucrer la «Recovery HD» en cas d'activation de la commande : diskutil resizeVolume par l'«Utilitaire de Disque» --> addition de la dotation : diskutil coreStorage resizeVolume désormais douée d'inocuité pour l'«Assistant BootCamp», car accompagnée aussi de la fonctionnalité nouvelle : Mise à jour de l'emplacement de la partition de secours...
--------------------
☞ il semble y avoir beaucoup d'évolutions souterraines en cours dans l'ingéniérie de l'OS «Yosemite» - malheureusement... non documentées pour la gouverne de l'utilisateur final.
