Mot de passe filevault non reconnu

bossdupad · 30 Juin 2014

Bonjour,

Je rentre de voyage, j'avais avec moi mon MacBook unibody late 2008.

Apres avoir pris l'avion a l'aller, j'ai été dans l'impossibilité de deverrouiller mon ordinateur avec mon mot de passe filevault habituel.

Je suis certains de mon mot de passe, j'ai branché un clavier externe et le probleme est toujours le meme. Je vais essayer de le connecter en externe demain sur un autre mac pour voir si cela fonctionne.

J'ai crus comprendre qu'une defaillance de mon disque SSD pouvais etre a l'origine du probleme
...

Certains ont ils deja rencontré ce soucis?

Merci d'avance.

Membre supprimé 1060554 · 1 Juillet 2014

Salut bossdupad.

Parmi mes Macs_vintage, j'ai une réplique du tien : un MacBook_Late 2008, supportant «Léopard 10.5.8», pour le compte admin principal duquel j'ai activé la technologie Filevault-1 --> je peux engager ici la conversation en 'connaissance de cause'...

À la différence de la version ultérieure introduite à partir de «Lion 10.7» : Filevault-2 qui protège le volume de démarrage global des Macs, la technologie originelle : Filevault-1 était activable optionnellement par chaque utilisateur admin sous Mac OS «Tiger 10.4» à Mac OS «Snow Léopard 10.6» et protégeait exclusivement son Dossier de Départ personnel recelé dans le répertoire global des Utilisateurs ('Users') [il est à noter qu'un utilisateur ayant protégé son Dossier de Départ par Filevaut-1 sous «Snow Léopard 10.6» peut conserver le 'bénéfice' de cette protection sous des versions ultérieures d'OSX à condition de les avoir installées en mises-à-niveau de cet OS].

Sous «Léopard 10.5» (ton OS) comme sous «Snow Léopard 10.6», l'activation de la protection Filevault-1 pour protéger un Dossier de Départ d'utilisateur aboutit à générer, à la fermeture de session, une image-disque de format .sparsebundle à l'intérieur du Dossier de Départ au nom de l'utilisateur contenu dans le répertoire des Utilisateurs, Dossier de Départ qui devient une espèce d'enveloppe logique contenant donc cette image-disque.

L'image-disque .sparsebundle contient tous les sous-répertoires de l'utilisateur avec leurs données, et présente 2 caractéristiques : un chiffrement à la fermeture de session d'après l'algorithme AES, associé à une clé cryptographique dérivée du mot-de-passe admin de l'utilisateur. Lorsque l'utilisateur, au démarrage, tape son mot-de-passe admin dans la fenêtre d'ouverture de session (LoginWindow), c'est en fait la clé cryptographique qu'il génère, laquelle permet de lancer le dé-chiffrement de l'image-disque .sparsebundle dont le montage autorise l'ouverture régulière de la session.

En l'absence de la connaissance du mot-de-passe générant la clé cryptographique, l'image-disque .sparsebundle chiffrée en AES recelée dans l'enveloppe du Dossier de Départ de l'utilisateur est absolument in-transgressable par tout autre utilisateur interne de l'OS, serait-il même root (le Super-Administrateur_Système), comme elle est intransgressable en mode Target par l'utilisateur d'un Mac Hôte connecté en FireWire au Mac Cible, s'il n'a pas la connaissance du mot-de-passe génératif de la clé cryptographique.

Cette protection radicale présente (comme toute chose) un revers de cet avers formidable du point de vue du niveau de protection des données utilisateur : en cas d'oubli du mot-de-passe générateur de la clé cryptographique, ou en cas d'impossibilité de le saisir exactement (pour un utilisateur qui aurait un problème de clavier, physique ou logique) - alors l'image-disque .sparsebundle est absolument inaccessible dans son contenu de données, car son dé-chiffrement ne peut être initié.

Par défaut, au premier Dossier de Départ d'utilisateur admin pour lequel la protection Filevaut-1 est activée, un Mot-de-passe principal se trouve défini (identique ou non au mot-de-passe générateur de la clé cryptographique de dé-chiffrement de l'image-disque .sparsebundle de ce compte, selon les options de cet utilisateur aborigène) - mot-de-passe principal qui joue le rôle théorique de "filet de sécurité" général pour tous les comptes protégés éventuellement par Filevault-1 --> ce mot-de-passe principal peut permettre, par exemple, à partir d'une session graphique root, en double-cliquant toute image-disque .sparsebundle d'un Dossier de Départ d'utilisateur, de générer une clé cryptographique secondaire permettant le dé-chiffrement de l'image et son montage [NB. Ce 'contournement' par mot-de-passe principal rend, de ce fait, caduque la protection par chiffrement alogorithmique de tout Dossier de Départ d'utilisateur qui n'est pas celui de l'utilisateur admin qui a le 1er activé la protection Filevault-1 et de ce fait défini le mot-de-passe "Filet de sécurité" de cette technologie. Car ce dernier peut, à volonté, monter les images-disques .sparsebundle des Dossiers de Départ protégés des autres utilisateurs, grâce à son monopole du mot-de-passe : "Filet de sécurité" --> il s'ensuit que pour ces "autres" utilisateurs, l'admin initiataire de la protection Filevault-1, détenteur du monopole du mot-de-passe : "Filet de sécurité", peut ouvrir ad libitum leurs Dossiers de Départ bien plus aisément que s'ils n'étaient protégés que par un simple mot-de-passe de session, ce qui fait toucher cette technologie à son point d'absurdité

].

