Installation SL depuis Lion avec Clé USB

punchnows

Membre enregistré
1 Avril 2013
7
0
33
Bonsoir,

Je dispose d'un MacBook Pro 2010 (2,66 Ghz Intel Core i7, 4 Go DDR3) sous Lion 10.8.5

Je souhaite repasser sous Snow Leopard mais mon lecteur CD ne fonctionne plus.
J'ai donc fait une clé USB Bootable de SL (je dispose de l'image CD de SL et de Lion). Le problème est que la clé apparaît bien dans le menu de boot mais que l'écran reste bloqué sur une pomme indéfiniment et que le menu du programme d'installation ne se lance jamais.
J'ai essayé de booter avec mon image CD de lion et ça fonctionne parfaitement, il n'y a donc pas de probleme dans la gravure de l'image sur la clé.

Je précise de plus que le programme d'installation de SL ne peut être lancer depuis Lion.

J'ai fait un test en effaçant ma partition principale depuis la partition de récupératon de lion, mais la clé ne se lançait toujours pas. J'ai donc du réinstaller lion par la partition de récupération.

Est ce la partition de récupération de Lion qui empêche la clé USB de se lancer ?

Merci à tous.
 
Et en formatant ton DD en 1 seule partition HFS+ vide via ta clé USB de Lion au préalable?
(de toute façon, tu ne comptais pas installer SL par dessus Lion, ça c'est impossible)

Je n'ai pas essayer. En effet je gardais toujours 2 partitions sur mon DD principal: Celle ou est installée Lion et celle ou sont j'ai "entreposés" certains fichiers que je voulais garder. J'effaçais donc le contenu de celle contenant Lion.
Je vais faire un essai en formatant entièrement le DD principal alors.
Je reviendrai pour donner le résultat.
 
Dernière édition:
Re bonjour,

J'ai essayé la même méthode avec un DD neuf branché en interne et le résultat est le même. Le menu de lancement refuse de démarrer et reste bloqué sur une pomme.
 
Salut punchnows.

Je dispose d'un MacBook Pro 2010 (2,66 Ghz Intel Core i7, 4 Go DDR3) sous Lion 10.8.5

Je suppose que par 'Lion' tu entends en mode abrégé : «Mountain Lion 10.8.5» (et pas l'OS : «Lion 10.7»).

Tu vas me dire : à quoi bon pinailler sur des questions de 'dénomination' - mon problème [qui est qu'étant passé à un OS ultérieur - 10.7 ou 10.8, peu importe - je ne peux plus ré-installer l'OS primitif de mon Mac] en sera-t-il le moins du monde changé?

- ma réponse serait : vraisemblablement oui, dans la mesure où des 'noms distincts' désignent des 'états-de-choses distincts'.

♤

  • Il faut savoir que ton Mac possède un programme interne (= 'Firmware', abrégé par la dénomination d'EFI) dont le terme préfixe : <'extensible' firmware interface> ne désigne aucunement une 'flexibilité' dudit logiciel, au sens où il serait 'accommodant' :D, mais sa capacité de 'mise-à-jour' à travers le temps.

    Ledit programme interne a donc tout du chien 'Cerbère' qui gardait l'accès des Enfers dans la mythologie grecque : il surveille en effet jalousement son domaine de compétence, qui est la cohérence des composants au niveau du 'hardware' et la compatibilité du 'software' (OS) avec ce 'hardware' - ce, d'après des paramètres qui sont implémentés dans son programme.

    Si, à la suite du bricolage-maison d'un ingénieux MacUser, le programme interne détecte une 'incohérence' (d'après ses paramètres) du 'hardware', cela signifie que le matériel du Mac ne va pas passer l'examen initial du 'POST' (Power-On Self-Test) qui se conclut, en cas de succès, par le retentissement du carillon de démarrage ('Chime') et l'EFI ne va pas donner le feu vert à la continuation des opérations.

    Si, par ailleurs, le 'hardware' ayant passé le test, l'EFI détecte dans le 'software' (actuel : l'OS du Disque ; potentiel : l'OS d'un disque d'installation) un Système logiciel incompatible (à l'aune de ses paramètres internes), alors il y blocage du 'boot', lequel, dans le cas de figure le plus flagrant se déclare par des 'signaux' sans appel : affichage à l'écran d'un 'sens interdit', message déclarant que tel programme ne peut être installé sur cet ordinateur, signal sonore ré-itéré de rejet (klaxon triple).​

  • Le programme interne évoqué, comme l'indique son nom, est 'extensible' : c'est-à-dire que les paramètres de 'cohérence' du 'hardware' et de 'compatibilité' du 'software' qui y sont implémentés sont susceptibles de mises-à-jour à travers le temps : ce qu'on appelle les 'MÀJ-Firmware'. En règle générale, ces mises-à-jour du Firmware échappent à la décision consciente de l'utilisateur, en ce qu'elles sont embarquées clandestinement, en mode non-déclaré, avec certaines mises-à-jours majeures de la version de l'OS installé sur le Disque Interne. Eh bien! d'après mon expérience, la MÀJ_logicielle : 10.8.3 de l'OS «Mountain Lion» implique, à l'installation, une MÀJ_Firmware parfaitement clandestine, qui ré-écrit les paramètres implémentés dans le Programme Interne du Mac sur lequel se fait la mise-à-jour.

  • Les 'mises-à-jour_Firmware' ont pour 'panneau publicitaire' d'«améliorer la compatibilité» d'une série de composants logiciels avec les pré-requis du 'hardware' du Mac. Donc elles se présentent invariablement comme un facteur de 'progrès' historique. Mais cet 'optimisme' déclaratif du 'recto' ne doit pas dissimuler le caractère 'discriminatif' du 'verso' : la ré-écriture des paramètres de compatibilité logicielle implémentés dans le 'Programme Interne' équivaut, strictement, à l'instauration d'une 'non_rétro-compatibilité' du Mac que supervise l'EFI avec des états détectés comme 'régressifs' de l'organisation logicielle. En clair, cela revient à dire que l'OS natif du Mac, forcément évalué comme 'compatible' à l'origine par l'EFI d'après ses paramètres initiaux, peut parfaitement devenir logiciellement 'incompatible' rapporté à une mise-à-jour des paramètres du 'Firmware'. Ce qu'on peut interpréter comme l'instauraiton d'une 'fuite-en-avant' irréversible, dès lors que les paramètres de l'EFI ne peuvent pas être ré-écrits à rebours pour les ramener à leurt état antérieur à la mise-à-jour.

  • Selon mon expérience, toujours, la MÀJ de l'EFI embarquée avec la MÀJ de l'OS : 10.8.3 implémente le 'Programme Interne' de paramètres qui rendent dorénavant l'OS «Snow Léopard» dans toutes ses versions (aussi bien 10.6.3 que 10.6.8) 'incompatible' avec les réquisits de l'EFI. On ne peut donc pas ré-installer cet OS sur un Mac qui le supportait nativement, dès lors que l'EFI a subi une telle mise-à-jour. Ce rejet par l'EFI d'une organisation logicielle naguère 'politiquement correcte' mais devenue 'dangereusement rétrograde' peut se signaler sous la forme insidieuse du 'pédalage sur-place indéfini' (dit vulgairement : dans la 'choucroute' et autre 'yaourt' :D) : l'affichage invariable d'un logo 'Pomme' (montrant que le fichier 'Boot_Loader', c'est-à-dire 'starter' de l'OS, reçoit un commencement d'exécution). Car ledit fichier demeure toujours exclusivement une 'application de l'EFI' dans son exercice : jamais son processus exécutif ne prend un caractère autonome, mais c'est toujours l'EFI qui a la 'main' sur son processus.

  • Sachant que le rôle d'un fichier 'Boot_Loader' est de charger le 'noyau logiciel' d'un OS (dit 'kernel'), avec ses implémentations éventuelles (extensions du noyau, dites 'kexts'), lequel 'noyau', une fois chargé, prend complètement la main sur les opérations logicielles - tant que le fichier 'Boot_Loader' est en instance d'exécution, c'est le 'Programme Interne' et lui seul qui garde la main sur son processus. À tout moment, parce que des paramètres en voie de chargement s'avèrent incompatibles avec les critères implémentés dans son programme, l'EFI peut invalider l'opération du fichier 'booter'. Aussi longtemps qu'une roue crantée giratoire ne s'affiche pas à l'écran, cela signifie qu'aucun noyau logiciel n'a été chargé de façon autonome et n'a pris la main pour initier la suite des opérations.

