Bonjour
Louis et
Powerdom.
Le cas de figure que vous soumettez m'intéresse
théoriquement parlant depuis un certain temps. Je le résume --> le point de départ est un partitionnement du disque interne qui ressemble à ceci :
Bloc de code:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme xxx GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD xxx GB disk0s2
[COLOR="Red"] 3: Apple_Boot Recovery HD 650.0 MB disk0s3[/COLOR]
[COLOR="Gray"]4: <partition_de_queue> xxx GB disk0s4
[/COLOR]
La
<partition_de_queue> provient d'une subdivision antérieure de la partition majeure supportant l'OS :
Macintosh HD (par l'«
Utilitaire de Disque», voire par l'«
Assistant BootCamp»). Ce partitionnement a la propriété de pouvoir générer en mode 'saute-mouton' de la partition connexe :
3: Apple_Boot Recovery HD 650.0 MB disk0s3 une partition qui se retrouve en 'queue-de-peloton' de la table des
devices (en n° 4 donc).
Pourquoi y a-t-il
problème? Car l'«
Utilitaire de Disque», qui met en œuvre le programme UNIX
diskutil, ne possède pas d'option pour ré-intégrer la partition n°4 à la partition de l'OS n°2 en mode 'saute_mouton' par rapport à la partition intercalaire n° 3 : la «
Recovery HD» en préservant cette dernière en place. Ce qui est possible dans le sens de l'
aller (création d'une partition en mode 'saute_mouton'), ne l'est pas dans le sens du
retour (dé-création d'une partition en mode 'saute_mouton'). Si l'on force la ré-agrégation de la partition n°4 à la n°2, alors la partition intercalaire n°3 se trouve entraînée dans le mouvement et détruite pour être AUSSI ré-intégrée à la n°2 de l'OS.
Normalement, lorsque la partition n°4 est le produit de l'«
Assistant BootCamp» (afin de pouvoir installer
Windows sur une partition dédiée), il existe une fonctionnalité du même
BootCamp permettant la destruction de la partition
Windows n°4 et sa ré-intégration en mode 'saute-mouton' à la n° 2 de l'OS sans toucher à la partition intercalaire n° 3 de la «
Recovery HD». Mais il arrive que l'utilisateur 'oublie' cette fonctionnalité, et 'supprime' la partition
Windows par l'«
Utilitaire de Disque» (au lieu de
BootCamp) - 'suppression' qui revient à oblitérer le statut de volume logique reconnu dans la table des
devices de la partition n° 4, sans malheureusement que cet espace-disque oblitéré soit ré-intégré à la partition n°2 de l'OS en 'saute-mouton' de la n° 3 de la «
Recovery HD» parce c'est impossible à faire par l'«
Utilitaire de Disque» sans suppression de la «
Recovery HD».
Le fait que l'installateur de «
Yosemite» instaure sur la partition dédiée à l'OS : la n°2 (=
/dev/disk0s2) un format
Groupe de Volumes Logiques : CoreStorage a, par ailleurs, un effet pervers sur la fonctionnalité de ré-intégration à l'OS de la partition
Windows implémentée dans l'
Assistant BootCamp : le volume de l'OS (n°2) ayant le statut de
Volume Logique in-modifiable en taille aussi longtemps qu'il ressortit du format
CoreStorage, la fonctionnalité de ré-intégration de l'
Assistant BootCamp se trouve
contredite logiquement par l'existence du format
CoreStorage et donc bloquée. Le résultat est identique au cas précédent produit par l'«
Utilitiaire de Disque» : une partition 'supprimée en volume' dont l'espace-disque est stérilisé en 'queue-de_peloton' des
devices sans pouvoir être ré-intégré au volume de l'OS sinon par suppression de la partition intercalaire n°3 de la «
Recovery HD».
Cet 'espace_caudal' en fin de peloton, s'il a été 'supprimé' du statut de volume logique, peut très bien être ré-intégré au statut de volume logique par l'«
Utilitaire de Disque» (pilote graphique du programme UNIX :
diskutil) : il suffit d'
effacer cet espace sans 'identité formelle' et une partition supportant de nouveau un volume, la n° 4 =
/dev/disk0s4 se trouve re-créée logiquement. Ce qui ne résout pas le problème posé, qui demeure de ré-intégrer cette partition n°4 à la n°2 de l'OS sans toucher à la n°3 de la «
Recovery HD».
Un esprit raisonnant logiquement ne peut qu'apercevoir ici une solution élégante : utiliser l'«
Utilitaire de Disque» pour subdiviser la 'partition_caudale' n°4, de manière à créer une petite partition 'super_caudale' n°5 d'une taille équivalente à celle de la n°3 de la «
Recovery HD», soit
650 MB. Après quoi, un simple clonage du Système de la «
Recovery HD» en n°3 sur la n°5 produirait un volume jumeau de récupération tout à fait en queue de peloton. Il ne resterait qu'à demander à l'«
Utilitaire de Disque» la ré-intégration de tous les volumes intermédiaires = n°3 («
Recovery HD) + n°4 (volume inutilisé) à la n°2 de l'OS - ce qu'il sait très bien faire en mode 'live' sans affecter les écritures du volume
Macintosh HD - et l'effet escompté serait accompli : il y aurait bien désormais une partition augmentée de l'OS suivie de celle d'une «
Recovery HD» (celle de la partition' super_caudale ' clonée).
Le malheur est que l'«
Utilitaire de Disque»
ne possède pas non plus l'option de créer d'aussi petites partitions-disque qu'une de 650 MB : ce choix est rejeté et cette tactique astucieuse par conséquent invalidée.
Le problème, que je me suis plu à décortiquer car tout à fait passionnant logiquement
, demeure donc entier.
♤
C'est sans doute possible en :
- supprimant la partition de secours
- supprimant la partition Linux
- augmentant la partition OS X pour qu'elle prenne tout l'espace
- recréant la partition de secours avec l'utilitaire ad hoc.
Le plus sûr (mais pas le plus rapide) serait de cloner le système avec Carbon Copy Cloner sur un disque dur externe démarrable [partitionné suivant le schéma GUID Partition Table (GPT)].
De démarrer sur ce clone et vérifier que tout est bien là.
Repartitionner (réinitialiser) le disque interne comme souhaité (une seule partition au format Apple (HFS+J) je suppose).
Puis cloner à rebours, toujours avec CCC, le disque externe vers cette nouvelle partition.
Ainsi tu devrais avoir ce que tu souhaites sans tâter de la ligne de commande (Terminal).
Même si c'est un peu longuet, ce n'est pas trop risqué.
Je pense que
bompi a résumé les 2 voies envisageables pour résoudre le problème tel que je l'ai mis à plat :
- soit (solution b) on demande à «Carbon Copy Cloner» de cloner la partition de l'OS + la «Recovery HD» afférante (option de ce logiciel) sur un DDE, on démarre sur le clone, on ré-intialise le disque interne du Mac par l'«Utilitaire de Disque» du clone, puis on rétro-clone avec l'option : re-créer une «Recovery HD» --> solution graphique, comme il le dit bien 'pas la plus rapide' mais bien 'la plus sûre' : garantie à 100%. Bombich (le développeur de «CCC») qui n'est pas un perdreau de l'année a selon toute apparence trouvé un programme qui permet ce que diskutil ne permet pas : créer sur un disque une micro-partition de 650 MB.
- soit (solution a) on ré-agrège les partitions n°3 («Recovery HD») et n°4 (partition_caudale) à la n°2 de l'OS et on re-crée une partition «Recovery HD» en une néo_n°3 avec l'utilitaire ad hoc.
Tout le monde aura deviné ici que la solution qui m'intéresse est cette dernière, la clé logique devenant : quid de cet
avec l'utilitaire ad hoc capable de faire ce que l'«
Utilitaire de Disque» (
diskutil) ne peut pas faire?
Après avoir ruminé cette question, je me suis souvenu que fut un temps Apple proposait un utilitaire toujours téléchargeable : le ☞
Lion Recovery Update v1.0☜ qui permettait de créer sur le disque interne d'un Mac qui en aurait été privé une «
Recovery HD»
sui generis. Il s'agit d'un paquetage composite, impliquant notablement le
.dmg du Système de la «
Recovery HD 10.7» (qui bien évidemment ne correspond pas aux attentes d'un utilisateur de «
Mavericks» ou de «
Yosemite»).
Mais, en explorant comment l'ensemble pouvait fonctionner, j'ai enfin mis la main sur la clé de l'énigme : il y a, bien caché dans les replis du paquetage, un
binaire qui est précisément le programme désiré pour générer une partition «
Recovery HD» de 650 MB et faire écrire les fichiers-système correspondants, pour autant qu'on fournisse à l'
exécutable les ressources attendues et qu'on l'invoque avec les options adéquates (malheureusement ce
binaire n'est pas documenté par un
man).
Avec l'aimable aval de
bompi, je propose en téléchargement public séparatif cet
exécutable Apple_natif, partie-prenante d'un téléchargement libre et qui fournit donc l'outil capable de suppléer les déficiences de
diskutil.
♧
Alors, voici
Louis, ce que tu peux appliquer comme méthode en
ligne de commande. Si abstruse qu'elle paraisse, elle ne demande que des copier-coller successifs dans le «
Terminal» scandés par l'appui sur la touche 'Entrée' pour activer chaque commande. Je te garantis la validité à 100% de ce tuto, l'ayant au préalable appliqué à mon propre Mac sans garde-fous d'aucune espèce, après avoir créé une partition n° 4 en 'saute-mouton' de la n°3 = «
Recovery HD» (càd. m'être fourré moi-même dans l'impasse) puis ayant fait intégralement confiance à ma faculté de raisonnement : ce «
bon sens» dont on sait depuis
Descartes qu'il se trouve «
également réparti en tous les hommes»... Résultat probant [NB.L'extrapolation de ce tuto à d'autres utilisateurs dépend entièrement de la
Table de partitionnement du disque interne de leur Mac --> il ne peut donc être question d'application
mécanique passe-partout].
- Télécharge le binaire Apple que j'ai chargé sous forme zippée dans le dossier public de ma DropBox : ☞dmtest☜. Arrange-toi pour que ce fichier exécutable dézippé se retrouve absolument sur ton Bureau : petite icône anthracite avec le sigle exec inclus et l'intitulé subalterne : dmtest . Une fois fait, va à Applications/Utilitaires et lance le «Terminal» qui affiche une fenêtre analogue à celle d'un traitement de texte spartiate .
- Commence par saisir :
et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande) --> une demande de password s'affiche (car tu demandes à passer en shell : root) --> tape ton mot-de-passe admin à l'aveugle (session admin requise) - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> tu es désormais en mode sh-3.2#.
- copie-colle (et c'est valable pour toutes les commandes suivantes) :
Bloc de code:
mv ~/Desktop/dmtest /bin/dmtest
et ↩︎ --> déplacement du binaire : dmtest dans /bin.
- À présent :
et ↩︎ --> rétablissement des accédants au binaire à root:wheel.
- Puis :
Bloc de code:
diskutil mount /dev/disk0s3
et ↩︎ --> montage du volume de la «Recovery HD» non monté par défaut.
- Enchaîne par :
Bloc de code:
cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg ~/Desktop && cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist ~/Desktop
↩︎ (déroule la fenêtre d'affichage pour sélectionner toute la commande) --> recopie sur le Bureau de session des 2 ressources clés pour la recréation d'une «Recovery HD» : le fichier BaseSystem.chunklist et le disque-virtuel BaseSystem.dmg à partir du volume monté de la «Recovery HD». Sois un peu patient. Il y a environ 500 MB à copier. Attends le ré-affichage de sh-3.2# avant d'enchaîner [Ne t'inquiète pas si tu ne vois pas le .dmg : il est graphiquement invisible mais bien présent à la fin].
- Suite :
Bloc de code:
chown 0:0 ~/Desktop/BaseSystem.dmg && chown 0:0 ~/Desktop/BaseSystem.chunklist
↩︎ --> rétablissement des accédants root:wheel sur les 2 ressources copiées sur le Bureau (au cas où...).
- Drastique :
Bloc de code:
diskutil mergePartitions hfs+ Macintosh\ HD /dev/disk0s2 /dev/disk0s4
et ↩︎ --> ré-agrégation au volume de l'OS de la partition «Recovery HD» ainsi que de la «Linux», en mode conservateur des données de la partition réceptrice de l'OS (/dev/disk0s2) et destructeur des partitions additives (/dev/disk0s3 & /dev/disk0s4). C'est ce qu'on appelle «brûler ses vaisseaux» . Sois patient encore mais pas longtemps : le re-partitionnement en mode 'live' s'effectue. Il n'y a plus que 2 partitions sur ton disque : n°1 = EFI, n°2 = OSX.
- Re-création :
Bloc de code:
/bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
et ↩︎ --> invocation du binaire dmtest pour qu'il repartitionne le volume de l'OS (point de montage /) en re-créant une «Recovery HD» de 650 MB avec les ressources d'écriture des 2 éléments copiés sur le Bureau (double option booléenne : 0 0 de vérification du .dmg). Sois patient, le plus patient ici --> tu as du moins du spectacle car ça trime dur comme le signalent les lignes d'affichage kilométriques dans la fenêtre du «Terminal». Attends absolument le retour de l'invite de commande : sh-3.2# sans toucher à rien.
- Nettoyage :
Bloc de code:
rm ~/Desktop/BaseSystem.dmg && rm ~/Desktop/BaseSystem.chunklist
et ↩︎ --> suppression des deux ressources copiées sur le Bureau.
- Il ne te reste plus qu'à faire un :
et je te prédis que l'affichage en réponse est :
Bloc de code:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500,1 GB disk0
1: EFI EFI 209.7 MB disk0s1
[COLOR="RoyalBlue"] 2: Apple_HFS Macintosh HD 499 GB disk0s2[/COLOR]
[COLOR="Red"] 3: Apple_Boot Recovery HD 650.0 MB disk0s3[/COLOR]
--> mission accomplie. DONE.
<NB. Je n'ai pas proposé, in fine, la commande de mise-à-jour des caches-système que j'avais en tête - ce pour accélérer le boot sur la «Recovery HD» - parce que les perspectives de plantage de «Yosemite» lorsque le TRIM est activé dès lors qu'on affecte les caches_système m'ont sérieusement échaudé. D'après mon expérience, si le premier boot est un peu longuet sur le volume de la «Recovery HD» sans MÀJ des caches, il est opératoire nonobstant.>
♡
@
Powerdom --> si tu fais un
dans ton «
Terminal» et si tu postes en retour le tableau de partionnement de ton disque, je t'adapte le tuto s'il y a lieu.
Warning ! : tout Mac supportant «
Yosemite» sur la partition n°2 (
/dev/disk0s2) dont le format aurait été viré à :
Groupe de Volumes Logiques : CoreStorage ne peut absolument pas appliquer ce tuto aussi longtemps que le format
CoreStorage n'est pas supprimé sur cette partition, car le
Volume Logique dont dépend l'OS est
inextensible dans le cadre de ce format.
♢