L'immense inconvénient de la protection Filevault-1, qui a engendré des ravages et conduit à son abandon (elle a aujourd'hui le statut 'Legacy' bien mérité), c'est que l'image-disque .sparsebundle soumise à de continuelles manipulations de chiffrement/dé-chiffrement algorithmique, possède une 'stabilité logique' assez aléatoire. En termes clairs : elle est susceptible de corruption, soit pour des raisons logiques (d'erreurs de manœuvre dans la session utilisateur), soit pour des raisons physiques (d'erreurs d'écriture à un disque défecteux) --> la conséquence d'une image-disque .sparsebundle corrompue, c'est qu'il n'y a plus rien à faire pour la dé-chiffrer et par là la monter, ni avec le mot-de-passe admin génératif de la clé cryptographique, ni avec le mot-de-passe "Filet de sécurité' génératif de la clé cryptographique secondaire.

Une de mes grandes 'terreurs' pendant les années où j'ai utilisé «Léopard 10.5» et où j'avais activé la protection Filevault-1 pour mon Dossier de Départ d'utilisateur admin - ç'a toujours été la hantise, au démarrage, d'un échec de reconnaissance de mon mot-de-passe de session génératif de la clé cryptographique

. Chaque démarrage était une occasion de 'transes', succédant aux 'affres' anticipatives de l'extinction. Bref, mon compagnonnage avec «Léopard 10.5» a été placé sous le signe de l'angoisse ré-itérée (à l'époque, je ne faisais pas de sauvegardes de données, ce qui m'eût permis, à partir de ma session ouverte dont l'image-disque .sparsebundle était montée suite à son dé-chiffrement, d'établir des copies 'non chiffrées' de mes contenus d'utilisateur sur un DDE). Sachant que 'revenir en arrière', càd. désactiver la protection Filevaut-1 établie pour un Dossier de Départ d'utilisateur, s'avère parfois impossible - le Système plantant à cette tâche - Filevault-1 avait tout de l'engrenage fatal...

☞ te supposant l'utilisateur admin aborigène de ton MacBook et vraisemblablement unique, outre ton mot-de-passe de session génératif de la clé cryptographique permettant le dé-chiffrement et le montage de l'image-disque .sparsebundle qui recèle tes données d'utilisateur, tu as dû définir un mot-de-passe principal : "Filet de sécurité" pour tout utilisateur de la protection Filevault-1 sur ton Mac, quand bien même tu étais le seul 'ayant-compte'. T'en souviens-tu et est-il par hasard différent de ton mot-de-passe de session? Si oui, tente de l'utiliser.

bossdupad · 1 Juillet 2014

Merci pour cette réponse très complète. Il est a noté que j'ai activé filevault après etre passé à Mavericks et que j'ai donc si je ne dis pas de bêtise, filevault 2 et pas la première version. Une corruption du système ou du disque SSD pourrait être la cause de mon problème?

Membre supprimé 1060554 · 3 Juillet 2014

Salut encore bossdupad.

Tes informations indiquant «Léopard 10.5» comme version d'OSX, j'en ai déduit que tu avais un problème avec FileVault-1 et ses chiffrements du Dossier de Départ_utilisateur en une image-disque .sparsebundle. Manifestement, elles ne sont pas à jour : tu es passé à «Mavericks 10.9» et c'est seulement à partir de cette mise-à-niveau que tu as activé la protection FileVault sans y conserver un cryptage préalable FileVault-1 --> tes problèmes sont donc bien relatifs à FileVault-2.

Je ne t'avais pas oublié, mais j'ai pris le temps d'infliger

à mon Mac (MacBook Pro_Early 2011, SSD, 2 Systèmes bootables : «Mavericks 10.9.3» vs «Snow Léopard 10.6.8») le chiffrement FileVault-2 sur la partition supportant le volume de démarrage 10.9. Histoire de voir par moi-même ce que ça donne...

♤

Simple 'impression subjective' : je trouve cette 'protection' plus effrayante encore que la précédente (la legacy : FileVault-1). En voici les raisons :

FileVault-2 chiffre le Volume-de-démarrage complet de l'OS concerné à la demande d'au moins un seul utilisateur admin y ayant un compte et qui en décide ainsi --> à la décision originelle d'activer la protection FileVault-1 par UN admin, une fenêtre s'affiche demandant si le compte SEUL de l'admin initiataire de la décision doit être lié au privilège de pouvoir engager le déchiffrement du volume-de-démarrage on_launch ou bien si d'autres comptes admin doivent y être associés. Sachant que pour être associé au privilège du déchiffrement du volume-de-démarrage on_launch, un autre admin doit renseigner son mot-de-passe de session normalement inconnu de l'admin initiataire de la décision de chiffrement du volume - eh bien! à supposer l'usage du Mac partagé entre plusieurs comptes qui ne soient pas de simples avatars d'un seul admin : l'aborigène, les autres utilisateurs pourraient se voir interdire carrément l'usage de leurs sessions par le coup de tête d'un seul autre, s'il prenait la décision unilatérale d'activer la protection FileVault-2 sur le volume-de-démarrage sans y associer par mot-de-passe de session renseigné les autres comtpes admin.

☞ Être en tant qu'ayant-compte admin sous la menace de l'Épée de Damoclès d'un seul qui pourrait verrouiller les autres à la porte de l'OS - je ne trouve pas cela spécialement rassurant d'un simple point de vue de Justice, laquelle, comme Aristote l'a bien souligné, équivaut au «respect de l'égalité».
Mais il y a plus (et pire) --> à supposer dans l'OS UN seul compte admin dont l'utilisateur décide pour lui seul d'activer la protection FileVault-2 (ce qui supprime le problème précédent de Justice en l'absence d'autres) - situation qui est le cas pour l'expérimentation que j'ai engagée sur mon Mac -, le chiffrement du volume-de-démarrage complet de l'OS induit une série de conséquences fâcheuses :
- Impossibilté de se logguer au boot dans la session Single_User, càd. de disposer du «Terminal» de root en clavier logique anglais - ce qui, en cas de pépin, ôte un outil avancé d'intervention sur les fichiers-Système de l'OS ;
- Impossibilité corrélative de se logguer au boot en Safe_Mode (démarrage 'sans_extensions' ou 'sans_échec'), ce qui, là encore, supprime un recours parfois bien utile en cas de pépin sur l'OS pouvant être 'mis entre parenthèses' par la suspension de l'activation d'une série de kexts de tierce-partie comme Apple natives ;
- Invalidation de l'interception de boot d'un logiciel comme «rEFInd», ce qui soustrait une fonctionnalité bien commode pour ceux - comme moi - qui l'utilisent régulièrement ;
- Impossibilité de se logguer dans une session graphique root, l'écran d'ouverture de session par comptes d'utilisateur (LoginWindow) étant inaccessible on_boot, puisqu'il y a chiffrement du volume-de-démarrage entier.
- Invisibilité du volume auxiliaire de la Recovery HD à l'écran de choix du disque de démarrage affiché par la touche 'alt' pressée on_launch, ce qui empêche la sélection du volume de récupération en vue d'opérations éventuelles de réparation ou de sauvetage de l'OS du disque principal ;
- Invisibilité totale du volume chiffré de l'OS en cas de démarrage sur un disque indépendant (celui d'un clone, ou comme sur mon Mac celui de la partition supportant l'OS «Snow Léopard» qui, bien entendu, n'est pas concerné par le chiffrement du volume «Mavericks» --> l'«Utilitaire de Disque» du volume indépendant est incapable de 'voir' le volume de l'OS supporté par le disque interne ; le «Terminal», s'il identifie bien un /dev/disk0s2, càd le device affecté aux écritures de l'OS concerné par le chiffrement, est dans l'incapacité d'en faire quoi que ce soit par l'intermédiaire de commandes : un diskutil mount /dev/disk0s2, par exemple, échoue à monter le volume chiffré supporté par le device, et une commande d'effacement du volume logique de type : diskutil eraseVolume HFS+ brol /dev/disk0s2 se heurte à une fin de non-recevoir (comme une commande plus globale : diskutil eraseDisk HFS+ brol /dev/disk0 portant sur le disque entier). La raison en est, qu'à l'instar du chiffrement par l'«Utilitaire de Disque» d'une partition de disque par le choix du Format : Mac OS étendu (journalisé_chiffré), il y a génération par FileVault-2 d'une structure logique gigogne de type : CoreStorage qui greffe un disque secondaire sur un disque primaire, le disque primaire étant rendu inaccessible par l'existence du disque secondaire qui en masque l'existence, et le disque secondaire lui-même échappant à la prise par l'effet du chiffrement (= 'circulus viciosus').
☞ En cas de blocage du déchiffrement du volume de l'OS par le mot-de-passe admin du compte associé, eh bien! l'utilisateur est littéralement à la rue de ce volume tout entier, incapable qu'il est d'y entrer soit par l'intermédiaire d'un autre compte, soit en mode Single Urer, comme d'agir sur le volume chiffré à partir d'un démarrage externe. Personnellement, je trouve cette situation pire encore que celle découlant du protocole FileVault-1.
Revenir en arrière en demandant, à partir de la session ouverte du compte qui a initié la protection FileVault-2, une désactivation de FileVault - semble un processus sans garantie absolue de validation. J'ai personnellement engagé la désactivation de la protection FileVault-2 que j'avais appliquée à mon volume-de-démarrage «Mavericks», et comme l'utilisateur peut très bien dans sa session ouverte vaquer à diverses tâches tandis que le déchifrement du volume s'opère en toile de fond, j'ai expérimenté les effets de l'attachement d'un DDE supportant des vidéos, avec lecture de l'une d'elle à l'écran de la session ouverte --> la conséquence ne se fait pas attendre : le délai affiché de déchiffrement croît indéfiniment et le processus se retrouve carrément planté par cette activité de l'utilisateur.

☞ Après désactivation de ces processus bloquants, bricolages divers et re-démarrages, je suis parvenu à relancer le déchiffrement du volume jusqu'à la désactivation complète de la protection FileVault-2 --> j'en ai gardé l'impression peu rassurante, que le processus de déchiffrement pourrait bien se retrouver bloqué au milieu du gué, comme on dit - et dans ce cas que le volume-de-démarrage concerné pourrait bien se retrouver 'neutralisé' par un protocole FileVault planté : ni désactivable jusqu'au bout, ni opérationnel au re-démarrage.

♧

J'espère que tu me pardonneras, bossdupad, l'étendue du topo précédent qui ne t'est directement d'aucune aide pratique. À le considérer comme un exposé de 'prémisses' logiques, j'en déduirais les 'conséquences' suivantes dans ton cas :

Le mot-de-passe utilisateur du compte lié au déchiffrement du volume-de-démarrage, que je suppose unique dans ton cas, normalement initie le déchiffrement du volume et l'ouverture enchaînée de la session de manière transparente pour l'usager. Ton problème est que ton mot-de-passe de session échoue à lancer la tâche de déchiffrement de la protection FileVault-2 --> se pourrait-il que le clavier logique de saisie (je ne sais pourquoi) ait été viré de l'AZERTY au QWERTY? Dans ce cas, il conviendrait que tu tentes (s'il n'y a pas de caractères accentués difficiles à y saisir) de taper ton mot-de-passe admin comme si tu utilisais un clavier Anglais.
Normalement, à la 1ère activation de la protection FileVault-2, une clé : filet de sécurité de 24 caractères par groupes de 4, de type : XXXX-XXXX-XXXX-XXXX-XXXX-XXXX t'a été imposée avec demande que tu la stockes quelque part au cas où tu en aurais besoin (éventuellement, sur les serveurs Apple). Est-ce le cas? Si tu l'as notée (sur papier par exemple) pour qu'elle soit recopiable, tu peux tenter de la saisir. Je ne sais pas comment cette manœuvre est opérable à l'écran de demande de mot-de-passe pour initier le déchiffrement du volume-de-démarrage : en substitution directe du mot-de-passe admin du compte? Ou après n (= '3'?) échecs de renseignement du mot-de-passe de session, y a-t-il un affichage proposant de passer par la clé : filet de sécurité? <éventualité : clavier AZERTY vs QWERTY de surcroît?>
Si tu démarres ton Mac les touches ⌘R tenues pressées, arrives-tu à te logguer dans la Recovery HD (je n'ai pas eu le réflexe de tester cette option sur mon Mac, m'étant contenté de 'alt' qui échouait à montrer le disque de la Recovery)? Si oui (Bureau simplifié avec fenêtre affichant 4 fonctionnalités), lance l'«Utilitaire de Disque» et demande la réparation du disque entier (à supposer que l'opération soit supportée).

☞ si les bricolages précédents échouent, d'après l'exposé des 'prémisses' que je t'ai infligé on_launch

--> j'ai peur que tu ne sois complètement bloqué sur ton volume-de-démarrage par un plantage de FileVault (causes : erreurs logiques affectant le Système initiées depuis ta session d'utilisateur? problèmes d'écritures à un SSD présentant des blocs défectueux? Autres?) et je ne vois pas alors ce qui pourrait te permettre de ré-entrer dans l'espace logique de ce volume (j'espère pour toi que tu as des sauvegardes de tes données...).

♡

pascalformac · 3 Juillet 2014

macomaniac a dit:
S (j'espère pour toi que tu as des sauvegardes de tes données...).

♡

une remarque de pré ~~launch~~ dej :siffle:

Et si c'est une sauvegarde Time machine , la sauvegarde même d'un mac avec filevault actif, elle n'est pas cryptée
(du moins en réglage par défaut , bien entendu on peut aussi crypter les sauvegardes)

bossdupad · 3 Juillet 2014

Merci une fois de plus pour cette réponse complete.

J'ai actuellement un disque dur externe avec Yosemite ( je suis dev officiel aussi, ça fait un peu con vu mon problème je sais

) donc j'ai pu récupérer un ordinateur qui se connecte à internet et je peux tester mes disque dur.

Je peux donc écarter les trois solution car le clavier AZERTY ou QWERTY ça ne change rien, de plus j'utilise mon clavier de macbook pour écrire ce message et toutes les touches fonctionne.

Pour ce qui est de la time machine, j'en ai une avec la plus part de mes données et j'ai bien le mot de passe du cryptage donc ça ça fonctionne encore, de plus mon disque de donnée qui lui aussi est crypté fonctionne toujours donc la perte de donnée reste limité au programme, favoris et autre brush photoshop ( bien que comme toujours dans ce genre de cas, je ne sais pas exactement ce qui trainait sur mon bureau juste avant le problème mais bon tant pis... )

Pour ce qui est de la clé de sécurité, justement c'est une grosse interrogation car je les ai toujours noté et impossible de la retrouver cette fois ci...

De plus, je n'ai jamais eu de partition recovery sur mon MacBook, je n'ai jamais compris pourquoi d'ailleurs, donc je peut écarter cette solution aussi.

Je vais essayer de retrouver cette clé et je vous tient au courant.

FrançoisMacG · 3 Juillet 2014

macomaniac

Des liens qui devraient t'intéresser :
http://support.apple.com/kb/PH14319?viewlocale=fr_FR
http://support.apple.com/kb/PH14319?viewlocale=fr_FR
http://support.apple.com/kb/HT5077?viewlocale=fr_FR

Et, par défaut, le clavier de saisie du mot de passe FileVault 2 est en qwerty.

bossdupad a dit:
je n'ai jamais eu de partition recovery sur mon MacBook, je n'ai jamais compris pourquoi d'ailleurs

Ce serait étonnant : FileVault 2 exige la présence d'une partition Recovery HD, même si elle est par défaut invisible et, sous FV2, ne peut être appelée que par Cmd+R.

bossdupad · 3 Juillet 2014

Merci pour les kbase, je les avais déjà lu

.

En fait de part mon boulot j'ai accès a toutes les ressources Apple mais même avec ça je sèche :/.

J'ai trouvé un screen d'une clé de secours mais quand je la rentre a la place du mot de passe cela ne fonctionne pas.

Je ne comprend pas trop où je dois la rentrer la clé de secours à vrai dire.

Membre supprimé 1060554 · 3 Juillet 2014

François.

Merci pour ces bonnes pistes de lecture [sans toi, je resterais dans l'illétrisme -informatique, s'entend - car je ne lis jamais de moi-même aucun texte de cette espèce] qui ont fait l'objet de toute mon attention - surtout la 3è à partir de laquelle, bien entendu, je n'ai pu m'empêcher, ayant rechiffré mon volume de départ Mavericks par l'activation de FileVault-2, d'expérimenter la manip proposée.

Effectivement, on peut démarrer sur la Recovery HD, mais uniquement à partir de la combinaison ⌘R (longuet avant que l'EFI trouve le boot.efi d'icelle --> doigts d'acier requis). J'avais copié sur une clé au préalable le /Library/Keychains/FileVaultMaster.keychain, fichier qui recèle en fait le mot-de-passe principal d'OSX (à condition qu'il ait été défini préalablement à partir du panneau des Utilisateurs et groupes des Préférences Système - sinon nib de fichier). Effectivement, la commande diskutil cs list permet d'accéder à la structure logique du volume CoreStorage qu'est devenu le volume Mavericks après chiffrement par FileVault-2 et notamment à l'UUID du volume logique de l'OS. Bref ça roule, mais cette manip ne peut pas intéresser bossdupad coucou: je ne t'oublie malgré ce conciliabule dans ton dos ), car
1. il n'est pas sûr qu'un mot-de-passe principal soit défini pour son OS ;
2. et de toute façon, il eût fallu délocaliser une copie du fichier FileVaultMaster.keychain[ généré par cette définition sur une clé attachable au Mac, parce que la commande de montage du volume logique CoreStorage chiffré de l'OS :
  Bloc de code:
```
diskutil cs unlockVolume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -recoveryKeychain /Volumes/nom_de_la_clé/FileVaultMaster.keychain
```
  nécessite le fichier supportant le mot-depasse principal - fichier dont bossdupad ne dispose pas manifestement ☞ fin de route, donc, pour utiliser la Recovery afin de monter le volume logique CoreStorage chiffré de l'OS.
♤
bossdupad (que je n'oubliais donc pas ).

Alors voici la procédure pour utiliser ta clé de sécurité FileVault que tu as retrouvée -->
1. Tu démarres ton Mac normalement et tu atteins un écran de login affichant les icônes et noms des utilisateurs bénéficiaires du privilège de pouvoir déchiffrer le volume logique CoreStorage de l'OS on_launch.
2. Tu cliques sur ton icône et un champ rectangulaire de saisie s'affiche en-dessous, vierge sur la gauche et arborant un ? à l'extrême droite --> sans aucunement saisir ton mot-de-passe dans le champ vide, tu cliques sur le ?
3. Un nouveau panneau s'affiche, énonçant l'indice du mot-de-passe de session (qui normalement suffit à lancer le déchiffrement du volume logique) en-dessus et en-dessous la proposition suivante :
  Bloc de code:
```
Si vous oubliez votre mot-de-passe...
...vous pouvez le ré-initialiser à l'aide de votre clé de secours
```
4. Tu choisis de continuer dans le sens de cette dernière option et un panneau te propose de saisir ta clé de secours FileVault-2 dans un champ de saisie où les caractères s'affichent (heureusement) en clair. Il s'agit d'une série de 6 groupes de 4 caractères séparés par des tirets qui s'inscrivent automatiquement au 4è caractère saisi de chaque groupe --> tu tapes donc ta clé du type :
  Bloc de code:
```
XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
```
5. Tu atteins un ultime panneau de proposant de ré-intialiser ton mot-de-passe --> je te conseille énergiquement de remettre ton mot-de-passe à l'identique --> tu as un champ vide de saisie, en-dessous un champ vide de confirmation, et en dernier lieu un champ vide d'indice du mot-de-passe --> tu rends donc une copie à l'identique de celle que tu as rendue lors de la création de ton compte-admin aborigène.
6. SI tout va bien --> tu te retrouves loggé directo dans ta session régulière d'utilisateur
♧

☞ tu vas vite être mis au pied du mur : SI ton volume logique chiffré CoreStorage est droit dans ses bottes, ça va marcher et mon conseil le plus urgent serait qu'après avoir sauvegardé tes données désormais en clair, tu engages la désactivation de la protection FileVault-2 qui est (à mon sens) une daube de 1er rang ; SI ton volume logique chiffré CoreStorage est foireux (pour toutes sortes de raisons déclencheuses), alors tu ne vas pas pouvoir de logguer dans ta session, parce que le volume échoue à être déchiffré et donc monté --> DEAD END.

☞ apostille : la clé de secours (filet de sécurité) FileVault-2 ne permet jamais qu'une ré-initialisation du mot-de-passe d'un des utilisateurs admin bénéficiaires du privilège de déchiffrer le volume logique chiffré CoreStorage. Elle ne sert donc jamais qu'à pallier l'oubli dudit mot-de-passe et n'a manifestement aucun autre privilège propre. En cas de blocage interne du volume logique chiffré CoreStorage, il ne faut s'attendre à aucune espèce de miracle par le truchement de cette clé.

bossdupad · 3 Juillet 2014

Apres vérification je viens de tester CMD + R au démarrage et je n'ai pas de partition de récupération qui s'affiche...

Par ailleurs, le point d'interrogation n'est pas affiché sans que je tape mon mot de passe et si je le tape et que je clic dessus il ne se passe rien...

Franchement je n'y comprend plus rien.

J'ai une partition recovery 10.10 sur mon disque dur que j'utilise pour Yosemite en boot externe, je peux peut être l'utiliser pour accéder au recovery de mon SSD sous Mavericks?

Membre supprimé 1060554 · 4 Juillet 2014

bossdupad a dit:
Apres vérification je viens de tester CMD + R au démarrage et je n'ai pas de partition de récupération qui s'affiche...

☞ il faut attendre quasiment une minute (sur un Mac équipé d'un SSD), les touches ⌘R pressées continûment au démarrage, pour que l'écran gris uni résultant cède la place à un où s'affiche le logo , signe que l'EFI a chargé le fichier Boot_Loader de la partition de récupération «Recovery HD». À partir de là, lentement mais automatiquement, les chargements logiciels s'enchaînent jusqu'à ouverture de la session de récupération. Si rien de tel ne s'opère sur ton Mac, c'est qu'effectivement ton disque interne est dépourvu de partition de récupération.

De toute façon inutile d'épiloguer sur la question, pour utiliser le démarrage sur la Recovery HD et son «Terminal» afin de monter le volume logique chiffré CoreStorage de l'OS, encore faudrait-il que par avance tu aies défini (dans le panneau des Préférences Système/Utilisateurs et groupes) un mot-de-passe principal générateur d'un fichier FileVaultMaster.keychain (at : Bibliothèque/Keychains) et que tu aies sauvegardé une copie de ce fichier en-dehors du volume chiffré de ton OS, sur un disque externe attachable au Mac comme une clé USB - ce que manifestement tu n'as pas fait. Faute de disposer de ce fichier sur un disque attachable au Mac en mode externe, et adressable à cette localisation depuis le «Terminal» de la session de récupération, tu ne peux rien faire pour monter le volume logique CoreStorage de l'OS chiffré par FileVault-2 en démarrant sur la Recovery.

bossdupad a dit:
Par ailleurs, le point d'interrogation n'est pas affiché sans que je tape mon mot de passe et si je le tape et que je clic dessus il ne se passe rien...

☞ Je t'ai décrit ce que j'ai expérimenté sur mon Mac une fois le volume de l'OS re-chiffré par FileVault-2 : lorsque tu atteins au démarrage l'écran de login, le champ rectangulaire vide de saisie du mot-de-passe d'utilisateur admin associé au privilège de pouvoir dé-verrouiller la protection FileVault-2 s'orne à l'extrême droite d'un minuscule ? gris qui est loin de sauter aux yeux : cliquer sur ce logo démasque un panneau à partir duquel la clé de sécurité FileVault-2 peut-être utilisée pour ré-intialiser le mot-de-passe admin qui a le privilège de pouvoir initier le déchiffrement du volume de l'OS. Si tu ne vois rien, tu peux toujours essayer - une fois/deuxfois/trois fois - de saisir un mot-de-passe bidon et de presser la touche 'Entrée' du clavier chaque fois pour activer ta saisie, normalement à la 3è erreur le panneau d'affichage de l'indice du mot-de-passe apparaît à l'écran. Normalement encore, en cas de disque chiffré par FileVault-2, ledit panneau devrait te proposer en option subalterne de ré-initialiser ton mot-de-passe admin grâce à la clé de sécurité à 24 caractères.

Ça ne m'étonnerait nullement, si la saisie adéquate de ton mot-de-passe admin s'avère incapable d'engager le déchiffrement du volume logique CoreStorage de l'OS, que l'option de passer par la clé de sécurité pour ré-intialiser ce mot-de-passe manque à s'afficher : l'échec du mot-de-passe et l'absence d'option de ré-intialisation consitueraient un 'bloc' --> le symptôme graphique que ton volume chiffré CoreStorage est corrompu et qu'il n'y a plus rien à faire pour le monter.

[Tel que je me représente la procédure normale : tu tapes un mot-de-passe admin valide --> le protocole FileVault-2 recolle les 'bandes' logiques séparées constituant l'état discret du disque chiffré en 'un seul tenant' et réalise l'attachement du disque reconstitué au Mac --> l'information est passée au kernel qui valide cet attachement et monte le disque sous forme de volume --> la session graphique est accessible. Apparemment, chez toi, il y a impossibilité de lancer le processus de 'recollage' des bandes logiques discrètes, un peu comme si le disque logique de l'OS était 'pulvérisé' en un puzzle de petits morceaux sans que soit disponible une méthode de ré-agrégation.]

bossdupad · 4 Juillet 2014

Ok, je pense que je vais arrêter la, visiblement le SSD doit présenter une défaillance, c'est ce que je me dit depuis le départ de toute façons... J'espère que iCloud a sauvegardée l'intégralité de mon trousseau mais je vais vite le savoir.

Par contre je ne pense pas que je puise réinstaller OS X sur le SSD du coup comme celui ci reste bloqué?

Avant de mettre à nouveau 100 euros dans un SSD, j'aurais bien tenté de réinstaller sur mon SSD actuel.

paranormal-wizzzard · 4 Juillet 2014

J'ai protégé une carte SD avec filevaut et parfois, je dois entrer 10 fois le mot de passe avant qu'elle daigne s'ouvrir...

Membre supprimé 1060554 · 5 Juillet 2014

paranormal-wizzzard a dit:
J'ai protégé une carte SD avec filevaut et parfois, je dois entrer 10 fois le mot de passe avant qu'elle daigne s'ouvrir...

☝︎

♤

bossdupad a dit:
...visiblement le SSD doit présenter une défaillance, c'est ce que je me dit depuis le départ de toute façons...

Je pense comme toi que ton volume chiffré par FileVault-2 est irrécupérable.

♧

bossdupad a dit:
Par contre je ne pense pas que je puise réinstaller OS X sur le SSD du coup comme celui ci reste bloqué?

Avant de mettre à nouveau 100 euros dans un SSD, j'aurais bien tenté de réinstaller sur mon SSD actuel.

☞ la protection FileVault-2 n'empêche pas de placer le Mac en position 'Target' (touche T pressée au démarrage jusqu'à apparition du logo : FireWire vs Thunderbolt à l'écran) --> connecter le Mac à un autre, soit par un cordon FireWire, soit par un Thunderbolt, ne permet certes pas de monter l'image-disque du volume chiffré sur le Bureau du Mac d'accueil si le protocole de déchiffrement est planté (sinon : possible par renseignement du mot-de-passe autorisé), mais l'«Utilitaire de Disque» du Mac d'accueil 'voit' le disque physique (ton SSD) ainsi que le volume logique non monté, et permet l'effacement ou le re-partitionnement [je présume que placer le SSD démonté dans un boîtier connecté par USB à un Mac d'accueil produit le même résultat].
☞ si tu démarres le Mac par contre, avec un disque externe attaché comportant un Système démarrable, et que tu bootes sur ce disque externe (clé USB embarquant un installateur de «Mavericks» ou clone d'OSX), l'«Utilitaire de Disque» ne permet pas d'atteindre le disque physique du Mac (SSD), mais il est possible de sélectionner (volume subalterne en alinéa) le Volume Logique Chiffré et de demander son effacement, opération qui, dans un second temps, permet de retrouver l'accès au disque physique du Mac.
☞ il en va de même pour quelqu'un qui démarre sur la partition de récupération Recovery HD (par ⌘R exclusivement) --> l'«Utilitaire de Disque» ne permet pas plus d'atteindre le disque physique du Mac (SSD), mais il est possible de sélectionner encore (volume subalterne en alinéa) le Volume Logique Chiffré même non monté et de demander son effacement, opération qui, dans un second temps, permet de retrouver l'accès au disque physique du Mac.

☞ Pour l'amateur de la ligne de commande, il est possible dans tous les cas de figures précédents de passer par le «Terminal» disponible.

Dans la fenêtre qui s'affiche, commencer par saisir la commande :

Bloc de code:

diskutil cs list

et ↩︎ (presser la touche 'Entrée' du clavier pour activer la commande) --> celle-ci va afficher en réponse la structure du dispositif CoreStorage trouvé qui sera celui correspondant au SSD du Mac du type :

Bloc de code:

Logical Volume Group [COLOR="RoyalBlue"]XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX[/COLOR]
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         xxx GB
    Free Space:   0 B
    |
    +-< Physical Volume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     xxx GB
    |
    +-> Logical Volume Family XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
        ----------------------------------------------------------
        Encryption Status:       Unlocked
        Encryption Type:         AES-XTS
        Conversion Status:       Complete
        Conversion Direction:    -none-
        Has Encrypted Extents:   Yes
        Fully Secure:            Yes
        Passphrase Required:     Yes
        |
        +-> Logical Volume XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
            ---------------------------------------------------
            Disk:                  disk1
            Status:                Online
            Size (Total):          xxx GB
            Conversion Progress:   -none-
            Revertible:            No
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS

Repérer le 1er UUID --> celui qui correspond à la structure holistique = le Logical Volume Group (LVG : Groupe de Volumes Logiques) que j'ai marqué en bleu.
Passer alors la commande spécifique de destruction de la structure holistique CoreStorage -->
Bloc de code:
```
diskutil coreStorage deleteLVG [COLOR="RoyalBlue"]XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX[/COLOR]
```
et ↩︎ --> attendre jusqu'au réaffichage de l'invite de commande que le processus se soit complété --> il y a récupération du Schéma de partition GUID originel.

♡

À sujet abscons, apostille absconse

--> L'activation de la protection FileVault-2 (à la différence de FileVault-1 qui créait un disque virtuel .sparsebundle local) génère une entité logique absconse intellectuellement parlant : une structure CoreStorage à l'emplacement de la partition /dev/disk0s2 de la Table de partition GUID du disque physique. Une structure CoreStorage est un Groupe de Volumes Logiques (LVG) incluant la partition EFI de la Table de partition GUID originelle, une Carte_d'Amorçage Boot OS X, un Disque_Physique_Virtuel (PV) et enfin un Volume_Logique (LV), lequel comporte 2 états alternatifs : non_monté (où le Volume est à l'état 'désagrégé' en bandes logiques sous l'effet du chiffrement) et monté (où le Volume est à l'état 'recomposé' en un ensemble logique sous l'effet du déchiffrement).

Le problème est que cette absconse structure, une fois mise en place, remplace littéralement le schéma de partition GUID initial du disque interne, par conversion de la partition initiale /dev/disk0s2 dans le LVG (Groupe de Volumes Logiques). Si bien qu'au démarrage (et avant tout déchiffrement éventuel du volume logique chiffré), le disque physique interne (le SSD = disk0) disparaît sous la représentation du LVG (Groupe de Volumes Logiques) qui génère on_boot un Disque Physique Virtuel (PV) en tant que support d'un Volume Logique (LV).

Démarrer le Mac, même sur un Système résidant sur un Disque Externe, fait activer la structure CoreStorage par le kernel et par là rend le disque physique interne inaccessible, car il est intercepté par la représentation entée sur lui du Groupe de Volumes Logiques : LVG qui en 'écrase' la présence sous la 'couche' du Disque Virtuel : PV support d'un Volume Logique : LV. Seule la position 'Target' (ou l'attachement du disque démonté par boîtier), en supprimant le démarrage, rend le disque physique adressable directement. Sinon, le Mac démarré, en cas de plantage de FileVault-2, il faut commencer par détruire la structure logique CoreStorage afin de récupérer l'accès direct au disque physique que sa représentation intercepte. Soit par effacement du Volume Logique Chiffré - même non monté - que permet l'«Utilitaire de Disque», soit par destruction du Groupe de Volumes Logique holistique que permet le «Terminal».

♢

[J'ai testé la faisabilité de toutes mes options précédentes, sans néanmoins pousser l'abnégation jusqu'à effacer (pour ensuite le rétro-cloner) le volume de mon SSD que j'avais une 3è fois re-chiffré par FileVault-2. J'ai juste vérifié dans chaque cas que la commande d'effacement ou de re-partitionnement dans l'«Utilitaire de Disque» était active (selon démarrage du Mac vs position 'Target') et j'ai vérifié la rectitude de la commande du «Terminal» sur la structure CoreStorage d'une clé USB chiffrée.]

☞ si la raison du plantage de FileVault-2 est une défaillance du SSD, la fiabilité de ce dernier pour supporter un OS sans chiffrement du volume de démarrage est sujette à caution

--> une excellente raison de pratiquer quotidiennement des sauvegardes (par clone vs &#8482

...

♖

pascalformac · 5 Juillet 2014

macomaniac a dit:
J'ai testé la faisabilité de toutes mes options précédentes,

ton sérieux habituel
:coucou:

sans néanmoins pousser l'abnégation jusqu'à effacer (pour ensuite le rétro-cloner) le volume de mon SSD que j'avais une 3è fois re-chiffré par FileVault-2.

oh?
Alors là je suis déçu.

En passant , je comprends parfaitement la limite à ton abnégation
j'aurai eu exactement la même.
Aider c'est génereux , mais risquer des couacs avec matosse perso à seules fins de test de certaines hypothèses c'est autre chose
(surtout avec filevault!)

Powerdom · 6 Juillet 2014

je pense qu'on va finir par une rubrique spéciale et regrouper : "les dépannages de tonton macomaniac"

contisplaya · 1 Octobre 2014

Je viens de me taper une belle sueur froide car mon mot de passe ne marchait plus au redémarrage du mac après avoir activé file vault. Et impossible d'accéder à mon mac et tout mon boulot pour demain. En plus j'avais bêtement stocké la clef de sécurité dans un ficher texte (lui même protégé par un mot de passe) par flemme de le recopier à la main.

En fait le clavier (qu'elle connerie by the way)

est bien en querty une fois qu'on redémarre après avoir activé filevault et mon mot de passe contient des accents et autres caractères super chiants à retrouver en qwerty...

Bref coincé devant l'écran du mot de passe j'ai eu l'idée de taper cmd+espace qui sous le finder permet de permuter d'un clavier à l'autre et la miracle ! un petit clavier apparait en haut à droite de l'écran et je peux choisir le clavier français dans la liste. Après j'ai tapé mon mot de passe et OUF! ça a marché

De retour dans le Finder et aux vu de la lecture de certains posts ici j'ai désactivé file vault. Je vais m'en passer je crois....

Deleted member 340362 · 1 Octobre 2014

Macomaniac, comme beaucoup ici, j'apprécie ta prose.
Certains points me font sourire. Tout d'abord tu parles de "vintage" à propos d'un Mac 2008 alors qu'ils peuvent en général adopter le système le plus récent. Ensuite, tu indiques que Filevault1 t'inspire peu de confiance, mais ensuite tu cites firevault2 comme "encore pire".

Concernant ce type d'outils, je préconiserais beaucoup plus de précautions qu'Apple en demande, c'est à dire une sauvegarde complète du système sur un disque non chiffré conservé dans un endroit sûr (au travail, caché chez soi...)

Powerdom · 2 Octobre 2014

Deleted member 340362 a dit:
une sauvegarde complète du système sur un disque non chiffré conservé dans un endroit sûr (au travail, caché chez soi...)

Le souci avec un disque que l'on cache au travail ou trop bien caché chez soi, c'est que l'on ne sauvegarde plus...
du genre : Oh flute je l'ai encore oublié au bureau, Je monterais au grenier demain pour sauvegarder...

Laurent S from Nancy · 4 Octobre 2014

Question qui peut sembler idiote, mais quand on possède deux disques dur dans son Imac, l'un utilisé par le système et les applis et les autres contenant les données, le second disque n'est pas du tout chiffré c'est bien ça ?

Mot de passe filevault non reconnu

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre supprimé 1060554

Invité

Membre vénérable

Membre actif

Pince-fourmis

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre supprimé 1060554

Invité

Membre actif

Membre expert

Membre supprimé 1060554

Invité

Membre vénérable

modérateur stagiaire

Membre actif

Deleted member 340362

Invité

modérateur stagiaire

Membre actif

Sujets similaires