Fais confiance à Macomaniac, il va sûrement passer par ici
☝︎
--> je subodore que le nommé (que dis-je? l'
interpelé :
cet Inter : Pelé à qui on refile la balle sur un terrain d'attaque difficile)
macomaniac va être la peine ici pour marquer le but décisif...
Dans le fil que tu as cité,
Sly , l'auteur :
jfkm ne se plaignait pas d'un problème de blocage de l'ouverture de session sous «
Yosemite», mais de l'absence de la «
Recovery HD» à l'affiche de l'écran des disques démarrables obtenu en démarrant avec la touche 'alt' pressée. Cette disparition du disque de la «
Recovery HD» à l'écran d'affichage des disques démarrables est un
effet_collatéral de l'établissement d'un
Format : CoreStorage sur la partition
/dev/disk0s2 du disque interne où est installé l'OS.
L'établissement de ce
Format : CoreStorage n'était en rien imputable à
jfkm - c'est l'installateur de «
Yosemite 10.10» qui inclut l'instruction de virer au préalable la partition de destination au
Format : CoreStorage, avant mise-à-niveau de l'OS pré-existant à cet emplacement. Cette
conversion de format automatique '
fait de l'ombre' (si tu me passes la métaphore) au volume adjacent de la «
Recovery HD» installé sur la partition connexe
/dev/disk0s3 en l'empêchant d'apparaître comme volume de
boot disponible à l'écran des disques de démarrage obtenu par 'alt' --> il n'est possible, alors, d'accéder à la session de la «
Recovery HD» que par un démarrage direct avec ⌘R.
Pour la suite de cette 'petite histoire', il semble bien que la commande de
Bénédiction (
blessing) passée par
jfkm dans le «
Terminal» ait alors fixé une préférence de démarrage sur le fichier
Boot_Loader : boot.efi de cette «
Recovery HD», de sorte que l'
EFI au démarrage exécutait automatiquement ce fichier, ce qui lançait l'ouverture de la session de récupération seule. Je présume, vu l'absence de nouvelles ultérieures de la part de
jfkm, que la commande rectificatrice dans le «
Terminal» fixant la préférence de
boot sur le fichier
boot.efi de «
Yosemite» aura rétabli pour lui la situation, en lui permettant un démarrage automatique sur l'OS.
[NB. Le fichier boot.efi est le démarreur d'un Système bootable sous Intel. Chaque Système bootable (OSX, Recovery HD) a son boot.efi de démarrage. Il incombe au Programme Interne de la Carte-Mère du Mac (EFI) d'exécuter tel ou tel Boot_Loader au démarrage, suite à quoi ledit boot.efi charge le kernelcache associé. Ce qui permet à l'EFI au démarrage de détecter l'existence d'un ou plusieurs boot.efi exécutable(s), alors même que ce fichier est noyé dans l'arborescence logique de son Système d'appartenance (pour OSX, rien moins que : /Volumes/Macintosh\ HD/System/Library/CoreServices !), c'est le blessing du dossier d'inhérence du Boot_Loader : cette 'bénédiction' fixe sur l'en-tête (header) du filesystem concerné l'équivalent d'un lien symbolique au fichier démarreur, qui le rend détectable au scan de l'EFI. En l'absence de blessing, l'EFI est incapable de détecter l'existence d'un boot.efi dans l'arborence du filesystem.]
Pour ce qui est du récent billettiste :
olivbtz qui s'est immiscé dans ce fil, il semble avoir réagi à la péripétie de
jfkm qui démarrait automatiquement sur la «
Recovery HD», et non à son problème originel qui consistait dans le fait que le volume de la partition de récupération ne s'affichait pas à l'écran des disques de démarrage obtenu avec 'alt'. Le problème de ce dernier intervenant relève-t-il simplement d'une procédure de
blessing du fichier
Boot_Loader de l'OS, ou dérive-t-il d'un plantage de son Système? Aucune idée pour l'heure...
♤
Bon : après ce festival en solo balle au pied
, il serait peut-être temps de s'occuper d'
Oakley...
Je pense malheureusement que l'hypothèse de
Sly -->
Disque crypté : tu as Filevault activé ? :eek:
doit être la bonne.
Non seulement l'installateur de «
Yosemite» est responsable d'une prolifération du
Format : CoreStorage sur les partitions-Système où cet OS s'est mis-à-niveau, mais il est responsable d'avoir proposé le chiffrement «
FileVault-2» qui a conduit de nombreux utilisateurs à obtempérer - et je conjecture qu'
Oakley fait partie du lot.
Le chiffrement «
FileVault-2» crypte le
Volume entier de l'OS à partir de «
Lion 10.7» et, pour ce faire, il commence par
convertir la partition support (
/dev/disk0s2 par défaut) au
Format : CoreStorage. Ce format consiste à enter une structure :
Groupes de Volumes Logiques sur la partition d'accueil --> à savoir, greffon d'un
Disque Physique Virtuel sur la partition
/dev/disk0s2 qui a l'inconvénient de dérober le disque physique réel à la représentation et l'adressage. Sur la base de ce
Disque Physique Virtuel seul, monte un
Volume Logique, et c'est dans ce
Volume Logique que l'OS est installé. Lorsque «
FileVault-2» est activé, il y a de surcroît
chiffrement du
Volume Logique : CoreStorage, càd. découpage en 'bandes' discrètes, dispersées à l'extinction du Mac, et dont le ré-ordonnancement au démarrage n'est déclenchable que par une
clé de déchiffrement, laquelle est normalement couplée avec tous les mot-de-passe d'utilisateurs détenant un compte régulier (
admin ou
standard) dans l'OS. De plus, une
clé de secours, constituée par une suite de caractères
alpha-numériques, est définie à la fin du protocole inaugural de chiffrement, et l'utilisateur initiataire du chiffrement est prié de la noter quelque part, afin de pouvoir déclencher grâce à ce 'passe-partout' le ré-ordonnancement des 'bandes' du volume au démarrage en cas d'oubli du mot-de-passe d'utilisateur.
L'inconvénient drastique du
Format CoreStorage Chiffré : «
FileVault-2» est qu'il proscrit un démarrage inaugural en mode
externe sur la «
Recovery HD», soit en direct par ⌘R, soit indirectement par 'alt' (ici parce que le simple
Format : CoreStorage occulte par défaut l'affichage du volume de la récupération). Mais «
FileVault-2» proscrit aussi le démarrage en
Single User (session dans le
shell de
root : -bash-3.2#), comme il proscrit le démarrage en mode
Target. Tout cela est logique : le volume de l'OS étant
chiffré, il est inadressable en mode externe, avant que son ré-ordonnancement en un tout n'ait été exécuté.
[NB. Un esprit incisif se demanderait, ici, dès lors que le fichier démarreur du volume de l'OS chiffré par «FileVault-2» est inadressable par l'EFI au démarrage - parce que contenu dans une arborescence qui n'existe, on boot, que disséminée en 'bandes' discrètes inexploitables : celle du volume d'inhérence - comment un tel Système peut bien démarrer? --> on touche là du doigt la raison pour laquelle le chiffrement «FileVault-2» ne peut s'instaurer que sur un disque où existe co-latéralement une «Recovery HD». Pourquoi? Car ce volume de la «Recovery HD» possède, lui, un démarreur non chiffré : son propre boot.efi, et c'est lui que va exécuter l'EFI au démarrage, avec cette singularité que ce fichier Boot_Loader, dès lors que «FileVault-2» est activé, possède l'argument de boot d'initier le déchiffrement du volume de l'OS en requérant le mot-de-passe ad-hoc, ce avant de charger le kernelcache de l'OS (limpide, non? - Les Américains sont foutrement tordus, quand on examine leurs productions idiosyncrasiques...).
NB-2. Le fait pour Oakley, dans la conjecture d'un Volume Logique Chiffré par «FileVault-2», d'accéder à l'écran de renseignement du mot-de-passe d'utilisateur censé initier le déchiffrement, est la preuve de l'existence d'une «Recovery HD» sur la partition /dev/disk0s3 de son disque, parce que son Boot_Loader : boot.efi de cette dernière est absolument requis pour que l'EFI puisse lancer le démarrage - ce qui est le cas. Que cette «Recovery HD», à l'instar de la «Divinité» chez Flaubert, soit «présente partout et visible nulle part», c'est logique aussi en accord avec la conjecture de «FileVault-2» activé : existence requise de la «Recovery HD» pour le démarrage, mais inacessibilité de la même avant le déchiffrement du volume de l'OS.]
Le mécanisme de ré-ordonnancement des 'bandes' discrètes du volume chiffré par «
FileVault-2» étant toujours sujet à grippage, suite à des erreurs logiques intervenues pendant le fonctionnement de l'OS déchiffré, dans ces cas de figure, à ma connaissance - il n'y a strictement rien à faire. J'ai peur qu'
Oakley soit dans ce cas de figure (et j'espère me tromper) :
Volume_Logique de l'OS chiffré par «
FileVault-2», impossibilité de démarrer en mode externe (
Recovery HD / Single User/ Target) et plantage du protocole de déchiffrement à l'initiative du mot-de-passe d'utilisateur
admin (et présumablement de la
clé de secours si elle venait à avoir été notée).
♧
☞ Comme il doit être frustrant pour
Oakley de contempler l'
Inter Pelé, appelé en principe en renfort, avoir tout l'air de marquer contre son camp
, je lui donne l'occasion de descendre sur le terrain pour tacler ce fantasque joueur et récupérer le ballon de la victoire --> il suffit de démarrer le Mac la combinaison de touches
⌘S tenues pressées : est-ce que la session du
Single User s'ouvre (tableau noir du «
Terminal» de
root en personne)? - Si oui, l'
Inter Pelé se retrouve le nez dans le gazon et
Oakley a une chance de marquer le but salvateur ; si non...
♡
