Je te conseille de faire un clone au préalable. Ainsi, la possibilité de rétro-cloner ton système t'est acquise et tu peux te livrer tranquillement à l'exercice expérimental sans avoir à craindre de perte de données et/ou d'OS démarrable.
Puisque tu as l'air disposé à de grandes manœuvres (et en supposant donc acquise l'existence d'un clone te permettant de reconstituer par rétro-clonage un OS démarrable sur le DDI de ton
MacBook Pro en cas d'échec d'une installation de «
Snow Léopard») - je tiens à te faire part de plusieurs hypothèses qui me tracassent vaguement et dont je n'ai jamais cherché à vérifier la validité par paresse expérimentale (je suis quelque peu rebuté par les expérimentations consistant en installations d'OS globales parce qu'elles impliquent un temps conséquent d'exécution à chaque fois et je préfère les expérimentations sectorielles (commandes ou usage d'applications) qui s'adossent à l'architecture intacte d'un OS déjà installé. En quoi
Descartes me reprocherait de pécher par
précipitation de la volonté - ressort dont il fait découler toutes les erreurs intellectuelles des hommes.
Je peux d'autant plus adéquatement développer ces hypothèses que j'ai le même Mac que le tien : un
MacBook Pro_Early 2011, à la seule différence du format (le mien étant un 15 pouces). Mac, donc, acheté neuf en état d'usine, et fourni au départ avec l'OS natif exact : à savoir «
Snow Léopard 10.6.6» dont j'ai les DVD gris spécifiques. OS que j'ai up-daté à 10.6.8 dans un premier temps, avant de l'up-grader sans
Clean Install d'abord à «
Lion 10.7», puis à «
Mountain Lion 10.8» et maintenant à «
Mavericks 10.9», chacun de ces up-grades mis-à-jour régulièrement aux updates de l'OS correspondant à leurs sorties. Donc une pratique consistant à suivre le courant de l'Histoire quoi qu'il en coûte, en s'efforçant de défendre les acquis du passé par récupération a posteriori (d'où mon goût pour les problématique d'émulations et de virtualisations qui m'intéressent pour des raisons de rétro-compatibilité dans le pur domaine Macintosh, et absolument pas pour des raisons de parallélisme de Systèmes hétérogènes - comme de virtualiser
Windows ou
Ubuntu) ; et non pas, donc, par fixation défensive à un stade de l'évolution logicielle et refus de se laisser entraîner par le cours du développement. Je rejette donc l'option du '
fossile_vivant' (comme, par exemple, de s'en tenir une fois pour toutes à l'environnement «
Snow Léopard» et de refuser de passer au-delà, ou comme la vérinaire de mon chat qui a comme outil professionnel un vénérable
iMac G4 Tournesol fixé à l'OS «
Jaguar 10.2» et que je soupçonne de pouvoir
booter sous Mac OS 9.2
...).
♤
Ton
MacBook Pro_Early 2011 ayant été re-conditionné par Apple, je m'explique qu'il t'ait été fourni avec l'OS «
Lion 10.7» installé, et pas «
Snow Léopard 10.6.6» en sortie d'usine. Mais justement ce facteur introduit une
variable dans le raisonnement qui n'est pas pour simplifier la donne :
Carte-Mère changée ou
inchangée? Parce que, en ce qui concerne mon propre
MacBook Pro_Early 2011 la Carte-Mère, elle, est native.
Pour en revenir à mon
MacBook Pro_Early 2011 à Carte-Mère inchangée, j'ai toujours partitionné mes DDI en une
Partition-Système (sur laquelle l'OS est installé) et une
Partition-Stockage (sur laquelle des données utiles résident). Il m'est donc facile à tout moment de sauvegarder les données stockées sur la Partition_B sur un DDE, d'effacer la Partition et d'installer un OS parallèle à des fins expérimentales pour voir s'il
boote, sans que cela implique l'effacement du DDI intégral. Mon expérience est donc que la ré-installation de «
Snow Léopard 10.6.8» sur la Partition_B (praticable sans mode '
Target' à partir de mon DVD gris 10.6.6 nativement compatible) donnait un OS
bootable sans difficulté tout le temps que sur la Partition_A s'est trouvé installée une version quelconque de «
Lion 10.7» aussi bien qu'une version de «
Mountain Lion 10.8» courant de 10.8.0 à 10.8.2 incluse. Mais l'up-date dudit «
Mountain Lion» de la Partition_A à la version 10.8.3 a introduit une césure dans le cours heureux de cette rétro-compatibilité : en ce que le Mac rejetait le
boot sur le DVD d'install 10.6.6 d'entrée de jeu, et, en cas d'installation indirecte grâce au mode '
Target' depuis un autre Mac du Système 10.6.8, refusait le
boot sur le volume de la partition_B. Dans les deux cas, avec émission d'un triple klaxon de détresse
. Ce qu'on appelle un '
dead end' assez piteux.
Mon interprétation du phénomène était assez simple : le signal était déclenché par la
ROM de démarrage (l'
EFI_Firmware supervisant le
boot) et c'était donc l'
EFI qui rejetait le
boot. Pourquoi diantre, si le Mac d'usine était compatible avec son OS natif = «
Snow Léopard 10.6.6»? La réponse tout aussi simple qui se présentait était que l'
EFI n'était pas restée en l'état d'usine, mais avait connu une mise-à-jour (répertoriée par Apple comme
MAJ de l'EFI_Firmware) impliquée concomitamment avec la MAJ 10.8.3 de l'OS «
Mountain Lion». C'était donc cette
EFI mise-à-jour qui rejetait le
boot sous l'OS natif du Mac [ce qui fait que les informations de «
MacTracker» sur la compatibilité_software des différents modèles de Mac sont à manier avec prudence à travers le temps, parce qu'elle ne tiennent pas compte du facteur
variable :
MAJ_de_l'EFI].
♧
Ces hypothèses posées, une question s'en impliquait : cette
MAJ_de_l'EFI si dommageable à la perpétuation du
boot sous «
Snow Léopard» était-elle
réversible ou
irréversible? -
Irréversible, semblait bien s'imposer comme réponse, si la modification des paramètres de l'
EFI s'était inscrite dans la ROM de démarrage de la Carte-Mère, car il aurait alors fallu disposer d'un programme capable de restaurer le
Firmware dans son état natif sur la puce même du Mac. Il semble bien que c'est la leçon qui se soit trouvée admise, suite à quelques débats théoriques auxquels j'ai participé naguère sur les forums de MacGénération.
J'ai toujours nourri des objections à cette fin de non-recevoir, nonobstant, ce parce qu'une autre hypothèse s'est toujours présentée à mon esprit comme d'autant plus envisageable qu'elle n'avait pas été réfutée : à savoir que les
MAJ_de-l'EFI ne modifieraient absolument pas la
ROM de démarrage de la Carte-Mère (le
Firmware au niveau de la puce, càd. le micro-logiciel qui y est installé), mais viendraient simplement implémenter une dimension
auxiliaire de cette
ROM de démarrage intouchée : à savoir la Partition invisible qui se crée concomitamment de l'OS sur le Disque d'installation interne des Macs Intel. Cette partition, assignée comme
disk0s1 dans la hiérarchie des
Devices, et intitulée
EFI, occupe un espace disque de près de 210 Mo. L'hypothèse qui a toujours alimenté mes doutes quant à l'
irréversibilité des
MAJ de l'EFI sur un Mac est la suivante : lesdites
MAJ de l'EFI viendraient s'écrire sur la partition invisible
EFI du Disque Interne, et pas sur la puce de la Carte-Mère.
Par voie de conséquence (ce qui montre bien que l'exercice du raisonnement consiste toujours à tirer des conséquences logiquement nécessaires à partir de prémisses admises hypothétiquement, et possède donc toujours cette '
douteuse rigueur' des procédés
hypothético-déductifs), à supposer exacte l'hypothèse ci-dessus de la localisation des
MAJ de l'EFI, elles seraient donc
réversibles purement et simplement par
ré-initialisation du disque, qui, effaçant la partition
EFI qui les recèle, ramenerait donc la
ROM de démarrage à ses propres ressources internes natives.
Par voie de conséquence de cette conséquence (puisque l'exercice purement déductif du raisonnement ne fait que mettre à jour dans l'ordre des implications le contenu de prémisses qui ne sont pas remises en cause), «
Snow Léopard» serait bien restaurable comme Système
bootable, dès lors que le disque où résident les
MAJ de l'EFI sur une partition dédiée aurait été préalablement 'érasé' de cette partition, de sorte que l'installation de «
Snow Léopard» recréerait une partition de l'
EFI sur le Disque Interne dont les paramètres seraient formellement adéquats à la
ROM de démarrage.
Déduction qui implique rétro-activement un affinement de l'hypothèse qui la fonde (que les
MAJ de l'EFI s'installent sur la partition
EFI du Disque Interne) : à savoir, que la
ROM de démarrage (sur la puce de la Carte-Mère), qui exécute le
POST (Power-On Self-Test =vérification_
hardware se soldant en cas de succès par le retentissement du
Chime = carillon de démarrage) invoquerait les paramètres de mise-à-jour de la partition
EFI du Disque Interne dans ce processus. À la suite de quoi elle donnerait ou non le feu vert à la poursuite du processus de
boot en exécutant ou non le fichier_
booter de l'OS (le '
boot.efi' des '
CoreServices' dont le chemin est stocké en NVRAM) qui, en lançant le chargement du
kernel et des
kexts, engage la passation de pouvoirs de l'
EFI au
NOYAU. En cas d'absence de paramètres mis-à-jour sur la Partition
EFI, la
ROM de démarrage ré-accepterait le
boot sur l'OS nativement compatible avec ses paramètres internes d'usine.
♡
Je me demande si tout ce petit raisonnement n'est pas un
Château de Cartes, comme le
Châtelain '
de Cartes' ainsi qu'il se nommait à l'origine, avant la mise-à-jour de son intitulé en '
Descartes', ne manque pas de me le faire soupçonner (car, quoique son crâne repose actuellement au
Musée de l'Homme sans avoir les honneurs du
Panthéon à la différence de bien de turbulents «
Nains_de_l'Histoire» qui s'ingénièrent à bâtir des taupinières de sable, selon le mot d'esprit de
Nietzsche - sa pensée s'exerce
sub specie aeternitatis sans nécessiter de
ROM de démarrage). Parce qu'il est tout entier appendu à une fragile
conjecture : que si 'flexible' soit (comme son nom de
Firmware l'implique) la
ROM de démarrage, son paramétrage interne n'est pas modifié par les
MAJ de l'EFI, mais que cette 'flexibilité' consiste à pouvoir tenir compte de paramètres externes 'muables'. Le mince argument défendant cette
conjecture étant qu'il faut bien trouver à la Partition
EFI du Disque Interne une
fonction, sans laquelle ce ne serait qu'un
ornement inexplicable.
Bref, cet anodin exercice de raisonnement matutinal va peut-être trouver avec ton expérimentation,
pestouche (à supposer que tu ré-initialises intégralement ton Disque Interne au départ, érasant par là la Partition
EFI mise-à-jour, avant d'installer un «
Snow Léopard 10.6.8 théoriquement compatible avec le réquisit minimal 10.6.6 de la
ROM de démarrage - ce, sans trop de crainte, puisque tu peux toujours re-cloner ton disque), sa
pierre de_touche longtemps attendue. Soit ça
boote, soit ça ne
boote pas.
<Infortunément un facteur non mesurable risque d'entâcher l'unilatéralité de cette expérimentation : si jamais, lors du re-conditionnement, la Carte-Mère de ton Mac avait été changée et une Carte-Mère «
Lion_Compatible» avait été installée. Car dans ces conditions la
ROM de démarrage sur la puce ne serait pas compatible avec le
boot sous «
Snow Léopard» mais avec «
Lion» minimum.>
Malheureusement, le problème qui ne manque pas d'apparaître en cas de succès est le suivant : qu'adviendra-t-il avec l'installation parallèle d'un OS ultérieur sur la 2è partition du Disque Interne (en le supposant bi-partitionné lors de la ré-intialisation)? Peut-on imaginer qu'une installation de «
Mavericks», par exemple, n'implémentera pas la Partition
EFI de paramètres de
MAJ de l'EFI qui,
da cappo, rendront le
boot sous «
Snow Léopard» impossible? Auquel cas, à supposer le
boot sous «
Sow Léopard» récupérable au commencement, ce qui confirmerait que les
MAJ de l'EFI s'installent sur la partition
EFI du disque sans modifier la
ROM de démarrage, ce serait une courte victoire, car pour préserver cet 'acquis', il faudrait nécessairement figer le Mac à un état maximum du software n'impliquant pas justement cette
MAJ de l'EFI incompatible avec le
boot sous «
Snow Léopard», soit «
Mac OS Mountain Lion 10.8.2 maximum, alors même que le Mac, en & pour soi, a le potentiel de supporter un
sofware ultérieur - ce qui le fixerait à l'état de '
fossile_vivant'.
♢
