Rétrospection sur un point détail qui m'interpelle
Je découvre ce fil après la bataille et j'espère que les participants ne m'en voudront pas si j'abonde en considérations rétrospectives.
Sincèrement, je ne conçois pas l'échec des 2 commandes proposées par
Jean 
:
Bloc de code:
sudo diskutil eraseVolume Free\ Space Empty /dev/disk0s4
sudo diskutil resizeVolume /dev/disk0s2 0b
parce qu'à partir de «
Yosemite» l'exécutable
UNIX :
diskutil a été mis à jour concernant ses capacités de récupérer l'espace d'une partition sise en
/dev/disk0s4, càd. en-dessous de la partition de récupération «
Recovery HD» sise en
/dev/disk0s3, à la partition-bénéficiaire de l'OS sise en
/dev/disk0s2. En effet, à partir du moment où la partition
/dev/disk0s4 se trouve "supprimée", càd. son espace retiré du schéma de partitionnement et viré à du
Free_Space (ce qu'a opéré avec succès la 1ère commande) ; alors commander un
resizeVolume ciblant en partition-bénéficiaire la
/dev/disk0s2 de l'OS avec l'argument final :
0b est désormais compris par le programme
diskutil ainsi : récupérer tout espace libre (jusqu'à épuisement de sa quantité =>
0 byte) situé directement en-dessous de la partition-bénéficiaire sans qu'aucune partition intercalaire de format
Apple_Boot (signalant une «
Recovery HD») ne soit considéré comme une limite (comme ce serait le cas si l'argument
-R avait été choisi), mais initier une "Mise-à-jour de l'emplacement de la partition de récupération" sur la série des blocs terminaux avant récupération de l'espace-libre dégagé en intercalaire.
J'ai de nombreuses fois opéré en mode "
live" sous «
Yosemite» (la partition-bénéficiaire étant celle de mon OS démarré) cette manipulation, soit de manière graphique (via l'«
Utilitaire de Disque»), soit en ligne de commande (par l'exacte même commande proposée par
Jean) et toujours le
Free_Space de la ci-devant partition
/dev/disk0s4 est bien venu gonfler la partition
/dev/disk0s2 sans suppression de la «
Recovery HD intercalaire (
/dev/disk0s3) ni erreur sur la cible-bénéficiaire.
--------------------
Aussi quand
bompi déclare :
Le problème est qu'il y a une partition (la partition de secours) entre les deux que l'on veut joindre.
Donc ça ne devrait pas être faisable en un coup (sauf si Apple est très gentil et que l'utilitaire fait un certain nombre de manipulations en un seul appel...)
son scrupule fait écho à la situation qui existait encore à l'époque de «
Mavericks», lorsque, dans l'«
Utilitaire de Disque», supprimer une partition en-dessous de la «
Recovery HD» puis étirer graphiquement le rectangle du volume de l'OS pour reprendre le
Free_Space grisé (la partition de récupération n'étant jamais affichée comme intercalée) conduisait à "sucrer" tout bonnement cette partition dont l'espace-disque se trouvait ajouté à la partition de l'OS comme si la commande avait été un :
Bloc de code:
sudo diskutil mergePartitions jhfs+ Macintosh\ HD /dev/disk0s2 /dev/disk0s4
Mais effectivement Apple a entendu l'appel de
bompi
("
sauf si Apple est très gentil et que l'utilitaire fait un certain nombre de manipulations en un seul appel...") et la mise-à-jour de
diskutil permet la chose depuis «
Yosemite» (je n'ai pas vérifié si
diskutil a ou non été rétrospectivement mis-à-jour dans les OS antérieurs à «
Yosemite» comme «
Mavericks»).
--------------------
Or quel message
Lordc a-t-il obtenu en lançant la commande
resizeVolume inaugurale ? Ceci :
quand j'execute la seconde j'obtiens :
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.
J'ai réussi à reproduire la manip qui génère ce message d'échec --> il s'agit d'une commande de redimensionnement du volume de l'OS :
Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 -R
ou
sudo diskutil resizeVolume /dev/disk0s2 0b
lorsque
aucun Free_Space n'existe du tout en-dessous de la partition «
Recovery HD» intercalée. Comme il y a toujours une toute petite bande d'espace libre entre les partitions (qui joue un peu le même rôle qu'une "marche-frontière" d'antan entre des royaumes : celui d'espace de "séparation"), la commande arrive à se lancer, mais une fois ce
Free Space minime entre
/dev/disk0s2 et
/dev/disk0s3 mesuré et trouvé inemployable, on obtient alors le message précité. Et la commande avorte.
--------------------
L'extraordinaire dans le cas de
Lordc, c'est que la commande de
Jean :
Bloc de code:
sudo diskutil resizeVolume /dev/disk0s2 0b
a la capacité de "traverser" la partition
Apple_Boot de la «
Recovery HD» pour cibler tout le
Free_Space existant en-dessous par le fait de l'argument final
0b (épuiser tout l'espace libre subalterne sans obstacle de la partition de récupération) --> il est donc logiquement inconcevable que le nouveau
diskutil l'assimile à une commande terminée par l'argument
-R (qui signifie strictement : épuiser tout l'espace libre immédiatement en-dessous de la partition-bénéficiaire à la condition sine qua non qu'
aucune partition -
y compris une de format
Apple_Boot - ne soit sur le chemin) et s'efforce alors de récupérer le seul espace libre présent : celui de l'intercalaire entre les 2 partitions
/dev/disk0Ss2 et
/dev/disk0s3, avec pour conséquence le message d'échec : "pas assez d'espace libre vacant".
Mais le 2è événement extraordinaire (et impliquant le contradictoire du premier comportement) est que, alors qu'un tel message d'échec équivaut à un avortement de la commande avec un code
1 (erreur présente),
diskutil ait converti la commande en récupération du
Free_Space en-dessous de la «
Recovery HD» à cette partition
/dev/disk0s3 devenue la bénéficiaire, alors même que l'instruction explicite mentionnait la partition
/dev/disk0s2 comme bénéficiaire exclusive, et alors que le même
diskutil ne trouvait pas au départ ce
Free_Space en-dessous de la «
Recovery HD»... Avec comme résultat surréaliste un gonflement du volume de la «
Recovery HD» de 650 Mo à 201,5 Go !
[cas typique de "déplacement" freudien - et moi qui croyait que seule la logique avait cours ici...]
Logiquement impensable sous «
Yosemite» / empiriquement avérable sous une
bêta d'«
El Capitan». Le fait que l'«
Utilitaire de Disque» d'«
El Capitan» ait refusé la tâche initialement (j'y ai constaté expérimentalement que lorsqu'on supprime - bouton "
-" une partition en-dessous de celle de l'OS, il n'y a plus opération cantonnée de virage à du
Free_Space, mais "tout-en-un" : le
Free_Space est automatiquement récupéré par le partition du dessus) - je l'interprète conjecturellement ainsi : avant toute opération de type "
resizeVolume", il y a toujours vérification de l'intégrité du système de fichiers de la partition bénéficiaire (ici celle de l'OS) --> en cas d'erreurs trouvées - qui ne sont pas réparées automatiquement - il y a code de sortie
1 (erreur présente) et avortement de l'opération.
Ce constat d'erreurs dans le système de fichiers de l'OS a-t-il fait foirer la commande :
sudo diskutil resizeVolume /dev/disk0s2 0b de
Jean ? Ou bien a-t-on affaire à un bogue pur et simple d'exécution d'un programme
UNIX dans l'environnement d'une
bêta (dont le "
bêta-testeur" fait les frais) ?
--------------------