&#9831;

&#9758; au risque de faire passer le sieur macomaniac pour un olibrius déprimant qui, le premier jour d'une Année Nouvelle, n'a rien de mieux à faire que d'annoncer des malheurs à son prochain :D, je présume que le 'Programme Interne' de ton MacBook Pro_2010 a connu la MÀJ_Firmware concomittante de la MÀJ_Logicielle : 10.8.3. En vertu de quoi l'installation 'rétro-grade' de l'OS natif : «Snow Léopard 10.6.3» est rejetée par l'EFI.

&#9758; ce n'est là qu'une conjecture de ma part, et je me réjouirais pour toi qu'elle soit inexacte. Tu as un moyen on ne peut plus décisif de lui faire passer le test crucial de sa valeur-de-vérité : tu mets ton MacBook Pro en position 'cible' (= 'Target') en gardant pressée la touche 'T' au démarrage, ce qui le vire à la fonction de DDE. Tu le connectes en FireWire à un autre Mac dont le 'Programme Interne' est susceptible d'accepter sans broncher le boot sur ta clé d'installation de «Snow Léoaprd 10.6.3». Une fois démarré sur l'installateur, tu utilises préalablement son «Utilitaire de Disque» pour re-paramétrer logiquement le Disque Interne de ton MacBook Pro ('GUID' et 'HFS+'), puis tu installes 10.6.3 sur le même Disque.

