M
Membre supprimé 1060554
Invité
Sur le secteur d'amorçage de ton disque (les blocs 0 à 32 d'en-tête), tu as 2 cartes de partitions :
La seule conjecture que j'ai réussi à former pour rendre compte de la perte du caractère démarrable de ta partition BOOTCAMP (alors même que son code de partition est correct et qu'elle supporte le boot_flag : indicateur de caractère démarrable) > est que la HMBR du bloc 0 de ton disque, suite à la création d'un format CoreStorage impliqué dans l'installation de «Sierra» sur la partition Macintosh HD, aurait subi l'interpolation au rang n°3 de la partition de secours Recovery HD qu'elle ignorait précédemment. Donc au lieu de décrire en mode hybridatif de la GPT les 3 partitions :
ce que je conjecture avoir été la situation logique de départ > après interpolation de la Recovery HD elle équivaut à :
=> donc la partition BOOTCAMP aurait glissé au rang n°4 dans la représentation hybridée de la HMBR > et comme seules 3 descriptions de partitions dans l'ordre y sont valides > la description GPT n°4 (= BOOTCAMP) > HMBR n°4 serait devenue invalide. Donc l'EFI au démarrage ne peut pas utiliser la table HMBR pour booter BOOTCAMP en mode « Legacy » > car la partition BOOTCAMP rejetée au rang n°4 n'y est plus valide.
=> ce que je proposerais comme expérimentation est : dans un premier temps ramener cette HMBR invalide au type par défaut PMBR (représentation de l'espace du disque comme constitué d'une seule partition) > et dans un 2è temps reconvertir cette PMBR dans un type HMBR valide qui serait le suivant :
GPT n°1 (= ESP) > HMBR n°1
GPT n°4 (= BOOTCAMP) > HMBR n°2
- la principale = la GPT (GUID Partition Table) dont les descripteurs occupent les blocs 1 > 32. C'est elle qui définit les 4 partitions actuelles de ton disque et qui permet à l'EFI (le Programme Interne du Mac) d'accéder au disque et d'exécuter le boot_loader : boot.efi (démarreur de Système) soit de la partition de l'OS Macintosh HD, soit de la partition de secours Recovery HD.
- la secondaire = la HMBR (Hybrid_Master_Boot_Record) dont les descripteurs occupent le seul bloc initial 0. Elle constitue une simple redondance logique de la GPT dans le mode MBR, càd. une re-description des même partitions du disque, au bloc près, définies au départ par la GPT, mais selon le type descriptif MBR. C'est donc un écho logique (où l'« écologique » ne va-t-il pas se nicher ?
) de la GPT. Son seul intérêt en ce qui te concerne est qu'elle permet à l'EFI du Mac de booter la seule partition BOOTCAMP qui supporte un OS de type Windows : la version 7.
- la secondaire = la HMBR (Hybrid_Master_Boot_Record) dont les descripteurs occupent le seul bloc initial 0. Elle constitue une simple redondance logique de la GPT dans le mode MBR, càd. une re-description des même partitions du disque, au bloc près, définies au départ par la GPT, mais selon le type descriptif MBR. C'est donc un écho logique (où l'« écologique » ne va-t-il pas se nicher ?
- normalement, en l'absence d'une partition dans un format Windows sur le disque, le bloc 0 du disque d'un Mac est occupé par une PMBR (Protective_Master_Boot_Record). Cette carte de partition secondaire ne décrit l'espace du disque que comme s'il était constitué d'une seule et unique partition totale. Ce qui, bien évidemment, ne correspond absolument pas à la réalité - car la réalité logique est fixée par la GPT principale et cette carte de partition définit au moins 3 partitions : ESP (EFI_System_Partition) n°1 > Macintosh HD n°2 > Recovery HD n°3.
Une telle table de partition PMBR est là, par défaut, pour "noyer le poisson" : empêcher que des programmes de type Windows, à les supposer démarrés, aient à leur disposition une carte de partition MBR décrivant correctement toutes les partitions existantes du disque > ce qui permettrait leur reformatage éventuel. Le "bloc" massif de la PMBR au contraire neutralise une lecture ciblée des partitions existantes (par exemple la Macintosh HD de l'OS) et "protège" ainsi les partitions GPT contre des effacements éventuels.
- Mais dès qu'une partition supplémentaire aux 3 régulières Apple est créée sur le disque dans un format Windows (fat32 ou exfat ou ntfs) > alors la PMBR du bloc 0 se trouve convertie automatiquement au type HMBR : Hybrid_Master_Boot_Record. Tu sais qu'on appelle "hybride" un rejeton issu du mélange de 2 espèces distinctes mais compatibles (comme un tigron est un hybride de tigre et de lion). Une HMBR est un tel hybride (d'ordre logique) de l'espèce de carte de partition Apple : GPT et de l'espèce de carte de partition Windows : MBR (hybridation logique hautement paradoxale, vu qu'il y a une espèce d'incommensurablité entre ces 2 espèces logiques). Cet improbable hybride HMBR (une espèce de « tigroule » logique : hybride du tigre et de la poule) a tous les traits descripteurs d'une MBR > mais emprunte à l'espèce GPT les définitions sectorielles des partitions que cette dernière à effectuées au préalable (càd. l'alignement de blocs constituant les partitions "au bloc près").
La limitation de principe d'une HMBR est qu'elle ne peut intégrer en mode « écho hybridatif valide de la GPT » que 3 et 3 seulement des partitions créées au préalable par la GPT - toute intégration « hybridative » de partitions GPT supplémentaires (si elles existent) étant invalide.
Une telle table de partition PMBR est là, par défaut, pour "noyer le poisson" : empêcher que des programmes de type Windows, à les supposer démarrés, aient à leur disposition une carte de partition MBR décrivant correctement toutes les partitions existantes du disque > ce qui permettrait leur reformatage éventuel. Le "bloc" massif de la PMBR au contraire neutralise une lecture ciblée des partitions existantes (par exemple la Macintosh HD de l'OS) et "protège" ainsi les partitions GPT contre des effacements éventuels.
- Mais dès qu'une partition supplémentaire aux 3 régulières Apple est créée sur le disque dans un format Windows (fat32 ou exfat ou ntfs) > alors la PMBR du bloc 0 se trouve convertie automatiquement au type HMBR : Hybrid_Master_Boot_Record. Tu sais qu'on appelle "hybride" un rejeton issu du mélange de 2 espèces distinctes mais compatibles (comme un tigron est un hybride de tigre et de lion). Une HMBR est un tel hybride (d'ordre logique) de l'espèce de carte de partition Apple : GPT et de l'espèce de carte de partition Windows : MBR (hybridation logique hautement paradoxale, vu qu'il y a une espèce d'incommensurablité entre ces 2 espèces logiques). Cet improbable hybride HMBR (une espèce de « tigroule » logique : hybride du tigre et de la poule) a tous les traits descripteurs d'une MBR > mais emprunte à l'espèce GPT les définitions sectorielles des partitions que cette dernière à effectuées au préalable (càd. l'alignement de blocs constituant les partitions "au bloc près").
La limitation de principe d'une HMBR est qu'elle ne peut intégrer en mode « écho hybridatif valide de la GPT » que 3 et 3 seulement des partitions créées au préalable par la GPT - toute intégration « hybridative » de partitions GPT supplémentaires (si elles existent) étant invalide.
La seule conjecture que j'ai réussi à former pour rendre compte de la perte du caractère démarrable de ta partition BOOTCAMP (alors même que son code de partition est correct et qu'elle supporte le boot_flag : indicateur de caractère démarrable) > est que la HMBR du bloc 0 de ton disque, suite à la création d'un format CoreStorage impliqué dans l'installation de «Sierra» sur la partition Macintosh HD, aurait subi l'interpolation au rang n°3 de la partition de secours Recovery HD qu'elle ignorait précédemment. Donc au lieu de décrire en mode hybridatif de la GPT les 3 partitions :
GPT n°1 (= ESP) > HMBR n°1
GPT n°2 (= Macintosh HD) > HMBR n°2
GPT n°4 (= BOOTCAMP) > HMBR n°3
GPT n°2 (= Macintosh HD) > HMBR n°2
GPT n°4 (= BOOTCAMP) > HMBR n°3
ce que je conjecture avoir été la situation logique de départ > après interpolation de la Recovery HD elle équivaut à :
GPT n°1 (= ESP) > HMBR n°1
GPT n°2 (= Macintosh HD) > HMBR n°2
GPT n°3 (= Recovery HD) > HMBR n°3
GPT n°4 (= BOOTCAMP) > HMBR n°4
GPT n°2 (= Macintosh HD) > HMBR n°2
GPT n°3 (= Recovery HD) > HMBR n°3
GPT n°4 (= BOOTCAMP) > HMBR n°4
=> donc la partition BOOTCAMP aurait glissé au rang n°4 dans la représentation hybridée de la HMBR > et comme seules 3 descriptions de partitions dans l'ordre y sont valides > la description GPT n°4 (= BOOTCAMP) > HMBR n°4 serait devenue invalide. Donc l'EFI au démarrage ne peut pas utiliser la table HMBR pour booter BOOTCAMP en mode « Legacy » > car la partition BOOTCAMP rejetée au rang n°4 n'y est plus valide.
=> ce que je proposerais comme expérimentation est : dans un premier temps ramener cette HMBR invalide au type par défaut PMBR (représentation de l'espace du disque comme constitué d'une seule partition) > et dans un 2è temps reconvertir cette PMBR dans un type HMBR valide qui serait le suivant :
GPT n°1 (= ESP) > HMBR n°1
GPT n°4 (= BOOTCAMP) > HMBR n°2
Dernière édition par un modérateur:
