Installer 2 OS différents sur le même disque

[Membre supprimé 1060554]

Le 1er Mai le travail est gratuit : c'est donc un jeu​

Salut Guyllaume.

La grande capacité de mon SSD me permet actuellement d'avoir 5 versions d'OSX installées en parallèle sur autant de volumes : 10.6, 10.7, 10.8, 10.9 et 10.10. "Opulence" enviable? En théorie, seulement. C'est un peu comme si je m'étais fait bâtir, dans l'aile studieuse d'un château, pas moins de cinq "Librairies" à la suite (selon le terme du Français classique désignant le Bureau-Bibliothèque où l'on aime se tenir, à l'image d'un Montaigne). Eh bien! Un homme n'ayant jamais qu'un seul "cul", il ne peut jamais occuper qu'un siège unique à la fois.

Pouvoir, en effet, choisir entre de nombreuses options disponibles est certes avantageux à la liberté, d'un point de vue théorique. Mais la pratique a vite fait d'infliger un démenti à cette vue de l'esprit : s'il y a bien quelque chose d'insupportable, c'est la perspective réitérée d'avoir à re-choisir chaque jour parmi les mêmes options récurrentes, au risque de démentir demain l'option d'aujourd'hui qui reniait celle de la veille. Cette inconstance de la liberté équivaut à une frivolité des décisions. Se tenir, par contre, à un choix, ce n'est pas renoncer à la liberté, puisqu'elle a présidé naguère à la décision - c'est en confirmer la valeur par le serment d'y persévérer. Comme l'énonce bien l'adage populaire : "mon siège est fait : je m'y tiens".

Ce petit dérapage en guise de 1er Mai de l'esprit amène une conclusion simple : l'utilisateur "fait son siège" commodément dans un seul OS pour une période donnée. Je ne fais pas exception à cette règle : j'ai fait mon siège dans l'OS «Yosemite» et la récurrence de cet environnement logique, choisi une fois au départ, a pris le charme de l'habitude - cette ressemblance d'aujourd'hui avec hier qui fait la durée d'un présent. Les autres OS installés sur mon SSD - eh bien! je ne m'y loge jamais habituellement ; ils ne me servent qu'occasionnement, pour des expérimentations localisées, aussi vite refermées qu'ouvertes.

N'aie pas à regretter, donc, que la structure logique du Fusion Drive ne permette pas le parallélisme fonctionnel de 2 OS, pas plus que la petite taille de ton SSD ne supporte un découpage entre de multiples volumes installalables --> la pratique aurait vite fait de te faire privilégier un seul et unique environnement informatique. Si je n'utilise couramment que moins de 60 Go de SSD pour mon OS privilégié, qu'auras-tu à m'envier si tu consacres à un OS préférentiel les 120 Go de ton SSD (avec ou sans Fusion Drive)?

Pour reprendre ma verte référence : la largeur du "cul" de chaque homme étant à quelques détails près égale à celle d'un autre, le plus grand des monarques pourra bien se faire construire le plus riche des trônes - la largeur de son postérieur demeurée égale à celle d'un manant ne lui fera pas occuper un siège d'une surface supérieure...

--------------------
​

Pour ce qui est de l'installation de ta clé, ne te prends pas la tête : le volume de la clé n'a pas à être renommé a priori, car le programme d'installation utilisé par la commande du «Terminal» : le binaire createinstallmedia commence toujours par re-formater le volume de la clé qu'on lui a désigné comme destination en lui imposant par défaut l'intitulé : Install O S X Mavericks (le dernier nom variant selon la version d'OSX à installer). C'est une fois ta clé installée, que tu peux a posteriori renommer son volume (dont l'image-disque est affichée par le Finder sur le Bureau de session) par l'intitulé que tu préfères - donc Mavericks 10.9.5 si tu le souhaites pour ta gouverne ultérieure.

Ne te préoccupe pas non plus des différences apparentes qu'il pourrait y avoir entre le volume installé par la commande du «Terminal» et celui installé par le logiciel de Guillaume Gète : «DiskMaker X». Gète a tripatouillé les choses dans ses versions récentes de «DiskMaker» d'une manière parfaitement dispensable (tu trouveras dans ce fil une exploration byzantine de la question par le signataire : ☞comment-mettre-a-jour-son-os-de-lion-a-mavericks☜). À mon avis, les ingénieurs d'Apple fournissant dans chaque installateur d'OSX à partir de «Mavericks 10.9» un programme natif permettant de créer un média d'installation (le programme createinstallmedia), c'est ce dernier avec sa logique d'installation qui doit être considéré comme le paradigme, absolument pas le programme de Gète qui est devenu non fiable depuis «Mavericks» (voir les attestations de Renaud31 dont je salue l'acuité intellectuelle).

Et quel est-il ce paradigme du programme Apple natif createinstallmedia? Le voici résumé en une image (puisque, si j'en crois Bonaparte : «un petit croquis vaut mieux qu'une longue explication») -->

Le programme createinstallmedia, lorsqu'on l'invoque correctement, exécute 3 opérations successives :
​

- a) un effacement/reformatage du volume de destination auquel est conféré le nom par défaut : Install OS X [Nom_de_l'OS]. Cette opération est commandée automatiquement par l'option finale de la commande : --nointeraction qui équivaut à : reformater le volume de destination sans intéractivité avec l'utilisateur mais en assumant a priori une réponse y = yes.

- b) une recopie de l'installateur tel qu'il a été téléchargé depuis l'AppStore (ce que n'importe qui ferait aussi bien en manuel via le Finder).

- c) la création finale du Système de boot qui va permettre seul à la clé d'être démarrable : comme montré dans mon image, il y a 2 sortes de composants : 2 fichiers "lanceurs" contenus dans le dossier .IABootFiles (soit comme dans n'importe quel OSX un boot_loader : boot.efi et un bloc_cache : kernelcache - solidarisant un clone du code du kernel ou "noyau" avec l'enveloppe globale des kexts ou "extensions du noyau") ; et un Système chargeable réduit aux stricts Essentials : ceux-ci, en réalité, ne constituent pas un Système démarrable intrinsèque, mais ne contiennent que des Préférences de pré-boot orientant le montage, dans l'installateur Install OS X Mavericks, du disque virtuel InstallESD.dmg recelant dans son volume monté OS X Install ESD un 2è disque virtuel : le BaseSystem.dmg qui monte un volume secondaire : OS X Base System qui est absolument identique au Volume-Système d'une «Recovery HD».​

☞ par suite, lorsque la clé est choisie comme disque de démarrage, le Programme Interne du Mac (EFI) exécute le chargeur boot.efi qui lance le bloc kernelcache, en suite de quoi le Système de pré-boot oriente le montage successif des Disques/Volumes gigognes : InstallESD.dmg --> OS X Install ESD --> BaseSystem.dmg --> OS X Base System et l'utilisateur se retrouve dans un environnement strictement identique à celui d'une «Recovery HD» avec les mêmes utilitaires à disposition. La seule différence, est que la fonctionnalité d'install n'est pas un "Ré-Installer OS X" qui invoque du Programme d'Instalaltion le téléchargement en ligne de packages non recelés sur le volume de la «Recovery HD» ; mais un "Installer OS X» qui invoque du Programme d'Installation la copie directe des fichiers-Système de l'OS d'après les packages recelés dans l'Installateur.

[Si tu t'étonnais de la prolixité de dossiers/fichiers de ma clé, c'est seulement parce que j'ai rendu visibles ces composants normalement porteurs de l'attribut d'invisibilité : le flag_hidden qui commande au Finder de ne pas les afficher graphiquement.]
​

--------------------
​

Pour ce qui est de la ligne de commande, elle n'est pas plus de mon invention que de celle des joueurs de pipeau (ou de flûte de Hamelin) qui pullulent sur le Net en agitant de petits fanions d'inventeurs : elle est d'origine_Apple, exactement comme le programme createinstallmedia qu'elle permet d'invoquer.

Sa prolixité apparente :

sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/"nom_du_volume_de_la_clé" --applicationpath /Applications/Install\ OS\ X\ YMavericks.app --nointeraction

ne doit pas, par la multitude de ses "arbres", dissimuler la simplicité du "bosquet" d'un point de vue logique --> en effet, elle se répartit en 4 arguments liés : 1° invocation préalable du programme createinstallmedia à la place où on peut le trouver avec le préfixe sudo pour opérer en droits root ; 2° ciblage du volume de destination de l'installation, annoncé par l'option : --volume ; 3° ciblage du dossier source d'installation, annoncé par l'option : --applicationpath ; 4° déclaration d'une préférence de formatage automatique a priori du volume de destination par l'option : --nointeraction.

Personnellement, quand j'ai à utiliser cette commande, j'ai mémorisé la séquence : createinstallmedia --> volume --> installateur --> formatage et voici comment je l'exécute concrètement. Je lance le «Terminal» où je n'écris que :

sudo

suivi d'un saut d'espace. À partir de là, je vais pêcher là où il se trouve sur un quelconque DDE l'installateur de mon choix, je fais ctrl_clic (control_clic ou clic secondaire) sur l'icône et je choisis : Afficher le contenu du paquet --> ce qui me permet de naviguer à : Contents/Resources où je trouve à sa place alphabétique le programme Apple : createinstallmedia --> je fais carrément au pointeur un glisser-déposer de ce fichier dans la fenêtre du «Terminal» et j'obtiens l'équivalent de :

sudo /chemin_à_l'installateur/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia

avec un saut d'espace automatique au final. Je saisis alors en manuel : --volume à la suite et je saute une ligne, ce qui me donne :

sudo /chemin_à_l'instalallateur/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume

--> je vais à présent à l'image-disque du volume de ma clé monté sur mon Bureau de session, et je fais carrément un glisser-déposer dans la fenêtre du «Terminal» ce qui renseigne automatiquement le chemin au volume de la clé et son nom au final - pour donner provisoirement ce qui suit :

sudo /chemin_à_l'installateur/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/Nom\ du \ Volume\ de\ ma\ clé

avec saut d'espace automatique au final.

J'ajoute à la main : --applicationpath et je saute un espace. Puis je vais dans le Finder à mon installateur d'OSX où qu'il soit et au pointeur j'en fais carrément un glisser-déposer dans la fenêtre du «Terminal» ce qui renseigne automatiquement le chemin à l'installateur et son nom à la fin - avec saut d'espace automatique en queue -->

sudo /chemin_à_l'installateur/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/Nom\ du \ Volume\ de\ ma\ clé --applicationpath /chemin_à_l'installateur/Install\ OS\ X\ Mavericks.app

Je termine manuellement par : --nointeraction (qui veut dire : formater le volume de la clé sans demander l'autorisation préalable) et j'obtiens au total un :

sudo /chemin_à_l'installateur/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/Nom\ du \ Volume\ de\ ma\ clé --applicationpath /chemin_à_l'installateur/Install\ OS\ X\ Mavericks.app -- nointeraction

--> je lance et, après authentification à l'aveugle par le mot-de-passe admin, ça s'exécute en un peu moins de 15'.

[J'entends s'exclaffer d'avance ceux qui s'imaginent qu'il est toujours plus facile de recopier bêtement des commandes sans les comprendre, à les recréer rationnellement par une contention de l'esprit. Je les mets au défi de lancer plus vite que moi le programme d'installation createinstallmedia --> le temps qu'ils renseignent dans Google "créer clé d'install OSX commande Terminal" et obtiennent une réponse recopiable, j'aurais déjà recréé la commande et lancé son exécution. Il est toujours plus facile d'agir à partir d'une compréhension de principe que d'appliquer mécaniquement des recettes qu'il faut toujours aller repêcher dans le grand livre de cuisine Google, parce que ne pas en avoir mémorisé la syntaxe faute d'une compréhension logique de son sens empêche de les garder formellement en tête et force toujours à aller les recopier dans un bréviaire.]

--------------------​

​

 

[Guyllaume]

Bonjour macomaniac.

Merci pour l'explication.
Je ne savais pas qu'on pouvait utiliser des glisser-déposer avec le Terminal. C'est vraiment très pratique ! Non seulement, ça permet comme tu le dis de bien comprendre la logique de la commande, et puis ça évite de faire des fautes de frappe.

L'opération n'a, là encore, pas mis 15 minutes mais... 29 ! C'est une clé en USB 2, voilà peut-être le pourquoi du comment.


On en arrive donc, si j'ai bien suivi, à la phase finale de nos opérations.
Partons du principe que je "casse" mon Fusion Drive :

1) est-il alors possible d'installer un OS sur le SSD et un autre OS sur le HDD ? (problème : 128 Go ça fait quand même léger je trouve, surtout quand je travaille sur des projets nécessitant de nombreux médias lourds)

2) est-ce possible de partitionner le HDD en deux partitions de 1,5 To chacune et d'installer un OS différent sur chaque partition ? Si oui, comment utiliser le SSD dans ce cas de figure ?


