À prendre cum grano salis (comme souvent avec le facétieux signataire de ces lignes)...
Si je puis me permettre une rétrospection, au vu des péripéties d'
Hubert dans ce fil, la méthode préconisée par
aurique 
:
pour tout remettre d'aplomb, le plus simple c'est :
- Clone de ta partition Mac (et contrôle que le clone est bien bootable)
- Formatage en 1 seule partition du disque dur
- Remise du clone dans la partition unique de 500Go.
était effectivement plus simple à employer, à condition d'utiliser comme logiciel la démo de «
Carbon Copy Cloner» capable de cloner sur un DDE non seulement le
volume de l'OS mais aussi la
partition de récupération «
Recovery HD» - ce afin de permettre, après démarrage sur le clone et ré-intialisation du disque du Mac, un rétro-clonage des 2 volumes et pas du seul de l'OS. Sans quoi (utilisation de «
Super Duper !» par exemple, qui ne sait pas cloner la «
Recovery HD»), l'issue finale aurait ressemblé à celle engendrée dans la suite de ce fil par une combinaison assez confuse de commandes dans le «
Terminal» entrecoupées de manipulations hasardeuses dans l'«
Utilitaire de Disque» opaque d'«
El Capitan» : à savoir, un volume réunifié de l'OS avec sucrage carrément de la «
Recovery HD».
Une telle issue n'était absolument pas nécessaire, toutefois. Il ne fallait absolument pas reformater la partition
/dev/disk0s3 de la «
Recovery HD» par une commande du type :
Bloc de code:
diskutil eraseVolume jhfs+ brol /dev/disk0s3
mais la laisser complètement hors du coup.
♤
Voici ce qu'il y a à comprendre : lorsqu'une partition se trouve créée sur le disque du Mac en
/dev/disk0s4, càd.
après celle de la «
Recovery HD» qui occupe régulièrement la position
/dev/disk0s3 dans la table des
devices (partition parfois issue, comme ici, d'un recours indû à l'«
Utilitaire de Disque» pour disposer de la partition créée par l'«
Assistant BootCamp»), l'utilisateur se pose la question de fusionner l'espace devenu inutile de cette partition
/dev/disk0s4 à celui de la partition
/dev/disk0s2 de l'OS de manière à disposer d'un volume réunifié. Comment s'y prendre ?
L'«
Utilitaire de Disque» '
de la vieille école' (soit jusqu'à «
Yosemite 10.10» compris), dans son menu "
Partitionner", propose pour ce faire 2 leviers graphiques : un bouton "
-" permettant de supprimer une partition sélectionnée, la
/dev/disk0s4 dans notre cas ; et une poignée de redimensionnement, permettant d'étirer l'espace de la partition supérieure (la
/dev/disk0s2 de l'OS ici) afin de lui faire absorber l'espace grisé de la partition supprimée (la ci-devant
/dev/disk0s4). Cette double opération fonctionne parfaitement bien, sans aucun problème "existentiel" pour la partition intercalaire de la «
Recovery HD» (située en
/dev/disk0s3) qui n'est jamais affichée localement dans le tableau graphique des espaces de partitions, mais qui n'est aucunement affectée par la manipulation d'étirement de l'espace de l'OS lui permettant de regagner l'espace d'une partition supprimée. Je rejette résolument ici la "légende urbaine" tenace voulant que la partition de récupération «
Recovery HD» soit mise en péril par cette manœuvre.
En effet, le binaire UNIX
diskutil que pilote graphiquement l'«
Utilitaire de Disque» a été mis à jour dans ses capacités programmatiques : il est désormais capable de gérer l'intercalement de la partition de récupération «
Recovery HD» afin que l'espace de cette dernière ne soit pas supprimé par une telle opération, mais de manière à ce que l'emplacement de cette partition de récupération soit "mis à jour". Ce qui doit se comprendre en terme de réaffectation du système de fichiers de cette partition (avec ses données) à une suite numérotée de blocs différente, dans la carte globale des blocs du disque du Mac, de la suite numérotée primitive - comme des tests précédés et suivis d'une commande informative :
le révèlent avec toute la clarté nécessaire.
♧
L'action sur le bouton "
-" au plan graphique équivaut strictement à passer la commande :
Bloc de code:
sudo diskutil eraseVolume Free\ Space brol /dev/disk0s4
(dans le cas précis d'une seule partition juste après celle de la «
Recovery HD»). L'indication
"Free Space" (espace_libre) signifie que l'espace-disque correspondant se trouve "échappé" de la
Table de partition GUID, mais la suite des blocs concernés est bien conservée en tant que série numérotée --> ce qui implique que l'espace_libre occupe toujours un emplacement-disque déterminé du point de vue des blocs concernés, quoique "échappé" de la
Table de partition GUID. Ainsi, le
"Free Space" n'est jamais libre, au sens où il n'aurait pas de localisation-disque, il est libre par rapport à la distribution actuelle des partitions de la
Table de partition GUID.
L'action sur la poignée de redimensionnement, lorsqu'il s'agit de réaffecter à la partition
/dev/disk0s2 de l'OS le
"Free Space" issu d'une ci-devant partition
/dev/disk0s4 supprimée mais toujours localisé sur la carte des blocs du disque en tant que série numérale
après celle des blocs de la «
Recovery HD» identifiée en
/dev/disk0s3, équivaut strictement à passer la commande (en droits
root) :
Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 0b
En effet, pour qu'une commande de redimensionnement de volume ciblant comme volume d'accueil celui, démarré, de l'OS (opération en mode "
live") requière la réaffectation à cette partition du
"Free Space" situé
après la «
Recovery HD» intercalaire, il faut impérativement et exclusivement terminer la commande par l'option :
0b (
"zero_byte") et absolument pas par l'option
R. L'option
R requiert, en effet, la réaffectation à la partition de l'OS de tout
"Free Space" qui existerait (du point de vue de la carte de numérotation des blocs du disque)
immédiatement à la suite de la série des blocs-disque allouée à la partition de l'OS - ce si et seulement si aucune partition de quelque sorte que ce soit et de quelque format que ce soit ne s'intercale directement. Si c'est le cas (par exemple présence de la «
Recovery HD» affectée à la série des blocs faisant immédiatement suite), alors la commande :
Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 R
échoue radicalement, car il n'existe aucun
"Free Space" disponible entre la partition de l'OS et la première partition suivante : celle de la «
Recovery HD».
L'option
0b (il est possible de lui substituer la valeur :
0g =
"zero_gigabyte", voire
0m =
"zero_mega_byte" - qui sont comprises comme équivalentes), tout au contraire, requiert la réaffectation à la partition de l'OS de tout
"Free Space" disponible
après la partition de l'OS jusqu'à la limite de la première partition
suivante -
à l'exception de la partition de récupération «Recovery HD» qui est échappée de cette requête, ce à cause de son format exclusif :
"Apple_Boot". Cela signifie que, lorsque l'option finale
0b est employée, la partition de la «
Recovery HD», intercalée entre celle de l'OS et le
"Free Space" qui vient après, est
échappée pour cette requête : elle n'est pas considérée comme une limite actuelle à la requête de réaffectation du
"Free Space" localisé après elle en terme de blocs du disque, car de par son format
"Apple_Boot", la partition «
Recovery HD» est un système de fichiers "déplaçable" sur une autre suite numérotée de blocs (seule une partition relevant de ce format possède ce "privilège" du caractère "déplaçable" de son affectation à une nouvelle suite de blocs, et par conséquent d'un statut "échappable" lors d'une requête de réallocation de
"Free Space" à la partition de l'OS qui la précède).
♡
Au tout début du fil, où
Hubert se retrouvait avec une partition de l'OS en
/dev/disk0s2, une «
Recovery HD» en
/dev/disk0s3 et un
"Free Space" de 100 Go correspondant à la suite des blocs-disque venant après la partition de récupération, une simple commande en mode "
live" :
Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 0b
aurait réalloué les 100 Go directement à la partition de l'OS avec mise-à-jour de l'emplacement du système de fichiers de la «
Recovery HD» sur une nouvelle suite de blocs.
Après des manipulations hasardeuses ayant conduit à la recréation d'une (et même de 2 - mais supposons pour simplifier une seule) partition au format
jhfs+ en
/dev/disk0s4, 2 seules commandes auraient suffi, en mode "
live", à réintégrer à la partition de l'OS les 100 Go en question avec mise à jour de l'emplacement de la «
Recovery HD» par affectation de son système de fichiers à une nouvelle suite de blocs :
Bloc de code:
sudo diskutil eraseVolume "Free Space" brol /dev/disk0s4
sudo diskutil resizeVolume /dev/disk0s2 0b
J'ai personnellement expérimenté sur mon Mac la validité des commandes que je viens de décrire. Si j'ai (avec la "
longitude" prosaïque qui m'est coutumière) épilogué sur ces points de détail avec la minutie (maco)maniaque d'un entomologiste coupeur d'ailes d'hyménoptères en 4
dans le sens de l'épaisseur - c'est parce que, sur les questions de manipulation des partitions du disque du Mac, l'usage du «
Terminal» n'est adéquat qu'à la stricte condition de mesurer exactement les effets induits par telle ou telle commande. Faute d'une telle discrimination toujours pointilleuse (et avouons-le rébarbative), le recours au va-et-vient clonage => DDE / rétoclonage => HDD/SDD (avec ré-initiatilisation intercalée du disque du Mac à partir d'un redémarrage sur le clone) est
toujours plus sûr et intellectuellement parlant
plus commode à envisager, càd.
plus simple.
.