Sachant qu'en mode 'Target', le Disque Interne du Mac cible ne relève provisoirement pas du 'hardware' de ce Mac, non plus que du 'Programme Interne' mis hort-circuit de ce Mac, mais du 'hardware' du Mac d'accueil et du 'Programme Interne' du Mac d'accueil, dès lors qu'il y a 'boot' sur l'installateur à partir du Mac d'accueil, il n'y aucun problème pour installer l'OS concerné sur un Disque Externe provisoirement dé-connecté du 'Programme Interne' du Mac dans lequel il réside. Car, pendant toute l'installation, et y compris le re-démarrage de l'OS fraîchement installé, le Disque en question a le statut de Device attaché au Mac d'accueil, lequel supportera, physiquement et programmatiquement (EFI) le re-démarrage.

C'est seulement une fois quitté le mode 'Target' (forcer l'extinction pour ce faire, après avoir quitté formellement l'OS installé dans le cadre du Mac d'accueil afin que le dossier-système de l'OS installé soit 'béni', c'est-à-dire que le chemin au fichier 'Boot_Loader' soit stocké dans l'en-tête des fichiers pour que l'EFI sache le trouver) - que tu peux re-démarrer ton MacBook Pro. Là, tu vas bien voir si l'EFI qui a la main au démarrage va ou non accepter d'exécuter jusqu'au bout le fichier 'Boot_Loader' (le boot.efi du répertoire : 'CoreServices') de l'OS «Snow Léopard 10.6.3» complètement installé sur le Disque Interne. C'est-à-dire charger le 'kernel' qui sera désormais maître des opérations.

Si tu as un 'triple klaxon', un 'sens interdit' ou autre logo 'Pomme' indéfiniment affiché (en mode : 'rétro-pédalage' dans le yaourt :D) - cela signifie que le 'Programme Interne' rejette définitivement «Snow Léopard» sur ton Mac à cause de la MÀJ de ses paramètres.

&#9825;
 
Dernière édition par un modérateur:
Salut punchnows.



