Bonjour
Theladykiller.
Tu n'as absolument
pas besoin de l'installateur de «
Yosemite» présent dans tes
Applications (et donc de le télécharger depuis l'AppStore puisque tu ne l'as pas actuellement sur ton Mac : +5 Go compressés, bon courage
). Car le
InstallESD.dmg évoqué dans le message de
rinoc et effectivement bien partie-prenante de l'installateur de «
Yosemite» est
en tout point identique au disque virtuel qui sert de support au volume de la partition de récupération invisible «
Recovery HD» qui s'est installée d'office sur une partition connexe de ton disque.
[En tout point identique pour une excellente raison : c'est que l'installateur crée la «
Recovery HD» par référence stricte au
InstallESD.dmg contenu dans son paquettage. Ce
.dmg est stocké dans le volume de 650 Mo de la «
Recovery HD» dans un dossier de
boot intitulé
com.apple.recovery.boot. Lorsque l'utilisateur choisit de démarrer sur cette partition, le
.dmg se trouve monté en volume, et ce volume est un
équivalent d'OS X seulement 'allégé' dans ses éléments de superstructures (applications etc.) mais
copie-conforme dans les essentiels de son infrastructure.
Un
kernel charge donc ce système au
boot, en commençant notamment par les
kexts (extensions du noyau) contenues dans un dossier
Extensions de la Bibliothèque-Système de l'OS de la «
Recovery»
en tout point semblable (pour les extensions Apple_natives) au dossier
Extensions de l'OS de la partition principale du disque.
En résumé : il n'y a pas de mystère --> si la «
Recovery HD» apparaît comme une interface graphique d'utilisateur limitée, celle-ci se greffe nonobstant sur une architecture d'OSX qui est le clone de celle de l'OS principal : même composants, mêmes ressources pour ce qui est des essentiels - ce qui explique pourquoi ... c'est un Système démarrable
. Il est regrettable que de nombreux utilisateurs qui se croient en panne parce qu'ils ont foiré une
kext de l'OS ne sachent pas qu'il existe 'sous le capot' la
panoplie complète des kexts natives (entre autres choses) et qu'il suffit de démarrer sur la «
Recovery» pour en recopier une version intègre du dossier de l'OS de la «
Recovery » dans le dossier correspondant de l'OS principal. Car, lorsqu'on est logé dans la session de la «
Recovery», l'adressage à l'arborescence de l'OS de la «
Recovery» démarré se fait à partir du point de montage direct
/ dans le «
Terminal», tandis que l'adressage à l'arborescence de l'OS principal non démarré se fait via le répertoire des volumes :
/Volumes/Macintosh\ HD/.
♤
À la suite de ce bref 'traité de la méthode' (qui doit t'apparaître aussi sibyllin que la 'Pierre de Rosette') la conséquence pratique n'est plus qu'une formalité (qui va te faire gagner facilement 2 H de téléchargement évité)
--> dans ta session haituelle ('admin' requise), tu vas à
Applications/Utilitaires et tu lances le «
Terminal» qui t'affiche une gentille fenêtre de traitement de texte minimaliste.
- Tu commences par saisir (tout ce qui suit en copier-coller direct) :
Bloc de code:
diskutil mount /dev/disk0s3
et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande) --> en réponse tu obtiens le retour d'affichage :
Bloc de code:
Volume Recovery HD on /dev/disk0s3 mounted
Tu viens de monter le volume de la «Recovery HD» qui est proscrit de montage automatique au démarrage du Mac, ce que tu peux vérifier graphiquement car l'image du volume Recovery HD s'affiche sur le Bureau (pour autant que dans les Préférences du Finder tu aies coché l'option : 'Afficher les Disques Durs).
- Tu enchaînes avec un petit :
Bloc de code:
open /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg
et ↩︎ --> tu montes par là le disque virtuel BaseSystem.dmg dont j'ai parlé (qui donc supporte le filesystem complet des essentiels d'OSX) et tu vois surgir sur ton Bureau en confirmation une image-disque intitulée : OS X Base System qui est le volume opératoire de l'OS de la «Recovery» [je te recommande de ne pas aller jouer à la Lady_Killer graphique dans cette arborescence-système ]
- Tu poursuis par la commande décisive :
Bloc de code:
sudo cp -R /Volumes/OS\ X\ Base\ System/System/Library/Extensions/msdosfs.kext /System/Library/Extensions/msdosfs.kext
et ↩︎ --> demande de password (commande sudo : opérer en qualité d'utilisateur substitut de root) --> tape ton mot-de-passe admin (session admin requise) à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> tu viens de copier la kext intouchée : msdosfs.kext du dossier des Extensions de l'OS de la «Recovery» dans le dossier miroir de l'OS démarré principal où son bundle est venu écraser celui en place.
[Je ne suis pas partisan en principe de modifier en mode 'live' les kexts d'un OS démarré, mais on va dire que celle-ci est un peu la 5è roue de la charrette, qu'il y a un effet de cache protecteur et que ça te facilite la vie pour les copier-coller - sinon, il aurait fallu démarrer sur la «Recovery»...]
- Une petite précaution :
Bloc de code:
sudo touch /System/Library/Extensions
et ↩︎ (pas besoin de mot-de-passe ici, dans les 5' qui suivent une première authentification) --> c'est pour remettre les 'pendules à l'heure' sur le répertoire des Extentions qui a été altéré.
- Allez hop! les finitions : tu saisis :
Bloc de code:
diskutil umountDisk /dev/disk1
et ↩︎ --> et tu as la satisfaction de voir disparaître l'image-disque OS X Base System qui vient d'être démontée.
- Tu finis par :
Bloc de code:
diskutil umount force /Volumes/Recovery\ HD
et ↩︎ --> par quoi tu vois disparaître à son tour du Bureau l'image du volume Recovery HD qui se trouve démonté. Re-démarre. DONE (pour autant que ton problème corresponde à celui cerné par rinoc 
)
♧