Si toutefois il est impossible d'avoir et deux OS différents, et de bénéficier de la vitesse du SSD, alors je me résoudrais à installer un seul OS.

Merci d'avance.

 

[Membre supprimé 1060554]

Je vois que tu as l'outil (la clé d'install de «Mavericks») --> tu te demandes à présent comment utiliser au mieux tes ressources de disques : 1 SSD de 120 Go et 1 HDD de 3 To.

Je suis ton raisonnement : tu trouves (vu ton type d'utilisation) qu'un OS sur les 120 Go seulement de ton SSD, c'est un peu juste à terme pour ton usage ; par contre, un autre OS sur les 3 To de ton HDD, ce serait trop d'espace. Donc tu te demandes si un Fusion Drive = la totalité de ton SSD (120 Go) + ½ de ton HDD (1,5 To) sur le volume duquel serait installé «Mavericks (par exemple) et un volume standard = l'autre ½ de ton HDD (1,5 To) sur lequel serait installé «Mountain Lion» (autre exemple) - ça ne serait pas la bonne option?

Je crois que ton fil aura été décidément l'espace de toutes les explorations : conjecturelles et expérimentales. Comme j'y ai pratiqué un excès de conjectures a priori que le critère a posteriori de l'expérimentation est venu démentir --> je me suis défié de moi-même. Alors j'ai expérimenté la conjecture ce matin : j'ai connecté à mon Mac un SSD-Thunderbolt et un HDD-USB et j'ai créé un Fusion Drive solidarisant une partition du SSD avec une partition du HDD --> j'ai installé successivement (par clonage de Systèmes préinstallés sur d'autres disques pour gagner du temps) «Snow Léopard 10.6.8» (mon Mac est compatible) et «Lion 10.7». Par ailleurs, une autre partition de mon SSD-Thunderbolt supporte le clone de mon Système principal «Yosemite 10.10.3» ; et une autre partition de mon HDD-USB supporte le clone d'un Système «Snow Léopard 10.6.8» (bootable isolément).

Voici la sanction de l'expérience : l'OS installé a posteriori sur le Volume Logique exporté par le Fusion Drive ne démarre pas --> l'EFI exécute bien le boot_loader : boot.efi (logo ) et ce dernier lance bien le kernel (roue crantée giratoire), mais le kernel, quant à lui, après une minute environ de tentative pour charger les kexts (extensions du noyau), plante : affichage à l'écran du logo ⊘ d'interdiction de stationner). Que l'OS installé sur le volume du Fusion Drive soit «Snow Léopard» ou «Lion». Par contre, l'OS de l'autre partition démarre (que ce soit celle du SSD ou du HDD), par une sorte de privilège de primogéniture.

Je me sentais passablement agacé de ne pas apercevoir clairement & distinctement la raison de ces échecs expérimentaux, qui tous mettent en lumière une limitation de compatibilité d'un format CoreStorage construit en mode "gestion multi-disque" (Fusion Drive) avec une installation standard "mono-disque" d'un OS en parallèle.

--------------------​

Donc j'ai conjecturé et expérimenté dans la foulée une autre solution potentielle : remplacer la technique Fusion Drive par la technique Apple RAID. Pour le faire bref : la problématique est identique (solidariser 2 partitions relevant de 2 disques séparés pour exporter un seul volume en sortie), la logistique diffère : un Fusion Drive étant un Apple RAID avec le format CoreStorage ; un Apple RAID étant un Fusion Drive sans le format CoreStorage.

J'ai donc commencé par créer 2 Apple RAID parallèles : l'un solidarisant une partition A de mon SSD-Thunderbolt avec une partition A' de mon HDD-USB ; l'autre solidarisant une partition B de mon SSD-Thunderbolt avec une partition B' de mon HDD-USB --> j'ai donc obtenu en sortie 2 Volumes Concaténés installables, sur lesquels j'ai installé par clonage 2 OS démarrables (intrinsèquement) : «Mavericks» sur le volume A et «Yosemite» sur le volume B.

Résultats : je démarre sans problème sur le volume RAID B («Yosemite») ; par contre le volume RAID A («Mavericks») est invisible à l'écran de choix du disque de démarrage et, s'il est listé dans le panneau de Préférences Système/Disque de démarrage, par contre sa sélection ne tient pas au volume et c'est toujours sur le volume RAID B que s'opère le démarrage --> le blocage ressemble trait pour trait à celui qui intervenait en cas de 2 Fusion Drives parallèles : dans ce cas de figure, c'est toujours uniquement le dernier volume qui démarre, pas le premier.

--------------------
​

Je me suis donc dit (fidèle à la maxime stoïcienne de ton presque homonyme Guillaume d'Orange le Stathouder - qui perdit toutes ses batailles contre l'occupant espagnol des Pays-Bas sauf la dernière qui décida de la guerre : «Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer») : pourquoi ne pas être fou et conjecturer le montage le plus baroque : créer en parallèle 1 Fusion Drive (solidarisant avec mode CoreStorage une partition A de mon SSD-Thunderbolt avec une partition A' de mon HDD-USB) et 1 Apple RAID (solidarisant sans mode CoreStorage une partition B de mon SSD-Thunderbolt avec une partition B' de mon HDD-USB)? --> aussitôt imaginé, aussitôt exécuté, ce qui m'a exporté 2 volumes spéciaux : un Volume Logique A sur lequel j'ai cloné «Mavericks» et un Volume AppleRAID B sur lequel j'ai cloné «Yosemite».

☞ VICTOIRE