Je suppose que par 'Lion' tu entends en mode abrégé : «Mountain Lion 10.8.5» (et pas l'OS : «Lion 10.7»).

Tu vas me dire : à quoi bon pinailler sur des questions de 'dénomination' - mon problème [qui est qu'étant passé à un OS ultérieur - 10.7 ou 10.8, peu importe - je ne peux plus ré-installer l'OS primitif de mon Mac] en sera-t-il le moins du monde changé?

- ma réponse serait : vraisemblablement oui, dans la mesure où des 'noms distincts' désignent des 'états-de-choses distincts'.

&#9828;

  • Il faut savoir que ton Mac possède un programme interne (= 'Firmware', abrégé par la dénomination d'EFI) dont le terme préfixe : <'extensible' firmware interface> ne désigne aucunement une 'flexibilité' dudit logiciel, au sens où il serait 'accommodant' :D, mais sa capacité de 'mise-à-jour' à travers le temps.

    Ledit programme interne a donc tout du chien 'Cerbère' qui gardait l'accès des Enfers dans la mythologie grecque : il surveille en effet jalousement son domaine de compétence, qui est la cohérence des composants au niveau du 'hardware' et la compatibilité du 'software' (OS) avec ce 'hardware' - ce, d'après des paramètres qui sont implémentés dans son programme.

    Si, à la suite du bricolage-maison d'un ingénieux MacUser, le programme interne détecte une 'incohérence' (d'après ses paramètres) du 'hardware', cela signifie que le matériel du Mac ne va pas passer l'examen initial du 'POST' (Power-On Self-Test) qui se conclut, en cas de succès, par le retentissement du carillon de démarrage ('Chime') et l'EFI ne va pas donner le feu vert à la continuation des opérations.

    Si, par ailleurs, le 'hardware' ayant passé le test, l'EFI détecte dans le 'software' (actuel : l'OS du Disque ; potentiel : l'OS d'un disque d'installation) un Système logiciel incompatible (à l'aune de ses paramètres internes), alors il y blocage du 'boot', lequel, dans le cas de figure le plus flagrant se déclare par des 'signaux' sans appel : affichage à l'écran d'un 'sens interdit', message déclarant que tel programme ne peut être installé sur cet ordinateur, signal sonore ré-itéré de rejet (klaxon triple).​

  • Le programme interne évoqué, comme l'indique son nom, est 'extensible' : c'est-à-dire que les paramètres de 'cohérence' du 'hardware' et de 'compatibilité' du 'software' qui y sont implémentés sont susceptibles de mises-à-jour à travers le temps : ce qu'on appelle les 'MÀJ-Firmware'. En règle générale, ces mises-à-jour du Firmware échappent à la décision consciente de l'utilisateur, en ce qu'elles sont embarquées clandestinement, en mode non-déclaré, avec certaines mises-à-jours majeures de la version de l'OS installé sur le Disque Interne. Eh bien! d'après mon expérience, la MÀJ_logicielle : 10.8.3 de l'OS «Mountain Lion» implique, à l'installation, une MÀJ_Firmware parfaitement clandestine, qui ré-écrit les paramètres implémentés dans le Programme Interne du Mac sur lequel se fait la mise-à-jour.

  • Les 'mises-à-jour_Firmware' ont pour 'panneau publicitaire' d'«améliorer la compatibilité» d'une série de composants logiciels avec les pré-requis du 'hardware' du Mac. Donc elles se présentent invariablement comme un facteur de 'progrès' historique. Mais cet 'optimisme' déclaratif du 'recto' ne doit pas dissimuler le caractère 'discriminatif' du 'verso' : la ré-écriture des paramètres de compatibilité logicielle implémentés dans le 'Programme Interne' équivaut, strictement, à l'instauration d'une 'non_rétro-compatibilité' du Mac que supervise l'EFI avec des états détectés comme 'régressifs' de l'organisation logicielle. En clair, cela revient à dire que l'OS natif du Mac, forcément évalué comme 'compatible' à l'origine par l'EFI d'après ses paramètres initiaux, peut parfaitement devenir logiciellement 'incompatible' rapporté à une mise-à-jour des paramètres du 'Firmware'. Ce qu'on peut interpréter comme l'instauraiton d'une 'fuite-en-avant' irréversible, dès lors que les paramètres de l'EFI ne peuvent pas être ré-écrits à rebours pour les ramener à leurt état antérieur à la mise-à-jour.

  • Selon mon expérience, toujours, la MÀJ de l'EFI embarquée avec la MÀJ de l'OS : 10.8.3 implémente le 'Programme Interne' de paramètres qui rendent dorénavant l'OS «Snow Léopard» dans toutes ses versions (aussi bien 10.6.3 que 10.6.8) 'incompatible' avec les réquisits de l'EFI. On ne peut donc pas ré-installer cet OS sur un Mac qui le supportait nativement, dès lors que l'EFI a subi une telle mise-à-jour. Ce rejet par l'EFI d'une organisation logicielle naguère 'politiquement correcte' mais devenue 'dangereusement rétrograde' peut se signaler sous la forme insidieuse du 'pédalage sur-place indéfini' (dit vulgairement : dans la 'choucroute' et autre 'yaourt' :D) : l'affichage invariable d'un logo 'Pomme' (montrant que le fichier 'Boot_Loader', c'est-à-dire 'starter' de l'OS, reçoit un commencement d'exécution). Car ledit fichier demeure toujours exclusivement une 'application de l'EFI' dans son exercice : jamais son processus exécutif ne prend un caractère autonome, mais c'est toujours l'EFI qui a la 'main' sur son processus.

  • Sachant que le rôle d'un fichier 'Boot_Loader' est de charger le 'noyau logiciel' d'un OS (dit 'kernel'), avec ses implémentations éventuelles (extensions du noyau, dites 'kexts'), lequel 'noyau', une fois chargé, prend complètement la main sur les opérations logicielles - tant que le fichier 'Boot_Loader' est en instance d'exécution, c'est le 'Programme Interne' et lui seul qui garde la main sur son processus. À tout moment, parce que des paramètres en voie de chargement s'avèrent incompatibles avec les critères implémentés dans son programme, l'EFI peut invalider l'opération du fichier 'booter'. Aussi longtemps qu'une roue crantée giratoire ne s'affiche pas à l'écran, cela signifie qu'aucun noyau logiciel n'a été chargé de façon autonome et n'a pris la main pour initier la suite des opérations.

