À l'époque on il se faisait une
réclame tapageuse du procédé du «
Fusion Drive» (solidarisation logique d'un petit SSD et d'un gros HDD), arguant qu'on tenait là une
hybridation réussie de la Carpe et du Lapin Assocation du Meilleur des 2 Mondes (la vitesse du SSD et la taille du HDD) - je me suis toujours demandé ce qui pouvait bien se passer quand un des 2 disques supportant le
Fusion Drive lâchait (avec toutes les probabilités pour que ce soit le HDD, parce que disque à plateaux en rotation exposé à l'usure par l'effet du mouvement mécanique).
De ce point de vue, je trouve ton cas exemplaire - en ce que le HDD de 3 To de ton
iMac n'a pas lâché
d'un coup (ce qui aurait planté brutalement le
Volume Logique exporté sur la base de l'association logicielle des 2 disques) ; mais
progressivement - de telle sorte que cette défaillance physique graduelle a produit des
effets qui ne se laissaient pas rapporter explicitement à une cause matérielle, mais paraissaient gérables au plan formel. Des ralentissements initiaux du fonctionnement logiciel qui ont engendré ta demande originelle :
installer 2 OS en parallèle afin de juger lequel avait le meilleur rendement, aux conflits formels de 2 systèmes associatifs coexistants (d'abord 2
Fusion Drives, puis 1
Fusion Drive et 1
AppleRAID), et enfin à l'impossibilité pour les systèmes de fichiers neufs des partitions du HDD aussi bien de passer le test de la
Vérification / Réparation (alors qu'ils étaient vides), que d'accueillir les contenus d'écritures d'un OS ou d'une partition de récupération.
Je trouve, en particulier, hautement curieux et remarquable, logiquement parlant, que l'itération d'opérations formelles demi-réussies / demi-ratées (les re-partitionnements recréant des systèmes de fichiers, les associations logiques de partitions relevant des 2 disques dans un
Goupe de Volumes Logiques : CoreStorage et le déclenchement avorté d'installations d'OS) à partir de purs re-démarrages sur le Système d'installation de clés USB
bootables, ait pu produire un "
effet_mémoire" comme tu l'as expérimenté. Un phénomène des plus extraordinaire - je dois dire ! Le volume d'une clé sur laquelle se trouve à la fois copiée l'application d'install d'un OS telle qu'on peut la télécharger depuis l'AppStore + créés les fichiers de démarrage permettant à ce volume d'être
bootable - certes n'est pas protégé en écriture et pourrait très bien se voir affecté par l'inscription d'espèces de fichiers
log ou autres consignant l'histoire des événements d'emploi du Système en question, voire encore des informations relatives aux supports de destination des tentatives d'installation ; mais que dire alors d'un "
effet_mémoire" transféré de la clé d'install de «
Mavericks» dont tu te servais seulement, à la clé d'install de «
Mountain Lion» dont tu ne te servais pas depuis lurette (le phénomène de reprise du Programme d'Installation, mais aussi la propension de l'«
Utilitaire de Disque» à régénérer sans instructions provenant de l'utilisateur un format
CoreStorage comme issue réparatrice d'une partition, alors même que cet «
Utilitaire» est strictement incapable d'un tel effet exception faite de la demande d'un format
Mac OS étendu journalisé chiffré - ce qui n'était pas le cas) ?
Il ne pouvait plus alors s'agir de "
fichiers_mémoire" inscrits sur les volumes de
boot des clés, mais enregistrés dans une instance dénominateur_commun : si ce n'était pas le support des disques, puisque leurs re-partitionnements / re-formatages équivalaient à la génération de systèmes de fichiers neufs et vides dans le cadre d'une
Table de Partition GUID formellement neuve ; j'en ai induit (contre tout l'enseignement de mon expérience à ce jour - mais en recourant résolument à la maxime de
Sherlock Holmes : «
Lorsque de toutes les occurrences imaginables on a exclu l'impossible, alors une qui a beau relever de l'invraisemblable est potentiellement vraie») qu'il pourrait conjectuellement s'agir d'une consignation à la mémoire
NVRAM de la Carte-Mère sous forme d'
arguments de boot -
boot_args - chargeables par le Programme Interne du Mac =
EFI au démarrage, qui seraient passés via le fichier démarreur
boot.efi du Système de
boot de telle ou telle clé au
kernel opérateur de ce même Système de démarrage... Invraisemblable, mais non inimaginable. D'où le
reset_NVRAM qui semble avoir partiellement fonctionné.
Le
Démon_Holmésien ne cesse, nonobstant, de me susurrer à l'oreille gauche : et s'il y avait un "
effet_mémoire" consigné sur le
header même des disques ? Ah là ! là ! Il y aurait de quoi frémir... J'entends par "
header" l'en-tête logique absolu d'un disque physique considéré non pas comme un simple bloc de matière, mais auquel une forme se trouve imprimée qui en fait un support logique d'écritures : à savoir, le
secteur 0 (
s0) qui n'apparaît jamais nulle part mais qui conditionne tout le reste (comme la "
Divinité" selon
Gustave Flaubert : «
Présente partout et visible nulle part»). Par exemple, lorsqu'on re-partitionne formellement un disque, c'est sur le
secteur 0 que la table de distribution des blocs du disque en un
Tableau de partition GUID se trouve inscrit et lisible a priori. Se pourrait-il que s'y inscrivent des informations relatives à l'histoire des événements survenus formellement aux disques, pour produire ce que j'ai appelé : un "
effet_mémoire" ? En ayant joué avec les programmes de gestion des tables de partition créés par
Roderick Smith (le développeur de «
rEFInd) - dont par exemple le programme
gdisk - je me suis rendu compte qu'un archivage n'était pas à exclure des dispositifs de partitionnement formels antérieurement imprimés à un disque sur le
header : s0 de ce même disque. Bon : n'explorons pas plus avant de scénarios anxiogènes, et contentons-nous d'imaginer un "
effet_mémoire" cantonné à la seule
mémoire_NVRAM de la Carte-Mère, qu'un
reset_NVRAM serait susceptible d'« effacer »...
--------------------
Si tu veux un OS provisoirement fonctionnel, ton idée de l'installer (
Mavericks) sur le seul volume majeur de ton SSD (
/dev/disk0s2) semble incontournable. Avec la masse des données sur un DDE. Un DDE USB3 pour la vitesse de transfert. Un boîtier USB3 dans lequel tu logerais un SSD
Crucial - problème de budget - combinerait la vitesse de transfert de l'USB3 à celle de fonctionnement d'un SSD. Personnellement, j'utilise ce qui était au départ un DDE Lacie Thunderbolt acheté d'occasion, dont j'ai remplacé le DDE par un SSD
Crucial (mon
MacBook Pro Early_2011 n'a pas d'USB3, mais un port Thunderbolt) --> les résultats sont décoiffants : le démarrage d'un OS externe installé sur le volume de mon SSD_Thunderbolt ne prend que 3" de plus que celui d'un OS interne sur mon SSD_SATA. J'installe un «
Yosemite» expérimental en 7' sur ce SSD_Thunderbolt. Grâce au programme
createinstallmedia, je peux convertir un des ses volumes en un installateur
bootable de
Mavericks ou de
Yosemite en moins d'une minute ! Le clonage via «
Carbon Copy Cloner» du volume interne recelant mon OS «
Yosemite» sur le volume de sauvegarde dédié de ce SSD externe Thunderbolt prend seulement 2'. Le Thunderbolt est l'unique moyen, pour un Mac "ancien", d'exploiter des SSD externes à égalité de performances avec un SSD interne SATA.
Tu pourrais bien sûr, par ailleurs, recréer un
Fusion Drive solidarisant ton SSD interne avec un tel disque externe constamment attaché à ton Mac.
Pour cette installation, tu as le choix de 2 procédés : - a) démarrage sur ta clé d'install ; -b) démarrage par internet --> en effet, le Programme Interne =
EFI de ton
iMac est implémenté de la capacité à démarrer en ligne sur le volume d'une
Recovery stocké non sur le disque interne (comme la
Recovery HD) mais sur les serveurs Apple : il suffit d'être connecté en Wi-Fi au net et de démarrer le Mac en tenant pressées ensemble les touches ⌘⌥R (cmd alt R) jusqu'à affichage du logo d'un globe terrestre en rotation --> le démarrage sur le volume virtuel demande environ 10', à l'issue de quoi tu te retrouves dans un environnement analogue à celui d'une «
Recovery HD» avec les mêmes utilitaires. La seule différence concerne la version de l'OS qui va s'installer sur le volume de destination choisi si tu actionnes l'option :
Ré-Installer OS X --> avec la
Recovery-online, c'est l'OS-Base (d'usine ou originel) du Mac qui va être installé, pour ton
iMac = «
Mountain Lion 10.8.4» --> en cas de blocage avec ta clé, tu pourrais toujours installer
ML par ce procédé internet, quitte ensuite à opérer une mise-à-niveau à
Mavericks.
Mais ne vaudrait-il pas le coup - non exclusivement de ton intention d'installation provisoire sur le SDD seul - (ce, même si ton
iMac n'est plus sous garantie) de contacter le SAV Apple par téléphone et d'exposer ton problème et toutes les tentatives que tu as faites en vain pour rétablir la situation : à savoir un HDD de 3 To, associé logiciellement à l'achat avec le SSD par une
Fusion Drive natif, qui se trouve indûment défaillant moins de 2 ans après l'achat ? Un dossier de prise en charge pourrait peut-être par là-même être constitué, débouchant optimalement sur un remplacement grâcieux de ton HDD et la remise en place fonctionnelle d'un
Fusion Drive supportant
Mavericks ou
Yosemite. En combinant
courtoisie et
ténacité (avec un saupoudrage de
désespoir et d'
étonnement devant une défaillance si subite) - peut-être que le dossier remontant à un décideur compréhensif susciterait un "geste" commercial... Sinon, tu aurais l'idée du budget à envisager - pas si lourd que ça je pense...
--------------------
.
