M
Membre supprimé 1060554
Invité
Comme on est en période d'oisiveté estivale > que mokuchley (l'auteur de ce fil) est rentré dans sa Caverne platonicienne rassuré quant à la normalité de sa configuration > je m'avise que cette incitation de r e m y :
Je me fais un plaisir d'y répondre.
Disque de 3 To voulait dire HDD d'un iMac associé à un SSD dans une configuration Fusion Drive. Dans une telle configuration > c'est toujours sur le HDD que la Recovery HD se trouve créée (en-dessous de la partition HDD du CoreStorage) > et c'est encore en-dessous que se trouve créée une partition BOOTCAMP pour Windows (après réduction de la partition CoreStorage du même HDD).
À supposer un iMac un peu récent supportant l'installation de Windows-10 > cette configuration ne pose aucun problème > parce que Windows-10 est un OS UEFI comportant un boot_loader .efi exécutable par l'EFI et impliquant une table de partition GUID sur l'en-tête du disque. Or une table de partition GUID (disons GPT pour abréger) ne comporte pas de limitation du nombre de blocs logiques sur un disque qu'elle peut gérer. Elle gère donc sans aucun problème une partition BOOTCAMP commençant (supposons-le) à la limite des 2800 Go et allant jusqu'à la marque terminale des 3000 Go.
S'il y a eu un problème qui a tarabusté les ingénieurs de la > ça été concernant les versions Legacy de Windows, Windows-7 par exemple, qui était des OS BIOS_based : càd comportant un boot_loader vintage inexécutable par l'EFI mais par un Programme Interne de type BIOS. Logiciel BIOS strictement incapable de lire une GPT pour obtenir l'adresse à la partition BOOTCAMP > mais requérant strictement une MBR lui décrivant l'adresse de la partition selon le schéma "Enregistrement de Démarrage Principal".
Or la limitation d'une table MBR est qu'elle n'a jamais pu gérer plus de 2,2 To de blocs logiques sur un disque - tout ce qui se situait au-delà ayant statut d'espace neutre inadressable comme espace de partition. D'où le problème épineux : comment faire pour qu'une partition BOOTCAMP puisse être créée sur un disque de 3 To sans que sa localisation au-delà des 2,2 To de blocs logiques ne la rende inindexable par une table MBR? Sous-problème technique d'un problème plus général qui se posait quelle que soit la taille du disque : comment faire sur un Mac pour booter un OS Legacy comme Windows-7 > càd. avoir un logiciel BIOS activable > qui disposerait sur l'en-tête du disque d'une table MBR pour obtenir l'adresse de la partition BOOTCAMP ?
La réponse à cette dernière question a donné lieu à un bricolage invraisemblable sur les Mac (qui étaient des EFI_based computers à l'époque où les si vantés PC étaient de minables bécanes BIOS_based en retard d'une génération). Comme quoi ce bricolage invraisemblable était entièrement destiné à ramener les Mac "en-arrière" pour leur faire émuler ces machines du passé qu'étaient les PC.
L'EFI des Mac a donc été implémentée d'une fonctionnalité secondaire : la capacité à émuler un BIOS. Pour que ce BIOS_émulé puisse trouver à lire une MBR sur l'en-tête d'un disque Mac > une double distribution a été mise-en-place telle que : sur le seul bloc 0 (ou premier bloc) des disques Mac > une table de partition secondaire MBR se trouve toujours incrite > tandis que sur la série suivante des blocs allant de 1 à 32 > une table GPT principale se trouve inscrite.
Avec un mécanisme logique automatique qui était le suivant : aussi longtemps qu'aucune partition dans un format Windows n'existait sur le disque > mais seulement des formats Apple > la MBR du bloc 0 était du type Protective_MBR (PMBR) = table MRB neutre > ne décrivant strictement aucune partition sur le disque qui puisse être adressée par un BIOS. Ainsi > l'EFI dans le temps de boot n'avisant aucune MBR décrivant des partitions > l'implémentation BIOS_émulé se trouvait neutralisée.
Mais dès qu'une partition dans un format Windows se trouvait créée (comme une partition BOOTCAMP dans un format préalable FAT-32) > alors automatiquement la PMBR du bloc 0 se trouvait convertie à un type Hybrid_MBR (HMBR) = MBR hybridée de la description des partitions actuelles du disque par la GPT principale. Il s'agissait donc de la génération automatique d'une MBR effective > décrivant les mêmes exactes partitions que la GPT en écho direct de celle-ci > selon le schéma "Enregistrement de démarrage principal".
Une première limitation de ce mécanisme ingénieux était que seulement 3 partitions déjà décrites dans la GPT pouvaient être répercutées en écho (echoed) dans la HMBR.
Mais la limitation cruciale intervenait avec les rares disques de 3 To : au cas où une partition BOOTCAMP serait créée dans la table GPT au-delà des 2,2 To de blocs logiques > alors elle ne pourrait pas être « echoed » (reflétée) dans la HMBR du bloc 0 > à cause de la limitation intrinsèque d'une MBR de ne pas pouvoir gérer plus de 2,2 To de blocs logiques.
La solution à ce problème était beaucoup plus enfantine que celle de permettre un boot BIOS_based --> elle consistait à partitionner a priori le disque de 3 To en une partition principale de 2,2 To et une partition secondaire de 800 Go. Dans ce cas le Fusion Drive était une association de 3 partitions : la principale du SSD et les 2 du HDD - ce qui ne pose aucun problème a priori au système de stockage CoreStorage particulièrement adaptable.
Le raffinement logiciel était alors le suivant : dans cette configuration à 2 partitions sur le HDD > la Recovery HD était toujours créée en intercalaire des 2 partitions CoreStorage qui étaient donc séparées par la partition de secours. On avait donc sur le HDD --> disk1s1 = partition EFI > disk1s2 = partition CoreStorage > disk1s3 = partition Recovery HD > disk1s4 = partition CoreStorage.
Dans cette configuration > toute demande de rétrécissement de la taille globale du CoreStorage Fusion Drive > adressait exclusivement la partition CoreStorage disk1s2 de 2,2 To du HDD (celle précédant la Recovery HD) > de telle sorte que la partition BOOTCAMP créée à partir de l'espace libéré par cette partition disk1s2 se trouvait toujours créée juste en-dessous de la Recovery HD disk1s3 mais toujours en-dessus de la partition CoreStorage disk1s4.
On obtenait donc une distribution : disk1s1 = EFI > disk1s2 = CoreStorage > disk1s3 = Recovery HD > disk1s4 = BOOTCAMP > disk1s5 = CoreStorage.
En quoi il s'agit d'une solution suffisante au problème de la limitation d'une MBR à 2,2 To de blocs saute aux yeux --> la partition CoreStorage disk1s2 étant créée a priori jusqu'à la limite des 2,2 To de blocs logiques > toute repartition de cette partition pour créer une BOOTCAMP générait toujours cette partition Windows dans la limite des 2,2 To de blocs logiques. Par suite > la conversion automatique de la PMBR neutre du bloc 0 à une HMBR de type descriptif faisait « écho » à une distribution de partitions GPT qui admettait en n°1 un équivalent de l'EFI disk0s1 > en n°2 un équivalent de la CoreStorage disk0s2 > échappait la description de la disk0s3 Recovery HD > et admettait en n°3 la description de la BOOTCAMP disk0s4. Ainsi la double limite des 2,2 To de blocs et de pas plus de 3 partitions GPT « echoed » en mode MBR était respectée.
=> je pense qu'il faut saluer comme il se doit l'ingéniosité de l'ingéniérie Apple dans la gestion du cas « Windows » sur Mac. Windows était vraiment un OS du passé > booté par des ordinateurs du passé : il fallait toute une série invraisemblable de « patches » logiques pour qu'un EFI_based computer comme le Mac > utilisant une GPT comme table de partition > puisse booter un OS Legacy comme Windows-7 > particulièrement sur des iMac utilisant un disque géant de 3 To associé en Fusion Drive à un SSD. Le raffinement de procédés permettant de repêcher Windows sur Mac (aujourd'hui inutiles) me paraît un exploit d'ingéniérie d'une générosité louable.
m'avait échappé dans le feu de l'action.
Je me fais un plaisir d'y répondre.
Disque de 3 To voulait dire HDD d'un iMac associé à un SSD dans une configuration Fusion Drive. Dans une telle configuration > c'est toujours sur le HDD que la Recovery HD se trouve créée (en-dessous de la partition HDD du CoreStorage) > et c'est encore en-dessous que se trouve créée une partition BOOTCAMP pour Windows (après réduction de la partition CoreStorage du même HDD).
À supposer un iMac un peu récent supportant l'installation de Windows-10 > cette configuration ne pose aucun problème > parce que Windows-10 est un OS UEFI comportant un boot_loader .efi exécutable par l'EFI et impliquant une table de partition GUID sur l'en-tête du disque. Or une table de partition GUID (disons GPT pour abréger) ne comporte pas de limitation du nombre de blocs logiques sur un disque qu'elle peut gérer. Elle gère donc sans aucun problème une partition BOOTCAMP commençant (supposons-le) à la limite des 2800 Go et allant jusqu'à la marque terminale des 3000 Go.
S'il y a eu un problème qui a tarabusté les ingénieurs de la > ça été concernant les versions Legacy de Windows, Windows-7 par exemple, qui était des OS BIOS_based : càd comportant un boot_loader vintage inexécutable par l'EFI mais par un Programme Interne de type BIOS. Logiciel BIOS strictement incapable de lire une GPT pour obtenir l'adresse à la partition BOOTCAMP > mais requérant strictement une MBR lui décrivant l'adresse de la partition selon le schéma "Enregistrement de Démarrage Principal".
Or la limitation d'une table MBR est qu'elle n'a jamais pu gérer plus de 2,2 To de blocs logiques sur un disque - tout ce qui se situait au-delà ayant statut d'espace neutre inadressable comme espace de partition. D'où le problème épineux : comment faire pour qu'une partition BOOTCAMP puisse être créée sur un disque de 3 To sans que sa localisation au-delà des 2,2 To de blocs logiques ne la rende inindexable par une table MBR? Sous-problème technique d'un problème plus général qui se posait quelle que soit la taille du disque : comment faire sur un Mac pour booter un OS Legacy comme Windows-7 > càd. avoir un logiciel BIOS activable > qui disposerait sur l'en-tête du disque d'une table MBR pour obtenir l'adresse de la partition BOOTCAMP ?
La réponse à cette dernière question a donné lieu à un bricolage invraisemblable sur les Mac (qui étaient des EFI_based computers à l'époque où les si vantés PC étaient de minables bécanes BIOS_based en retard d'une génération). Comme quoi ce bricolage invraisemblable était entièrement destiné à ramener les Mac "en-arrière" pour leur faire émuler ces machines du passé qu'étaient les PC.
L'EFI des Mac a donc été implémentée d'une fonctionnalité secondaire : la capacité à émuler un BIOS. Pour que ce BIOS_émulé puisse trouver à lire une MBR sur l'en-tête d'un disque Mac > une double distribution a été mise-en-place telle que : sur le seul bloc 0 (ou premier bloc) des disques Mac > une table de partition secondaire MBR se trouve toujours incrite > tandis que sur la série suivante des blocs allant de 1 à 32 > une table GPT principale se trouve inscrite.
Avec un mécanisme logique automatique qui était le suivant : aussi longtemps qu'aucune partition dans un format Windows n'existait sur le disque > mais seulement des formats Apple > la MBR du bloc 0 était du type Protective_MBR (PMBR) = table MRB neutre > ne décrivant strictement aucune partition sur le disque qui puisse être adressée par un BIOS. Ainsi > l'EFI dans le temps de boot n'avisant aucune MBR décrivant des partitions > l'implémentation BIOS_émulé se trouvait neutralisée.
Mais dès qu'une partition dans un format Windows se trouvait créée (comme une partition BOOTCAMP dans un format préalable FAT-32) > alors automatiquement la PMBR du bloc 0 se trouvait convertie à un type Hybrid_MBR (HMBR) = MBR hybridée de la description des partitions actuelles du disque par la GPT principale. Il s'agissait donc de la génération automatique d'une MBR effective > décrivant les mêmes exactes partitions que la GPT en écho direct de celle-ci > selon le schéma "Enregistrement de démarrage principal".
Une première limitation de ce mécanisme ingénieux était que seulement 3 partitions déjà décrites dans la GPT pouvaient être répercutées en écho (echoed) dans la HMBR.
Mais la limitation cruciale intervenait avec les rares disques de 3 To : au cas où une partition BOOTCAMP serait créée dans la table GPT au-delà des 2,2 To de blocs logiques > alors elle ne pourrait pas être « echoed » (reflétée) dans la HMBR du bloc 0 > à cause de la limitation intrinsèque d'une MBR de ne pas pouvoir gérer plus de 2,2 To de blocs logiques.
La solution à ce problème était beaucoup plus enfantine que celle de permettre un boot BIOS_based --> elle consistait à partitionner a priori le disque de 3 To en une partition principale de 2,2 To et une partition secondaire de 800 Go. Dans ce cas le Fusion Drive était une association de 3 partitions : la principale du SSD et les 2 du HDD - ce qui ne pose aucun problème a priori au système de stockage CoreStorage particulièrement adaptable.
Le raffinement logiciel était alors le suivant : dans cette configuration à 2 partitions sur le HDD > la Recovery HD était toujours créée en intercalaire des 2 partitions CoreStorage qui étaient donc séparées par la partition de secours. On avait donc sur le HDD --> disk1s1 = partition EFI > disk1s2 = partition CoreStorage > disk1s3 = partition Recovery HD > disk1s4 = partition CoreStorage.
Dans cette configuration > toute demande de rétrécissement de la taille globale du CoreStorage Fusion Drive > adressait exclusivement la partition CoreStorage disk1s2 de 2,2 To du HDD (celle précédant la Recovery HD) > de telle sorte que la partition BOOTCAMP créée à partir de l'espace libéré par cette partition disk1s2 se trouvait toujours créée juste en-dessous de la Recovery HD disk1s3 mais toujours en-dessus de la partition CoreStorage disk1s4.
On obtenait donc une distribution : disk1s1 = EFI > disk1s2 = CoreStorage > disk1s3 = Recovery HD > disk1s4 = BOOTCAMP > disk1s5 = CoreStorage.
En quoi il s'agit d'une solution suffisante au problème de la limitation d'une MBR à 2,2 To de blocs saute aux yeux --> la partition CoreStorage disk1s2 étant créée a priori jusqu'à la limite des 2,2 To de blocs logiques > toute repartition de cette partition pour créer une BOOTCAMP générait toujours cette partition Windows dans la limite des 2,2 To de blocs logiques. Par suite > la conversion automatique de la PMBR neutre du bloc 0 à une HMBR de type descriptif faisait « écho » à une distribution de partitions GPT qui admettait en n°1 un équivalent de l'EFI disk0s1 > en n°2 un équivalent de la CoreStorage disk0s2 > échappait la description de la disk0s3 Recovery HD > et admettait en n°3 la description de la BOOTCAMP disk0s4. Ainsi la double limite des 2,2 To de blocs et de pas plus de 3 partitions GPT « echoed » en mode MBR était respectée.
=> je pense qu'il faut saluer comme il se doit l'ingéniosité de l'ingéniérie Apple dans la gestion du cas « Windows » sur Mac. Windows était vraiment un OS du passé > booté par des ordinateurs du passé : il fallait toute une série invraisemblable de « patches » logiques pour qu'un EFI_based computer comme le Mac > utilisant une GPT comme table de partition > puisse booter un OS Legacy comme Windows-7 > particulièrement sur des iMac utilisant un disque géant de 3 To associé en Fusion Drive à un SSD. Le raffinement de procédés permettant de repêcher Windows sur Mac (aujourd'hui inutiles) me paraît un exploit d'ingéniérie d'une générosité louable.
Dernière édition par un modérateur:
