Salut
jbwawa
J'avais complètement loupé ton fil et j'interviens donc dans une position d'
épigone (que j'affectionne). Puisque je parle d'«
Épigones » (ceux qui vinrent après la mort d'
Alexandre exercer leur magistrature), c'est sans passer du coq à l'âne que la solution que tu as apportée au sac de nœuds de ton
Fusion Drive me fait penser à la manière dont
Alexandre résolut l'énigme du
Nœud Gordien.
C'était un nœud sans queue ni tête qui maintenait en place le timon d'un char, une prophétie promettant l'empire de l'Asie à qui saurait le défaire. Ce nœud avait déjoué toutes les tentatives de dénouage logique des experts ès bouts de ficelles. Alexandre, sans s'embêter une seconde, tira son glaive et le trancha d'un seul coup en apportant au problème une solution matérielle inattendue. Et, conformément à la prédiction, devant sa petite armée de phalangistes et de cavaliers les immenses concentrations d'hommes des armées de Darius se dispersèrent comme de la poussière.
Ce qui m'incite à intervenir dans ton fil, c'est une
anomalie très remarquable présentée par le Tableau de partitionnement de tes disques, lorsqu'ils étaient encore solidarisés en mode
Fusion Drive - anomalie en tout point digne d'un
Nœud Gordien dont je te propose un "dénouement" logique
épigone qui ne t'apportera rien, puisque tu as procédé à ta "coupure" physique
alexandrine...
--------------------
Il n'y a rien à signaler d'anormal dans la table de partition de ton SSD (
/dev/disk4 dans ton dispositif Target) :
/dev/disk4s1 est l'
ESP (l'
EFI System Partition) de 209 Mo, qui est l'en-tête de toute
Table de Partition GUID régulière ;
/dev/disk4s2 est la partition-Système n°1 supportant le
Physical Volume n°1 du
Fusion Drive qui sert de support d'exportation partiel au
Volume Logique global
Macintosh HD ;
/dev/disk4s3 est la partition du
booter Boot OS X, qui recèle le pilote de montage du
Volume Logique à partir du support du
Physical Volume.
Non : l'anomalie réside entièrement sur le HDD (
/dev/disk3 en mode Target). Mais pas dans son début de partitionnement qui est on ne peut plus régulier. En effet, en
/dev/disk3s1 est l'
ESP régulière de la table de partition du HDD ;
/dev/disk3s2 est la partition-Système n°2 supportant le
Physical Volume n°2 du
Fusion Drive qui sert d'autre support d'exportation au
Volume Logique global
Macintosh HD ;
/dev/disk3s3 est la «
Recovery HD» qui s'installe toujours, en cas de
Fusion Drive, sur le HDD en-dessous de la partition-Système n°2 (et en-dehors du périmètre logique du
CoreStorage) ; enfin /
dev/disk3s4 est la partition
BOOTCAMP qui, en cas d'installation encore, se situe régulièrement juste en-dessous de la «
Recovery HD» du HDD dans une situation de
Fusion Drive.
--------------------
Mais où est donc l'anomalie alors ? C'est qu'il existe une
partition-Système n°3 en-dessous de la partition
BOOTCAMP, soit en
/dev/disk3s5. Cette partition, porteuse d'un format
CoreStorage et intitulée
Macintosh HD, relevait nécessairement du
Fusion Drive encore. Ce qui fait que, contrairement à la règle, ton
Fusion Drive n'était pas une association de 2 partitions-Système, mais de 3 partitions-Système :
/dev/disk4s2 +
/dev/disk3s2 +
/dev/disk3s5. C'est ce qu'il apparaît à la mention de ton
/dev/disk5 [qui ne doit pas faire illusion : il ne s'agit nullement d'un disque (
external, physical), mais d'un disque (
external, virtual) : le
Volume Logique global
Macintosh HD exporté par le
Fusion Drive est régulièrement évalué comme une disque de second ordre] => la ligne de recencement des partitions relevant du
CoreStorage mentionne :
Logical Volume on disk4s2, disk3s2, ... => jamais, régulièrement, n'interviennent de
... lorsqu'un
Fusion Drive solidarise seulement 2 partitions. Ici, il n'y a qu'une interprétation possible :
... = l'abrégé de
disk4s5, 3è partition impliquée dans le
CoreStorage.
--------------------
Ce qui est donc absolument exceptionnel, c'est que la partition de récupération «
Recovery HD» (
disk3s3) et la partition
BOOTCAMP (
disk3s4)
s'intercalent entre 2 partitions du HDD relevant du
Fusion Drive (
disk3s2 et
disk3s5). L'espace-disque du
Fusion Drive relevant du HDD est donc fractionné en 2, avec intercalement de 2 partitions dans des formats spéciaux (
Apple_Boot pour la
Recovery HD et normalement
Microsoft Basic Data pour
BOOTCAMP. Mais pas du tout ! Ce fameux
BOOTCAMP est au format
Apple_HFS, càd.
Mac OS étendu (journalisé) => il est donc impossible que cette partition supporte un OS
Windows démarrable (format
NTFS requis), ni ne soit une partition destinée à cette installation (format provisoire
MS-DOS =
FAT-32).
Si je laisse entre parenthèses cette question du format incompatible (qui doit provenir d'un reformatage d'une partition
Windows), la question est : pourquoi la partition
BOOTCAMP est-elle
située là où on la trouve ? La réponse gît dans le facteur suivant : sur des disques de très grande taille (+ de 1 To), tout ce qui intervient en terme d'espace-disque au-delà des
2,2 premiers To n'est plus représentable dans une
table de partition MBR. Or, lorsque l'«
Assistant BootCamp» procède à la mise en place d'une partition
Windows, il joue sur la particularité suivante : la
table de partition GUID maîtresse du disque, se trouve
doublée par une
partition MBR secondaire qui sert de référence à
Windows. Si la partition d'accueil de
Windows était comprise
après les 2,2 premiers To du disque, elle serait donc
irreprésentable dans le
table de partition MBR secondaire et rien ne fonctionnerait => sur un disque de
3 To, la partition
BOOTCAMP doit donc se situer
en-deçà des 2,2 premiers To du disque. C'est le cas ici : elle commence à
2 To et se termine à
2,16 To (c'est ce qui s'appelle calculer juste).
--------------------
Donc normalement, il y avait en-dessous de cette partition
BOOTCAMP un espace disque de
+ 800 Go inutilisé. Alors de 2 choses l'une : soit cet espace-disque a été récupéré
d'usine au
Fusion Drive en qualité de partition support n°3 (une création d'Apple). Soit cet espace-disque de + 800 Go ne faisait pas originellement partie du
Fusion Drive, mais il y a eu une série de bidouillages "maison" : a) ajout des 800 Go au
Fusion Drive qui devenait triple : b) reformatage en
JHFS+ de la partition
BOOTCAMP NTFS.
Si la partition
BOOTCAMP a été reformatée, je présume que c'est parce que
Windows ne marchait plus (à cause d'une partition créée en-dessous de + 800 Go) ; mais si le
Fusion Drive ne marchait plus (ou mal), c'était à cause de la distribution binaire sur le HDD (
disk3s2 // disk3s5) avec interruption de la «
Recovery HD» et d'un ex-BOOTCAMP (
disk3s3 - disk3s4) => le second
booter BOOT OS X (en
disk3s6) devait avoir du grain à moudre pour contrinuer au montage du
Volume Logique à partir de 2 supports de
Physical Volumes du HDD.Je pense que c'est cette distribution "imbriquée" qui faisait coincer les commandes de destruction...
Jamais vu un tel...
Nœud Gordien !
--------------------