: les 2 volumes sont alternativement démarrables (tout était donc, non pas un problème de caractère démarrable intrinsèquement des OS installés sur des volumes concurrents, mais un problème de validation des partitions de démarrage : Boot_OS_X qui se créent en flanquement d'un Volume Logique : CoreStorage ou d'un Volume Concaténé : AppleRAid --> s'il existe en parallèle 2 structures concurrentes de même type (2 Fusion Drives ou 2 Apple RAID) solidarisant chacune 1 partition d'un SSD et 1 partition d'un HDD, alors il y a instauration en flanquement de ces partitions supports de volumes de paires de petites partitions de démarrage spécifiques : Boot_OS_X qui soumettent le programme de gestion des disques diskarbitration à une alternative qui le dépasse --> sa manière de régler cette alternative des options consiste à en neutraliser une au détriment de l'autre --> seule la dernière partitions de démarrage : Boot_OS_X est validée comme carte d'amorçage, et l'autre est considérée comme invalide (et par suite l'OS parfaitement démarrable intrinsèquement du volume concerné se trouve mis hors course) --> seul le volume dépendant de la partition d'amorçage validée se trouve ainsi affiché comme disque démarrable et par là même peut être démarré.

La solution à ton problème consiste donc à partitionner ton SSD en 2 : partition A = 60 Go (destinée à un Fusion Drive) et partition B = 60 Go (destinée à un Apple RAID) ; et à partitionner pareillement ton HDD en 2 : partition A' = 1,5 To (destinée à un Fusion Drive) et partition B' = 1,5 To (destinée à un Apple RAID) --> il suffit alors de créer un Fusion Drive CoreStorage solidarisant les partitions A (SSD) et A' (HDD) pour rejeter un Volume logique de 1,56 To que j'appellerais par exemple «Mavericks» ; et de créer en parallèle un AppleRAID Concaténé solidarisant les partitions B (SSD) et B' (HDD) pour rejeter un Volume Concaténé de 1,56 To que j'appellerais par exemple «Mountain Lion». Cela fait, à partir de 2 démarrages successifs sur des clés d'install, il suffira d'installer «Mavericks» sur le volume homonyme et «Mountain Lion» sur le volume homonyme --> d'après mon expérimentation, les 2 volumes sont équitablement démarrables en alternance (car les partitions d'amorçage : Boot_OS_X ne sont apparemment pas interprétées comme contradictoires par le programme de gestion des disques diskarbitration mais sont validées par lui comme constituant une alternative compatible --> par suite, les volumes qui en relèvent sont affichés comme disques de démarrage altenatifs et le démarrage optionnel sur l'un ou l'autre est possible).

Il n'y a aucune différence de fond entre un Fusion Drive et un AppleRAID sauf sur un point. Dans chaque technologie de solidarisation de partitions de disques distincts, c'est toujours le SSD qui a la priorité des écritures jusqu'à une limite d'environ 10% de l'espace disponible. C'est donc toujours sur le SSD que s'écrivent toutes les écritures inaugurales : donc celles du Système (j'ai pu vérifier ce point en cassant un de mes Apple RAID expérimentaux : c'était uniquement sur la partition du SSD que le Système avait été cloné). La différence, c'est qu'un Fusion Drive est une union dynamique, un AppleRAID une union statique --> dans un Fusion Drive, il s'opére des rétro-cessions d'écritures entre les 2 disques en fonction du plus grand nombre d'accès des blocs de données en lecture, de manière à transférer les plus lues au SSD et rétrocéder les moins lues au HDD ; dans un AppleRAID, les écritures sont fixées un fois pour toutes au support d'inscription premier (ne pas s'exagérer quand même la puissance transactionnelle d'un Fusion Drive --> ça reste une optimisation marginale).

--------------------​

 

[Sly54]

La solution à ton problème consiste donc à partitionner ton SSD en 2 : partition A = 60 Go (destinée à un Fusion Drive) et partition B = 60 Go (destinée à un Apple RAID) ; et à partitionner pareillement ton HDD en 2 : partition A' = 1,5 To (destinée à un Fusion Drive) et partition B' = 1,5 To (destinée à un Apple RAID) --> il suffit alors de créer un Fusion Drive CoreStorage solidarisant les partitions A (SSD) et A' (HDD) pour rejeter un Volume logique de 1,56 To que j'appellerais par exemple «Mavericks» ; et de créer en parallèle un AppleRAID Concaténé solidarisant les partitions B (SSD) et B' (HDD) pour rejeter un Volume Concaténé de 1,56 To que j'appellerais par exemple «Mountain Lion».

Bravo pour ta persévérance !

Par contre, il ne faudrait pas qu'une des partitions patatouille un peu, autrement adieu veau, vache, cochon, Fusion Drive et RAID !! :banghead:

 

[Guyllaume]

Bonjour.

Si j'ai bien suivi, il faudrait donc 2 formats différents et non 2 identiques pour que les 2 OS soient démarrables.
Au final, c'est comme si j'avais 2 Fusion Drive mais dont l'un n'utilise pas les rétro-cessions de données (donc moins rapide, mais aussi moins "usant" pour le SSD).

On va faire ça alors, j'attends tes directives macomaniac.

Par contre, il ne faudrait pas qu'une des partitions patatouille un peu, autrement adieu veau, vache, cochon, Fusion Drive et RAID !! :banghead:

Comment dois-je comprendre ce message ? Si par exemple la partition A du SSD lâche, tout le système lâche, y compris le deuxième OS ?

*après 30 secondes de réflexion*
Finalement, ça ne change rien. Si j'étais dans ma configuration initiale (un Fusion Drive de 3 To avec un seul OS), si par exemple le SSD venait à lâcher, je perdrais tout et je n'aurais plus que le HDD d'opérationnel pour un reformatage.
En fait, le Fusion Drive peut s'apparenter à du RAID 0 (enfin pas vraiment mais un peu dans l'idée) et l'AppleRAID à du JBOD, c'est ça ?
Corrigez-moi si je dis des bêtises.

Merci d'avance.

 

[bompi]

Je dirais que le RAID d'Apple est du RAID, tout simplement.
La comparaison de Fusion Drive avec le RAID 0 est pertinente dans la mesure où les problèmes de sûreté de fonctionnement sont les mêmes (un disque claque et tout est perdu). Mais cela ajoute une optimisation dans la gestion des fichiers absente du RAID 0.

 

[Membre supprimé 1060554]

En guise de prolégomène : comme Sly & bompi , je pense que ces montages associatifs de disques physiques distincts (aussi bien la variété récente CoreStorage que la variété classique AppleRAID) créent un ensemble qui est plus faible que chaque élément pris isolément du point de vue de l'espérance vitale de l'espace formel utilisable. Car chaque élément pris séparément (un SSD ou un HDD exploité isolément pour monter un volume standard jhfs+) supporte un volume dont la durée de vie potentielle, en tant que système de fichiers, n'est diminuée a priori que du % de risques : "erreurs logiques" x "usure intrinsèque du disque" ; alors que l'ensemble (la solidarisation SSD + HDD pour exporter un Volume unique reposant sur l'intégration logistique CoreStorage ou AppleRAID) supporte un volume dont la durée de vie potentielle, en tant que système de fichiers, est diminuée a priori du % de risques : "erreurs logiques" x "usure intrinsèque de chaque disque additionné de l'usure extrinsèque de l'autre disque". C'est un cas paradoxal où, loin d'augmenter la force, l'union accroît la faiblesse : si le HDD lâche, par exemple, aussi bien dans le cadre d'un Fusion Drive que d'un Raid, alors le Volume entier est fichu en tant que système de fichiers.

Mais comme tu le remarques, Guyllaume, le fait que tes 2 disques physiques exportent au lieu d'un seul volume initial (ton Fusion Drive), deux concomitants (Fusion Drive + AppleRAID) - cela n'augmente en rien le % de risques lié à une défaillance physique des supports. Je pense que cloner régulièrement le système de fichiers des 2 volumes exportés sur support externe (des DDE supportant les volumes de clones démarrables), c'est la réponse logique à cette prise de risque.

Pour ce qui est du problème logique rencontré : comment assurer le caractère démarrable de deux volumes concomitants au lieu d'un seul, dès lors qu'un des volumes au moins est issu d'une association de disques (Fusion Drive ou AppleRAID)? - tu as très bien cerné la seule issue formelle : nécessité d'avoir simultanément 2 formats composites d'espèce différente : un format associatif CoreStorage + un format associatatif AppleRAID. Aucune des autres combinaison n'est validée : format associatif CoreStorage + volume standard jhfs+ / format associatatif AppleRAID + volume standard jhfs+ / double format associatif CoreStorage rejetant 2 Volumes Logiques / double format associatif AppleRAID rejetant 2 Volumes Concaténés.

Il aurait très bien pu se faire qu'aucune combinaison ne soit valide (du point de vue du caractère démarrable des 2 volumes exportés en sortie). Il se trouve par chance qu'une et une seule l'est - la raison en étant, me semble-t-il, la capacité ou non du programme diskarbitration (qui gère le montage des disques en volumes au démarrage) d'honorer ou non en terme de compatibilité les Cartes d'Amorçage : Boot_OS_X des partitions-supports des volumes considérés. Cette raison, comme tu le vois sans difficulté, se réduit ici au constat d'un état de fait opaque : dans tous les cas de figures qui ne sont pas la concomitance de 2 formats associatifs d'espèce différente, diskarbitration lit les Cartes d'Amorçage : Boot_OS_X comme incompatibles formellement et par suite arbitre la situation en n'en validant qu'une seule (la dernière selon la table des devices) et en en invalidant l'autre (la première selon la table des devices) ; dans le seul cas de figure qui consiste en la concomitance de 2 formats associatifs d'espèce différente, diskarbitration lit les Cartes d'Amorçage : Boot_OS_X comme compatibles formellement et par suite arbitre la situation en les validant toutes les deux, rendant par là les volumes équitablement démarrables en alternance. Pourquoi cet état de choses? Ahaaa! Il faudrait être programmeur pour ça (ce que je ne suis en aucun cas, mode, forme ni figure) afin d'aller scruter les instructions du programme de diskarbitration qui consistent en lignes de code issues de la décision de l'équipe d'ingénieurs informatiques d'Apple en charge de son développement. Décision contingente (ils auraient pu élargir le protocole de reconnaissance des Cartes d'Amorçage de la part de diskarbitration)? Décision forcée (ils n'avaient pas les moyens de concevoir un tel élargissement de la compatibilité)? Décision accidentelle (ils ne se sont jamais posé la question, n'envisageant pas le cas de figure où un utilisateur serait assez farfelu pour chercher à produire en concomitance un Volume associatif et un Volume Standard)? ☞ je suis hors course ici...

--------------------
​

Passons à la technique, puisque ta décision est faite : apurer la situation actuelle de tes disques en supprimant le Fusion Drive bicéphale en cours qui rejette 2 Volumes Logiques (dont le seul supportant «Mountain Lion» démarrable, l'autre, indémarrable, ayant de surcroît vu son système de fichiers remplacé accidentellement par celui de l'Installateur de «Mavericks») ; puis créer en concomitance un Fusion Drive et un AppleRAID afin d'avoir 2 volumes associatifs réellement démarrables en alternance ; installer enfin «Mavericks» sur l'un et «Mountain Lion» sur l'autre.

Je pense que l'opération globale se laisse découper en phases bien distinctes -->

- 1° Suppression du Fusion Drive et libération des 2 disques.

