Tu as un format
CoreStorage greffé sur la partition-Système :
/dev/disk0s2. Ça provient d'une instruction cachée de l'installateur de «
Yosemite», qui opère fréquemment ce changement de format à l'insu de l'utilisateur.
--------------------
En synthèse, ce format spécial construit, sur la partition-support (
/dev/disk0s2), un bassin d'instances logiques dénommé :
Groupe de Volumes Logiques, dont l'organisation interne est la suivante : à la base, un
Physical Volume (
Volume Physique) importé sur la partition-support, qui est une couche logique émulant un disque dur ; en position intermédiaire, une
Logical Volume Family (
Famille de Volumes Logiques), qui est une instance de paramétrage du volume exportable à partir du Disque Dur Émulé ; en position sommitale, un
Logical Volume (
Volume Logique), qui est le volume exporté d'après les paramètres de la
Famile de Volumes Logiques sur la base du Disque Dur Émuté [ce volume logique est le conteneur du
jhfs+ filesystem (système de fichiers :
Mac OS étendu journalisé) de l'OS] ; enfin, une micro-partition consécutive de 134 Mo :
Apple_Boot Boot OS X (Carte d'amorçage), qui recèle le
Driver (pilote) gérant le montage du
Volume Logique après lecture des paramètres de la
Famille de Volumes Logiques.
Comme tu vois, une organisation logique invisible, particulièrement byzantine (partition
/dev/disk0s2 {
Physical Volume -->
Logical Volume Family -->
Logical Volume -->
jhfs+ filsystem } /
Boot OS X Driver) dont tu peux afficher le tableau en passant dans le «
Terminal» (depuis ta session par exemple) la commande :
(qui consiste à invoquer le binaire
UNIX diskutil avec l'option
CoreStorage - "
cs" en abrégé - et le verbe d'action :
list = "lister"). Il ne serait pas mauvais que tu postes ici ce tableau imposant, parce que manifestement il y a quelque chose de "foireux" dans le dispositif de ton
CoreStorage.
--------------------
Si je suis entré un peu dans le détail de l'architecture logique du
Groupe de Volumes Logiques déployée par un format
CoreStorage, ce n'est pas par exercice d'érudition oisive
; mais parce qu'il permet de capturer un point critique, qui touche au montage du
Volume Logique.
Lorsque le
Volume Logique a le statut "libre" (= "
non-chiffré", qui est son statut standard), cela implique qu'au démarrage du Mac qui met en route le
Programme Interne (
firmware =
EFI de la Carte-Mère) le programme auxiliaire du
DiskManager exécute automatiquement le
Driver (pilote) de la carte d'amorçage
AppleBoot Boot OS X, lequel lit les instructions de la
Famille de Volumes Logiques et procède au montage du
Volume Logique --> le
Volume Logique :
Macintosh HD est donc toujours automatiquement monté au démarrage du Mac, que l'utilisateur choisisse de démarrer le système de fichiers
OS X qu'il recèle, ou qu'il choisisse alternativement de démarrer sur un volume
bootable indépendant (comme celui de le «
Recovery HD» ou d'un clone sur un DDE par exemple).
Par contre, lorsque le
Volume Logique a le statut "verrouillé" (= "
chiffré" suite à l'activation du logiciel : «
FileVault-2»), le
Driver de la partition
Boot OS X exécuté par le
DiskManager au démarrage, à la lecture des paramètres de la
Famille de Volumes Logiques du
CoreStorage, tombe sur l'obligation d'activer une clé de déchiffrement comme condition du montage du
Volume Logique. Aussi longtemps que cette clé de déchiffrement n'a pas été activée par le renseignement d'un mot-de-passe habilité d'utilisateur, le
Driver laisse le
Volume Logique à l'état non-monté parce que verrouillé. C'est ce qui se passe, par exemple, lorsqu'un utiilisateur dont le
Volume Logique «
Macintosh HD» de l'OS est chiffré par «
FileVault-2», démarre sur la partition de répération «
Recovery HD» : la clé de déchiffrement du
Volume Logique n'ayant pas été activée, le
Driver de la carte d'amorçage
Boot OS X laisse ce
Volume Logique démonté (car verrouillé).
--------------------
Si j'applique cette petite grille de lecture à ton cas de figure, je ne peux que constater une situation paradoxale : en effet, tout se passe comme si le
Volume Logique de ton
CoreStorage ne montait pas automatiquement (comme dans le cas de figure du
chiffrement par «
FileVault-2») - ainsi que le révèle ta capture de l'«
Utilitaire de Disque» qui le montre "grisé" (indication graphique de non-montage) et qui le déclare verbalement : "
non-monté" ; mais la mention simple dans le panneau du même «
Utilitaire de Disque» de : "
Partition Logique" comme format de ce volume, au lieu de "
Partition Logique Chiffrée" mentionné lorsque le volume est
chiffré par «
FileVault-2», révèle que ton
Volume Logique a intrinsèquement le statut : "
non-chiffré". Il devrait donc être automatiquement monté comme volume lorsque tu démarres sur le Système de la «
Recovery HD», ce qui n'est pas le cas, puisque quand tu as fait un :
ls /Volumes, tu t'es aperçu que le
Volume Logique «
Macintosh HD» était absent de l'espace des volumes montés.
J'ai l'impression qu'il y a un dysfonctionnement dans ton
Groupe de Volumes Logiques, et je ne sais pas si l'intitulé biscornu du
Volume Logique en est la raison ou inversement l'effet. Car, autant l'avouer, une grande opacité enveloppe le fonctionnement hyper-compliqué de ce type d'architecture logique à étages multiples. Avant d'utiliser une méthode disons "drastique" pour apurer la situation (cloner le
jhfs+ filesystem de l'OS sur le volume d'un DDE par «
Carbon Copy Cloner» - qui clone aussi la «
Recovery HD» en parallèle --> démarrer sur le clone, ré-initialiser entièrement le disque du Mac --> rétro-cloner le système de fichier sur un volume standard du disque du Mac - avec rétro-clonage à la clé d'une «
Recovery HD») ; tu pourrais encore faire un test ou deux dans l'environnement de la «
Recovery HD» :
- 1° tu lances l'«
Utilitaire de Disque», tu sélectionnes la ligne grisée
j'zaime bien... du
Volume Logique non monté et tu presses au-dessus le bouton intitulé : "
Monter" --> est-ce que le volume vire à l'affichage plein, signe qu'il est monté :
j'zaime bien... ? Si oui, alors tu pourrais quitter l'«
Utilitaire de Disque» et revenir au «
Terminal» pour passer la commande :
Bloc de code:
diskutil renameVolume /dev/disk0s2 "Macintosh HD"
et voir ce qui se passe (mais j'ai l'impression que cela équivaut à guérir un "symptôme" et pas la racine du problème).
- 2° sinon, comme tu sembles avoir tenté d'utiliser le programme
mount, sache que cet utilitaire abstrus ne peut pas être invoqué pour monter directement un système de fichiers externe, mais requiert de le monter dans un répertoire indépendant qui va lui servir de point de montage (il n'y a que dans la session du
Single User que l'usage de
mount donne l'impression qu'il peut agir directement sur un système de fichiers). Donc je te propose à partir du «
Terminal» de commencer par créer un dossier temporaire dans l'espace
/Volumes du système de la «
Recovery HD» afin qu'il puisse jouer le rôle de point de montage (ce dossier sera automatique purgé au re-démarrage) --> tu passes donc la commande préliminaire :
Bloc de code:
mkdir /Volumes/mount-point
qui crée un dossier
mount-point temporaire dans l'espace
/Volumes. Tu peux alors enchaîner par un :
Bloc de code:
mount -t hfs -w /dev/disk0s2 /Volumes/mount-point
(tu mentionnes avec l'option
-t le type de format de fichiers
hfs = "
Mac OS étendu" et avec l'option
-w le statut "
writable" --> l'identifiant
/dev/disk0s2 de la cible = le
device à monter --> l'adresse /
Volumes/mount-point du dossier devant servir d'espace de point-de-montage du
filesystem) --> est-ce que tu touches un message d'erreur radical ou simplement le ré-affichage de
-bash-3.2# ? Si c'est le 2è cas de figure (même avec mention préalable de
"hfs : invalid argument" qui, d'après mes expérimentations, n'empêche pas le montage d'un
Volume Logique CoreStorage), alors un :
te montre-t-il ton
Volume Logique monté ? Si oui, tu peux retenter la commande de renommage (mais idem : c'est s'attaquer à la partie émergée de l'iceberg du dysfonctionnement)...
--------------------
macomaniac
