Le message :
Bloc de code:
A3ACC036-885E-4B5D-81CF-0BDDD0A2790B is already unlocked and is attached as disk3
signifie que le
Volume Logique SSD est bien
déverrouillé et
attaché au Système en tant que
disque virtuel externe /dev/disk3. Le mécanisme logique du
CoreStorage paraît hors de cause.
Si tu ne vois pas de
volume monté > la faute doit alors en être imputée au
système de fichiers JHFS+ terminal > lequel comporte des
erreurs l'empêchant de monter l'espace la partition sous forme de volume.
Cette combinaison :
CoreStorage valide /
système de fichiers invalide me paraît le sens du message que tu obtiens quand tu tentes de réparer :
Le code de sortie de la vérification du sytème de stockage est 0.
Le code de sortie de la vérification du sytème de fichiers est 8.
code de sortie de la vérification du système de stockage =
0 => le dispositif du
CoreStorage est sans erreur.
code de sortie de la vérification du sytème de fichiers =
8 => le
système de fichiers JHFS+ terminal comporte des erreurs.
--------------------
Pour tenter d'éclairer le contexte (dans une spéculation dont je revendique entièrement le caractère abstrus et aventuré) : le
chiffrement de la partition
disk2s2 de ton SSD externe a mis en place, comme
condition logique, un format
CoreStorage dans cette partition. Figure-toi l'équivalent d'un énorme disque dur virtuel
dmg inamovible fixé à l'espace brut de cette partition. Tu as donc un
Physical Volume qui émule un disque dur, dont l'espace de blocs est entièrement
chiffré > et un
Logical Volume qui s'
exporte à partir de lui, en tant qu'équivalent entiièrement
déchiffré. C'est l'instance intermédiaire d'une
Famille de Volumes Logiques qui gère cette
conversion Volume Physique Chiffré <=>
Volume Logique Déchiffré, en fournissant une
clé qui permet un mécanisme à la volée de
déchiffrement (dans le sens volume physique > volume logique) /
chiffrement (dans le sens volume logique > volume physique).
Ça, c'est le dispositif
CoreStorage Chiffré. Pour ce qui est du
système de fichiers > c'est un
JHFS+ standard qui se trouve
ancré, en positition terminale, à un
dev_node du
Volume Logique. C'est donc une situation logique tout ce qu'il y a de bizarre - même quand ça marche. Parce que le
Volume Logique ne
monte pas par le fait d'un
système de fichiers, comme dans le cas standard de l'absence d'un
CoreStorage, où le
système de fichiers ancré sur l'en-tête d'une partition détermine le montage de l'espace des écritures sur les blocs de la partition sous forme de "répertoire de fichiers" = volume utile. Non : le
Volume Logique est «
exporté » par la fonction pilote de la
Famille de Volumes Logiques comme une sorte de «
disque converti » : une transformation logique du «
Volume Physique ». C'est pour cela qu'il est identifié comme un
disque (et pas comme un
volume standard). C'est ce "
Volume-Disque" virtuel (container logique),
conversion logique du
Volume Physique, qui
porte le
système de fichiers JHFS+ classique. Le
Volume Logique n'est donc pas
monté par le
système de fichiers, puisqu'il
porte le
système de fichiers. Le
Volume Logique du
CoreStorage est donc une espèce de
couche logique vide, qui a fonction de
support pour le
système de fichiers JHFS+.
C'est donc le
système de fichiers JHFS+ qui
monte terminalement l'espace de répertoire de fichiers, càd. un "
volume" au sens classique. Le bizarre dans toute cette affaire de
CoreStorage > c'est que le "
volume" monté par le
système de fichiers JHFS+ n'apparaît pas comme «
différent » du
Volume Logique du
CoreStorage : il n'est nullement répertorié comme une instance supplémentaire, un "
volume du Volume". Et pourtant, force est bien d'admettre qu'il y en a une, de
distinction - la preuve, c'est que tu en fais les frais.
En effet, le
Volume Logique de ton
CoreStorage est bien «
exporté » à partir du
Volume Physique. La
Famille de Volumes Logiques opère bien le
déchiffrement à la volée. Il y a bien
déverrouillage. Le
Volume Logique est bien
reconnu comme un
Disque Virtuel de second ordre,
attaché au Système à l'instar d'un disque en dur - en tant que
/dev/disk3. Mais... justement ce
Volume Logique déverrouillé et
attaché n'apparaît pas comme
volume monté, alors même qu'il est
exporté du
Volume Physique. Ce me semble la preuve même que le
Volume Logique d'un
CoreStorage n'est
pas un volume classique. Ce n'est
pas un
volume monté > c'est le
support logique (couche) d'un
système de fichiers pouvant
monter un volume classique qui ne va pas se montrer "
distinct", au montage, du
Volume Logique qui le porte. Dans ton cas : c'est le
système de fichiers terminal qui comporte des
erreurs l'empêchant de monter un volume de fichiers.
En résumé : le
Volume Logique est bien «
exporté » en mode
déverrouillé /
déchiffré > c'est le
système de fichiers JHFS+ qu'il
supporte qui ne «
monte » pas le volume classique. S'il en est bien ainsi : tu es dans la situation d'un
système de fichiers classique comportant des
erreurs graves invalidant le
montage d'un volume. La complication provenant du mécanisme logique du
CoreStorage Chiffré intercalé sur la partition.
--------------------
Je me demande si le dispositif du
CoreStorage accepterait une opération de
déchiffrement dans ces conditions. Si tu passes la commande :
Bloc de code:
diskutil coreStorage decryptVolume -passphrase xxxxxx
(où mes
xxxxx représente ton mot-de-passe de déverrouillage du
Volume Logique SSD saisi en clair) > est-ce que tu obtiens un message d'erreur ou est-ce que la procédure de déchiffrement est acceptée ?
Si elle était acceptée > tu pourrais vérifier de temps en temps, par des commandes :
le
% d'avancement du déchiffrement (à la rubrique de bas du tableau :
Logical Volume > Conversion status) > à complétion : tu n'aurais plus qu'un
système de fichiers JHFS+ standard réancré sur l'en-tête brut des blocs de la partition
disk2s2.
Ce serait pour vérifier si, dans ces conditions plus "terre-à-terre" > le
système de fichiers JHFS+ se montre réparable.
