Pas de Recovery HD Yosemite

Ce que je tenterai en Recovery :
Bloc de code:
diskutil cs revert 96CE02B1-AA7C-40F5-B800-607F67783B3A

Cela supprimerait le CoreStorage.

Tu pourrais ensuite retenter la commande :
Bloc de code:
bless  --folder  /Volumes/"Macintosh HD"/System/Library/CoreServices   --setBoot

Si ça ne fonctionne pas il faudra tenter une réinstall via internet toujours en mode Recovery. Assez long, mais tes données et tes programmes ne sont pas touchés.

Bon courage

EDIT : Avant tout si tu appuis sur alt lors du boot as-tu le choix du disque de boot et vois-tu Macintosh HD?
 
Dernière édition par un modérateur:
Ce que je tenterai en Recovery :
Bloc de code:
diskutil cs revert 96CE02B1-AA7C-40F5-B800-607F67783B3A

Cela supprimerait le CoreStorage.

Tu pourrais ensuite retenter la commande :
Bloc de code:
bless  --folder  /Volumes/"Macintosh HD"/System/Library/CoreServices   --setBoot

Si ça ne fonctionne pas il faudra tenter une réinstall via internet toujours en mode Recovery. Assez long, mais tes données et tes programmes ne sont pas touchés.

Bon courage
Merci pour ton retour, j'ai déjà relancé l'install (je ne suis pas chez moi et j'ai 4h de route... je peux pas me tirer sans que le mac re-fonctionne !) juste pour confirmer du coup : La recovery HD n'apparait pas mais elle est bien présente sur le Mac, il suffira alors à l'utilisateur de démarrer en CMD+R pour y accéder en temps normal.
C'est bien ça ?
 
Je vois que FreeeeZ avait (vox clamans in deserto) appelé macomaniac à la rescousse hier soir et que Jean
359510_original.gif
a suppléé l'absence de ce facétieux farfelu avec son expertise coutumière :merci: Je fais donc une apparition dans ce fil dans cette position d'épigone que j'affectionne pour sa gratuité - pour ne pas dire son inutilité
361608_original.png


En survolant a posteriori le tableau, je vois que : un format CoreStorage non chiffré est greffé sur la partition /dev/disk0s2 de l'OS (œuvre de l'installateur de «Yosemite» opérée à l'insu de l'utilisateur). Ce format empêche régulièrement l'affichage du volume de la «Recovery HD» à l'écran de choix du disque de démarrage obtenu par l'option "alt" au départ. Étant réversible, la commande indiquée par Jean :
Bloc de code:
diskutil coreStorage revert 96CE02B1-AA7C-40F5-B800-607F67783B3A
passée depuis le «Terminal» de la «Recovery HD» peut suffire à le supprimer sans mise à mal du système de fichiers supporté par le volume.

Cela constaté, un format
CoreStorage en soi ne constitue aucun facteur de blocage du démarrage sur le volume de l'OS ; Il n'est aucunement responsable du non-affichage de ce volume à l'écran de choix du disque de démarrage obtenu par l'option "alt" (mais seulement, comme dit ci-dessus, du non-affichage du volume de la «Recovery HD» à cet écran).

Ce qui permet l'affichage d'un volume (Mac) à l'écran de choix du disque de démarrage obtenu par l'option "alt", c'est la capacité pour le
Programme Interne du Mac (l'EFI de la carte-mère), sollicité par la touche "alt" à opérer un scan préalable des volumes montés, de discriminer les volumes supportant un fichier "démarreur" d'OSX (un boot_loader : boot.efi) --> les volumes et seulement les volumes contenant un tel fichier (en ce qui concerne les volumes de type "Mac") seront affichés à l'écran susdit en tant que "disques démarrables".

Mais pour que l'EFI puisse "apercevoir" lors du scan à la volée des volumes disponibles les fichiers
boot.efi alors qu'ils sont, sur le volume d'un OSX, régulèrement enfouis dans l'arborescence du Système et donc par là rendus non immédiatement détectables, il faut que l'en-tête (header) du filesystem en question soit béni ("blessed"), càd. porte l'inscription du chemin au répertoire d'inhérence du boot_loader : /System/Library/CoreServices de manière à ce que l'EFI puisse automatiquement suivre ce chemin pour aller scanner le contenu du dossier CoreServices, y détecter l'existence d'un boot.efi et par suite afficher le volume conteneur comme "disque démarrable".

C'est là tout le sens de la commande :
Bloc de code:
bless --folder /Volumes/"Macintosh HD"/System/Library/CoreServices --setBoot
qui dans son option initiale
--folder opère la bénédiction du système de fichiers du volume de l'OS (l'option finale --setBoot en rajoute une couche, en manipulant de surcroît un argument de boot en NVRAM pour forcer le démarrage automatique sur le volume concerné). Le fait qu'en dernier essai l'invite de commande -bash-3.2# se soit immédiatement réaffichée est le signe que la commande a bien été passée.

Le fait qu'aucun re-démarrage automatique sur le volume de l'OS ne s'ensuive paraît alors une énigme. De même que l'absence persistante du volume de l'OS à l'écran de choix du disque de démarrage obtenu par l'option "alt". De même que le non-effet, depuis le menu Disque de Démarrage de la «Recovery HD», de la sélection du volume de l'OS.


Le retour de commande à un moment donné :
Bloc de code:
--folder /Volumes/"Macintosh HD"/System/Library/CoreServices --setBoot
No mount point for /Volumes/"Macintosh HD"/System/Library/CoreServices
Can't determine mount point of ' /Volumes/"Macintosh HD"/System/Library/CoreServices' and ' '
ne peut pas vouloir dire que le programme bless n'aurait pas été invoqué (car il y aurait eu : command not found --> il ne s'agissait que d'un lapsus de retranscription). Mais bien plutôt que le point de montage / du filesystem de ce volume n'était pas identifiable à l'instant de la commande. Dont une réédition paraît être passée. Sans pour autant que le volume soit davantage repérable ni démarrable. Alors que la commande diskutil list trouve quand même à le lister...

Je trouve bizarre que ce volume joue ainsi le yo-yo... Signe d'un disque au bord de la défaillance physique? Signe d'un Système de fichiers endommagé (absence de fichier démarreur
boot.efi éventuellement)? Nul doute que la ré-installation radicale de l'OS que FreeeeZ paraît avoir engagée était la bonne décision, car tout semble témoigner d'un problème d'accès aux écritures de l'OS. Sans pourtant qu'il n'y ait de constat d'I/O error. J'avoue que je suis déconcerté par cet "entre-deux" (on verra bien si le démarrage s'effectue)...
 
Dernière édition par un modérateur:
Merci BEAUCOUP MacoManiac pour cette synthèse qui, je l'espère, saura sauver d'autres utilisateurs dans le même cas.

Pour la petite histoire le Mac en question est un MBP 15" i7 2,2Ghz, 4Go RAM, 500Go DD.
Au moment de ma prise en main sous Lion 10.7.2 avec des temps de latence qui me semble interminables (le fait que je soit sur un 15" Retina, n'aide surement pas...)
je nettoie, optimise (CleanmyMac2, Onyx... et à la main...) tout ce que je peux avant d'upgrader le tout sous 10.10 via l'AppStore. C'est au lendemain, (et comme tu le mentionne très justement Macomac) en démarrant sur alt que je constate une seule partition visible ; je trouve alors ce forum et les lignes de Terminal au dessus qui une fois rentrées me provoque l'inverse : je ne voit plus que la Recovery.
Il est encore tôt, et je prend ca pour une mauvaise manip de ma part, je re-install direct "au moins le système sera comme neuf, je me dis, et mieux nettoyé qu'un upgrade de 3 versions d'OS".

Mais à la seconde fois, même constat : aucune Recovery visible - entrée de lignes de commande, même effet !

Bizarre, est-ce un tour des Dev Apple sur 10.10.2 ?
Je me suis posé la question...
...We are Hanging Here...

Merci à tous les 2 Jean & MacoManiac pour votre aide réactive !
Ci-dessous un recap' efficace de Macomaniac sur le sujet mentionné dans ce Forum ci-dessus :

En survolant a posteriori le tableau, je vois que : un format CoreStorage non chiffré est greffé sur la partition /dev/disk0s2 de l'OS (œuvre de l'installateur de «Yosemite» opérée à l'insu de l'utilisateur). Ce format empêche régulièrement l'affichage du volume de la «Recovery HD» à l'écran de choix du disque de démarrage obtenu par l'option "alt" au départ. Étant réversible, la commande indiquée par Jean :
Bloc de code:
diskutil coreStorage revert 96CE02B1-AA7C-40F5-B800-607F67783B3A
passée depuis le «Terminal» de la «Recovery HD» peut suffire à le supprimer sans mise à mal du système de fichiers supporté par le volume.

Cela constaté, un format
CoreStorage en soi ne constitue aucun facteur de blocage du démarrage sur le volume de l'OS ; Il n'est aucunement responsable du non-affichage de ce volume à l'écran de choix du disque de démarrage obtenu par l'option "alt" (mais seulement, comme dit ci-dessus, du non-affichage du volume de la «Recovery HD» à cet écran).

Ce qui permet l'affichage d'un volume (Mac) à l'écran de choix du disque de démarrage obtenu par l'option "alt", c'est la capacité pour le
Programme Interne du Mac (l'EFI de la carte-mère), sollicité par la touche "alt" à opérer un scan préalable des volumes montés, de discriminer les volumes supportant un fichier "démarreur" d'OSX (un boot_loader : boot.efi) --> les volumes et seulement les volumes contenant un tel fichier (en ce qui concerne les volumes de type "Mac") seront affichés à l'écran susdit en tant que "disques démarrables".

Mais pour que l'EFI puisse "apercevoir" lors du scan à la volée des volumes disponibles les fichiers
boot.efi alors qu'ils sont, sur le volume d'un OSX, régulèrement enfouis dans l'arborescence du Système et donc par là rendus non immédiatement détectables, il faut que l'en-tête (header) du filesystem en question soit béni ("blessed"), càd. porte l'inscription du chemin au répertoire d'inhérence du boot_loader : /System/Library/CoreServices de manière à ce que l'EFI puisse automatiquement suivre ce chemin pour aller scanner le contenu du dossier CoreServices, y détecter l'existence d'un boot.efi et par suite afficher le volume conteneur comme "disque démarrable".

C'est là tout le sens de la commande :
Bloc de code:
bless --folder /Volumes/"Macintosh HD"/System/Library/CoreServices --setBoot
qui dans son option initiale
--folder opère la bénédiction du système de fichiers du volume de l'OS (l'option finale --setBoot en rajoute une couche, en manipulant de surcroît un argument de boot en NVRAM pour forcer le démarrage automatique sur le volume concerné). Le fait qu'en dernier essai l'invite de commande -bash-3.2# se soit immédiatement réaffichée est le signe que la commande a bien été passée.

Le fait qu'aucun re-démarrage automatique sur le volume de l'OS ne s'ensuive paraît alors une énigme. De même que l'absence persistante du volume de l'OS à l'écran de choix du disque de démarrage obtenu par l'option "alt". De même que le non-effet, depuis le menu Disque de Démarrage de la «Recovery HD», de la sélection du volume de l'OS.


Le retour de commande à un moment donné :
Bloc de code:
--folder /Volumes/"Macintosh HD"/System/Library/CoreServices --setBoot
No mount point for /Volumes/"Macintosh HD"/System/Library/CoreServices
Can't determine mount point of ' /Volumes/"Macintosh HD"/System/Library/CoreServices' and ' '
ne peut pas vouloir dire que le programme bless n'aurait pas été invoqué (car il y aurait eu : command not found --> il ne s'agissait que d'un lapsus de retranscription). Mais bien plutôt que le point de montage / du filesystem de ce volume n'était pas identifiable à l'instant de la commande. Dont une réédition paraît être passée. Sans pour autant que le volume soit davantage repérable ni démarrable. Alors que la commande diskutil list trouve quand même à le lister...

Je trouve bizarre que ce volume joue ainsi le yo-yo... Signe d'un disque au bord de la défaillance physique? Signe d'un Système de fichiers endommagé (absence de fichier démarreur
boot.efi éventuellement)? Nul doute que la ré-installation radicale de l'OS que FreeeeZ paraît avoir engagée était la bonne décision, car tout semble témoigner d'un problème d'accès aux écritures de l'OS. Sans pourtant qu'il n'y ait de constat d'I/O error. J'avoue que je suis déconcerté par cet "entre-deux" (on verra bien si le démarrage s'effectue)...
 
@FreeeeZ
En effet ces lignes post #4 sont dangereuses au vues de ton expérience. Il serait pas mal que @bompi les supprime ou les adapte avant que ça n'enduise d'autres utilisateurs avec de l'erreur.

Dans ton cas, si tu veux rendre visible la partition de recovery il faut passer la commande :

Bloc de code:
diskutil cs revert 96CE02B1-AA7C-40F5-B800-607F67783B3A

Dans tous les cas ça fonctionne avec cmd+R et c'est le principal.

Bonne continuation.
 
Merci encore @jeanjd63 je n'ai pas pu vérifier si avec ma dernière re-install de Yosemite, les 2 partitions étaient de nouveaux visibles. Mais je suis sûr que ces lignes pourront me servire de nouveau et sinon à bien à d'autres.
Merci
 
Je me ré-immisce dans ton fil, FreeeeZ, pour ajouter une petite glose en rapport avec ta remarque suivante :

à la seconde fois, même constat : aucune Recovery visible - entrée de lignes de commande, même effet !

J'ai comme l'impression que tes "tribulations logicielles" n'ont pas eu pour source un problème logique mais psychologique. Tu as été troublé de constater, suite à ton installation de «Yosemite», l'absence d'affichage du volume de la «Recovery HD» à l'écran de choix du disque de démarrage obtenu par l'option "alt" par contraste avec la présence à l'affiche du volume de la «Recovery HD» à ce même écran auparavant. Tu as interprété cette absence d'affichage graphique comme une disparition réelle de l'objet. Par suite, tu as cherché par de multiples façons (commandes dans le «Terminal» et/ou ré-installation de «Yosemite») à restaurer l'affichage graphique du volume de la «Recovery HD» à l'écran obtenu par "alt" parce que, dans ton esprit, affichage équivalait à existence et non-affichage à non-existence.

Je pense que tu dois dissocier (psychologiquement parlant) affichage graphique de l'objet et signe d'existence de l'objet. Sur le disque d'un Mac, de nombreux "objets" existent sans pourtant être affichés graphiquement. En d'autres termes : ce n'est pas parce que l'objet n'est pas (rendu) visible pour l'utilisateur, que cet objet n'existe pas en terme de "réalité logique". Par exemple, il existe de nombreux fichiers, voire dossiers, dans l'architecture d'OS X, sans pour autant qu'ils soient visibles pour l'utilisateur, càd. affichés graphiquement (ainsi : un répertoire aussi crucial que le dossier-Système /private est graphiquement invisible pour l'utilisateur, néanmoins il est doté d'une existence logique déterminante --> c'est parce que lui est attaché un attribut d'invisibilité - le flag:hidden - que le Finder <application qui gère l'affichage graphique dans la session de l'utilisateur> interprète cet objet comme devant rester "hors-affichage").

Le même cas de figure se produit en ce qui concerne cet "objet" qui est la partition de récupération : «Recovery HD». Ce volume a toujours existé en parallèle de celui d'OSX sur le disque de ton Mac. Mais, comme tu as pu le constater de longue date, bien avant «Yosemite», cet objet qu'est la «Recovery HD» se trouve régulièrement frappé d'invisibilité graphique pour 2 applications qui sont comme les "lunettes" de l'utilisateur : pour le Finder, d'abord, qui n'affiche pas sur le Bureau l'image-disque du volume de la «Recovery HD» - ce pour une excellente raison : c'est que ce volume ne monte pas automatiquement au démarrage, et par conséquent, étant démonté, n'est pas susceptible d'un affichage graphique sous forme d'image-disque ; pour l'Utilitaire de Disque, ensuite, qui n'affiche pas du tout en mode standard la partition de la «Recovery HD» (que son volume soit monté ou démonté) et qui par suite laisse croire à de nombreux utilisateurs que l'objet (la partition-disque) n'existe pas.

Que s'est-il passé de neuf quand tu as installé «Yosemite»? Eh bien! aucunement une suppression d'existence de l'objet : «Recovery HD», mais simplement une mise-à-jour de cette existence à la version 10.10.x. Toujours aussi invisible pour le Finder. Toujours aussi invisible pour l'Utilitaire de Disque. Pourquoi as-tu donc eu l'impression que l'installation de «Yosemite» avait opéré une suppression de cet objet? C'est qu'à la différence avec, disons, «Mavericks 10.9», tu ne voyais plus le volume de la «Recovery HD» affiché à l'écran de choix du disque de démarrage obtenu avec "alt". La raison n'en est pas (comme dit ci-dessus) que «Yosemite» (ou une installation que tu te figurais "manquée" de «Yosemite») aurais supprimé l'existence de la «Recovery HD» dont tu imaginais que l'affichage à cet écran était la preuve. Mais parce que l'installateur de «Yosemite» a tendance, à l'insu de l'utilisateur, à greffer sur la partition de l'OS un format spécial : le format
CoreStorage qui paraît avoir de plus en plus les faveurs des ingénieurs de la Pomme. Le format CoreStorage a un effet qu'on peut juger indésirable : dès qu'il existe comme "wrapper" ("enveloppe" du Système de fichier de l'OS), alors le volume connexe de la «Recovery HD» ne peut plus être affiché à l'écran de choix du disque de démarrage (touche "alt"). L'objet existe toujours (la «Recovery HD»), mais son invisibilité a augmenté d'un cran : ce n'est plus seulement au Finder qu'il échappe (volume non monté --> non affiché comme image-disque) ; ce n'est plus seulement à l'Utilitaire de Disque qu'il échappe (partition inaffichable) ; c'est au DiskManager qu'il échappe désormais (outil de gestion graphique des disques). Il faut alors (re-)démarrer avec la combinaison de touches ⌘R pour atteindre l'environnement de la «Recovery HD».

Veux-tu te rassurer quant à la persistence de l'
existence de la «Recovery HD» en tant qu'objet logique?

- a) Alors, pour rendre au DiskManager sa capacité d'afficher ce volume, il faut nécessairement supprimer le format CoreStorage de la partition d'OSX et avoir «Yosemite» installé, non dans l'enveloppe d'un Volume Logique, mais dans un volume standard jhfs+.

- b) Pour vérifier périodiquement en ligne de commande l'existence de l'objet en question, il suffit d'aller à : Applications/Utilitaires et de lancer le «Terminal», pour saisir dans la fenêtre de "traitement de texte" qui s'affiche la commande :
Bloc de code:
diskutil list
(= invocation du programme "utilitaire de disque" avec le verbe impératif "lister" <la distribution des partitions-disques>) et ↩︎ (presser la touche "Entrée" du clavier pour activer la commande) --> en retour de commande, s'affiche le tableau du partitionnement
existant des disques actuellement attachés au Mac (en interne ou externe) et tu vois régulièrement un :
Bloc de code:
3:    Apple_Boot Recovery HD    650.0 MB   disk0s3
à sa place - preuve de l'existence logique de la «Recovery HD».

- c) Pour avoir à chaque fois un affichage graphique de la «Recovery HD» dans la GUI de l'«Utilitaire de Disque», que cette partition soit montée en volume ou démontée en volume, alors il suffit d'activer le menu "Déboguer" de ce logiciel. Je t'invite à lancer le «Terminal» et à copier-coller illico la commande suivante :
Bloc de code:
defaults write com.apple.DiskUtility DUDebugMenuEnabled 1
et ↩︎ (tu invoques le programme
defaults qui gère les paramètres de préférences d'utilisateur avec impératif d'écriture ciblée sur l'applicaition Utilitaire de Disque pour l'option : "activer le menu déboguer") --> quitte le «Terminal» et re-démarre ton Mac. Ta session ré-ouverte, lance l'Utilitaire de Disque : tu aperçois désormais, dans la barre supérieure des menus, un nouveau menu (sur la droite) = "Déboguer" --> déroule ses sous-menus et coche (vers le bas) l'option : Afficher chaque partition --> comme par enchantement, la partition /dev/disk0s3 de la «Recovery HD» s'affiche dans la colonne de gauche de l'utilitaire, en grisé (car son volume est démonté). Tu peux le monter si tu veux, et l'image-disque du volume sera alors affichée par le Finder sur le Bureau de session (attention! ne bidouille surtout pas le dossier de boot : com.apple.recovery.boot) --> ainsi, tu as la preuve graphique de l'existence de l'objet logique : «Recovery HD», quand bien même, à supposer le format CoreStorage toujours greffé sur la partition de ton OS, le DiskManager continuerait à ne pas afficher son volume à l'écran de choix du disque de démarrage...
 
Dernière édition par un modérateur:
Bonjour à toutes et à tous,

J'ai eu le même problème que FreeeeZ.

Mais je n'ai pas eu besoin de réinstaller El Capitan : dans l'utilitaire de disque de la Recovery HD, j'ai lancé la procédure SOS de réparations des permissions sur la partition Macintosh HD.
Et ça refonctionnait.

Merci pour vos posts.