&#9831;

&#9758; au risque de faire passer le sieur macomaniac pour un olibrius déprimant qui, le premier jour d'une Année Nouvelle, n'a rien de mieux à faire que d'annoncer des malheurs à son prochain :D, je présume que le 'Programme Interne' de ton MacBook Pro_2010 a connu la MÀJ_Firmware concomittante de la MÀJ_Logicielle : 10.8.3. En vertu de quoi l'installation 'rétro-grade' de l'OS natif : «Snow Léopard 10.6.3» est rejetée par l'EFI.

&#9758; ce n'est là qu'une conjecture de ma part, et je me réjouirais pour toi qu'elle soit inexacte. Tu as un moyen on ne peut plus décisif de lui faire passer le test crucial de sa valeur-de-vérité : tu mets ton MacBook Pro en position 'cible' (= 'Target') en gardant pressée la touche 'T' au démarrage, ce qui le vire à la fonction de DDE. Tu le connectes en FireWire à un autre Mac dont le 'Programme Interne' est susceptible d'accepter sans broncher le boot sur ta clé d'installation de «Snow Léoaprd 10.6.3». Une fois démarré sur l'installateur, tu utilises préalablement son «Utilitaire de Disque» pour re-paramétrer logiquement le Disque Interne de ton MacBook Pro ('GUID' et 'HFS+'), puis tu installes 10.6.3 sur le même Disque.

Sachant qu'en mode 'Target', le Disque Interne du Mac cible ne relève provisoirement pas du 'hardware' de ce Mac, non plus que du 'Programme Interne' mis hort-circuit de ce Mac, mais du 'hardware' du Mac d'accueil et du 'Programme Interne' du Mac d'accueil, dès lors qu'il y a 'boot' sur l'installateur à partir du Mac d'accueil, il n'y aucun problème pour installer l'OS concerné sur un Disque Externe provisoirement dé-connecté du 'Programme Interne' du Mac dans lequel il réside. Car, pendant toute l'installation, et y compris le re-démarrage de l'OS fraîchement installé, le Disque en question a le statut de Device attaché au Mac d'accueil, lequel supportera, physiquement et programmatiquement (EFI) le re-démarrage.

C'est seulement une fois quitté le mode 'Target' (forcer l'extinction pour ce faire, après avoir quitté formellement l'OS installé dans le cadre du Mac d'accueil afin que le dossier-système de l'OS installé soit 'béni', c'est-à-dire que le chemin au fichier 'Boot_Loader' soit stocké dans l'en-tête des fichiers pour que l'EFI sache le trouver) - que tu peux re-démarrer ton MacBook Pro. Là, tu vas bien voir si l'EFI qui a la main au démarrage va ou non accepter d'exécuter jusqu'au bout le fichier 'Boot_Loader' (le boot.efi du répertoire : 'CoreServices') de l'OS «Snow Léopard 10.6.3» complètement installé sur le Disque Interne. C'est-à-dire charger le 'kernel' qui sera désormais maître des opérations.

Si tu as un 'triple klaxon', un 'sens interdit' ou autre logo 'Pomme' indéfiniment affiché (en mode : 'rétro-pédalage' dans le yaourt :D) - cela signifie que le 'Programme Interne' rejette définitivement «Snow Léopard» sur ton Mac à cause de la MÀJ de ses paramètres.

&#9825;
Merci beaucoup pour ce post édifiant. Je cherchais justement à comprendre le pourquoi du comment, et tes explications tombent parfaitement juste.
Je vais essayer la solution proposée.

Encore merci.
 
salut
Je viens de recevoir 2 DDE de 1 To et , sans attendre, me suis lancé dans les sauvegardes .. sur un imac lion et un MBP sous snow leo .
Sur mon MBP, j'ai utilisé CCC et crée un clone. Dans les 40 minutes . Bon
j'ia booté dessus . cool
Sur le imac j'ai essayé :confused:de faite Time machine . ça a a planté . ouais
j'iai re-effacé la partite incriminée et je vais retenter le truc .
Du coup j'ai essayé de booter avec le DDE ( donc SL ) sur le IMAC : nade .
comme bien dit sur ce thread. :love::eek:
Donc si je MPB crame , rien a faire a part copier des fichiers séparément ?
donc faire aussi un time machine ?
déja que le imac ne lit pas les photos du MPB
en machine esclave ( ah ah ) surement mais en cas de panne HARD, rien :eek:
 
Dernière édition par un modérateur: