10.7 Lion Impossible activer filevault

[usurp]

Bonjour,

J'ai un problème pour activer Filevault sur 2 iMac sous Lion (20 pouces blanc fin 2006 3Go de ram et DD 1To. Je sais, ils sont vieux, mais fonctionnent très bien pour leurs utilisations).
Procédure normale d'activation via "sécurité et confidentialité", création de la clef de secours puis redémarrage.
Mais lors du redémarrage, le système semble s'ouvrir normalement (au lieu d'avoir tout de suite les utilisateurs autorisés à déverrouiller le disque), puis ce qui semble être un redémarrage (l'écran s'éteint et bruit du lecteur dvd) pour finir par arriver sur l'écran d'ouverture de session.
Quand je retourne dans les préf sécurité, pas de cryptage du disque en cours, FileVault est désactivé.

Réparation des autorisations et réparation disque effectués, pas de soucis identifiés.
J'ai créé un autre utilisateur admin au cas où, même problème.
J'ai activer l'utilisateur root et essayé depuis ce compte, sans résultat.
J'ai formaté le disque et ré-installé un Lion tout propre, sans rien d'autre que le système, idem.

Pour info la partition "Apple_Boot recovery" est bien présente.
Sur un 3ème iMac de ce type je n'ai pas rencontré de problème particulier. La seule différence avec les 2 autres : moins de mémoire (2Go) et disque dur 700Go.

Est-ce que quelqu'un a déjà rencontré ce problème ?
Si vous avez une piste, elle est la bienvenue

Merci

--Usurp--

 

[Membre supprimé 1060554]

Là tu piques ma curiosité, usurp

Je te propose le test suivant => dans le «Terminal» d'un «Lion» réticent à activer «FileVault», tu passes une commande de la forme suivante :

sudo fdesetup enable -user ton_username -forcerestart

--> l'utilitaire fdesetup (filevault_disk_encryption_setup = paramétrage du chiffrement de disque filevault : c'est le binaire qu'utilise le logiciel «FileVault») est appelé en droits root (sudo) avec le verbe enable (activer), l'option -user (utilisateur) suivie de la saisie de l'username (le nom court de l'utilisateur accrédité à déverrouiller le Volume Chiffré à l'écran de login initial => tu saisis ici ton username, genre usurp) et la 2è option -forcerestart (forcer le re-démarrage après mise-en-place du CoreStorage permettant le chiffrement).

Tu presses la touche ↩︎ du clavier pour activer la commande --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> la demande suivante s'affiche :

Enter the password for user 'ton_username':

--> tape ton mot-de-passe de session admin à l'aveugle encore (afin d'authentifier ton mot-de-passe à déverrouiller le Volume Chiffré) et conclut par ↩︎ --> une :

Recovery key = 'XXXX-XXXX-XXXX-XXXX-XXXX-XXXX'

va être générée à l'écran du «Terminal» suivie d'un :

System is being restarted.

--> ton Mac re-démarre après un laps de temps appréciable (occupé à générer le Groupe de Volumes Logiques du CoreStorage Chiffré). Tu peux sauvegarder "à la volée" la clé de récupération de mot-de-passe sur un bout de papier - mais la fenêtre du «Terminal» va être réaffichée à l'écran lorsque tu ré-ouvriras ta session, avec l'ensemble des saisies restaurées, dont la Recovery Key que tu pourras cette fois enregistrer au propre.

Je viens de faire cette opération dans une session expérimentale de «Mavericks 10.9.5» => «FileVault-2» est activé sans problème et, au re-démarrage, c'est bien un écran de déverrouillage qui s'affiche d'entrée, avec mon icône d'utilisateur flanquée de celle d'un Utilisateur invité => est-ce que ça marche chez toi ? Si ça marchait, tu peux, en ouvrant le panneau : Menu  > Préférences Système > Sécurité et confidentialité > FileVault suivre l'avancement du chiffrement du Volume Physique qui sert de disque dur virtuel, et à partir duquel monte le Volume Logique Déchiffré où le système de fichiers de l'OS est ancré.

 

[usurp]

Merci de ta réponse détaillé !

Alors peut-être un début d'explication au problème : fdesetup "command not found". Testé avec 2 comptes admin différents et depuis le compte root.
Vais explorer cette piste.

--usurp--

 

[Membre supprimé 1060554]

Salut usurp

Je viens de m'apercevoir en démarrant sur «Lion» que l'utilitaire fdesetup n'existait pas encore dans cet OS. Il n'a été introduit qu'à partir de «Mountain Lion 10.8» at: /usr/bin. Autant pour moi, donc !

Mais qu'à cela ne tienne ! J'ai une commande alternative pour toi, que je viens de tester avec succès dans l'environnement de «Lion 10.7.5» (j'ai tous les OS de «Snow Léopard 10.6.8» à «El Capitan 10.11.4» installés dans des partitions séparés du disque de mon MacBook Pro 17" Late_2011 - tous démarrables => donc je peux tester. C'est ce que j'aurais dû commencer par faire pour fdesetup, mais j'étais persuadé que ce binaire existait depuis «Lion» où a été présenté «FileVault-2» pour chiffrer le disque de l'OS et non plus simplement les dossiers d'utilisateurs comme le faisait antérieurement «FileVault-1»).

Mais pour connaître le contexte logique de ton iMac => peux-tu passer le commandes suivantes dans le «Terminal» ?

D'abord :

diskutil list

et ↩︎ --> cette commande appelle l'utilitaire diskutil (disk_utility : bien présent dans «Lion» celui-là !)) avec le verbe list (lister) --> en retour, tu vois s'afficher le tableau des partitions du disque de ton Mac (ne connecte pas de périphériques au moment de la commande, pour ne pas que les partitions de leurs disques ne soient aussi affichées) --> peux-tu faire un copier-coller de ce tableau ici  (pas de cliché) ?

Saisis encore la commande :

diskutil cs list

