Salut
benjinthesky
Même si une voix intérieure me chuchote que cet exercice spéculatif va exagérer dans l'abstraction > j'y persiste > car l'abstraction est la dimension des déterminations de la pensée.
Lorsque que je boot en maintenat alt pour choisir le disque il me propose qu'un seul disque "FD" (avant il me proposait 2 disque FD), et le
boot plante. Mais parfoi il me propose les 2 disques (comme avant) FD lors du boot, je selectionne le 2eme (SSD) et le boot fonctionne.
Donc mon ssd n'est pas programmé en disque de boot, mais peut on corriger cela sur un FusionDrive??
Comme le montre le tableau du
CoreStorage (résultat de la commande :
diskutil cs list) que tu as posté > un dispositif de type "
Fusion Drive" se laisse décrire ainsi :
- un Physical Volume se trouve « importé » sur chacune des 2 partitions d'accueil : la disk0s2 du SSD (slice 2 <tranche 2> du disk0) et la disk1s2 du HDD. Chacun de ces Physical Volumes équivaut à la conversion de l'espace de blocs de chacune des 2 partitions en un "disque dur émulé". Cette conversion de l'espace des partitions en "disques durs émulés" de type Physical Volumes implique une modification de l'en-tête (header) de chacune des partitions : là où étaient directement inscrits les fichiers du système de fichiers JHFS+ gérant l'espace de chacune des partitions pour exporter un volume standard > ont été substitués des fichiers descripteurs de type CoreStorage.
- un Logical Volume unique se trouve « exporté » à partir des 2 Physical Volumes des partitions disk0s2 & disk1s2. Ce Logical Volume n'est pas exactement un "volume" (au sens standard du terme) comme son intitulé de "Volume" incite à l'imaginer. Car un "volume" (au sens standard) est le produit du système de fichiers précurseur inscrit sur l'en-tête d'une partition > système de fichiers qui présente l'espace des blocs de la partition comme un "répertoire de fichiers" = un volume, susceptible d'être monté / démonté.
Mais le Logical Volume d'un CoreStorage n'est pas suscité par un système de fichiers précurseur, car son précurseur, au contraire, est un (ou deux pour un Fusion Drive) Physical Volume : un disque dur émulé, à partir duquel il se déploie par « exportation ». Un Logical Volume est alors un disque virtuel lui aussi : disque miroir du disque dur émulé du Physical Volume (une redondance logique).
C'est sur l'en-tête de ce disque virtuel exporté (dev node) que se trouve ancré le système de fichiers JHFS+ > système de fichiers qui récupère sa fonction standard de présentation de l'espace logique du Logical Volume comme un "répertoire de fichiers" = un "volume", susceptible d'être monté / démonté. Le volume apparent (montable / démontable) d'un CoreStorage est donc un « volume de Volume Logique », Volume Logique lui-même exporté à partir d'un Volume Physique - sans que l'exportation en question soit l'effet produit du système de fichiers, car ce dernier n'est pas le précurseur du Volume Logique, mais son dépendant (il réside sur un dev node de ce Volume Logique et présuppose toujours son exportation préalable).
- toute la question devient alors : comment s'opère l'exportation du Volume Logique > si elle n'est pas l'effet direct d'un système de fichiers précurseur > mais si elle doit s'opérer sans les services d'un tel système de fichiers > en tant qu'exportation logique à partir d'un Volume Physique qui est un disque dur émulé ? La réponse est : par un mécanisme logique strictement analogue à l'exportation d'un volume-RAID à partir des bandes RAID inscrites sur des partitions de disques en cas d'existence d'une « Matrice-RAID » > mécanisme qui consiste en l'existence d'un « booter » sur une partition logique résidant au pied immédiat de la partition concernée.
Un Fusion Drive impliquant 2 Physical Volumes importés sur 2 partitions de disques : les disk0s2 & disk1s2 > il est donc logiquement nécessaire que 2 partitions logiques de type « booter » existent au pied immédiat des partitions qui ont le statut de Physical Volumes du CoreStorage : la partition disk0s3 = Apple_Boot : Boot OS X n°1 & la partition disk1s3 = Apple_Boot : Boot OS X n°2. Ces partitions « booter » (générateur logique) recèlent les fichiers exécutifs permettant l'exportation d'un Volume Logique à partir de Volumes Physiques, en tant que Disque Virtuel de second ordre déployé sans l'intervention d'un système de fichiers précurseur. C'est l'EFI (Programme Interne du Mac) qui peut seule exécuter l'un ou l'autre « booter » d'un CoreStorage "Fusion Drive" > afin d'enclencher l'exportation du Volume Logique.
=> tu comprends alors « théoriquement » l'
asymétrie de présentation entre l'écran du
Boot_Manager de l'
EFI (affiché par la touche "
alt") et le panneau du
Disk_Manager de l'OS (affiché dans les
Préférences Système). À l'écran du
Boot_Manager de l'
EFI > ne sont accessibles que les «
booter » du
CoreStorage "
Fusion Drive", car à ce stade le
Volume Logique n'est
pas encore exporté à partir des
Physical Volumes > il ne le sera que par exécution par l'
EFI d'un des 2 «
booter » disponibles (entraînant l'exécution du «
booter » comparse - cf. ci-dessous). Tu as donc (normalement) les
2 «
booter » affichés du
CoreStorage "
Fusion Drive" : celui de la partition
disk0s3 (SSD) et celui de la partition
disk1s3 (HDD). Alors que le panneau affiché par le
Disk_Manager de l'OS > intervient
après le démarrage de l'OS > qui présuppose que le
Volume Logique du
CoreStorage ait été exporté à partir des 2
Physical Volumes > et que le
système de fichiers JHFS+ terminal, ancré sur le
dev node du
Volume Logique, ait permis le montage du volume standard recelant les fichiers du Système.
--------------------
Mais voici à présent une « sur-complication » de ce scénario qui peut apparaître déjà assez "chinois" -->
- au pied immédiat de la partition CoreStorage du HDD (et toujours exclusivement du HDD) doit résider nécessairement la partition de secours Recovery HD solidaire de macOS > càd. exactement en disk1s3. Mais le mécanisme logique d'exportation d'un Volume Logique à partir des Physical Volumes d'un CoreStorage "Fusion Drive" implique de toute nécessité qu'au pied immédiat de la partition CoreStorage du HDD (aussi bien qu'au pied de celle du SSD) existe un « booter » du Volume Logique > càd. exactement en disk1s3.
- Il y a donc conflit logique des localisations, puisque la partition disk1s3 se trouve disputée par 2 nécessités logiques concurrentes : la Recovery HD de macOS et le « booter » du Volume Logique. De ces 2 nécessités logiques conflictuelles > la nécessité du « booter » est primordiale, car le « booter » conditionne l'exportation primitive du Volume Logique CoreStorage dont dépend la possibilité de démarrer macOS > alors que la Recovery HD recèle un Système Recovery OS alternatif de macOS dont le démarrage n'a qu'un statut secondaire.
- Pour résoudre ce conflit de localisation et de précellence > 2 dossiers logiques se trouvent créés dans le volume de la Recovery HD : un dossier com.apple.Boot.S recelant les exécutables du « booter » et le dossier standard com.apple.recovery.boot recelant le Recovery OS. De ces 2 dossiers > le dossier du « booter » a la précellence logique > ce qui explique qu'il soit affiché en tant que démarreur à l'écran du Boot_Manager de l'EFI > en masquant le dossier du Recovery OS (qui n'est alors démarrable que par une commande directe ⌘R).
--------------------
=> Ce que tu expérimentes avec ton
CoreStorage "
Fusion Drive" est alors un affichage "
intermittent" d'un des 2 «
booter » au lieu qu'il y ait toujours affichage
simultané des 2. Normalement, lorsque les 2 «
booter » sont affichés
ensemble > il est possible de choisir comme «
démarreur » l'un des 2 indifféremment comme "
point de départ génératif" de l'
exportation du
Volume Logique > car l'exécution d'un des 2 «
booter »
détermine logiquement l'exécution de l'autre «
booter » > de telle sorte que l'
exportation du
Volume Logique se trouve activée sur les 2
Physical Volumes de base.
Si tu ne vois affiché qu'
un seul «
booter » et pas les 2 > il est clair que cela signifie que l'autre «
booter » n'est pas logiquement accessible à ce moment-là > et donc que l'
exportation du
Volume Logique du "
Fusion Drive"
ne peut s'opérer, faute d'activation du second
Physical Volume.
Tu dis que le «
booter »
intermittent est celui du
SSD (partition
disk0s3) > pas celui du HDD (partition
disk1s3 =
Recovery HD convertie à la fonction
prioritaire de «
booter », et à la fonction
secondaire de
Recovery OS). À quoi le vois-tu (me demandé-je) ? - bien forcé de me faire les réponses de mes demandes ici --> je vais supposer (supposition peut-être hasardeuse) > que si tu survoles (
hover over) le "disque" de ce «
booter » avec ton pointeur > mention apparaît en-dessous de sa partition-disque de résidence > ce qui te permettrait de dire qu'il s'agit bien de celui du SSD (j'erre peut-être ici sur un point décisif pour ce qui est du diagnostic des raisons de la panne).
S'il en est bien ainsi («
booter » intermittent de la seule partition
disk0s3 du
SSD) > le problème
ne découlerait
pas alors d'un
conflit dans le volume de la
Recovery HD des 2 dossiers concurrents (du «
booter » :
com.apple.Boot.S vs le dossier
Recovery OS :
com.apple.recovery.boot) > mais ne concernerait que le «
booter »
unilatéral du
SSD.
S'il s'agit bien du «
booter »
unilatéral du
SSD > alors je conjecture que le problème a une
source matérielle : la
nappe du ci-devant Super-Drive à laquelle est actuellement connecté le SSD est en voie de
défaillance (
et/ou il n'y a pas assez de
débit de cette connexion SATA pour un
SSD).
NB. Tu peux poster ici en-copier-coller le tableau résultant d'une commande :
> tableau qui montrera les 2 partitions
CoreStorage flanquées des 2 partitions «
booter » : une
Apple_Boot BOOT OS X disk0s3 pour le
SSD & la
Apple_Boot Recovery HD disk1s3 pour le
HDD (où la
Recovery HD assume prioritairement la fonction de second «
booter » du
CoreStorage).
--------------------
