Je reviens dans ce fil, parce qu'y est intervenu un bref échange à 3 voix sur un sujet problématique - sans autre sanction que l'« oubli » à la place de la « vérité ».
kevinsmaja =>
— Redémarrer avec CMD+R
— Utilitaire de disque
— Effacer APPLE SSD SM0128G MEDIA (Table de partition GPT)
macomaniac =>
Comme j'avais tenté de l'expliquer, cette manœuvre n'est pas possible à partir de ce type de démarrage => si tu démarres, en effet, sur une partition du disque (la «Recovery HD»), tu ne peux pas effacer le "disque" entier, càd. effacer sa table de partition GPT et en recréer une neuve, puisque tu es démarré sur une des partitions de cette table. Effacer la table serait effacer la partition active, ce qui est interdit par le montage en volume du système de fichiers de cette partition et le démarrage du Système de l'OS.
jeanjd63 =>
Il me semblait que lorsque l'on démarrait en mode recovery, c'était un système de fichier virtuel qui se créait en mémoire, en tout cas c'est ce que l'on voit quand on fait un : diskutil list en mode Recovery.
=> Lorsque j'ai rédigé mon message, je croyais énoncer un truisme : qu'il est impossible d'effacer la table de partition d'un disque si l'on est démarré sur une de ses partitions, le système de fichiers d'icelle, actif, s'y trouvant indémontable en volume, ce qui introduit une exception à la règle de démontage de tous les systèmes de fichiers d'un disque afin de pouvoir le retabler globalement.
J'ai donc été surpris par la remarque dubitative de
Jean 
- surpris dans le sens où une remarque inattendue d'un interlocuteur ébranle d'un seul coup la cohérence d'une vision des choses en y créant une faille. Béance dans laquelle l'esprit, qui sommeillait sur un oreiller de paresse intellectuelle, trouve abruptement à s'échapper de son confort pour se mouvoir dans tous les sens dans un mélange grisant d'aventure spéculative et d''inquiétude de la désorientation.
Bref : je me suis senti « travaillé » intérieurement par la question, et je me suis livré à des investigations sur un
MacBook Pro 15" Mid_2010 qu'on m'a refilé et avec lequel j'ai toute latitude expérimentale.
--------------------
Disposant de tous les installateurs d'
OS X solidaires d'une «
Recovery HD» (de «
Lion 10.7» à «
El Capitan 10.11») et ayant loggé un SSD dans le
MacBook Pro pour ne pas être handicapé par la lenteur d'un HDD, j'ai installé successivement dans le volume unique de ce SSD chaque OS de
10.7 à
10.12 en
clean install, ce qui a généré une partition de secours «
Recovery HD» collatérale chaque fois.
Chaque fois, j'ai démarré sur la «
Recovery HD», et, dans l'«
Utilitaire de Disque», j'ai sélectionné le disque entier du SSD et le menu "
Effacer", qui, à l'échelle du disque entier, signifie : effacer la
GPT (Table de Partition
GUID) et en recréer une vierge => dans un premier temps, j'ai obtenu un échec pour toutes les «
Recovery HD» de
10.7 à
10.10 compris, au motif que : "
Impossible de démonter le disque" confirmant mon idée première : en démarrant sur la partition «
Recovery HD» du disque, il est impossible de démonter le système de fichiers actif de cette partition et donc d'effacer la
GPT du disque pour en créer une vierge qui effacerait la partition de démarrage (contradiction logique forclose par le principe d'identité).
Pourtant ô surprise : en démarrant sur la partition «
Recovery HD» d'«
El Capitan 10.11», il m'a été possible d'effacer la
GPT entière du SSD, à la condition de démonter manuellement le volume de l'OS au préalable, sans obtenir de message d'erreur : '
Impossible de démarrer le disque".
Jean avait donc raison
aussi dans ce cas de figure, ce qui illustre la déclaration de
Leibniz : «
les hommes ont raison dans ce qu'ils affirment, mais tort dans ce qu'ils nient » - une déclaration plus subtile qu'il n'y paraît, car nous nous arrangeons d'habitude pour affirmer ce que nous pensons en le présentant comme une négation d'idées d'autrui, ce qui fait que nous avons toujours tort dans l'énoncé de nos raisons, parce que nous n'intégrons pas la raison des autres dans notre raison, mais que nous l'en proscrivons comme si c'était une non-raison.
Fort de cet avertissement
leibnizien, j'ai décidé de ne pas rétrécir
a priori la valeur de l'expérience qui donnait raison à
Jean à l'échelle d'une exception locale, en attribuant en regard une valeur générale à l'expérience qui me donnait raison ; mais au contraire, d'accorder au cas particulier donnant raison à
Jean une valeur exemplaire d'une règle générale, quitte à diminuer ma raison en retour de bâton à un statut d'exception.
Ce qui revenait à dire : qu'est-ce qui permettait à un démarrage sur la «
Recovery HD» d'«
El Capitan» de pouvoir retabler la
GPT du disque, et qui, absent des démarrages sur les «
Recovery HD» des autres OS, interdisait ce retablage ? Mais qui le permettrait aussi bien, si j'arrivais à en introduire le facteur dans les autres démarrages ?
--------------------
Il n'est pas faux de dire que, dès qu'on formule un problème dans une forme de question adéquate, aussitôt sugit la réponse (toute réponse découlant donc de la juste formulation d'une question). En effet, la réponse s'est imposée d'emblée : ce qui singularise «
El Capitan» par rapport à tous les OS qui l'ont précédé, c'est que son installateur crée d'office un format
CoreStorage sur la partition de l'OS.
Patiemment, j'ai converti manuellement chaque
clean install des OS
10.7 > 10.10 au format
CoreStorage => le résultat ne s'est pas fait attendre : avec
toutes les «
Recovery HD», j'ai été capable d'effacer la
GPT entière du disque, ce qui était impossible auparavant.
J'étais exactement dans la position de la « poule qui a trouvé un couteau », ne sachant quoi en faire - car ces expériences parfaitement avérées contredisaient avec l'autorité d'une règle de la raison ce que ma raison m'affirmait avec évidence par ailleurs : à savoir qu'il est impossible de retabler un disque dont un système de fichiers au moins est actif, et qu'il est impossible, démarré sur une partition du disque et ayant activé son système de fichiers, de le désactiver et donc de retabler le disque entier.
La règle découverte :
CoreStorage => possibilité de retabler la
GPT à partir de la «
Recovery HD» était donc une
impossibilité théorique, quoique un
fait avéré dans la pratique.
Pourquoi l'impossible était-il possible en cas de
CoreStorage ? Et en quoi donc un
CoreStorage sur la partition de l'OS pouvait-il affecter la «
Recovery HD» collatérale ?
J'ai re-démarré, en situation de
CoreStorage sur la partition de l'OS, sur chaque «
Recovery HD» de
10.7 à
10.11 et j'ai examiné les choses avec 3 outils : le «
Safari» de "
Obtenir de l'aide en ligne" qui permet, par
⌘O, d'ouvrir une navigation locale en mode graphique ; par l'«
Utilitaire de Disque» ; par le «
Terminal». J'abrège en sautant au résultat =>
jamais, en situation de
CoreStorage, la partition de la «
Recovery HD» n'est
montée en volume alors même qu'il y a démarrage de type
Recovery. Ce qui revient à dire que le système de fichiers de cette partition n'est pas activé. Donc, démonté, rien n'empêche un retablage de la
GPT du disque, puisque le système de fichiers de la partition de l'OS non démarré est démontable aussi. Comme celui de la partition d'en-tête
EFI.
Par contre, en re-démarrant sur chaque «
Recovery HD» en l'absence de
CoreStorage sur la partition de l'OS (dans le cas d'«
El Capitan», après réversion manuelle dans le «
Terminal» de ce format) => le volume de la «
Recovery HD» est
toujours monté, et le système de fichiers de cette partition est rigoureusement indémontable, car actif => donc la
GPT ne peut pas être retablée, à cause de ce système de fichiers non démontable.
Ce dernier cas de figure, je le concevais (c'était ma raison initiale). Mais l'autre : comment était-il possible de démarrer sur une
Recovery HD, sans que le volume correspondant de la partition du disque ne soit monté, son système de fichiers activé ?
--------------------
Là encore : en formulant adéquatement une question, surgit la réponse => je connais un cas de démarrage de type
Recovery qui ne dépend pas du montage de la partition correspondante du disque : c'est le démarrage en mode "
par internet". Qu'est ce qui se passe dans ce cas ? Le Système du serveur de l'AppStore auquel le Mac est connecté par internet instruit la création dans la
RAM d'un container-disque virtuel : un
RAMDisk nommé
Untitled, qui reçoit une table de partition
sui generis, avec une partition-Système dans laquelle se trouve copié un dossier de démarrage
com.apple.recovery.boot contenant un
boot.efi, un
kernelcache ou
prelinkernel, des fichiers d'instruction de
boot et une image-disque
BaseSystem.dmg qui, montée, donne un volume
OS X Base System recelant un Système démarrable [cf. mon message qui décortique ce dispositif : ☞
Mac OS X, les PC users ne rigolent pas, au contraire !☜, message
#21.]
Eh bien ! la seule solution à mon paradoxe était qu'en cas de présence d'un
CoreStorage sur la partition de l'OS, le démarrage en mode «
Recovery HD» était du même genre que le démarrage
par internet, la connexion en ligne à l'AppStore en moins => la création préliminaire d'un
RAMDisk en
RAM, dans lequel se trouverait copié le dossier de
boot dont l'original était recelé sur la partition
Recovery HD du disque : le dossier-Système
com.apple.recovery.boot.
Effectivement ! Lors d'un démarrage de type "
CoreStorage collatéral", le démarrage en mode
Recovery (je ne parle par du démarrage par internet ici) est
beaucoup plus lent que sans
CoreStorage : il y a un écran gris sans ( qui signale l'activation du
boot.efi du Système de secours) pendant environ 30 secondes, pendant lesquelles doit intervenir la création du
RAMDIsk en
RAM et la recopie du dossier de boot original
com.apple.recovery.boot => après quoi, dès l'affichage de la , c'est sur le Système du
RAMDisk qu'il y a démarrage et absolument pas sur celui de la partition «
Recovery HD» du disque, dont le volume est démonté et le système de fichiers inactif.
Ce qui restait obscur alors était le point suivant : en quoi un format
CoreStorage sur la partition de l'OS modifiait-il en quoi que ce soit le démarrage en mode «
Recovery HD» pour produire un tel résultat : la création d'un
RAMDisk en
RAM et le démarrage sur un volume de la
RAM et pas du disque ?
--------------------
Comme toujours : il suffit de poser la question pour avoir la réponse. Un format
CoreStorage sur la partition de l'OS a la propriété de masquer le volume de la «
Recovery HD» si l'on démarre avec "
alt" (car le
boot_loader boot.efi de la «
Recovery HD» sert alors de
boot.picker exclusif à l'
EFI pour démarrer le Système du
CoreStorage - chiffré ou non - et ne peut donc pas signaler un Système de type
Recovery sur un volume démarrable) => on ne peut donc démarrer sur la «
Recovery HD» qu'avec
⌘R.
Et si c'était tout bêtement la commande de démarrage
⌘R qui induisait la création d'un
RAMDisk, qu'il y ait un
CoreStorage ou non sur la partition de l'OS ? J'ai fait tous les tests de démarrage en mode
⌘R, de
10.7 à
10.11, en l'
absence d'un
CoreStorage sur la partition de l'OS : le résultat est le même => création d'un
RAMDisk, et possibilité de retabler la
GPT du disque.
Ce n'est donc pas l'actualité d'un
CoreStorage sur la partition de l'OS qui affecte le type de démarrage
Recovery : c'est le mode utilisé pour choisir le démarrage
Recovery => choix du volume via "
alt" => démarrage sur le
Système du disque => retablage impossible de la
GPT ; démarrage par
⌘R => création d'un
RAMDisk Recovery => retablage de la
GPT du disque possible. C'est seulement parce qu'un
CoreStorage interdit le démarrage
Recovery via "
alt" et oblige au démarrage via
⌘R qu'il détermine la génération d'un
RAMDisk Recovery en
RAM. Mais c'est exclusivement le recours à la commande
⌘R (exécutable en l'absence de
CoreStorage) qui enclenche le mode :
RAMDisk Recovery vs "
alt" qui enclenche le mode :
Recovery HD du disque.
⌘R crée donc un clone du système de la
Recovery dans un
RAMDisk de la
RAM, exactement comme le fait
⌘⌥R, sauf que le dossier-système
com.apple.recovery.boot est cloné depuis la partition du disque avec
⌘R, et qu'il est cloné depuis le serveur de l'AppStore, avec
⌘⌥R (outre le fait que ce n'est pas le même OS qu'on peut ré-installer : du disque vs d'usine). En résumé : les démarrages
recovery de type
⌘R ou
⌘⌥R conduisent à un démarrage en
RAM sur un
RAMDisk, alors que le démarrage
recovery via "
alt" est un démarrage classique sur une
partition du disque.
Le Système démarrable étant toujours contenu dans le volume monté
OS X Base System d'une image-disque
BaseSystem.dmg dans
tous les cas > la différence réside dans le type de
container logique (
device) de résidence de cette image-disque : en cas de démarrage avec "
alt", ce
container logique est la
partition du disque qui monte un volume
Recovery HD ; dans le cas du démarrage avec
⌘(⌥)R, ce
container-logique est un
RAMDisk de la
RAM, qui monte un volume
Untitled. Il y a donc dispositif gigogne :
Container-disque :
Recovery HD > volume image-disque :
OS X Base System vs Container RAMDisk :
Untitled > volume image-disque :
OS X Base System.
--------------------
Je pense que j'ai résolu le paradoxe : ma raison correspondait au démarrage standard
Recovery HD avec "
alt" ; la raison de
Jean correspond au démarrage original
Recovery RAMDisk avec
⌘(⌥)R. Les 2 possibilités co-existent, comme modalités concurrentes.
Je termine sur cette observation : le démarrage
Recovery RAMDisk avec
⌘(⌥)R permet le retablage de la
GPT du disque, par effacement des partitions et re-création d'une table
GPT neuve avec 2 seules partitions : un en-tête
EFI et un volume d'accueil vide.
Cette puissance d'effacement du disque possède une implication redoutable pour quelqu'un qui commettrait la légèreté de re-démarrer à ce moment-là, ou dont l'option "
Ré-installer OS X" se heurterait à un blocage du serveur de l'AppStore => c'est qu'
aucun système démarrable n'existe plus sur le disque, et que le Système
Recovery actuellement démarré réside purement en
RAM dans un
RAMDisk => il est donc volatile comme tout contenu de la
RAM.
Re-démarrer dans ce cas de figure conduit au fatal
? mentionnant qu'il n'y a plus sur le disque aucun système démarrable. Si le Mac est d'un modèle antérieur à 2010, le démarrage par internet
⌘(⌥)R ne lui est pas possible => en cas de perte du DVD de secours de l'OS ancien avec lequel il avait été fourni à l'achat (genre «
Snow Léoaprd») et en l'absence de sauvegarde bootable => le Mac est tranformé en planche a repasser
--------------------
