Salut
Karvan
Ton problème est passionnant (si tu me passes le qualificatif) d'un point de vue théorique. Mais il ne me vient pas pour l'instant de conjecture discriminante. Je peux toujours te faire part du petit jeu spéculatif auquel je me trouve conduit > malheureusement (si tu as la patience de lire ma prose un tantinet abstraite et abstruse) tu constateras que « la montagne [conceptuelle] accouche d'une souris [empirique] »
Si tu observes la table de partition du disque incriminé :
Bloc de code:
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_CoreStorage Warehouse 4.0 TB disk3s2
3: Apple_Boot Boot OS X 134.2 MB disk3s3
> RAS pour la partition n°
1 =
EFI --> en-tête régulier de la table de partition
GUID > la partition n°
2 Warehouse est la partition sur laquelle se trouve échafaudé le
Groupe de Volumes Logiques du
CoreStorage Chiffré > enfin tu notes une partition n°
3 :
Apple_Boot Boot OS X 134.2 MB disk3s3.
C'est cette dernière partition qui est intéressante : c'est la partition dite du «
booter » (ou démarreur logique du
CoreStorage Chiffré) > toujours inscrite au
pied immédiat de la partition
CoreStorage correspondante. Lorsque tu démarres ton Mac > normalement c'est la seule partition du disque automatiquement montée en un volume
Boot OS X > de manière à ce que le dossier du «
booter » :
com.apple.Boot.P y recelé soit éventuellement accessible.
Je présume que tu as choisi (at:
menu >
Préférences Système >
Disque de démarrage) le volume (non chiffré)
TerraMac comme volume-cible de
démarrage automatique > ce qui veut dire que dans la mémoire
NVRAM de la Carte-Mère, à l'entrée :
efi-boot-device (appareil de démarrage automatique de l'
EFI <
EFI = le
Programme Interne du Mac ou
Firmware, recelé dans une puce de la Carte-Mère et activé à la pression sur le bouton
Power>) se trouve inscrite l'adresse constituée par l'
UUID de ce volume sur la partition
disk0s2. Donc, logiquement parlant, l'
EFI > lit l'adresse de boot de l'
efi-boot-device > et devrait
illico filer à l'en-tête du volume-cible (
TerraMac) sur lequel une bénédiction (
blessing) a inscrit le
chemin au
boot_loader (démarreur d'OS) :
boot.efi à exécuter en préambule (at:
/System/Library/CoreServices/boot.efi). Dès que l'
EFI a exécuté ce
boot_loader > l'écran s'allume > et une s'affiche signalant l'activation du
boot.efi.
Ce qui est étrange dans ton cas > c'est que cette séquence logique
déterministe : {
EFI >
efi-boot-device >
header du volume
TerraMac > chemin au
boot.efi > exécution du
boot.efi} se trouve "interceptée" (si je puis dire) par le
montage, non pas du
Volume Logique Warehouse (il est
verrouillé à ce stade "dans" le
Volume Physique du
CoreStorage et
non exporté à ce moment-là à cause du chiffrement) > mais du volume du «
booter » :
Boot OS X.
On peut présumer qu'au moment où l'
EFI accède à l'instruction de l'
efi-boot-device en
NVRAM > normalement tous les volumes montables sont
actuellement montés :
TerraMac >
Recovery HD (collatérale) > «
booter »
Boot OS X dédié au
CoreStorage Chiffré Edition > «
booter »
Boot OS X dédié au
CoreStorage Chiffré Warehouse > «
booter »
Boot OS X dédié au
CoreStorage Chiffré Time Machine BU.
Pourquoi alors l'itinéraire logique déterministe de l'
EFI serait-il intercepté par
le seul montage du volume
Boot OS X du «
booter » du
CoreStorage Chiffré Warehouse ?
C'est là que je sèche en terme de conjecture théorique discriminante :
- si je me figure le volume du « booter » Boot OS X dédié au CoreStorage Chiffré Warehouse déjà actuellement monté > pourquoi (diantre !) ce volume monté intercepterait-il l'EFI > puisque le chemin de l'EFI est tracé de manière déterministe par l'instruction at: efi-boot-device en NVRAM ?
- si je suppose alors qu'il y ait un problème de montage du « booter » Boot OS X dédié au CoreStorage Chiffré Warehouse > alors il serait envisageable que le trajet exécutif de l'EFI soit suspendu > le temps que s'effectue ce montage du volume du « booter ». En empilant alors une conjecture seconde : impossibilité de monter le volume de ce « booter » à ce stade > alors il serait envisageable que le trajet exécutif de l'EFI se trouve suspendu sine die.
=> ce qui ne fait que relancer le problème :
pourquoi alors y aurait-il
échec du montage du seul volume du «
booter » dédié au
CoreStorage Chiffré Warehouse (et pas du montage des volumes des autres «
booter ») ? Et pourquoi, une fois l'OS du volume
TerraMac démarré > attacher alors seulement le disque
Warehouse permet un
montage sans échec (ce qui implique au départ le montage du «
booter ») ?
Je suis en train de me laisser déborder gentiment par le nombre des facteurs conjecturaux > sans grande capacité discriminatoire en cours de spéculation. Bon ! si je dis : le
montage d'un volume une fois un
OS démarré est de type «
en kernel » > je pourrais dire alors que le
kernel de l'OS n'a aucun problème avec le «
booter » de
Warehouse > non plus qu'avec le système de fichiers du volume etc. Par contre, au
démarrage du Mac > il n'y a
pas de montage de volumes «
en kernel », puisqu'il n'y a
pas de
kernel activé (pas d'OS démarré encore).
Ma mince conjecture devient alors : c'est le montage «
hors kernel » des volumes, dans la phase de pré-boot de l'
EFI, qui poserait problème relativement au
volume du «
booter » du
CoreStorage Chiffré Warehouse.
Pourquoi lui et lui seul à ce stade préliminaire ? - c'est là que je sèche.