Si tu as des données liées à ton usage de «Mountain Lion» depuis quelque temps, sauvegarde-les au préalable sur un DDE (voire clonage du volume de cet OS entier, via «Carbon Copy Cloner» par exemple.

Connecte ensuite ta nouvelle clé «Mavericks 10.9.5» (dont le «Terminal» doit avoir un clavier AZERTY je présume) et démarre dessus. Dans le «Terminal» tu commences par saisir le classique :

diskutil cs list

et ↩︎ --> dans le tableau du CoreStorage qui s'affiche, tu sélectionnes et copie dans le presse-papier l'UUID du Groupe de Volumes Logiques affiché tout en haut xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Cela fait, tu saisis (en collant à sa place l'UUID dans la commande) :

diskutil coreStorage deleteLVG xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

et ↩︎ (j'espère que le démontage des 2 Volumes Logiques va s'opérer sans anicroche en préalable).

Si tu avais une erreur de démontage affichée, quitte le «Terminal», et dans l'«Utilitaire de Disque» sélectionne successivement chaucun des Volumes Logiques («Mavericks» et «Mountain Lion») et presse le bouton : "Démonter" dans la petite barre de menus juste au-dessus --> les affichages des volumes doivent virer au grisé, signe du démontage des volumes. Alors, tu reviens au «Terminal» et tu récidives ta commande qui devrait être honorée ce coup-ci.

--> Tu te retrouves avec 2 volumes standards respectivement dépendant chacun du seul support d'un des disques phsyiques. Je te conseille de Re-démarrer ton Mac et (avec "alt") de booter derechef sur ta clé de «Mavericks 10.9.5» (il ne faut pas abuser des capacités du kernel en exercice - celui du Système de ta clé ici - à supporter en mode live le produit de pareils re-partitionnements).

♤
​

- 2° Re-partitionnement en 2 de chaque disque : SSD et HDD.

Le plus commode est que tu te serves pour cela de l'«Utilitaire de Disque» de ta clé.

Tu sélectionnes le disque global de ton SSD (ligne supérieure, attenante à la marge), tu choisis le menu "Partitionner", tu vas au sous-menu : "Schéma de partition" et tu bascules l'onglet de la bannière supérieure "Actuel" pour choisir l'option : 2 Partitions --> tu obtiens juste en-dessous un affichage graphique du partitionnement prévisionnel, sous forme de 2 rectangles équitables en taille intitulés respectivement : Sans titre 1 et Sans titre 2 --> tu sélectionnes le rectangle Sans titre 1 et dans les options de droite, tu te contentes de modifier seulement l'intitulé en : Fusion-SSD ; ensuite, tu sélectionnes le rectangle Sans titre 2 et dans les options de droite, tu te contentes de modifier seulement l'intitulé en : Raid-SSD. Cela opéré tu presses le bouton : "Appliquer" et tu obtiens 2 volumes égaux sur ton SSD initulés Fusion-SSD & Raid-SSD.

Tu sélectionnes à présent le disque global de ton HDD (qui doit supporter un volume issu du Fusion Drive + le volume de la «Recovery HD» de «Mountain Lion») et tu opéres de manière analogue --> tu crées l'option 2 Partitions et tu t'arranges pour renommer les volumes prévisionnels en Fusion-HDD pour celui du haut et Raid-HDD pour celui du bas et tu fais "Appliquer", ce qui produit en sortie 2 volumes principaux sur le HDD intitulés Fusion-HDD & Raid-HDD.

--> Pour ne pas abuser encore des bons et loyaux services du kernel en charge, je te conseille de re-démarrer comme précédemment pour rebooter avec "alt" toujours sur ta clé «Mavericks 10.9.5».

♧
​

- 3° Création d'un Fusion Drive exportant un Volume Logique : «Mavericks».

Ça passe entièrement par le «Terminal» ce coup-ci.

D'abord passe la commande classique :

diskutil list

et ↩︎ --> tu obtiens le tableau de partitionnement standard de tes 2 disques + celui de ta clé. Cela te permettra d'adapter rigoureusement les identifiants des partitions que je vais citer dans la commande qui suit, en supposant (sans garantie, car je ne sais pas en quelle position numérique de disque ta clé va se trouver listée, ce qui pourrait perturber ma conjecture que ton SSD est identifié dans la table des devices comme /dev/disk0 et ton HDD comme /dev/disk1).

Commence par saisir l'équivalent adapté de :

diskutil coreStorage createLVG FUSION /dev/disk0s2 /dev/disk1s2

et ↩︎ --> il convient pour les 2 identifiants terminaux des partitions-disques que tu repères exactement dans le tableau précédent lequel correspond au nom Fusion-SSD --> si c'est bien (tout à droite) disk0s2, alors tu écris d'abord : /dev/disk0s2 (sinon, tu adaptes) ; puis lequel correspond au nom Fusion-HDD --> si c'est bien (tout à droite) disk1s2, alors tu écris d'abord : /dev/disk1s2 (sinon, tu adaptes).

Le cadre formel d'un Groupe de Volumes Logiques : CoreStorage de type Fusion Drive va se trouver créé, avec intégration primaire de 2 Physical Volumes ne rejetant pour l'instant aucun Volume Logique.

L'opération faite (chaque fois sanctionnée par le réaffichage de l'invite de commande), tu t'aperçois que le «Terminal» a l'exquise courtoisie de mentionner au final du processus l'UUID du Groupe de Volumes Logiques : CoreStorage en mode Fusion Drive qui vient d'être généré --> tu sélectionnes ce xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx et tu le colles dans le presse-papier.

À présent tu saisis exactement la commande :

diskutil coreStorage createLV xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx jhfs+ Mavericks 100%

et ↩︎ (tu colles à sa place l'UUID dans la commande) --> c'est la commande qui ordonne l'exportation d'un Volume Logique unique, intitulé «Mavericks», à partir des 2 Physical Volumes du Groupe de Volumes Logiques de type Fusion Drive. L'opération complétée, tu peux quitter le «Terminal» et vérifier de visu dans l'«Utilitaire de Disque» qu'un Volume Logique intitulé «Mavericks» est bien listé.

---> Arrivé à ce point, tu aurais tort de prétendre abuser de la puissance du kernel en exercice --> re-démarre impérativement ton Mac en re-bootant (avec "alt") encore une fois sur ta clé «Mavericks 10.9.5»...

♡
​

- 4° Création d'un Apple RAID exportant un Volume Concaténé : «Mountain Lion».

Ça passe entièrement par le «Terminal» encore.

Repasse la commande classique

diskutil list

afin de toucher derechef le tableau du partitionnement des disques, afin de pouvoir renseigner correctement les identifiants des partitions dans la table des devices pour la commande qui suit (car la création du Fusion Drive rejetant un Volume Logique est susceptible d'apporter encore plus de perturbations).

Saisis alors l'équivalent adapté (s'il y lieu dans les identifiants des partitions) :

diskutil appleRAID create concat "Mountain Lion" jhfs+ /dev/disk0s3 /dev/disk1s3

et ↩︎ --> il est décisif, là encore, que tu repères strictement les identifiants dans la table des devices qui correspondant en premier au nom : Raid-SSD --> si c'est bien disk0s3, alors tu saisis /dev/disk0s3 (sinon, tu adaptes) ; et en 2è au nom : Raid-HDD --> --> si c'est bien disk1s3, alors tu saisis /dev/disk1s3 (sinon, tu adaptes encore).

Il est possible qu'un panneau surgissant te déclare à la fin de l'opération que "le disque que vous venez d'insérer n'est pas lisible par cet ordinateur" --> tu presses superbement le bouton "Ignorer" et, à complétion dans le «Terminal», tu vas vérifier dans l'«Utilitaire de Disque» que tu as bien un nouveau volume disponible intitulé : «Mountain Lion».

--> Comme tu vois, l'opération pour créer un AppleRAID est plus simple que pour créer un Fusion Drive. Ne tente pas d'abuser pas des loyaux services du kernel en charge ! Re-démarre encore une fois ton Mac et re-boote sur ta clé de «Mavericks 10.9.5»...

♢
​

- 5° Installation de «Mavericks» et de «Mountain Lion» sur leurs volumes respectifs.

Je n'ai guère à diriger ta main plus longtemps. Tu commences par installer «Mavericks» sur le volume de destination «Mavericks». À complétion, après t'être retrouvé logé dans une session neuve d'utilisateur, tu déconnectes ta clé «Mavericks» et tu connectes celle qui supporte l'installateur de «Mountain Lion» puis tu re-démarres avec "alt" et tu bootes sur le disque de l'installateur «Mountain Lion». Tu n'as plus qu'à installer «Mountain Lion» sur le volume de destination homonyme.

Après quoi, tu vas bien voir à la fin si tu te retrouves logé dans une session neuve de «Mountain Lion». Vérifie que le démarrage alternatif 10.9 / 10.8 est validé. Je t'ai mis «Mavericks» sur le Volume Logique du Fusion Drive, et «Mountain Lion» sur le Volume Concaténé de l'AppleRAID. Évidemment, tu pourrais renverser les options.

​

​

 

[Guyllaume]

Bonjour.

J'ai démarré sur ma clé «Mavericks 10.9.5», j'ai entré la commande "diskutil cs list" puis "diskutil coreStorage delete LVG xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" (en remplaçant les x bien entendu) et le Terminal m'affiche :
Usage: diskutil coreStorage delete lvgUUID|lvgName
Delete a CoreStorage logical volume group. All logical volumes will be removed.
Ownership of the affected disk is required.

Que dois-je faire ?

EDIT
Oups, j'ai mis un espace entre "delete" et "LVG". J'ai refais la commande sans l'espace et ça a l'air de se lancer (Started CoreStorage operation, Ejecting Logical Volumes, Destroying Logical Volume Group, Erasing disk0s2 ... ).

Je poursuis les opérations.

 

[Invité]

Bien joué d'avoir remarqué l'espace en trop !

Tiens, complètement hors de propos.
Je remarque à l'instant la "signature" de MacO
T'étais un Boss aussi avec ResEdit ?

 

[Guyllaume]

Opérations terminées avec succès !
J'arrive à booter sur les deux OS, parfait. Petite remarque, les installations de ces derniers m'ont paru nettement plus longues que la dernière fois. Peut-être que la configuration de mon système y est pour quelque chose...

Autres remarques sur l'ensemble des opérations :

1) Le n° du HDD était... 15 ! Effectivement, mieux valait ne pas se tromper. D'ailleurs, le secteur (c'est bien comme ça qu'on l'appelle ?) des partitions "Raid" du SSD et du HDD est passé de 3 à 4 après la création de la partition Mavericks.

2) Au début de l'étape 2, après avoir effacé mon Fusion Drive, mes 2 disques étaient en rouge dans l'Utilitaire de disque et un message s'est affiché :

The storage in this Mac is no longer setup to use Fusion Drive.
Would you like to restore it to using Fusion Drive ?
Changing the configuration will erase the following disks :
Untitled
Untitled

Ce à quoi j'ai répondu Ignorer (j'avais Réparer comme autre alternative). Mes disques ont ensuite retrouvé une couleur "normale".

3) Après création du Apple-Raid, deux "Bande RAID pour «Mountain Lion»" sont apparues dans l'Utilitaire de disque, sous le Groupe de Volumes Logiques FUSION. Je ne sais pas à quoi elles correspondent...

4) Au moment d'installer l'OS Mountain Lion sur le disque "Mountain Lion", le message suivant s'est affiché :
« Certaines fonctionnalités d'OS X Mountain Lion ne sont pas prises en charge pour le disque Mountain Lion »
Des fonctionnalités telles que FileVault et le mode de récupération seront indisponibles si vous installez Mountain Lion sur ce disque.

Visiblement, le mode RAID empêche la création d'une Recovery.



Voilà pour les remarques.
A voir le comportement de mes deux sessions maintenant. En attendant un nouveau changement de système ou de nouveaux pépins... :rolleyes:
En tout cas un grand merci à toi macomaniac pour ton dévouement à ma cause !

 

[Membre supprimé 1060554]

Bravo, Guyllaume, pour ta persévérance et ton courage expérimental. Et bien entendu pour ton succès final. Ayant de mon côté un goût pour l'heuristique, j'ai trouvé dans ton fil un laboratoire où mettre à l'épreuve des conjectures. En guise de scholies de tes constats :

1) La numérotation des disques. Il valait mieux se méfier, en effet. Car, quand on démarre soit sur une «Recovery HD» (ce qui n'était pas le cas ici), soit sur un «Installateur d'OSX» (ce qui était ton cas) --> ce disque de boot a tendance à s'arroger le n°1 = disk1 après le disque en connexion SATA dans le Mac (ton SSD qui a dû rester numéroté en disk0). Or le boot sur un tel volume génère de surcroît le montage d'une ribambelle de disques temporaires de faible capacité qui s'arrogent la suite de la numérotation après celle du disque de boot, en général effectivement de disk2 à disk14. D'où le rejet de l'identification du HDD dans la position de disk15. Une erreur de citation des partitions du HDD (le secteur du disque répondant au nom de HDD-Fusion et celui répondant au nom de HDD-Raid) dans les commandes de création du CoreStorage et/ou de l'AppleRAID et hop! fichu. Tout aurait été à recommencer. C'est la raison pour laquelle je t'avais invité à donner des noms reconnaissables aux volumes lors de ton partitionnement dans l'«Utilitaire de Disque» - sans ça, on a du mal à identifier les bons secteurs des disques dans les commandes ultérieures...

--------------------​

2) Les messages d'erreur. Quand on supprime un Fusion Drive (ou même un format CoreStorage simple greffé sur la partition solitaire du disque du Mac réservé à l'OS), il y a génération formelle d'une nouvelle distribution du partitionnement, mais le kernel (le noyau opérateur) en activité [celui du Système démarré de l'installateur ici] continue sur sa lancée d'honorer les paramètres antérieurs --> c'est surtout le re-démarrage du Mac qui remet les choses d'aplomb : continer à aller de l'avant bille en tête serait s'exposer à des blocages. Dans mes expérimentations multiples de création en parallèle d'un Fusion Drive et d'un AppleRAID, j'ai tenté à un moment donné d'enchaîner dans la foulée création du CoreStorage --> création de l'AppleRAID : la sanction ne s'est pas fait attendre --> message d'erreur pour la 2è opération, déclarant qu'il n'y avait pas assez de "place" disponible pour la création de l'AppleRAID. Un simple re-démarrage a remis les choses en place.

--------------------​

3° Les Bandes-RAID. Ce sont les Cartes_d'Amorçage de l'AppleRAID : càd. de petites partitions qui supportent le "booter" (le dispositif logique de montage) de l'AppleRAID. Il y en a autant que de partitions principales intégrées au RAID--> dans ton cas = 2. Curieusement à première vue, ces Cartes_d'Amorçage se créent après la partition-support principale, et pas avant comme la Carte_d'Amorçage de l'EFI qui, dans la distribution d'une Table de partition GUID standard, est toujours en position de header ("en-tête") = /dev/disk0s1 avant la partition-principale qui supporte l'OS = /dev/disk0s2. Mais, à bien y réfléchir, c'est une illusion d'optique. Car un AppleRAID consiste en la conversion de la partition-support de chaque disque concerné en Disque Physique Virtuel --> par rapport à ce "pseudo-disque" qui occupe sur ton SSD, par exemple, la position /dev/disk0s3, la Carte d'Amorçage du "booter" qui occupe la position /dev/disk0s4 est donc l'équivalent d'un véritable header ("en-tête") par rapport... au montage du Volume Concaténé exporté en sortie de RAID. C'est la même disposition logique pour le Fusion Drive --> le CoreStorage commence par convertir la partition-support ciblée (sur ton SSD toujours la /dev/disk0s2) en Physical Volume (= "Disque Physique Virtuel"), et juste après s'intercale l'instance d'un "booter" spécifique : la Carte d'Amorçage propre au CoreStorage qui s'intitule, elle, Boot OS X et qui joue le même rôle : d'être le header ("en-tête") par rapport... au montage du Volume Logique exporté en sortie de Fusion Drive. Et idem sur le HDD, puisque aussi bien dans le cas du RAID que de la Fusion, il y a une partition-support correspondante virée elle aussi au statut de Disque Physique Virtuel.

Si les 2 dispositifs logistiques : le Corestorage du Fusion Drive & l'AppleRAID du Raid allaient ou non pouvoir s'articuler formellement sur chacun des disques, de telle manière que chaque partition-support principale convertie en Disque Physique Virtuel (la /dev/disk0s2 & /dev/disk15s2 pour le Fusion Drive et la /dev/disk0s3 & /dev/disk15s3 pour l'AppleRAID) puisse se trouver suivie de sa partition-booter spécifique (Boot OS X vs Bande RAID) afin que le Volume de synthèse exporté en sortie (le Volume Logique du Fusion Drive & le Volume Concaténé de l'AppleRAID) puisse être monté --> c'était déjà pour moi la grande inconnue (l'autre étant si le programme du diskarbitration allait ou non interpréter ces Cartes d'Amorçage comme logiquement compatibles ou exclusives l'une de l'autre).

Apparemment ça le fait, mais l'imbrication formelle des 2 architectures de partitions (celle du CoreStorage et celle de l'AppleRAID) sur chacun des 2 disques (SSD et HDD) ressemble à la production improbable d'un hybride fécond entre 2 espèces distinctes (ce que proscrit normalement la barrière génétique entre les espèces). Pour moi qui ne suis absolument pas au fait de l'ingéniérie informatique, il y a quelque chose d'inscrutable dans ces technologies et je me contente de les interpréter par transposition analogique avec le domaine de l'«entomologie».

--------------------​

4° Limitations fonctionnelles. Je me demandais, effectivement, ce qui allait se passer en ce qui concerne la création de «Recovery HD». Lorsque un OS à partir de «Lion 10.7» s'installe, en effet, sur un volume associatif (exporté par un Fusion Drive ou un AppleRAID qui solidarisent un SSD et un HDD), ce n'est jamais sur une partition supplémentaire du SSD que s'installe la «Recovery HD» mais toujours sur une partition du HDD (c'est logique : réserver le maximum d'espace-SSD au bloc-Système de l'OS). Je présume que le Programme d'Installation de l'OS recèle des instructions en ce sens, lorsque le volume de destination est reconnu comme supporté par un format associatif de 2 disques. Oui, mais une «Recovery HD» s'installe normalement "à la suite" de la partition dédiée à l'OS de référence, donc sur le HDD "à la suite" du "bloc" : partition-support convertie en Disque Physique Virtuel - Carte d'Amorçage. Allait-il donc y avoir sur ton HDD la séquence : en-tête EFI --> Physical Volume CoreStorage --> Boot OS X --> Recovery HD --> Disque Physique Virtuel AppleRAID --> Bande RAID --> Recovery HD ? Ayant installé dans mes expériences par clonage, j'avais volontairement exclu la génération de «Recovery HD» pour me simplifier la vie et donc je n'en savais rien.

Ton témoignagne est qu'une seule «Recovery HD» s'installe et pas 2. Celle afférante à l'OS du Fusion Drive («Mavericks» donc). Déjà, il faut savoir que quand l'OS dépend d'un format CoreStorage, la partition de récupération collatérale n'est pas affichée à l'écran de choix du disque de démarrage (obtenu avec "alt"), mais démarre à partir de l'option directe ⌘R. Je me suis longtemps demandé pourquoi. Je conjecture que ça à voir encore avec le programme diskarbitration qui apparemment n'arrive pas à intégrer en mode compatibilité la lecture d'un "booter" de type Boot OS X conditionnant le montage d'un Volume Logique : CoreStorage et celle du "boot_loader" classique connexe de type boot.efi permettant le démarrage de la «Recovery HD». Pourquoi, à présent, une seule «Recovery HD» au lieu de 2 dans le cas d'une imbrication : Fusion Drive + AppleRAID ? Ahaaa! Je suis un peu au bout de mon rouleau ici quant à la raison des effets. Je me demande quand même s'il ne serait pas possible de forcer la main dans ce cas : il existe en effet un programme Apple non documenté (le programme dmtest) qui permet la génération volontaire d'une «Recovery HD» à partir de ressources trouvables dans un Installateur quelconque d'OS X (le disque virtuel BaseSystem.dmg + le fichier collatéral BaseSystem.chunklist) - génération créatrice d'une partition d'accueil de 650 Mo pile à l'endroit mentionné dans la ligne de commande du «Terminal» qui invoque ce programme. Donc pourquoi pas en queue de peloton du HDD, si mentionné?

Je me demande ce qui se passerait alors --> re-partitionnement réussi + installation du dossier de boot d'une «Recovery HD : 10.8» ? Si oui, le disque de cette «Recovery HD : 10.8» serait-il affiché à l'écran de choix des disques de démarrage, afin de pouvoir être choisi? Où serait-il démarrable par ⌘R ssi le volume de l'OS de référence (dans ton cas le «Mountain Lion» exporté par l'AppleRAID) se trouvait au préalable sélectionné comme disque de démarrage automatique (par un argument de boot en NVRAM) ? Si j'ai le loisir d'une telle expérimentation, il faudra que je rende compte de son issue...

--------------------​

☞ Au final, je te conseille de t'initier à la technique du clonage des volumes (ou du seul volume de ton OS préférentiel) sur un DDE d'une taille adéquate (disque global tablé en GUID + volume formaté en Mac OS étendu (journalisé)). Comme un clone est une image-miroir démarrable, en cas de pépin, non seulement tu as une sauvegarde, mais tu as là un Système démarrable autrement confortable pour opérer que l'environnement d'outils d'un Installateur ou d'une «Recovery HD» - et un système rétro-clonable de surcroît, qui évite des ré-installations en mode "clean", càd. dépouillées de données et réglages personnels.

Lorsque tu clones un volume dont le montage dépend, soit d'un Fusion Drive, soit d'un AppleRAID, soit d'un déchiffrement («FileVault-2» activé), soit même d'un simple format CoreStorage sur une partition solitaire non chiffrée --> alors il faut savoir que la seule chose qui soit clonée est le système de fichiers dans son déploiement terminal : c'est-à-dire dans tous ces cas de figures un système de fichier standard jhfs+ (Mac OS étendu journalisé) - jamais les conditions logiques de son déploiement terminal --> il n'y a donc jamais clonage d'un Fusion Drive, d'un AppleRAID, d'un chiffrement ou d'un format CoreStorage.

Cloneur gratuit (dans son mode standard) : ☞SuperDuper!☜ ; cloneur payant (mais qui sait tout faire, y compris recloner des «Recovery HD») : ☞Carbon Copy Cloner☜. Ça pourrait te rendre service, car chacun de tes "Systèmes-associatifs" (Fusion Drive et AppleRAID) ne repose que sur ½ SSD = 60 Go pour gagner en vitesse exécutive ; le reste du support étant 1,5 To de HDD forcément lent --> tu risques assez vite de rencontrer des limitations d'efficacité et être amené à réviser tes choix...

​

 

[Guyllaume]

Bonsoir macomaniac.
Je donne des nouvelles (pas franchement bonnes) de ma situation.

Depuis ma dernière intervention, je me suis absenté et n'ai pas utilisé mon iMac pendant quelques jours. Ce n'est que ce mardi que je l'ai rallumé.