et ↩︎ --> cette commande ressemble à la précédente, avec l'intercalaire cs (abrégé de CoreStorage) --> si tu n'as pas de format spécial CoreStorage (inventé avec «Lion» et requis pour un chiffrement du volume de l'OS), tu obtiendras un :

No CoreStorage Logical Volume Group found

(indique-le alors) ; sinon, tu obtiendras un :

CoreStorage Logical Volume Groups : 1 found

suivi de l'affichage du tableau imposant des instances du Groupe de Volumes Logiques --> si c'était le cas, peux-tu encore faire un copier-coller de ce tableau ?

☞ d'après ces informations, je pourrais vérifier si la commande à laquelle je pense est adaptée...

 

[usurp]

Merci encore Macomaniac.

Résultat du diskutil :
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Ddlocal 999.3 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

Ddlocal étant bien le nom de ma partition de démarrage

et j'ai bien "no CoreStorage logical volume groups found"

 

[Membre supprimé 1060554]

Alors voici la commande tu peux passer :

sudo diskutil cs convert disk0s2 -passphrase toto

(tu peux faire un copier-coller de sudo diskutil cs convert disk0s2 -passphrase, tu sautes un espace et tu remplaces mon toto par un mot-de-passe de ton choix qui va jouer le rôle de mot-de-passe général de déverrouillage du disque chiffré (l'équivalent d'une recovery key - tu peux choisir le même que ton mot-de-passe de session admin) et tu actives la commande (avec saisie du mot-de-passe admin à l'aveugle).

Tu devrais toucher cet affichage :

Started CoreStorage operation on disk0s2 Ddlocal
Resizing disk to fit Core Storage headers
Creating Core Storage Logical Volume Group
Attempting to unmount disk0s2
Switching disk0s2 to Core Storage
Couldn't unmount disk0s2; converted volume won't appear until it's unmounted
Core Storage LVG UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Core Storage PV UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Core Storage LV UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Finished CoreStorage operation on disk0s2 Ddlocal
Encryption in progress; use `diskutil coreStorage list` for status

Si tu as bien touché cet affichage, attention ! L'architecture du CoreStorage Chiffré est formellement définie, mais les disques virtuels qu'il gère ne sont pas tous en place => il est impératif que tu re-démarres ton iMac sans attendre. Au re-démarrage, tu vas toucher un écran de déverrouillage dans lequel (pour l'instant) il n'y a qu'une icône grise rectangulaire de disque et la mention : Mot du passe du disque => tu renseignes toto (ce que tu as choisi à la place) dans le champ de saisie.

Moi, j'étais en choix d'ouverture de session automatique après déverrouillage. Si ce n'est pas le cas chez toi, tu vas peut-être récupérer à la fin du démarrage un nouvel écran de login, classique, où tu pourras entrer dans ta session avec ton mot-de-passe courant.

Une fois dans ta session, va au panneau : Menu  > Préférences Système > Sécurité et confidentialité > FileVault => est-ce que tu vois s'afficher une barre de progression du Chiffrement (qui concerne le Volume Physique) ? Si oui, c'est bien parti : ne lance pas de processus lourds dans ta session, car ils ralentiraient le processus de chiffrement. Tu vas apercevoir dans le panneau une mention : "Des utilisateurs ne sont pas autorisés à déverrouiller le disque" avec un triangle jaune d'avertissement => déverrouille le cadenas du panneau avec ton mot-de-passe admin, clique le bouton "Autoriser des Utilisateurs" et pour chaque nom d'utilisateur mentionné que tu veux autoriser à déverrouiller le Volume Physique Chiffré au démarrage, y compris le tien s'il y a lieu, clique ce nom et dans le panneau qui se démasque chaque fois renseigne le mot-de-passe de session de l'utilisateur (tu verras une coche verte en regard de chaque utilisateur autorisé).

Quand le chiffrement est fini, re-démarre encore une fois => ce coup-ci, tu devrais toucher un écran préliminaire de déverrouillage comportant toujours l'icône grise rectangulaire de disque et la mention : Mot du passe du disque (mot-de-passe toto) ; mais en sus autant d'icônes d'utilisateurs que tu en as autorisés dans le panneau de FileVault => il s'agit ici, pour la session que tu veux ouvrir, de renseigner le mot-de-passe de session de l'utilisateur (ce mot-de-passe a été autorisé à pouvoir déverrouiller le disque chiffré, de manière à monter le Volume Logique Déchiffré). Il ne doit plus y avoir désormais de second écran de login.

☞ on dirait un conte de fées, non ? Chez moi, tout ce que je t'ai décrit s'est déroulé sans anicroches. Et chez toi ?

 

[usurp]

J'ai toujours aimé les contes, mais la vie a plutôt tendance à m'orienter vers ceux de la Cryptes que ceux des Fées
La preuve :

Commande exécutée, j'ai bien les indications de création comme toi (exactement, à part les UUID bien sur).

Mais après reboot immédiat, cela fait comme lorsque j'active FileVault via les préfs système : rien
Pas d'écran de déverrouillage de disque, et une fois le système lancé :
diskutil corestorage list : no CoreStorage logical etc...

J'ai ré-exécuté la commande et fait un diskutil corestorage list tout de suite pour voir :

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 522DE250-4294-4E44-8500-FC3A92F62426
=========================================================
Name: Ddlocal
Sequence: 1
Free Space: 0 B (0 B)
|
+-< Physical Volume 52314342-0E7B-4912-A97F-B6C9A0A16CAD
----------------------------------------------------
Index: 0
Disk: disk0s2
Status: Online
Size: 999345127424 B (999.3 GB)

Je redémarre, refait un diskutil cs list : no CoreStorage logical volume groups found

Si j'avais appris le Latin je crois que je l'aurai perdu !

Et-il possible que cela viennent des disques (je ne sais pas si ce sont ceux d'origines) ?

J'aimerai bien que clochette se ramène avec sa poudre magique

 

[Membre supprimé 1060554]

Ton tableau initial :

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 522DE250-4294-4E44-8500-FC3A92F62426
=========================================================
Name: Ddlocal
Sequence: 1
Free Space: 0 B (0 B)
|
+-< Physical Volume 52314342-0E7B-4912-A97F-B6C9A0A16CAD
----------------------------------------------------
Index: 0
Disk: disk0s2
Status: Online
Size: 999345127424 B (999.3 GB)

correspond trait pour trait à celui que j'avais obtenu via un diskutil cs list juste après la commande => il apparaît (clairement) qu'il manque au Logical Volume Group les 2 instances terminales (qui font une paire) : la Logical Volume Family (qui pilote le Volume Logique et recèle le logiciel de déchiffrement quand c'est le cas) et le Logical Volume (qui est le Volume Logique qui monte à partir du Physical Volume, exactement comme celui d'un énorme .dmg = disque virtuel plaqué sur la partition disk0s2).

C'est seulement après re-démarrage que le paire d'instances : Logical Volume Family > Logical Volume se trouve déployée. Donc chez toi une méchante sorcière proscrit la génération de cette paire, et volatilise même le demi-CoreStorage qui avait été mis en place. Moi qui suis latiniste, justement, vais-je en perdre mon Virgile ? Ton cas de figure est "super-intéressant", mais pour l'instant, c'est la descente aux Enfers (de Dante, qui n'avait pas perdu son Virgile pour autant dans l'affaire)...

(Fais peut-être une sauvegarde, au cas où - car il y a quelque chose de pas catholique dans toute cette histoire...)

Tu peux alors faire un test de génération d'un CoreStorage Non-Chiffré, pour voir si c'est le même plantage (il n'y a dans ce cas aucun écran initial de déverrouillage, mais login classique à l'écran d'ouveture de session affiché en fin de démarrage). La commande est :

sudo diskutil cs convert disk0s2

=> tu vois l'idée ? S'il est impossible de générer un CoreStorage ouvert sur ton disque, alors sachant que «FileVault» est incapable de procéder à un chiffrement sans génération préalable d'un CoreStorage, on tiendrait là la raison de l'échec du chiffrement (sans connaître pour autant alors la raison de l'échec de la génération d'un CoreStorage).

Attention encore : il est impératif que tu re-démarres ton Mac à l'issue de la commande, parce que le CoreStorage, formellement esquissé, n'est pas opératoire encore (le kernel ou micro-noyau n'a pas intégré ce dispositif). Après re-démarrage, que donne un diskutil cs list ?

 

[usurp]

Hello Macomaniac

Le CoreStorage non chiffré à bien été généré.

Résultat du diskutil cs list après redémarrage (et même 2) :

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 90E49BD3-6810-4851-A092-7870A04C34C9
=========================================================
Name: Ddlocal
Sequence: 1
Free Space: 0 B (0 B)
|
+-< Physical Volume E3C37969-8D89-4492-BD7B-E84025DDC134
| ----------------------------------------------------
| Index: 0
| Disk: disk0s2
| Status: Online
| Size: 999345127424 B (999.3 GB)
|
+-> Logical Volume Family BF03641C-49CA-4B07-A365-841D30436839
----------------------------------------------------------
Sequence: 3
Encryption Status: Unlocked
Encryption Type: None
Encryption Context: Present
Conversion Status: NoConversion
Has Encrypted Extents: No
Conversion Direction: -none-
|
+-> Logical Volume 154E4589-F98F-444E-875A-32B5115999C6
---------------------------------------------------
Disk: disk1
Status: Online
Sequence: 3
Size (Total): 999026356224 B (999.0 GB)
Size (Converted): -none-
Revertible: Yes (no decryption required)
LV Name: Ddlocal
Volume Name: Ddlocal
Content Hint: Apple_HFS

Je suppose maintenant qu'il faut exécuter une commande pour lancer le chiffrement du style

 sudo diskutil EncryptVolume "le lvUUID du logical volume group" disk0s2 -passphrase "la recovery key"

.
A tout hasard j'ai lancé la procédure classique d'activation de FileVault sans résultat. Mais cela n'a pas shooté le CoreStorage.

 

[Membre supprimé 1060554]

«Lion» était l'OS pionnier pour ce qui est du CoreStorage et de FileVault-2». Par suite, l'exécutable diskutil dans «Lion» ne dispose pas de tous les raffinements qui lui ont été implémentés par la suite, regardant le CoreStorage. Notamment (je viens de vérifier) le verbe encryptVolume (ou encrypLV) n'est pas disponible pour le diskutil de «Lion». Conséquence : si tu as un CoreStorage non-chiffré (c'est ton cas), tu ne peux pas lui appliquer une opération de chiffrement de cette façon. Et comme «FileVault» continue de renacler chez toi : c'est bloqué.

Le CoreStorage non chiffré, c'était une histoire de vérifier si c'était là le facteur de blocage. Apparemment, ça ne l'est pas : c'est «FileVault» qui est en panne, chez toi. Alors, voici ce que tu peux faire encore :

- a) comme ton CoreStorage obtenu par le verbe convert est réversible (non destructivement pour le système de fichiers de l'OS) par définition, tu peux le supprimer aussi aisément que tu l'as fabriqué, par une commande du type :

sudo diskutil cs revert lvUUID

(lvUUID = le XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX du Logical Volume, la dernière instance du Groupe de Volumes Logiques, que tu obtiens en repassant d'abord un diskutil cs list - ne pas renseigner d'identifiant de partition en sus, rien que sudo diskutil cs revert XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX). Ton CoreStorage va être déconstruit sans coup férir, mais là encore il est impératif que tu re-démarres ensuite, sinon le nouvel état du partitionnement n'est pas chargé.

- b) afin de vérifier si le plantage de ton «FileVault» n'est pas d'ordre logiciel, je te conseille ensuite de démarrer par ⌘R sur ta partition de récupération «Recovery HD» et, dans la fenêtre des 4 Utilitaires OS X, d'activer l'option : "Ré-installer OS X" à destination de ton volume Ddlocal => Wi-Fi requis. AppleID. Téléchargement depuis l'AppStore des paquets de restauration de «Lion 10.7.5» dans le volume Ddlocal (environ 5 Go : 2H 30' à 3H), suivi de la restauration du Système (dans les 45'). Les comptes d'utilisateurs, leurs données non plus que les applications tierces ajoutées ne sont touchés - seul le Système OS X est restauré.

=> tu vas bien voir à complétion, une fois ta session ré-ouverte, si tu peux activer «FileVault»...​

 

[usurp]

Ok, vais relancer une install depuis l'appstore.

Le système actuel était "tout neuf", mais installé depuis une clef usb, qui a peut-être une défaillance quelconque. Hors comme je ne me rappelle plus si c'est déjà depuis cette clef que j'avais installé les systèmes posant problème...(Sur les 3 machines, j'ai du logiquement en installer une via la mise à jour gratuite proposée par l'AppStore, permettant de récup l'installateur et les 2 autres par la clef créée lors de cette première install, ce qui pourrait expliquer le pb de 2 iMac sur 3 si cette clef est un peu foireuse)

Je fais ça et reviens par ici pour la suite

 

[usurp]

Système ré-installé et mis à jour.
Et je ne peux toujours pas activer FileVault, ni par les préfs système ni par diskutil ....
Un AHT depuis le disque d'origine ne détecte aucun problème, un test depuis "EtreCheck" non plus.
Je commence à supputer une incompatibilité des dd avec FileVault. Je vais rechercher les factures voir si ce sont ceux d'origine ou pas.

Edit : Vérification faite, c'est l'iMac sur lequel FileVault fonctionne dont j'avais changé le Disque Dur (remplacé le 1To par un 700Mo)

 

[Membre supprimé 1060554]

Ça sent le problème matériel, en effet.

Si tu as un DDE USB sous la main (Table GUID / Volume JHFS+ - j'espère que ton Ddlocal de près de 1 To n'est pas plein à ras bord), tu peux faire 2 tests :

- a) tu fais un clone du volume de ton OS (en utilisant la version ☞Carbon Copy Cloner 3.5☜ par exemple - démo fonctionnelle) > tu démarres sur ton clone > tu essaies d'activer «FileVault» sur ce volume externe => succès ou échec ?

- b) en cas d'échec de a, tu effaces le volume du clone (ou tu crées un petit volume annexe de 20 Go) > tu installes un «Lion» clean > tu démarres sur le «Lion» externe > tu essaies d'activer «FileVault» sur ce volume externe => succès ou échec ?

 

[usurp]

Bien le bonjour

Suite (et fin?) de l'histoire.

Install d'un système tout neuf sur disque externe (dans un dock).
Démarrage sur ce disque, nickel, activation de FileVault sans problème . Encryptage cette nuit.
Ce matin opération de la bête, je démonte le disque interne et le remplace par cette nouvelle install. Tout est ok.

Mais curieux par nature, je mets mon ex-disque interne dans le dock USB, démarre dessus, et vais activer FileVault.
Et bien FileVault s'est bien activé !!! Il est en cours chiffrement.

Donc ça n'est pas le modèle de DD en lui-même qui pose problème.
Mystère.

Le problème est résolu, mais pas clairement identifié, dommage.
Vais faire quelques test avec la deuxième bécane.

Merci en tout cas Macomaniac pour ton aide et tes explications détaillées.

 

[Membre supprimé 1060554]

Le problème est résolu, mais pas clairement identifié, dommage.

En effet... Si ce n'est pas une question de disque, alors un problème de nappe (le cable connecteur plat qui relie le disque à la Carte-Mère) : mal branchée ? fatiguée ?

Tu peux faire encore un test, un : sur le disque que tu as actuellement en interne, tu dois bien pouvoir créer une petite partition de 20 Go ? Tu installes un «Lion» propre, tu démarres dans une session neuve de ce Système et tu tentes de lancer «FileVault» => tu vas bien voir si ça passe ou non. Même test éventuellement si tu remets ton HDD de 1 To en interne : tu fais une petite partition > «Lion» propre > démarrage dessus > tentative «FileVault» => tu vas bien voir encore.

Si ça bloque en interne encore (alors que tes disques sont opérationnels), je ne verrais plus alors que la nappe à incriminer...​

 

[usurp]

Test en installant un nouveau Lion sur une autre partition du DD que j'ai mis dans l'iMac.
Pas de problème, FileVault à bien pu s'activer --> le problème n'est donc pas lorsque le disque est en interne.
Si ce n'était aussi ch...t de changer le disque je remettrai bien le 1To en place. Vais voir avec la deuxième bécane.

 

[usurp]

Bonjour à tous
Avec le 2eme ordi qui pose problème, même manip et même résultat. Je m'y attendais mais on ne sait jamais...
Mais cette fois j'essaye d'activer FileVault (pourquoi n'y ai-je pensé avant) depuis le terminal de la HD recovery avec la commande

 diskutil cs convert disk0s2 -passphrase lemotdepassesecours

Bingo ! Après redémarrage j'ai bien le FileVault d'activé et le chiffrement en cours.
Ça n'explique pas d’où vient le problème initial mais évitera le démontage cette fois.

En espérant que ce retour d'expérience puisse servir à d'autre.

Plus de boule verte, sinon je t'aurai donné tout mon quota Macomaniac merci

 

[Membre supprimé 1060554]

usurp

cette fois j'essaye d'activer FileVault (pourquoi n'y ai-je pensé avant) depuis le terminal de la HD recovery avec la commande diskutil cs convert disk0s2 -passphrase lemotdepassesecours Bingo ! Après redémarrage j'ai bien le FileVault d'activé et le chiffrement en cours.
Ça n'explique pas d’où vient le problème initial mais évitera le démontage cette fois.

Beau coup par la bande !

Les raisons du plantage de l'activation de «FileVault» en mode "live" (l'OS démarré) vont malgré tout rester ignorées. Pour résumer : toutes les apparences d'une prise en compte formelle dans un premier temps ; mais, au re-démarrage du Mac, pas plus de chiffrement (et de CoreStorage requis) que de beurre en broche...

Allons, pour le panache : une conjecture de plus, une (qui ne changera rien à la donne) ! Lorsque des opérations d'écriture se trouvent commandées pendant une ouverture de session dans l'OS, elles ne s'effectuent pas forcément directement aux blocs du disque, mais il arrive qu'elles soient mises-en cache (dans le buffer_cache par exemple) selon le mode write_back : ce qui signifie que c'est seulement à la fermeture de session que ces opérations d'écriture vont s'effectuer du cache aux blocs du disque (avant extinction ou re-démarrage de la bécane).

Est-il possible de supposer alors que la commande d'activation de «FileVault» (impliquant génération d'un CoreStorage Chiffré) ait été passée au buffer_cache, mais qu'à la fermeture de session, dans le laps de temps imparti à l'écriture du cache au disque avant re-démarrage, il y ait eu un plantage de l'opération ? Ce qui fait que le Mac re-démarrait comme à l'ordinaire, rien n'ayant été écrit réellement au disque ?

Le problème avec ce genre de conjecture, c'est que ça ne fait que reculer d'un cran l'ordre des raisons : car on peut toujours se demander quelle est alors la cause de la cause => pourquoi, et seulement dans le cas d'une opération de génération d'un CoreStorage Chiffré (et pas Non-Chiffré), y aurait-il eu invalidation de l'écriture cache => disque entre la fermeture de la session et le re-démarrage ? Tu vois le hic...

L'expérience de vider les caches-Système au préalable aurait-elle pu changer la donne ? Ou bien la raison n'était-elle pas intrinsèque au buffer_cache, mais pouvait-elle tenir au kernel en charge de gérer le travail de transfert d'écriture au disque (kernel ma foi fort obligeant lorsqu'il s'agissait de celui de la «Recovery HD») ? Il y a tellement de facteurs ardus à scruter (quand on n'est pas ingénieur informatique) susceptibles d'intervenir ici, que je vais laisser ma conjecture partir en fumée comme celle d'un coup d'arquebuse qui a fait long feu