Bon -
en synthèse, à la lecture des 2 tableaux, j'ai une nouvelle rassurante, et une nouvelle qui fâche :
- la nouvelle rassurante : tes disques, matériellement parlant, ont l'air en bon état et il ne doit pas y avoir de problèmes de nappe. Tout doit être physiquement fonctionnel. Aucun démontage à prévoir et pas non plus de changement de matériel.
- la nouvelle qui fâche : un de tes 2 disques, nommément le SSD de 120 Go (/dev/disk0), est corrompu d'un point de vue logique. Ton Fusion Drive n'est pas sauvable en l'état. Le Volume Logique qui recelait ton OS «El Capitan», avec ton compte d'utilisateur et tes données, n'est pas récupérable. La seule issue est de faire disparaître les décombres du Groupe de Volumes Logiques encore en place, et de re-créer un Fusion Drive neuf, mais évidemment exportant un Volume Logique vierge, sur lequel il faudra ré-installer un OS.
--------------------
En mode
analytique : un format
CoreStorage consiste à créer un architecture logique globale appelée :
Groupe de Volumes Logiques, qui est une "
Logical Pool" : un bassin d'instances logiques. L'instance primaire consiste en un
Physical Volume, qui est une couche logicielle importée sur la partition d'un disque et émulant un disque dur. Ce disque dur émulé sert de support-disque à une paire d'instances secondaire et tertiaire : une
Logical Volume Family (
Famille de Volumes Logiques : instance de paramétrage du
Volume Logique exporté) et un
Logical Volume (
Volume Logique exporté à partir du disque dur émulé) : c'est dans ce
Volume Logique, "
on top of the pool", que réside le système de fichiers standard
jhfs+ de l'OS. En queue de peloton du
Groupe de Volumes Logiques, enfin, existe un "
Driver" (pilote) qui sert à monter le
Volume Logique. C'est un dispostif un peu analogue à celui d'une image-disque
.dmg : tu as un disque virtuel (une image-disque) qui est un conteneur à partir duquel monte un volume.
Dans un
Fusion Drive, on a un format
CoreStorage dont le
Groupe de Volumes Logiques n'importe pas, en terme d'instance primaire, un seul
Physical Volume, mais 2 : un greffé sur la partition d'accueil d'un SSD et un autre greffé sur la partition d'accueil d'un HDD. Ces 2 disques durs émulés se trouvent coiffés par l'instance secondaire d'une
Logical Volume Family unique, qui relie leurs deux instances de manière à exporter sur ces 2 supports-disques un
Volume Logique unique.
Ce bref aperçu te permet de décoder le tableau du
Groupe de Volumes Logiques (2è capture) --> tu as bien le signalement de l'existence du
Logical Volume Group (l'architecture globale) en tête de tableau ; et tu as le signalement de l'existence des 2 disques durs émulés =
Physical Volumes. Mais c'est là que les choses se gâtent : le
Physical Volume greffé sur la partition
/dev/disk1s2 de ton HDD est intact, avec les propriétés logiques correspondantes ; mais le
Physical Volume qui devait être greffé sur la partition
/dev/disk0s2 de ton SSD n'offre plus aucune propriété logique ("
no properties"). Le
Groupe de Volumes Logiques a conservé la mémoire de son
UUID (
IDentifiant
Unique
Universel de 32 caractères alpha-numériques), mais en fait la couche logique qui émulait un disque dur a "sauté". C'est la première fois que je contemple une telle situation. Je connaissais le cas de
Groupes de Volumes Logiques dont les
Physical Volumes restaient intacts, mais dont la paire d'instances secondaire et tertiaire (
Famille de Volumes Logiques &
Volume Logique) avait été "décapitée". Là, c'est la première fois que j'avise la disparition carrément d'une instance primaire : un
Physical Volume. Par voie de conséquence de la volatilisation d'un des 2 disques durs émulés, tu notes l'absence d'instance n°2 : la
Logical Volume Family dans ton tableau, et par suite l'absence de l'instance n°3 : le
Logical Volume.
Ce qui me renvoie à l'examen du premier tableau, dans lequel on a le descriptif logique des 2 disques séparés. Rien à redire pour ton HDD de 500 Go (
/dev/disk1) : tu as en tête l'
EFI System Partition (
ESP) solidaire de la
Table de Partition GUID (
/dev/disk1s1), puis la partition
CoreStorage sur laquelle est greffé le 2è
Physical Volume (
/dev/disk1s2). Ensuite, la partition de récupération de la «
Recovery HD» (
/dev/disk1s3). Enfin, la partition où est installé «
Windows» (
/dev/disk1s4) avec en queue de peloton son "
Driver" (
/dev/disk1s5). Par contre, le tableau de ton SSD (
/dev/disk0) est carrément illisible, à part l'
ESP en
/dev/disk0s1. Un "
Microsoft Reserved" de 16,8 MB occupe indûment une pré-partition minuscule à l'emplacement même (
/dev/disk0s2) réservé logiquement au disque dur émulé n°1 d'un
Fusion Drive. C'est en
/dev/disk0s3 (contre toute attente) que se trouve rejetée la partition majeure de 119,7 Go, mais au lieu d'être indexée par un format :
Apple_CoreStorage signalant la couche du
Physical Volume n°1, on lit un :
Microsoft Basic Data BOOTCAMP qui n'a absolument rien à y faire. La seule chose formellement correcte est l'
Apple_Boot Boot OS X sur la partition
/dev/disk0s4 : c'est le "
Driver" (pilote) du
Groupe de Volumes Logiques (qui n'a malheureusement plus rien à piloter).
J'avais eu vent que dans les
bêtas d'«
El Capitan», la mise en œuvre de «
BootCamp» était susceptible de générer de sérieux problèmes. Ma conjecture est que tu es victime d'un tel cas de figure : il y a eu corruption logique de la partition
CoreStorage de ton SSD supportant le
Physical Volume n°1 en contre-coup de l'utilisation de ton «
Windows» installé grâce à «
BootCamp». La situation est logiquement irrattrapable. À mon avis, il faut entièrement ré-initialiser le SSD qui actuellement supporte un partitionnement hybride inexploitable. La condition préalable étant de détruire le
Groupe de Volumes Logique du
Fusion Drive réduit à des décombres inutilisables. Si tu n'as pas de sauvegarde, tes données sont perdues, à moins d'essayer de scanner les disques physiques avec un logiciel de récupération de données à partir du démarrage sur un Système externe (OS installé sur un DDE).
--------------------
J'ai quand même une poignée de bonnes nouvelles pour la fin :
⚫︎ Tu peux démarrer sur ta partition de récupération «Recovery HD» installée sur le HDD hors périmètre logique du CoreStorage pour détruire le Fusion Drive et en recréer un. Est-il sage, néanmoins, de laisser en place le Système «Windows» actuel, vu les déboires créés ?
⚫︎ Tu possèdes alors une ressource plus radicale : le démarrage en mode «Récupération par internet» (touches ⌘⌥R = cmd alt R pressées ensemble au démarrage) qui est implémenté dans le Programme Interne de ton Mac de 2012 et qui opère un téléchargement en RAM de l'image-disque BaseSystem.dmg d'une «Recovery» sur le volume monté de laquelle ton Mac pourra re-démarrer en toute indépendance de ses 2 disques physiques. Ce qui permet une ré-initialisation complète, et la re-création d'un Fusion Drive vierge. Ensuite, la «Recovery-Internet» permet le téléchargement des packages d'installation d'une version d'OSX qui n'est pas la version synchrone de celle qui existait sur le disque (donc pas d'«El Capitan»), mais l'OS-Base (d'usine) du Mac : pour toi, ça devrait être soit «Lion 10.7», soit «Mountain Lion 10.8». C'est ensuite que tu pourrais re-télécharger un installateur d'«El Capitan». Mais si tu acceptes une remarque : il est toujours malavisé d'utiliser comme OS principal un OS en développement (= "bêta"), toujours sujet à bogues (comme tu en as fait l'expérience). La version actuelle de «Yosemite 10.10.5» serait sans doute un meilleur choix...
⚫︎ Mais tu as un contournement plus commode, qui consiste à connecter à ton Mac un DDE vierge de données à préserver, à démarrer sur ta «Recovery HD» (⌘R), à initialiser le disque du DDE (menu "Effacer" dans l'«Utilitaire de Disque» de la «Recovery HD») et à activer la fonctionnalité : "Ré-installer OS X» sur le volume du DDE - ce qui te fera, ce coup-ci, installer une version d'«El Capitan». Tu pourras re-démarrer à la fin sur ce système externe permettant d'opérer pour remettre les choses en place sur tes disques et créer un Fusion Drive neuf. Et finalement, télécharger «Yosemite» ou «El Capitan» de l'AppStore pour l'installer sur le Volume Logique flambant neuf...
☞ je me tiens à ta disposition pour la suite, si besoin était, quand tu auras fait le point et avisé d'une décision...