Salut encore
Bob
De même que nous n'avons pas fini de découvrir les
possibilités logiques du
CoreStorage (innovation logicielle remontant à l'OS «
Lion 10.7») en tant que format gestionnaire d'une population de «
disques virtuels » (dénommés «
Volumes ») ; je pense que nous n'avons pas fini, corrélativement, d'inventorier les
erreurs logiques du
CoreStorage, càd. les accidents qui peuvent survenir lorsque, augmentée la complexité d'une structure logique, se trouve concomitament accru son degré de « sensibilité » à des événements "périphériques".
Quand je dis : « nous », je désigne les membres du forum
OS X (comme l'orateur présent) qui ne sont nullement dans le « secret des dieux », càd. au fait de l'ingéniérie informatique d'Apple responsable du développement logiciel du
CoreStorage et qui doivent se débrouiller pour gérer les événements avec les quelques outils mis à disposition : la poignée de verbes publiés pour commander l'utilitaire
diskutil en liaison à la spécification
CoreStorage.
Quand je dis : « erreurs logiques », je vise ces cas de processus de «
chiffrement » ou de «
déchiffrement » interminables du volume de l'OS, qui impliquent le
CoreStorage, puisque seul son dispositif à « couches multiples » est susceptible d'une protection par cryptage des données. Je vise aussi ces cas de « décapitation logique » de la paire : «
Famille de Volumes Logiques / Volume Logique » qui ont été attestés plus d'une fois ici même sur les forums ; mais également ces cas de « perte de disque associé » intervenus occasionnellement dans une situation de «
Fusion Drive ». Pour ne pas parler d'« erreurs de mot-de-passe » chargé de déverrouiller un
Volume Logique Chiffré afin de permettre son montage.
Quand je dis : « sensibilité périphérique », je désigne en particulier des « accidents logiques » induits par des « incidents d'alimentation électrique » alors même qu'un dispositif
CoreStorage se trouve activé. Coupures du secteur, par exemple (responsables de « décapitation logique » du
CoreStorage) - et ici, dans le cas de
Bob, accident électrique lié à un nettoyage du clavier sans extinction du Mac. L'effet logique produit dans ce dernier cas de figure a été un renommage absurde du
Volume Logique exporté par le dispositif
CoreStorage non-Chiffré greffé sur la partition de l'OS.
--------------------
Un
CoreStorage est un « organisme logique » global (un
Groupe de Volumes Logiques) solidarisant 3 « organes logiques » (ou instances) : un
Volume Physique importé à même la partition de la
Table de Partition GUID, et qui consiste en un «
Disque Dur Émulé » ; une
Famille Logique médiatrice, qui gère entièrement la génération d'un volume à partir de ce disque virtuel (en indépendance de la table de partition
GUID primaire) ; un
Volume Logique exporté du
Volume Physique par le mécanisme de la
Famille Logique (qui gère son
Chiffrement ou
non-Chiffrement, notamment). Enfin, cerise sur le gâteau, le
Volume Logique (
exporté du
Volume Physique par la
Famille Logique)
exporte à son tour un «
dev node » : un « point de montage afférant à un
device » qui sert d'ancrage au système de fichiers
jhfs+ terminal dont dépend l'OS (en quelque sorte le
Volume Logique sert de
disque virtuel de second ordre pour le système de fichiers de l'OS).
Normalement le
Volume Logique du
CoreStorage emprunte son nom au système de fichiers de l'OS auquel il sert de support, de telle sorte qu'il y a
identité nominale nom de volume / nom de système de fichiers. L'incident électrique survenu a manifestement cassé cette identité : le système de fichiers
jhfs+ de l'OS continue d'être identifié par l'intitulé
Macintosh HD ; par contre, le
Volume Logique qui lui sert de « support-disque virtuel », a été renommé absurdement :
-)àç!è§('"rezazeràç!è§('"é"(§è!çà)-)àç!è§('"zéaz'(§è!çà)--)àç!è§('"rtyuioppoiuytreqzaeyuiop^poiuytreszq.
--------------------
Aucun verbe publié pour la spécification
CoreStorage de
diskutil ne permet une
vérification / réparation de la structure logique d'un
Groupe de Volumes Logiques. Que le
Volume Logique monte encore, et que le système de fichiers supporté de l'OS démarre : ça paraît une espèce de miracle fragile. Manifestement, le commande de réversion du dispositif
CoreStorage a échoué, ce qui, en supprimant les couches intercalaires, aurait préservé le système de fichiers intact de l'OS et l'aurait « ré-assis » directement à même la partition
GUID primaire.
Je vois donc 2 expérimentations possibles :
- a) démarrer par
⌘R sur la partition de récupération «
Recovery HD». Lancer d'abord l'«
Utilitaire de Disque» et vérifier s'il est possible de
démonter le
Volume Logique affiché dans la colonne de gauche (quel que soit son intitulé) - à condition que le logiciel parvienne à charger cette instance (sans ratatouiller interminablement). Une fois démonté ce Volume (en supposant que cela se puisse), quitter l'«
Utilitaire de Disque» et aller à la barre supérieure des menus de l'écran, menu :
Utilitaires et lancer le «
Terminal».
Passer d'abord la commande :
et ↩︎ qui devrait redonner le tableau des instances du
CoreStorage. Sélectionner l'
UUID de 32 caractères alpha-numériques
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX du
Logical Volume (tout en bas du tableau : la dernière instance) et par
⌘C la copier dans le presse-papier. Passer alors la commande :
Bloc de code:
diskutil cs revert XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
et ↩︎ (surtout
pas de
sudo initial : cette option n'est pas supporté dans le
shell de la «
Recovery HD» où l'opérateur est
root d'entrée - saisir manuellement
diskutil cs revert en respectant les
2 espaces intercalaires, sauter alors encore
un espace et par
⌘V coller à sa place l'
UUID du presse-papier) --> quelle conséquence s'ensuit-elle ? Affichage de la déconstruction du
CoreStorage, rendu possible par le démontage du
Volume Logique et/ou le non-démarrage du système de fichiers de l'OS ? Ou rien ? Attention ! un
diskutil list dans la foulée est vain, car le
kernel garde la mémoire du dispositif
CoreStorage aussi longtemps qu'il n'y a pas eu re-démarrage.
=> Re-démarrer sur l'OS et vérifier si le volume monté a toujours son intitulé absurde ou non. Dans le «
Terminal», un
diskutil list renvoie-t-il toujours à la mention de
TYPE un format
Apple_CoreStorage pour la partition de l'OS, ou seulement un
Apple_HFS ? Un
diskutil cs list retourne-t-il le tableau du
CoreStorage ou le message :
no CoreStorage Logical Volume Groups found ?
- b) s'il y a échec sur toute la ligne de la commande, est-il possible de
cloner (en utilisant la démo - gratuite un mois - de ☞
Carbon Copy Cloner☜ le contenu du volume de l'OS dans le volume d'un DDE USB (tablé en
GUID, format "
Mac OS étendu journalisé") ou bien «
CCC» échoue-t-il à prendre en compte le nom surréaliste de volume "
Source" ? S'il y a échec, cloner comme "
Source", dans le répertoire des
Utilisateurs, le seul dossier de départ
jausely (ainsi les données d'utilisateur du système de fichiers seront sauvegardées). Ce dernier procédé devrait à tout le moins être honoré.
=> si
a) a échoué, et quelle que soit alors l'issue de
b) --> la solution radicale sera sans doute de supprimer le
CoreStorage entier en effaçant la partition, voire en effaçant le disque complet du Mac en démarrant sur un Système tiers, avant ré-installation de l'OS, puis récupération des données sauvegardées...