Episode 1 : mardi

Tout semblait aller correctement, démarrage impeccable sur Mavericks, iMac rapide etc etc.
Je commence par importer des fichiers personnels depuis un disque dur externe, je modifie quelques Préférences Système anodines (souris, Dock...).

Tout va bien puis d'un coup, ralentissement du Mac !
Les applications ont commencé à ramer. Finder, Préférences Système, QuickTime... Dès que je clique quelque part ou ouvre une fenêtre ou un document, c'est lent. Même l'application du jeu d'Echecs ! :eek: J'ai la roue colorée qui tourne pendant des secondes et des secondes.
Mon transfert de données depuis mon DDE (en USB 3) a subitement perdu énormément en débit, l'USB 1 à côté c'est une Formule 1 !
En revanche, pas de problème de ralentissement avec Safari, va savoir pourquoi. o_O

Bref, j'éteins mon Mac, et là aussi c'est lent, plus que d'habitude. J'entends également un bruit un peu plus "sec" (désolé, je ne sais pas comment traduire cela) du(des) disque(s) qui s'étei(gne)nt. Disons que la coupure est plus franche que d'habitude.



Episode 2 : jeudi

Je rallume mon iMac aujourd'hui. Démarrage très lent cette fois-ci (toujours sur Mavericks). Situation idem à mardi concernant le système, à savoir des applications qui buguent, mais aucun souci avec Safari.

Ensuite, après un temps d'inactivité, mon Mac s'est mis en veille. Je le rallume et tout était ralentit ce coup-ci. Même Safari !

Je décide de redémarrer sur le disque Mountain Lion pour voir si lui aussi a des problèmes.
Redémarrage trèèèès long (entre l'affichage des Préférences Système, de la rubrique Disque de démarrage et du redémarrage lui-même).
Bref, j'arrive sur ma session Mountain Lion, elle semble fonctionner correctement. Je teste quelques applications qui s'exécutent sans broncher, mais quelques minutes après, les problèmes resurgissent ! Y compris pour Safari.

J'éteins le Mac, c'est encore lent par rapport à d'habitude, et toujours ce petit bruit différent d'auparavant à l'extinction des disques.

Je rallume mon iMac ce soir, le démarrage sur Mountain Lion est correct cette fois-ci. Les applications ne buguent pas (Finder, Préférences Système, Safari...). C'est à n'y rien comprendre. Je suis persuadé que si je redémarre, je vais de nouveau rencontrer des ralentissements...


--------------------------


Chose importante : je précise que je n'ai installé aucune application, ni effectué aucune mise à jour depuis la création de mes 2 volumes en Fusion Drive et AppleRAID.

Je n'ai pas fait non plus de manipulations pour vérifier ou réparer quoique ce soit. J'ai préféré ne rien faire et attendre ton avis sur la situation.

Ce qui est étrange, c'est qu'à l'époque où on avait réussi à installer 2 OS sur un seul Fusion Drive (et dont uniquement Mountain Lion était bootable), je n'avais aucun souci de ralentissement...

Merci d'avance pour ton aide !
J'imagine déjà une hypothèse qui serait de détruire mon système actuel, de séparer le SSD du HDD et d'installer un OS sur chacun des disques, afin de voir si l'un a un problème qui ferait buguait l'ensemble de mon système actuel.
Mais j'attends de voir si tu as une solution miracle avant...

 

[Membre supprimé 1060554]

Ce fil étant parrainé par la devise magnifique de Guillaume d'Orange, le Stathouder : «Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer» - la survenue d'un nouvel épisode malchanceux n'a rien qui puisse surprendre ni décourager la Bonne Volonté

À te lire, Guyllaume, je pense que ressortent à la fois une certitude et une incertitude :

- La certitude : elle est d'ordre subjectif --> tu as choisi «Mavericks 10.9» comme OS principal, en privilégiant cet environnement pour tes opérations ; et tu as repoussé par là-même «Mountain Lion 10.8» dans le rôle d'OS auxiliaire, en n'y recourant qu'à fin de vérification : c'est la sanction de la pratique.

- L'incertitude : elle est d'ordre objectif --> quelle est la raison exacte des ralentissements qui affectent tes 2 OS parallèles ? S'agit-il d'un problème logique : la gestion simultanée de partitions de tes 2 disques (SSD & HDD) par 2 technologies "associatives" (Fusion Drive vs AppleRAID) qui coexisteraient malaisément ? Ou s'agit-il d'un problème mécanique : la défaillance graduelle d'un des 2 disques et/ou de sa nappe (vraisemblablement le HDD, en tant que support en rotation) ?​

☞ En intégrant ces 2 facteurs, je pense qu'il est possible de s'appuyer sur la certitude pour gérer l'incertitude :

- 1° allouer à l'OS «Mountain Lion» un espace suffisant mais congru sur le HDD (entre 200 et 500 Go) afin de l'y installer sur un volume permanent, désormais inaffecté par les manipulations concurrentes concernant l'autre OS («Mavericks») --> ainsi, tu aurais un Système auxiliaire installé de façon simple et classique : une seule partition d'un disque traditionnel (HDD), permettant de juger, par des démarrages expérimentaux, si le fonctionnement est disons "normal pour un tel OS sur un disque à plateaux en bon état".

De ce point de vue, quand mon MacBook Pro Early_2011 avait toujours son HDD de 750 Go natif, j'ai poussé l'installation successive des OS d'Apple dessus jusqu'à «Mavericks 10.9.5» y compris --> «Mountain Lion» ramait déjà sur un tel support (sans jamais swapper : 8 Go de RAM) avec notamment une lenteur pénible de démarrage (j'ai beaucoup d'applications automatiques et de services qui se lancent en ouverture de session). "Ballon de plage" fréquent. Avec «Mavericks», malgré une gestion nouvelle de la RAM par technique de compression, le ralentissement général des processus avait grimpé d'un cran encore (toujours sans aucun swap), avec un lancement d'une longueur pathétique et des ballons de plage à répétition --> j'ai donc jeté l'éponge, et remplacé le HDD par un SSD et je n'ai plus aucun problème sous «Yosemite 10.10» actuellement.

Par rapport à ce cas personnel que je viens de relater, le tout est de bien juger l'ordre du "ralentissement" des opérations : "normal" pour un HDD x un OS "lourd" logiciellement parlant (ils le sont tous, je trouve, depuis 10.8) ? Ou bien "anormal" pour une telle configuration (càd. des processus pathétiquement lents) ?

--------------------​

- 2° allouer à l'OS «Mavericks» la quasi totalité du SSD (la partition /dev/disk0s2 de 120 Go - l'en-tête régulier EFI /dev/disk0s1 de 209 Mo restant inéliminable disons par sécurité) afin d'assurer au Système et à ses applications le meilleur rendement possible. Cette donne préliminaire acquise, la gestion de l'espace restant du HDD (3 To - les 200 <--> 500 Go du volume de l'OS auxiliaire «Mountain Lion» = 2,5 à 2,8 To) est soumise à options :

- a) la technique du meilleur des (2) mondes : elle consiste à reconstituer un Fusion Drive associant logiquement la partition principale /dev/disk0s2 du SSD (120 Go) et la partition majeure /dev/disk1s2 du HDD (2,5 <--> 2,8 To) dans un Groupe de Volumes Logiques : CoreStorage --> la règle du jeu est claire et commande la manière de procéder à la mise en place : toutes les écritures vont exclusivement au départ à la partition du SSD jusqu'à une marge de 10% d'espace-disque résiduel, qui va être désormais utilisé comme zone de mémoire-tampon ; au-delà, tout le surplus s'écrit dans un 1er temps à la partition associée du HDD, des rétro-cessions SSD <--> HDD n'intervenant que pour des paquets de données n'excédant pas 4 Go, en fonction du marquage des blocs les plus fréquemment vs les moins fréquemment atteints en lecture, et uniquement dans les phases d'éveil du Mac sans activité de session. La leçon à tirer : n'installer jamais après coup (le SSD plein) d'applications monumentales (comme l'ancien «Final Cut Studio 2» qui prenait carrément 50 Go d'espace-disque avec tous ses composants), car elles iront définitivement au HDD et par conséquent rameront ferme à l'emploi. Ce principe respecté, il n'y a aucune bonne raison (logique) que l'OS en mode Fusion Drive ne soit pas rapide. Si des ralentissements majeurs survenaient, alors qu'il n'y a que des données associées sur le secteur du HDD, ça voudrait dire que ce disque est en berne (et ça devrait se voir aussi avec le fonctionnement "pur HDD" de «Mountain Lion».

- b) la technique du beurre et de l'argent du beurre : elle consiste à ne pas solidariser les 2 disques en un seul volume apparent, mais, l'OS installé exclusivement sur le SDD, à opérer une recopie du répertoire domiciliaire de l'utilisateur principal = toi (le Home_Folder à ton nom court d'utilisateur contenu dans le répertoire-Système des Utilisateurs) sur le volume parallèle du HDD. Cela fait, il suffit d'associer le compte nominal de l'utilisateur dans l'OS du SSD à la copie du Home_Folder déportée sur le HDD (il n'y a qu'un chemin logique à éditer dans la carte d'identité de l'utilisateur = trivial), à redémarrer de sorte que l'OS utilise désormais comme dossier de session de l'utilisateur celui du HDD, et alors à supprimer carrément le dossier home original du répertoire des Utilisateurs de l'OS du SSD --> cette technique qui a fait ses preuves distribue sélectivement tout le "logiciel" sur le SSD et les "données" sur le HDD (contenues qu'elles sont dans les différents dossiers de données du Home_Folder déporté sur le HDD : Images, Vidéos etc. Les grosses bibliothèques éventuelles gérées par des applications comme «iTunes» en faisant partie). Le fait que les "outils" du SSD doivent accéder à des données qui résident sur le HDD n'occasionne pas en principe de ralentissement majeur. En cas de traitement d'énormes paquets de données (genre fichiers vidéos de 40 Go), alors il faudrait sélectivement, de la place demeurant libre sur le SSD, les y copier au préalable pour tout faire en mode SSD, avant de les recopier après travail sur le HDD (ou des DDE).

- c) la technique de la chèvre et du chou : elle consiste à séparer radicalement le Système (= SSD) et les données (= HDD), sans déport du dossier d'utilisateur sur le HDD. Ce qui implique une condition préliminaire : une approche ascétique du dossier-Système d'utilisateur (le home_folder) contenu dans le répertoire des Utilisateurs, qui consiste à ne pas y stocker de données à part celles que des applications de tierce-partie tiennent à y fourrer. Pas de bibliothèque «iTunes». Pas de bibliothèque «iPhoto». Pas de vidéos pullulantes dans le dossier Vidéos. Pas de fatras inénarrable encombrant le Bureau, mais une tabula rasa. Tri et distribution classificatrice a la mano uniquement dans des dossiers/sous-dossiers créés et gérés par l'utilisateur à sa convenance. Et donc domiciliables hors-SSD et donc hors-OS du SSD, sur le HDD (lorsqu'il y en a un en parallèle) ou des DDE --> personnellement, ça a toujours été ma méthode et cela le restera toujours. Refus radical qu'aucune application s'interpose a priori entre moi et mes données pour les gérer dans des arborescences dépendant de catalogues inscrutables dans leur organisation. Non. Les choses exactement où je les ai mises et où je sais qu'elles sont. Directement. Appréhendables par inspection intuitive de l'esprit. Je sais de quoi je parle : j'ai 12 000 livres dans ma "Librairie" (espace bibliothèque privé). Et pas un seul catalogue. Ainsi, j'échappe au paradoxe russellien de la Bibliothèque.
​

