M
Membre supprimé 1060554
Invité
Une fois salués (
) compères bompi & Moonwalker qui se sont courtoisement empressés de répondre à Annick («Honneur_aux_Dames!») - je constate, pour ma part, que pestouche a conduit son expérimentation à son terme et que tout fonctionne heureusement sur son MacBook Pro_Early 2011 selon l'agencement suivant :
➤ (Disk0) = DDI
☞ ce qui appelle de ma part une série de remarques en guise d'apostille que je dédie, en ce 11_Novembre, aux 'Largués' de la guerre d'Évolution_Forcée qu'Apple mène contre la maintenance des Acquis, lesquels, pour appartenir à l'Antérieur, n'en sont pas pour autant In_Actuels, et donc méritent si cela se peut qu'on y préserve une Présence_du_Passé. Je dédie donc nominalement ces élucubrations matutinales abstruses à boninmi pour sa formidable création d'un «Fil_des_Largués» [en effet si 'Largués' y a-t-il de la susdite 'Guerre_d'Évolution', je ne les en suppose pas moins toujours à jour de l'Usage_de_la_Raison, car, comme le remarque incidemment Claude Levi-Strauss dans ses considérations sur l'Histoire : «Les Hommes ont toujours raisonné aussi bien» et il n'y a aucune évolution sous ce rapport mais seulement un changement des objets auxquels ils appliquent leurs raisonnements]
☞ la limite de validité du raisonnement que je viens d'exposer tient à la valeur_de_vérité d'une hypothèse que l'expérimentation de pestouche n'a malheureusement pas permis de vérfier de façon dirimante : à savoir que les MAJ-de_l'EFI, qu'Apple embarque de la plus clandestine des manières avec certains updates d'OS ou carrément avec l'upgrade à un OS, s'écriraient sur la Partition_EFI (disk0s1) du Disque Interne, et en aucune façon sur le micro-logiciel EFI_Boot_ROM de la puce de la Carte-Mère. Ce qui rendrait ces MAJ effaçables avec toute ré-initialisation du Disque Interne effaçant cette Partition_EFI, avant re-installation d'un OS obsolète comptatible néanmoins avec l'EFI_Boot_ROM d'un Mac 'semi_obsolète', dont l'installation re-créera une Partition_EFI implémentée de paramètres de boot compatibles avec cet OS_'Legacy'.
) compères bompi & Moonwalker qui se sont courtoisement empressés de répondre à Annick («Honneur_aux_Dames!») - je constate, pour ma part, que pestouche a conduit son expérimentation à son terme et que tout fonctionne heureusement sur son MacBook Pro_Early 2011 selon l'agencement suivant :➤ (Disk0) = DDI
▶︎ (disk0s1) = EFI
▶︎ (disk0s2) = Snow Léopard 10.6.8
▶︎ (disk0s3) = Lion
▶︎ (disk0s4) = Recovery_HD
▶︎ (disk0s5) = Volume_libre
▶︎ (disk0s2) = Snow Léopard 10.6.8
▶︎ (disk0s3) = Lion
▶︎ (disk0s4) = Recovery_HD
▶︎ (disk0s5) = Volume_libre
♤
☞ ce qui appelle de ma part une série de remarques en guise d'apostille que je dédie, en ce 11_Novembre, aux 'Largués' de la guerre d'Évolution_Forcée qu'Apple mène contre la maintenance des Acquis, lesquels, pour appartenir à l'Antérieur, n'en sont pas pour autant In_Actuels, et donc méritent si cela se peut qu'on y préserve une Présence_du_Passé. Je dédie donc nominalement ces élucubrations matutinales abstruses à boninmi pour sa formidable création d'un «Fil_des_Largués» [en effet si 'Largués' y a-t-il de la susdite 'Guerre_d'Évolution', je ne les en suppose pas moins toujours à jour de l'Usage_de_la_Raison, car, comme le remarque incidemment Claude Levi-Strauss dans ses considérations sur l'Histoire : «Les Hommes ont toujours raisonné aussi bien» et il n'y a aucune évolution sous ce rapport mais seulement un changement des objets auxquels ils appliquent leurs raisonnements]
- le mode 'Target' a bien permis l'exploitation indirecte du DVD d'Install retail «Snow Léopard 10.6.3, incompatible avec l'EFI de la Carte-Mère du MacBook Pro, en le démarrant sur un Mac-Source compatible pour sa part. L'application de la MAJ_Combo 10.6.8 en 2è couche a restauré la compatibilité de cet OS installé sur le DDI du MacBook Pro avec l'EFI_Boot_ROM de ce Mac, et donc rendu cet OS bootable.
- la Carte-Mère du MacBook Pro n'avait donc pas été changée lors du re-conditionnement pour une 'Lion_compatible' dont la ROM de démarrage aurait requis «Lion 10.7.2» minimum, rendant «Snow Léopard» in-bootable.
- l'EFI_partition (disk0s1) du DDI (disk0), complètement ré-initialisé dans sa Table_Logique et son Format avant ré-installation à partir de l'«Utilitaire de Disque» du DVD d'Install «Snow Léopard 10.6.3», a donc été re-créée en 1ère instance en tant que 'disk_NULL' formel par cet utilitaire, puis implémentée en 2è instance de paramètres de boot à l'installation en mode 'Target' de «Snow Léopard». Elle est donc 'Snow Léopard_compatible'. En ce qui concerne l'OS «Lion» qui est devenu le résidant après coup de (disk0s3) par rétro-clonage, il faut relever que cet OS n'a pas été installé stricto sensu sur cette partition du DDI, mais re-copié avec une procédure finale de 'blessing' ('bénédiction') qui a écrit le chemin au fichier booter du kernel (le boot.efi des 'CoreServices') dans le header ('en-tête') des fichiers de (disk0s3) où l'EFI saura le trouver en cas d'option de boot sur «Lion». Par voie de conséquence, l'inscription de l'OS «Lion» sur (disk0s3) en mode 'clonage' n'a absolument pas affecté les paramètres de (disk0s1) = la partition_EFI qui demeure en l'état actuel 'Snow Léopard_compatible'.
- d'après mon expérience, aucune MAJ de «Lion», en la supposant non pas re-clonée avec un OS majoré résidant indépendamment sur un DDE, mais régulièrement installée grâce à un .dmg d'installation sur le volume même (disk0s3) du DDE (ce qui implique un re-démarrage), n'est susceptible de modifier les paramètres de boot de la partition_EFI (disk0s1) au point de la rendre 'Snow Léopard_incompatible'.
- d'après mon expérience encore, l'OS «Mountain Lion 10.8», à supposer qu'on l'installe régulièrement sur (disk0s3) en démarrant sur l'Installateur supporté par une clé-USB par exemple, de sorte qu'il va venir up-grader l'OS «Lion» déjà résidant avec conservation des données, n'implémente pas à l'installation la partition_EFI (disk0s1) de paramètres de boot : 'Snow Léopard_incompatibles' si_&_seulement_si l'Installateur porte une version de 10.8.0 à 10.8.2 incluse. L'installation d'une version 10.8.3 ou supérieur implémente, par contre, la Partition_EFI de paramètres de boot : 'Snow Léopard_incompatibles'. Il doit sans aucun doute en être de même pour toute installation de «Mavericks 10.9». Le problème étant que la version de l'Installateur de «Mountain Lion» proposée à la vente sur l'Appe Store est > à 10.8.2.
- néanmoins, si l'on suppose cette installation opérée sur un clone du «Lion» de (disk0s3) démarré sur le DDE en mode autonome, alors l'implémentation des paramètres de boot 'Snow Léopard_incompatibles' ne sera pas adressée à la Partition_EFI (disk0s1) du DDI (disk0) non démarré, mais à la Parition_EFI du DDE démarré qui, par 'Default' du séquençage_logique des devices, sera compté comme (disk0) en tant que disque démarré, et donc sa Partition_EFI comme (disk0s1) en tant que partition du disque démarré. La Partition_EFI du DDI sera sont intouchée lors d'une telle installation.
- un rétro-clonage de l'OS «Mountain Lion > 10.8.2» sur le (disk0s3) du DDI, inscription par re-copiage et pas par installation, n'affectera donc pas la Partition_EFI de ce DDI séquencée (disk0s1) lors du re-démarrage. Par voie de conséquence logique, on doit pouvoir s'attendre à ce que cette Partition_EFI, restée implémentée de paramètres de boot : 'Snow Léopard_compatibles' (même après up-grade à «Lion»), continue de permettre le boot sous «Snow Léopard 10.6.8» et, alternativement, sous «Mountain Lion >10.8.2» à condition qu'aucune MAJ_Système ne soit autorisée de cet OS sur son volume. Et de même pour «Mavericks».
- la raison est que : l'installation de certaines MAJ d'un OS (exemple : «Mountain Lion 10.8.3»), ou tout court certains OS à l'installation (exemple : «Mavericks 10.9») implique en coulisses l'installation d'une MAJ_de_l'EFI : 'Snow Léopard_incompatible'. Ce que le re-copiage d'un OS pré-installé sur un autre disque (un DDE), disque dont la Partition_EFI spécifique a subi la MAJ seule, évite, car un rétro-clonage sur une partition de DDI n'importe pas les paramètres de boot de la Partition_EFI du disque_Source, mais laisse intact les paramètres de boot de la Partition_EFI du disque de destination.
- ce contournement par 'clone_recopie' au lieu de 'disque_installation' présente la limitation de faire stagner les paramètres_EFI du DDI à un stade_'Legacy' qui pourrait bien limiter certaines fonctionnalités logicielles de l'OS évolué inscrit en mode indirect (rétro-clonage).
- la Carte-Mère du MacBook Pro n'avait donc pas été changée lors du re-conditionnement pour une 'Lion_compatible' dont la ROM de démarrage aurait requis «Lion 10.7.2» minimum, rendant «Snow Léopard» in-bootable.
- l'EFI_partition (disk0s1) du DDI (disk0), complètement ré-initialisé dans sa Table_Logique et son Format avant ré-installation à partir de l'«Utilitaire de Disque» du DVD d'Install «Snow Léopard 10.6.3», a donc été re-créée en 1ère instance en tant que 'disk_NULL' formel par cet utilitaire, puis implémentée en 2è instance de paramètres de boot à l'installation en mode 'Target' de «Snow Léopard». Elle est donc 'Snow Léopard_compatible'. En ce qui concerne l'OS «Lion» qui est devenu le résidant après coup de (disk0s3) par rétro-clonage, il faut relever que cet OS n'a pas été installé stricto sensu sur cette partition du DDI, mais re-copié avec une procédure finale de 'blessing' ('bénédiction') qui a écrit le chemin au fichier booter du kernel (le boot.efi des 'CoreServices') dans le header ('en-tête') des fichiers de (disk0s3) où l'EFI saura le trouver en cas d'option de boot sur «Lion». Par voie de conséquence, l'inscription de l'OS «Lion» sur (disk0s3) en mode 'clonage' n'a absolument pas affecté les paramètres de (disk0s1) = la partition_EFI qui demeure en l'état actuel 'Snow Léopard_compatible'.
- d'après mon expérience, aucune MAJ de «Lion», en la supposant non pas re-clonée avec un OS majoré résidant indépendamment sur un DDE, mais régulièrement installée grâce à un .dmg d'installation sur le volume même (disk0s3) du DDE (ce qui implique un re-démarrage), n'est susceptible de modifier les paramètres de boot de la partition_EFI (disk0s1) au point de la rendre 'Snow Léopard_incompatible'.
- d'après mon expérience encore, l'OS «Mountain Lion 10.8», à supposer qu'on l'installe régulièrement sur (disk0s3) en démarrant sur l'Installateur supporté par une clé-USB par exemple, de sorte qu'il va venir up-grader l'OS «Lion» déjà résidant avec conservation des données, n'implémente pas à l'installation la partition_EFI (disk0s1) de paramètres de boot : 'Snow Léopard_incompatibles' si_&_seulement_si l'Installateur porte une version de 10.8.0 à 10.8.2 incluse. L'installation d'une version 10.8.3 ou supérieur implémente, par contre, la Partition_EFI de paramètres de boot : 'Snow Léopard_incompatibles'. Il doit sans aucun doute en être de même pour toute installation de «Mavericks 10.9». Le problème étant que la version de l'Installateur de «Mountain Lion» proposée à la vente sur l'Appe Store est > à 10.8.2.
- néanmoins, si l'on suppose cette installation opérée sur un clone du «Lion» de (disk0s3) démarré sur le DDE en mode autonome, alors l'implémentation des paramètres de boot 'Snow Léopard_incompatibles' ne sera pas adressée à la Partition_EFI (disk0s1) du DDI (disk0) non démarré, mais à la Parition_EFI du DDE démarré qui, par 'Default' du séquençage_logique des devices, sera compté comme (disk0) en tant que disque démarré, et donc sa Partition_EFI comme (disk0s1) en tant que partition du disque démarré. La Partition_EFI du DDI sera sont intouchée lors d'une telle installation.
- un rétro-clonage de l'OS «Mountain Lion > 10.8.2» sur le (disk0s3) du DDI, inscription par re-copiage et pas par installation, n'affectera donc pas la Partition_EFI de ce DDI séquencée (disk0s1) lors du re-démarrage. Par voie de conséquence logique, on doit pouvoir s'attendre à ce que cette Partition_EFI, restée implémentée de paramètres de boot : 'Snow Léopard_compatibles' (même après up-grade à «Lion»), continue de permettre le boot sous «Snow Léopard 10.6.8» et, alternativement, sous «Mountain Lion >10.8.2» à condition qu'aucune MAJ_Système ne soit autorisée de cet OS sur son volume. Et de même pour «Mavericks».
- la raison est que : l'installation de certaines MAJ d'un OS (exemple : «Mountain Lion 10.8.3»), ou tout court certains OS à l'installation (exemple : «Mavericks 10.9») implique en coulisses l'installation d'une MAJ_de_l'EFI : 'Snow Léopard_incompatible'. Ce que le re-copiage d'un OS pré-installé sur un autre disque (un DDE), disque dont la Partition_EFI spécifique a subi la MAJ seule, évite, car un rétro-clonage sur une partition de DDI n'importe pas les paramètres de boot de la Partition_EFI du disque_Source, mais laisse intact les paramètres de boot de la Partition_EFI du disque de destination.
- ce contournement par 'clone_recopie' au lieu de 'disque_installation' présente la limitation de faire stagner les paramètres_EFI du DDI à un stade_'Legacy' qui pourrait bien limiter certaines fonctionnalités logicielles de l'OS évolué inscrit en mode indirect (rétro-clonage).
♧
☞ la limite de validité du raisonnement que je viens d'exposer tient à la valeur_de_vérité d'une hypothèse que l'expérimentation de pestouche n'a malheureusement pas permis de vérfier de façon dirimante : à savoir que les MAJ-de_l'EFI, qu'Apple embarque de la plus clandestine des manières avec certains updates d'OS ou carrément avec l'upgrade à un OS, s'écriraient sur la Partition_EFI (disk0s1) du Disque Interne, et en aucune façon sur le micro-logiciel EFI_Boot_ROM de la puce de la Carte-Mère. Ce qui rendrait ces MAJ effaçables avec toute ré-initialisation du Disque Interne effaçant cette Partition_EFI, avant re-installation d'un OS obsolète comptatible néanmoins avec l'EFI_Boot_ROM d'un Mac 'semi_obsolète', dont l'installation re-créera une Partition_EFI implémentée de paramètres de boot compatibles avec cet OS_'Legacy'.
♡
