Autant l'avouer crûment : j'ai du mal a avoir des « idées claires & distinctes » touchant les « événements logiques » relatés dans ce fil. Parce que les « causes » ne semblent pas produire des « effets » conformes au « déterminisme logique », mais au contraire « irrationnels ».
Pour ne pas embrouiller le tableau, autant circonscrire certains « mécanismes logiques » qui ne relèvent pas intrinsèquement des problèmes susdits :
- a) en ce qui concerne le
CoreStorage, et la génération d'un disque identifié dans le «
Terminal» comme :
/dev/disk2 (internal, virtual). Alors autant stopper ici tout de suite la prise de tête. Un
CoreStorage est un format d'exception, qui intercale un empilement de couches logiques entre la base (la partition
/dev/disk0s2 du disque qui sert de secteur de sustentation) et le sommet (le système de fichiers
jhfs+ contenant les données de l'OS). En gros, donc, qui fourre un intercalaire complexe entre la partition et le système de fichiers classiques.
Cet intercalaire (dit globalement : "
Groupe de Volumes Logiques") pour le réduire à ce qui importe ici consiste en 2 choses : une
émulation de disque dur plaquée sur la partition-support, exactement comme un disque virtuel
.dmg, intitulé : "
Volume Physique" & un volume qui monte à partir de ce disque dur émulé, intitulé "
Volume Logique". La conséquence, quand on fait un
diskutil list, c'est que 2 espèces de disques sont identifiées : le "
disque physique"
primaire (
disk0), qui est le SSD, avec ses partitions primaires ; et le "
disque virtuel" secondaire (
disk1), induit par l'
émulation de disque du
CoreStorage. Dans le cas de ton Mac, comme il y a en interne 2 disques physiques (au lieu d'un seul), ils sont donc identifiés respectivement comme
disk0 &
disk1 (internal, physical) et l'
émulation de disque du
CoreStorage se trouve donc identifiée comme
disk2 (internal, virtual).
Par rapport au
CoreStorage, «
El Capitan» a généralisé la tendance engagée avec «
Yosemite» : lorsqu'on télécharge son installateur depuis l'AppStore et qu'on installe à partir de lui, l'installateur d'«
El Capitan» a l'instruction de générer un format
CoreStorage sur la partition de destination de l'OS en préalable à la recopie des fichiers-Système. Ce n'est pas un
CoreStorage chiffré (comme quand on active «
FileVault»), c'est un
CoreStorage "
nu" (autant dire : ne servant à rien d'autre qu'à embrouiller les choses). Donc chaque fois que tu as ré-installé à partir de la «
Recovery-Internet» (sur ton
iMac dont
10.11 est l'OS d'usine), comme cela se serait produit si tu avais ré-installé depuis la «
Recovery HD» (même téléchargement d'un installateur
10.11 depuis l'AppStore) ou si tu avais encore téléchargé dans ta session de l'OS le même installateur depuis l'AppStore pour le lancer en mode "
live" => chaque fois, l'installateur suit l'instruction interne de génération d'un
CoreStorage sur la partition de destination et tu te retrouves donc avec en prime un disque secondaire identifié comme :
(Internal, Virtual).
☞
en résumé : ne pas se prendre la tête avec ça. C'est une péripétie qui n'a rien à voir avec les problèmes que tu as relatés et qui mérite d'être laissée "entre parenthèses" (par «
réduction phénoménologique», comme aurait dit compère
Husserl...).
♤
- b) en ce qui concerne un démarrage sur une partition de récupération. Que ce soit la «
Recovery HD» (qui occupe une partition de disque interne =
/dev/disk0s3), ou que ce soit la «
Recovery-Internet» (qui est purement supportée en RAM après téléchargement, sans localisation sur le disque interne) : dans les 2 cas, le Système est contenu dans un dossier de démarrage
com.apple.recovery.boot, qui comporte des fichiers de
boot (
Boot_Files) et un
disque virtuel .dmg de 450 Mo (
BaseSystem.dmg) qui se trouve monté en un
volume virtuel de 1,3 Go (
OS X Base System) recelant un version abrégée d'
OS X. Donc, en cas de
diskutil list dans le «
Terminal» d'une «
Recovery» démarrée, il est normal de trouver mention d'un :
Apple_HFS OS X Base System quelque part, car il s'agit là du volume monté du disque virtuel
BaseSystem.dmg recelant le Système démarré de la récupération.
Quant à la ribambelle d'une douzaine de micro-disques listés, ce n'est certes pas fait pour simplifier la vision des choses, mais c'est un état de faits régulier en cas de démarrage sur une «
Recovery» : il semble y avoir un mécanisme logique qui monte des dossiers recelés dans le volume virtuel de la «
Recovery» (
OS X Base System) comme des "Volumes Temporaires", lesquels sont identifiés à l'instar de "pseudo-devices" (en n'étant que des "
Disk Images").
☞
en résumé : ne pas non plus se prendre la tête avec ça - c'est confus au possible, mais hors sujet en ce qui regarde ta problématique.
♧
- c) en ce qui concerne le mécanisme logique de prise-en-charge de la «
Recovery HD» par «
Carbon Copy Cloner». Lorsqu'on lance une première opération de clonage du volume d'
OS X sur le volume d'un DDE, «
Carbon Copy Cloner» commence par gérer une tâche d'
archivage du dossier de démarrage de la «
Recovery HD» (dont le volume se trouve monté pour ce faire) dans une
image-disque "
maison" créée
ad-hoc dans la
Bibliothèque Générale de l'OS "
source". L'adresse est :
/Library/Application\ Support/com.bombich.ccc/Recovery HD.dmg.
Ensuite, «
CCC» clone le volume de l'OS "
source" dans le volume de "
destination" du DDE, et, ce faisant, il copie donc le dossier
com.bombich.ccc créé dans l'
Application Support de l'OS "
source" dans le dossier correspondant du clone du DDE. Ainsi, le clone comporte en miroir l'
archive du disque virtuel
Recovery HD.dmg qui peut, une fois monté, servir de "
source" à la recréation d'une «
Recovery HD».
Enfin, régulièrement, «
CCC», après scan du disque du DDE, déclare qu'aucune «
Recovery HD» n'existe en corollaire de l'
OS X cloné et demande à l'utilisateur s'il veut qu'une récupération y soit créée : en cas d'acquiescement, le disque du DDE recèlera donc une «
Recovery HD» en corollaire de la partition de l'OS cloné, à l'image du disque "
source".
Lorsque, vice-versa, on rétro-clone l'
OS X du clone sur le disque interne du Mac, la tâche pour «
CCC» ne diffère pas de celle d'un clonage "aller" : il y a recopie des fichiers d'
OS X sur le volume donné en "
destination", et si, après scan du disque, «
CCC» s'aperçoit qu'il n'existe pas de «
Recovery HD», alors il proposera en fin de tâche d'en créer une. Au cas où (pour une raison = x) cette tâche secondaire ne serait pas proposée, il est toujours possible de la forcer une fois démarré sur le clone. Il suffit pour cela, dans la colonne de gauche de «
CCC», de ne pas sélectionner l'onglet "Tâches", mais l'onglet "
Volumes" et de choisir le volume monté de l'OS du disque interne du Mac => un espace central se démasque, avec un bouton tout en bas intitulé : "
Recovery HD" => le presser équivaut à demander à «
CCC» de gérer l'existence d'une «
Recovery HD» en annexe du volume choisi (via un petit re-partitionnement préalable de la partition-cible), ce à partir du
disque archivé dans la
Library/Application\ Support/com.bombich.ccc/Recovery HD.dmg du clone. Si aucune «
Recovery HD» n'existe sur le disque interne du Mac, alors «
CCC» propose d'en re-créer une à partir de l'image-disque d'archivage.
☞
en résumé : un clone fait sur un DDE par «
CCC», il n'est jamais besoin (théoriquement parlant) de ré-installer le Système d'
OS X pour recréer une «
Recovery HD» sur le disque interne du Mac, au cas où elle y ferait défaut. Il suffit, après démarrage sur le clone, de sélectionner le volume en question (dans l'onglet général "
Volumes" du logiciel) et de presser le bouton "
Recovery HD" pour lancer la tâche de re-création à partir du disque d'archivage.
♡
Mon intention dans ces descriptifs (certes un tantinet prolixes) a été la suivante : faire le point sur certaines questions évoquées précédemment afin de permettre, clarification faite, de les exclure ("circonscrire") de la problématique centrale évoquée dans ce fil.
Comme cela m'a demandé d'écrire un bloc de prose déjà substantiel, je vais me borner à abréger regardant le problème essentiel.
❉
Il paraît bien que ce problème ait consisté pour l'essentiel dans le fait suivant : certaines
opérations d'écriture à destination du disque interne du Mac à partir soit de la «
Recovery HD» (effacement de la partition
Datas), soit d'un clone démarré (recopie sur la partition d'accueil
/dev/disk0s2) aient connu un «
destin paradoxal » : il y a eu en premier lieu
effectuation d'écriture vérifiable (effacement - d'après
diskutil list) ou restauration du clone sur le volume dédié à
OS X du disque interne (vérification de la présence des logiciels tiers correspondant à la
source du clone dans le volume cloné de
destination monté sur le Bureau du clone) ; mais en second lieu, re-démarrage effectué sur l'OS restauré du disque interne, s'est avéré un
défaut d'effectuation des écritures précédentes (partition
Data résiliente ou OS resté à l'état virginal de sa
clean install préalable sans qu'il y ait eu restauration par le clone : pas de logiciels tiers notamment).
Il semble que ce
phénomène paradoxal d'« écritures fantômes » aurait affecté aussi bien «
Carbon Copy Cloner» que «
SuperDuper !», en ce qui concerne le rétro-clonage et que seul un démarrage sur la «
Recovery-Internet» (donc un Système supporté en RAM) était exempt de ce phénomène d'« écritures fantômes ». Comme si les «
écritures paradoxales » s'adressaient non pas au
disque réel, mais à une
image virtuelle temporaire du disque qui se dissiperait après re-démarrage, le
disque réel s'avérant intouché par l'opération antérieure.
❈
Alors : est-ce que
Locke « déb_
loque » ou bien est-ce que c'est le noyau des choses qui « dé_
blocke » ?
☞ Il se trouve qu'un des documents que
Locke a fournis apporte la preuve indiscutable de son intégrité mentale, en étalant au grand jour un phénomène de «
représentation logique paradoxale » (message
#34) :
Bloc de code:
dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *256.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 255.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS Datas 499.8 GB disk1s2
/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +255.2 GB disk2
Logical Volume on disk0s2
31802A71-6C60-430D-963C-73B157D29917
Unencrypted
=> il n'y a rien qui vous frappe ? La partition
2: Macintosh HD 255.2 GB disk0s2 est identifiée comme recelant un format :
Apple_HFS standard, et pourtant plus bas il est mentionné qu'existerait un
Logical Volume on disk0s2 = 31802A71-6C60-430D-963C-73B157D29917. Comme si l'opération d'écriture de réversion du format
CoreStorage préconisée par
Jean =>
diskutil cs revert 31802A71-6C60-430D-963C-73B157D29917 (et manifestement effectuée par
Locke pour que le format
Apple_CoreStorage ait disparu de la partition
/dev/disk0s2 qu'il affectait précédemment cf. message
#30) avait eu une «
issue paradoxale » :
suppression du
CoreStorage (format
HFS sur
/dev/disk0s2) et
maintien du
CoreStorage (
Volume Logique montant à partir de
/dev/disk0s2).
✿
C'est la première fois que je vois,
de visu, une pareille
attestation paradoxale d'existence d'un
format ET de
contre-existence d'un autre
format «
en même temps et dans le même lieu » => il s'agit donc
stricto sensu d'une
contradiction logique.
Cette contradiction logique ne peut avoir qu'un domaine de sustentation : le
kernel. Seul le
kernel charge, en effet, la
représentation logique du disque : sa
Table de Partition avec les
formats des
filesystems.
☞ Alors je lance une conjecture dominicale on ne peut plus hasardeuse et fragile : un bogue affecterait-il le fonctionnement logique du
kernel de la version
10.11.2 de l'OS «
El Capitan», en supposant qu'il y a là une version mise-à-jour du
kernel inaugural de
10.11.0 à
10.11.1 ? Se pourrait-il que ledit
kernel, dans
certaines conditions spécifiques,
déraille, au point de déployer une
représentation « temporaire » de l'espace-disque qui ne tienne pas le
re-démarrage ?
❀