--------------------​

☞ une fois les incontournables opérés : suppression intégrale de la distribution actuelle Fusion Drive x AppleRAID et l'OS auxiliaire «Mountain Lion» a priori installable sur un volume secondaire du HDD, à toi de réfléchir et de décider comment tu veux gérer l'emprise spatiale de l'OS principal «Mavericks» : Fusion Drive (unique et rejetant un unique volume), ou OS=SSD avec déport du dossier d'utilisateur sur le HDD, ou enfin Système intégral sur le SSD (avec dossier d'tuilisateur "maigre") et données empilables a la mano sur le HDD. Mais cela n'a rien d'un choix cornélien : car, admis en a priori que l'OS doit être installé, avec les applications, sur le SSD, ce qui implique que le gros des données va résider en regard sur le HDD - la délibération ne porte que sur le seul modus associativus des 2 secteurs du SSD et du HDD qui les supportent : CoreStorage, Home_Déporté ou Indépendance ?

 

[Invité]

Ce problème de lenteur n'est pas directement lié au fait que 64Go pour un Fusion Drive, c'est vraiment trop peu ?
Il me semble que les plus petits SSD Apple dans les Fusion Drive d'origine font 128Go

 

[Guyllaume]

Bonsoir.

Merci macomaniac pour les explications. A vrai dire, je pensais que tu allais m'indiquer des opérations de maintenance à exécuter, mais vu l'état de mon système actuel, elles seraient difficiles à réaliser puisque tout est d'une lenteur agaçante (démarrage, utilisation et extinction du Mac).

Pourtant, ma session Mountain Lion semblait plutôt bien fonctionner. J'ai pu travailler dessus sans avoir de ralentissements majeurs. Mais au fil des Go remplissants ma partition Mountain Lion, les ralentissements ont augmenté jusqu'à atteindre un niveau plus ou moins équivalent à celui de ma session Mavericks.

J'ai actuellement 50 Go d'espace occupé sur ma partition Mountain Lion, ce qui pourrait confirmer l'hypothèse d'Invité sur les 64 Go (-10%) d'espace-disque.
Cependant, je rencontrais déjà ces problèmes de ralentissement lorsque j'avais mon Fusion Drive "classique" (avec un seul volume logique), ce qui infirmerait ton hypothèse macomaniac sur un problème logique dû à la gestion simultanée de partitions de mes 2 disques par 2 technologies "associatives" (donc qui favoriserait plutôt un problème matériel :dead: ).
De toute façon, je trouve cela étrange qu'un HDD soit lent. Qu'il soit plus lent qu'un SSD, ok, mais là qu'il soit vraiment très lent comme tu le décris avec ton Macbook (et comme c'est peut-être le cas pour moi), c'est quand même bizarre. Imagine les gens qui ont comme disque interne uniquement un HDD : ce serait l'enfer !

Bref, je pense qu'il va falloir inévitablement passer par un reformatage du système car ce n'est pas possible d'utiliser un ordinateur lent comme ça... Je privilégierais pour l'instant la solution 1°+2°a) afin de conserver un Fusion Drive. Puis si jamais ce n'est toujours pas satisfaisant, peut-être tenter comme je l'évoquais une configuration avec un OS sur chaque disque pour voir si l'un dysfonctionne par rapport à l'autre.

 

[Membre supprimé 1060554]

Salut Guyllaume.

D'après des tests dont j'avais lu le compte-rendu, un Fusion Drive a l'exacte vitesse exécutive du SSD aussi longtemps que les écritures se font sur ce disque : comme elles vont toutes en priorité au SSD --> aussi longtemps, donc, que de l'espace sur la partition dédiée de ce disque est disponible - ce qui équivaut à la taille totale de la partition - 10%. Cette limite atteinte, il y a report à l'espace-disque du HDD (avant tout processus d'optimisation entre les 2 disques), mais les tests montraient que la vitesse exécutive, sous l'effet porteur du SSD supportant toute la structure logicielle installée sur lui en un premier temps, ne retombaient pas à celle d'un HDD classique, mais se stabilisait en moyenne à une valeur intermédaire entre vitesse SSD et vitesse HDD. Soit, si on admet par hypothèse, pour une vitesse = 1 d'un HDD, une vitesse = 4 d'un SSD, à une valeur médiane = 2 pour le travail d'écriture au HDD. L'optimisation ultérieure, transférant au SSD les blocs d'écriture (en dessous de 4 Go) plus fréquemment atteints en lecture contre la rétro-cession au HDD d'une quantité équivalente de blocs d'écriture moins fréquemment atteints en lecture du SSD, permettant en principe de relocaliser uniquement sur le SSD les ressources d'emploi fréquent et de refaire grimper leur vitesse à celle du SDD (= 4 dans mon hypothèse). Avec une contre-partie : des applications peu fréquemment utilisées qui auraient été ré-écrites au HDD de ce fait, avec les ressources de fichiers corollaires, lors de leur activation occasionnelle, opérant uniquement sur la base du secteur du HDD, devraient retomber à sa vitesse opératoire propre (soit 1 dans mon hypothèse).

Comme tu vois, un mécanisme logique complexe dont les arbitrages échappent à l'utilisateur, mais dont les effets ne devraient jamais tomber en-dessous de la vitesse normale d'un HDD, mais, pour l'usage le plus courant, osciller entre une vitesse x2 à x4 (dans mes hypothèses). L'excessive lenteur dont tu te plains pour ton Fusion Drive, mais aussi pour le plus classique AppleRAID parallèle (qui implique la même priorité d'écriture au SSD dans un 1er temps, mais sans transactions croisées entre les 2 disques au-delà), lenteur correspondant à une valeur inférieure à la vitesse régulière d'un HDD (imaginons donc x0,5 à x0,1 dans mes hypothèses) ne me semble pas normale dans aucun des 2 cas. Elle paraît être intervenue dès qu'il y a eu quasi saturation de l'espace-disque disponible de la partition-SSD (soit 60 Go - 10% = 6 Go --> 54 Go environ) et report d'écritures à la partition associée du HDD. Pour quelle raison exacte? J'ai peur que le fin mot ne nous échappe pour l'instant. Car il y a au moins 2 cas de figure possibles : HDD globalement en cours de défaillance matérielle (ce qui se traduit généralement par une lenteur croissante d'écriture/lecture au disque) ? Ou conflit formel des 2 technologies "associatives" (Fusion Drive vs AppleRAID), qui se déclarerait pile au point de saturation du secteur du SSD dédié, lorsque le secteur correspondant du HDD (quoique sain) viendrait à être exploité ?

Si le HDD est globalement en cours de défaillance matérielle, je pense que la nouvelle distribution logique que tu vas mettre en place devrait assez rapidement en attester ou non : tu vas bien voir d'entrée de jeu si le «Mountain Lion» installé purement sur une partition du HDD a et garde une vitesse exécutive acceptable (= x1 dans mon hypothèse), ou tombe dans une excessive lenteur (= x0,5 à x0,1 dans mon hypothèse). Tu devrais voir aussi, vers les 108 Go d'espace-disque occupé dans ton nouveau Fusion Drive (= limite d'écritures prioritaires impartie sur le SSD seul) - ce qui est confortable et pas susceptible d'être atteint si vite que ça - si le recours à l'espace-disque du HDD fait chuter la vitesse du Fusion Drive vers une lenteur excessive également. Ce qui, en principe, ne devrait pas affecter tous les processus. Par exemple, «Safari», installé d'entrée sur la partition du SSD et en service de pur butinage web, devrait garder une vitesse corrrespondant au SSD (x4 dans mon hypothèse), par rapport à des opérations impliquant des ressources d'écritures sur le HDD. À moins qu'un HDD en cours de défaillance ne se mette à plomber le Fusion Drive global dès que des écritures, quelles qu'elles soient, ont commencé à s'effectuer au secteur dédié du HDD. En tout cas, il serait hautement anormal, dans le cas d'un Fusion Drive solitaire, rejetant un Volume Logique solitaire, de ne pas garder une vitesse exécutive oscillant entre x4 à x1 (d'après mes hypothèses) selon les processus concernés : une chute en-dessous de x1, vers des x0,5 à x0,1, signerait un problème matériel. Une concordance avec une excessive lenteur de l'OS installé uniquement sur une partition du HDD («Mountain Lion» qui lui aussi tournerait à des x0,5 à x0,1) équivaudrait quasiment à une preuve que ton HDD est en fin de vie. Une compatibilité formelle Fusion Drive vs AppleRAID en parallèle redeviendrait alors une hypothèse d'école à tester, en cas de changement du HDD pour un neuf.

Bien sûr, l'appréciation subjective de la lenteur de processus est élastique - néanmoins elle demeure (je pense) un critère d'évaluation admissible de... l'inacceptable. Un utilisateur avec tant soit peu d'expérience de l'informatique sent très bien quand quelque chose cloche gravement au niveau du confort d'usage attendu...

♤
​

Passons à la pratique. À vue de nez, les opérations se répartissent en 4 phases : 1° = destruction du Fusion Drive et de l'AppleRAID ; 2° Re-partitionnement du SSD et du HDD redevenus indépendants ; 3° Re-création d'un Fusion Drive unique ; 4° Ré-installation des 2 OS : «Mavericks» sur le Volume Logique du Fusion Drive & «Mountain Lion» sur le volume standard du HDD.

Si tu es d'accord avec ce tableau de marche -->

- 1° Destruction du Fusion Drive et de l'AppleRAID (attention : toutes les données vont être supprimées. Fais tes sauvegardes au préalable, s'il y a lieu).

