Salut
Doug&.
Une série de cas ont attesté récemment, sur les forums
MacGénération, de plantages du processus de chiffrement du volume de l'OS «
Yosemite» par «
FileVault-2» - ce qui s'avère, dans le panneau des
Préférences Système/Sécurité et confidentialité/FileVault, à la stase de l'indicateur de progression du cryptage (voire à l'affichage périodique d'une fenêtre réclamant, pour que l'opération se complète, le branchement sur secteur du Mac alors que ce dernier est déjà branché).
Cette situation bloquée du processus de chiffrement n'empêche nullement le déverrouillage du Mac par saisie du mot-de-passe d'utilisateur au démarrage, non plus que l'ouverture de session et l'utilisation normale du Mac. Mais elle scelle le dispositif du disque, parce que «
FileVault», en préalable de l'opération de cryptage, a converti le volume de l'OS au format :
CoreStorage - format qui, aussi longtemps qu'il est en place, verrouille le disque du Mac en empêchant tout adressage direct du disque physique réel. Et, je le conçois parfaitement, elle suscite un malaise permanent de l'utilisateur, toujours en train de se demander si cette situation bancale ne va pas "dégénérer" logiquement en entravant, à l'improviste, la capacité de démarrage et d'ouverture de session.
La
raison de ce blocage du processus de chiffrement n'est pas établie à ce jour, ce qui ne permet pas de lui apporter une
solution rationnelle pertinente. S'il s'agissait, par exemple, d'une incompatibilité entre le programme de chiffrement (
fdesetup) lancé par l'application «
FileVault-2» et tel facteur =
x de l'OS «
Yosemite», alors le problème serait peu susceptible de solution dans le cadre même de cet environnement aussi longtemps qu'une MÀJ de l'OS n'aurait pas remédié au facteur de conflit.
------♤
Cet état des lieux brossé, 2 voies se dessinent pour affronter ce problème : a) des
procédés empiriques des plus aléatoires, qui paraissent avoir marché dans certains cas et n'avoir rien donné dans d'autres ; b) une intervention drastique d'
effacement du disque avant ré-installation de l'OS - ce qui, bien entendu, supprime le problème en éliminant son espace d'exercice, mais demande à cette fin de faire sauter au préalable le verrouillage logique du format
CoreStorage qui bloque a priori tout reformatage comme tout retablage directs.
Afin de ne pas étendre exagérément mon "discours", je me propose dans ce qui suit de ne décrire que les
procédés empiriques susceptibles de débloquer la situation et d'attendre ton retour d'expérience pour éventuellement exposer le procédé de déboulonnage du format
CoreStorage avant ré-installation de l'OS - s'il y avait lieu.
------♧
Les
procédés empiriques qui ont
occasionnellement marché sont au nombre de 2 et se trouvent documentés dans ces fils auxquels tu peux te référer : a) ☞
Bug avec FileVault - Yosemite☜ (méthode
netatoo) ; b) ☞
Problème Yosemite/Filevault☜ (méthode
Keke) <NB. le créateur de ce dernier fil atteste pour sa part avoir résolu son problème via un
effacement du disque du Mac à partir d'un clone : cette méthode
nico correspond évidemment au procédé "drastique" que j'ai déclaré m'abstenir de développer pour l'instant>.
En survolant ces 2 méthodes, tout me porte à penser qu'elles s'apparentent au bon vieux "coup de pied dans la ferraille" pour faire repartir un engin rétif : introduire une "secousse logique" en en espérant un déblocage
.
- Méthode netatoo.
- Démarrer par ⌘R sur la partition de récupération «Recovery HD» et aller directement à l'extrême gauche de la barre supérieure de menus de l'environnement d'accueil : Menu  --> sous-menu : Disque de Démarrage. Sélectionner au pointeur le volume de l'OS Macintosh HD normalement grisé, car non monté à cause du verrouillage initial par «FileVault» --> un panneau surgit demandant de déverrouiller le volume pour le monter avec le mot-de-passe admin associé à la clé de déchiffrement --> obtempérer, ce qui monte le volume de l'OS qui apparaît désormais en surbrillance et en gras : Macintosh HD (mais ne surtout pas re-démarrer dessus). Quitter le panneau du Disque de démarrage au contraire, ce qui laisse le volume de l'OS à l'état : monté.
- Revenir à la fenêtre des Utilitaires OS X et lancer l'«Utilitaire de Disque» --> dans sa colonne de gauche, sélectionner le volume de l'OS monté (et donc manipulable) Macintosh HD, et successivement activer les fonctionnalités : Réparer le Disque & Réparer les Permissions. Cela fait, re-démarrer normalement sur l'OS et, la session ouverte, aller vérifier à : Menu /Préférences Système/Sécurité et confidentialité/FileVault s'il n'y a pas une transformation de l'affichage : de "pause" indéfinie à une indication de "délai" horaire déterminé avant complétion, ce qui signifierait un déblocage du processus de chiffrement.
<NB. Corriger le filesystem de l'OS qui se trouve directement concerné par le chiffrement peut paraître un procédé capable de faire "bouger" les choses, par "secousse logique" apportée à l'objet... >
--------------------
- Méthode Keke.
- Une fois la session normale de l'OS ouverte, débrancher le Mac du secteur avant d'aller à : Applications/Utilitaires et lancer le «Terminal». Dans la fenêtre qui s'affiche, saisir exactement la commande :
et ↩︎ (presser la touche 'Entrée' du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> taper le mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> s'affiche en réponse une demande de re-saisie du mot-de-passe admin afin d'autoriser la désactivation de «FileVault» sur / = le point de montage du volume de l'OS --> re-taper le mot-de-passe admin et ↩︎ pour la 3è fois.
- Re-démarrer le Mac et, la session ré-ouverte, le re-brancher sur secteur et aller voir ce qui se passe dans le panneau : Menu /Préférences Système/Sécurité et confidentialité/FileVault --> maintien de la stase du chiffrement ou redémarrage d'activité.
<NB.Il faut savoir que le programme fdesetup (FileVault Disk Encryption SETUP : mise-en-place du chiffrement de disque FileVault) est le moteur opératoire de «FileVault-2». Le verbe "disable" commande une désactivation du chiffrement, lors même que ce dernier ne s'est pas complété : ce conflit logique d'instructions est, éventuellement, susceptible de faire bouger les choses par "secousse logique" imprimée à l'exécution du programme lui-même... >
------♡
Rien n'empêche absolument de penser - toutes choses égales d'ailleurs - qu'un
bug d'affichage graphique dans le panneau des
Préférences Système/Sécurité et confidentialité/FileVault ne présente pas une vision erronée de la situation réelle. Il y a moyen de vérifier l'état de choses effectif en repassant par le «
Terminal» -->
- Tout d'abord, la commande :
et ↩︎ affiche l'état réel du chiffrement, et en cas d'opération en cours inachevée, le % accompli jusqu'ici.
- Par ailleurs, la commande :
et ↩︎ affiche le dispositif d'ensemble du format CoreStorage du volume de l'OS instauré par «FileVault» en condition préalable du chiffrement. Ce qui permet, dans les 2 instances terminales du tableau : Logical Volume Family & Logical Volume, de vérifier finement les indicateurs de l'état des lieux : si le processus de conversion est "en cours" ou "complet" ; si son sens est "antérograde" (Forward) ou "rétrograde" (Backward) ; et quel % du travail se trouve déjà accompli.
- Dans tous les cas de figure, puisqu'on a affaire à une "image arrêtée" à un instant T et n'affichant pas de processus dynamique, il est intéressant, par exemple 15' - ou 30' ou 60' - après une des 2 commandes ci-dessus, sans avoir quitté le «Terminal» ni fermé sa fenêtre, de récidiver la commande fdesetup status et/ou diskutil cs list, ce qui permet d'obtenir un 2è tableau fournissant une image arrêtée des choses à l'instant T+1 --> le comparatif des données, notamment des %, permet de façon décisive de savoir s'il y a activité souterraine - effective même si minime - du programme fdesetup ou au contraire stase complète.
<Il faut savoir, ici, que le plus petit processus lancé dans la session d'utilisateur (puisque cette dernière n'est pas suspendue pendant le chiffrement) en parallèle au programme de fdesetup ralentit considérablement l'exécution du chiffrement et augmente le délai de complétion. Plusieurs processus, ou un seul gourmand en ressources, déclenchent un étirement indéfini du délai de complétion calculable. Pourquoi n'y aurait-il pas, après tout, passage à la limite envisageable avec suspension sine die du processus de chiffrement - toutes choses dues à un utilisateur trop 'actif' dans sa session en concomitance?>
------♢