Pour ce faire, il te faut agir depuis un Système indépendant opérant sur un Disque autonome --> rien de mieux que l'installateur de «Mavericks 10.9.5» sur ta clé USB. Tu démarres dessus, donc, et tu lances le «Terminal» :

- a) Destruction du Fusion Drive.

Commence par passer la commande habituelle :

diskutil cs list

qui va t'afficher le tableau du Groupe de Volumes Logiques : CoreStorage du Fusion Drive --> il suffit que tu sélectionnes et que tu colles dans le presse-papier l'UUID du Groupe de Volumes Logiques (celui qui est listé tout en tête du tableau). Ce qui te permet d'enchaîner par la commande de destruction :

diskutil coreStorage deleteLVG xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

où tu colles à sa place l'UUID du Groupe de Volumes Logiques. L'opération complétée (réaffichage de l'invite de commande -bash-3.2#), je te conseille de re-démarrer ton Mac et de re-booter dans la foulée sur ton installateur de «Mavericks».

- b) Destruction de l'AppleRAID.

Elle implique seulement le ciblage du nom du volume de l'AppleRAID, soit dans ton cas Mountain Lion (que tu mettras entre "", afin de neutraliser l'espace vide central de l'intitulé). Tu saisis donc :

diskutil appleRAID delete "Mountain Lion"

et tu attends la complétion. Je te conseille encore de re-démarrer ton Mac et de re-booter dans la foulée sur l'installateur de «Mavericks».
​

--------------------​

- 2° Repartitionnement du SSD et du HDD.

Tu utilises pour ce faire l'«Utilitaire de Disque» -->

- a) Re-partitionnement du SSD

Tu sélectionnes son disque global (ligne supérieure, attenante à la marge), tu choisis le menu Partitionner et au sous-menu : Schéma de partition tu bascules l'onglet "Actuel" --> "1_partition" et tout à droite, le Format par défaut étant comme il convient "Mac OS étendu (journalisé)", à la rubrique Nom tu choisis : Mavericks-SSD et tu presses le bouton "Appliquer".

- b) Re-partitionnement du HDD

Tu sélectionnes son disque global, menu Partitionner, mais au sous-menu Schéma de partition tu bascules l'onglet "Actuel" --> 2_partitions --> tu vois au centre 2 rectangles équitables comme option par défaut, soit 1,5 To chacun --> il s'agit que tu les re-dimensionnes de manière à augmenter la taille du supérieur (dédié au Fusion Drive) et à diminuer corrélativement la taille de l'inférieur (dédié à «Mountain Lion»). Pour ce faire, tu peux utiliser la poignée de re-dimensionnement située au point médian de la ligne séparatrice des 2 rectangles : tu la pinces au pointeur et tu déplaces la ligne séparatrice vers le bas jusqu'à atteindre la valeur que tu veux pour le futur volume de «Mountain Lion» --> c'est toi qui est juge : 500 Go? 300 Go? 150 Go? Cela fait, sélectionne le rectangle du haut, et dans le champ de droite intitulé Nom --> inscris : Mavericks-HDD ; idem pour le rectangle du bas, et tu écris à Nom --> Mountain Lion. Tu vérifies que le Format chaque fois est bien --> Mac OS étendu (journalisé) et tu fais "Appliquer".
​

--> je te conseille, à complétion, de re-démarrer encore ton Mac et de re-booter dans la foulée sur l'installateur de «Mavericks».

--------------------​

- 3° Re-Création d'un Fusion Drive.

Tu relances le «Terminal» et -->

- a) Création d'un Groupe de Volumes Logiques associatif de 2 Physical Volumes (Disques Physiques Virtuels) :

Comme tu l'as expérimenté précédemment, il faut vérifier au préalable à quel rang sont listées les partitions-disques dans la Table des devices lorsque le démarrage s'effectue sur le disque externe d'une clé, rejetant plus d'une dizaine de disques temporaires. Tu commences donc par :

diskutil list

en vérifiant si la partition du SSD : Mavericks-SSD est bien listée en /dev/disk0s2 (sinon tu adapteras mon schéma de commande qui vient) ; et si la partition du HDD : Mavericks-HDD est listée en /dev/disk1s2 (ou si son identification est rejetée à quelque chose comme /dev/disk15s2 ou autre --> tu adaptes s'il y a lieu)

Tu passes alors la commande :

diskutil coreStorage createLVG Mavericks /dev/disk0s2 /dev/disk1s2

en veillant, comme indiqué, à bien adapter les identifiants des partitions !

- b) Exportation d'un Volume Logique unique à partir du Groupe de Volumes Logiques solidarisant 2 Physical Volumes.

Tu remarques que le «Terminal» a l'exquise courtoisie d'afficher, à la fin du retour de commande de la commande createLVG précédente, l'UUID du Groupe de Volumes Logiques qui a été créé --> tu le sélectionnes et le colles dans le presse-papier comme d'habitude et tu enchaînes avec :

diskutil coreStorage createVolume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx jhfs+ Mavericks 100%

où tu colles à sa place l'UUID. Je te conseille, à complétion, de re-démarrer encore pour re-booter dans la foulée sur l'installateur de «Mavericks» (je ne suis pas un maniaque du re-démarrage, mais l'expérience m'a montré que le kernel en charge - celui du Système démarré de ton installateur ici - est conservatif autrement de la distribution des systèmes de fichiers chargée au départ).
​

--------------------​

- 4° Ré-installation des 2 OS : «Mavericks» & «Mountain Lion».

--> je te conseille en préalable de lancer encore l'«Utilitaire de Disque» pour vérifier que tu as bien à ta disposition 2 volumes : un Volume Logique «Mavericks» (le plus volumineux) et un Volume standard «Mountain Lion» (le moins volumineux). Cela fait :

- a) Installation de «Mavericks».

Tu n'as plus qu'à lancer l'installateur de ton «Mavericks» avec comme destination le Volume Logique intitulé Mavericks. Une partition de récupération «Recovery HD» devrait être créée sur la partition dédiée du HDD, par re-partitionnement live du volume Mavericks. Ton Mac va re-démarrer automatiquement en sortie, et tu vas pouvoir paramétrer un compte admin et ouvrir une session.

- b) Installation de «Mountain Lion».

Détache ta clé d'install «Mavericks 10.9.5» et connecte la clé d'install de «Mountain Lion 10.8.5» --> tu dois pouvoir de ta session lancer le processus directement par double-clic sur l'installateur de la clé. Tu choisis le volume standard Mountain Lion comme destination. Ton Mac re-démarrera automatiquement en sortie et tu pourras paramétrer un compte et ouvrir une session dans «Mountain Lion».
​

--------------------​

☞ Je suis curieux de savoir si tu vas bien avoir 2 «Recovery HD» à la fin, ou s'il y a une incompatibilité en cas d'existence d'un Fusion Drive --> il te suffit dans ta session «Mountain Lion», d'aller à Applications/Utilitaires pour lancer le «Terminal» et passer la commande :

diskutil list

et tu verras si tu as 1 ou 2 Apple Boot Recovery HD listées.

Si tu en avais 2 (et pas la seule du Fusion Drive), je suis encore curieux de savoir ce que donne un démarrage avec la touche "alt" --> est-ce qu'en plus des 2 volumes choisissables : «Mavericks» et «Mountain Lion», tu as par hasard un volume : Récupération 10.8.5 ?

Il est impossible que tu aies une Récupération 10.9.5, parce que lorsque l'OS corollaire est installé sur un Volume Logique : CoreStorage (come c'est le cas avec ton Fusion Drive), alors sa «Recovery HD» est masquée à l'écran de choix du disque de démarrage (touche alt). Mais cela ne devrait pas impacter, si elle existe, l'autre «Recovery HD» indépendante du Volume Logique (ou si  ?).

--> si tout se passait comme dans le Meilleur des Mondes, alors pour démarrer sur la Récupération 10.9.5, il faudrait booter avec la combinaison de touches ⌘R, et pour démarrer sur la Récupération 10.8.5, passer par l'écran de choix du disque de démarrage (touche alt). Si, bien sûr, en ce qui concerne la commande ⌘R, le volume de démarrage automatique est bien «Mavericks» (argument renseigné en NVRAM) - car si c'était «Mountain Lion», alors le démarrage avec ⌘R ferait logiquement booter sur la Récupération 10.8.5 corollaire - et la «Recovery HD» de «Mavericks» resterait inaccessible...

♧​

 

[Guyllaume]

Bonjour macomaniac et merci pour les explications.
Je n'ai pas encore eu le temps d'effectuer les opérations, je ferai cela sûrement ce week-end ou en début de semaine prochaine. Je te tiendrai au courant dans la foulée des résultats obtenus.
Encore merci.

 

[Invité]

On attend avec impatience ces expérimentations !

 

[Guyllaume]

Vous aimez les rebondissements inattendus ? Voici une nouvelle séquence palpitante !

Je démarre le Mac normalement pour l'utiliser (une dernière fois avant reformatage me dis-je), il reste bloqué avec la page grise, le logo Apple et la roue crantée qui tourne à l'infini...
Au bout d'un quart d'heure j'ai abandonné et l'ai éteint "à la sauvage" avec le bouton Power.

J'ai ensuite essayé une réinitialisation du contrôleur de gestion du système (SMC), et cette fois-ci le Mac a bien voulu démarrer correctement (lentement, mais correctement) !

J'arrive donc sur l'écran du mot de passe de ma session Mountain Lion, je le tape et là... je retombe sur cette même page ! Hallucinant...
Je me dis que je l'ai peut-être mal écrit donc je recommence en m'assurant de ne pas me tromper : idem. C'est comme si j'actualisais une page Internet, je retombe sur le même écran.
J'ai tenté de taper mon mot de passe en QWERTY ou de n'entrer aucun mot de passe mais ça ne fonctionne pas.

Bloqué, je décide de redémarrer le Mac et de recommencer l'opération, mais toujours sans réussite.
Je redémarre ce coup-ci avec Alt sur Mavericks pour essayer : ô miracle, ça marche ! Je suis donc arrivé sur ma session Mavericks, que j'avais délaissé au profit de Mountain Lion qui moulinait moins...

Inutile de préciser que je ne comprends rien à ce qui se passe, et je n'ai rien trouvé à ce sujet sur le Net.
J'espère sincèrement que le prochain reformatage va tout régler parce que ça part dans tous les sens...

 

[Guyllaume]

Bonsoir.

J'ai démarré mon iMac sur Mavericks : le logo stationnement interdit s'est affiché. Je l'éteins et retente : cette fois l'iMac est freezé. Bon...

Est-ce que cela change le déroulement des opérations de reformatage que je m'apprête désormais à faire ou pas ?

Merci d'avance.