# Problème de démarrage bootcamp



## alex-rcs (13 Octobre 2016)

Bonjour,

Je viens de faire la mise à jour MacOS Sierra, et maintenant quand j'essaye de redémarrer mon mac sur la partition Windows 7, j'ai un écran noir avec un curseur blanc clignotant des le redémarrage.
Tout fonctionnait bien avant la mise à jour...

Que faire ?


Merci d'avance !


----------



## Locke (13 Octobre 2016)

alex-rcs a dit:


> Que faire ?


Pour  le moment, lance le Terminal et fais un retour des commandes...

*diskutil list*

...et...

*diskutil cs list*

...dans ta réponse en faisant un clic sur l'icône carrée avec un signe plus, de sélectionner Code, puis de faire un Copier/coller du résultat de chaque commande...






...clic sur les images pour agrandir. 

Les ténors du Terminal devraient faire une apparition et ce sont *jeanjd63* et *macomaniac*.


----------



## alex-rcs (13 Octobre 2016)

Merci de ta réponse !

Voilà les retours :


```
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            399.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                100.0 GB   disk0s4

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            Macintosh HD           +396.1 GB   disk1
                                 Logical Volume on disk0s2
                                 A81404A6-6821-48CE-B599-3D808B4F0A0B
                                 Unencrypted
```


```
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 8C3D7070-0EE9-4420-8787-27A558A56DC9
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         399248105472 B (399.2 GB)
    Free Space:   2760474624 B (2.8 GB)
    |
    +-< Physical Volume B46C930C-5499-4382-8D13-E7C327916A57
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     399248105472 B (399.2 GB)
    |
    +-> Logical Volume Family 1F38392D-BF3A-4FDB-9272-C0DFA7C7447D
        ----------------------------------------------------------
        Encryption Type:         None
        |
        +-> Logical Volume A81404A6-6821-48CE-B599-3D808B4F0A0B
            ---------------------------------------------------
            Disk:                  disk1
            Status:                Online
            Size (Total):          396135309312 B (396.1 GB)
            Revertible:            Yes (no decryption required)
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS
```


----------



## Deleted member 1099514 (13 Octobre 2016)

Salut.

Pas de lézard à priori.
On peut tenter de supprimer le CoreStorage, mais j'ai des doutes que ça puisse résoudre le pb de Windows.
A tenter :
*diskutil cs revert A81404A6-6821-48CE-B599-3D808B4F0A0B
*
Puis redémarrer.

A mon avis, il faudrait démarrer sur un DVD Windows 7 (ou une clé USB) et tenter de réparer windows.


----------



## macomaniac (13 Octobre 2016)

Salut *Alex
*
Il me semble que l'«Assistant BootCamp» de «Sierra» ne permet plus l'installation de Windows-7 > mais qu'en cas de W-7 pré-installé sur le disque du Mac > «Sierra» n'empêche en rien le boot sur la partition *BOOTCAMP* préexistante de W-7. Ce serait à vérifier - histoire de savoir s'il faut incriminer ou non l'OS.

Ce qui est sûr, c'est que l''installateur de «Sierra» intercale un dispositif *CoreStorage* entre le container-disque de la partition *Macintosh HD* et le système de fichiers terminal dont dépendent les fichiers Système & perso. Soit : un *Volume Physique* (émulant un disque dur) importé sur la partition > dont s'exporte un *Volume Logique* (portant le système de fichiers terminal) - avec une *Famille de Volumes Logiques* intermédiaire qui gère le montage du *Volume Logique* à partir du *Volume Physique*. Le *Volume Logique* exporté est assimilé à un disque interne virtuel de second ordre : *disk1* par rapport au *disk0* du disque dur.

Il y a des alors des chances, si ta partition-Système (*disk0s2*) n'accueillait pas de format *CoreStorage* avant ta mise-à-niveau à «Sierra» > que la génération du *CoreStorage* ait fichu le bazar et invalidé le caractère démarrable de ton «Windows». Simple conjecture de ma part.

Comme le format *CoreStorage* de la partition *disk0s2* est marqué : « *Revertible: Yes (no decryption required)* » (réversible non destructivement pour le système de fichiers en place, gérant l'OS et les données) => tu peux déjà le déconstruire pour revenir à un format standard. Pour cela, passe la commande (copier-coller) :

```
diskutil coreStorage revert A81404A6-6821-48CE-B599-3D808B4F0A0B
```
 et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) > une fois que tu auras récupéré l'invite de commande à ton nom (genre *alex-rc$*) avec message de réussite > *re-démarre* impérativement ton Mac parce que le *kernel* continue sinon de faire comme si le *Volume Logique* exporté existait toujours en tant que *disk1* > *après re-démarrage* > tu auras un système de fichiers directement ancré sur l'en-tête de blocs de la partition.

Comme *Jean *(dont je m'avise qu'il vient de me précéder tandis que je m'échinais sur mon brouillon) > je ne pense pas qu'une simple réversion du *CoreStorage* puisse te faire récupérer le caractère bootable de ta partition *BOOTCAMP* > car tout doit se jouer au niveau de la Table de Partition secondaire *MBR* inscrite sur le bloc *0* du disque (tandis que la *GPT* principale est écrite sur les blocs *1* > *32* suivants). L'OS W-7 boote, en effet, en mode « *Legacy* », càd. par exécution par l'*EFI* (*Programme Interne* du Mac) du code de la *MBR* du bloc *0* et pas par exécution du code de la *GPT* (comme pour les versions plus modernes de Windows). Donc > l'instauration du format *CoreStorage* a dû affecter (avec la génération du disque I*nternal, Virtual* de 2è ordre : *disk1* = *Volume Logique* ») la description des partitions dans la table *GPT* principale > dont la table secondaire *MBR* est un écho sélectif (s'il s'agit d'une *Hybrid_MBR* : *MBR* hybridée du partitionnement pré-existant de la *GPT*). Il doit donc se faire que la *MBR* du bloc *0* ne représente plus actuellement la partition *BOOTCAMP* ou que cette partition ait perdu pour elle son *bootable_flag* : indicateur de caractère démarrable.

On s'engage là dans une voie logique délicate > je te suggère simplement pour commencer de passer la commande (après déconstruction du *CoreStorage*) :

```
sudo gpt show /dev/disk0
```
 et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ => en retour > tu vas obtenir le tableau de la distribution des blocs de ton disque + une identification des tables de partition sur le secteur d'amorçage du disque > peux-tu faire un copier-coller de ce tableau ici ?

=> c'est pour vérifier si tu as bien un *HMBR* (*H*ybrid_*MBR*) sur le bloc *0* du disque (qui serait identifiée alors comme « *suspicious_MBR*).


----------



## alex-rcs (13 Octobre 2016)

Merci de vos réponses aussi précises !

Voilà le retour à la première commande :


```
Started CoreStorage operation on disk1 Macintosh HD
Switching partition from Core Storage type to original type
Reclaiming space formerly used by Core Storage metadata
Even though the disk is now fully reverted, you should reboot soon to re-mount your reverted disk from the actual original partition
Removing Physical Volume
Destroying Logical Volume Group
Remounting former Physical Volume as normal disk
Core Storage LV UUID: A81404A6-6821-48CE-B599-3D808B4F0A0B
Core Storage disk: disk0s2
Finished CoreStorage operation on disk1 Macintosh HD
```


Comme conseillé, je vais redémarrer mon mac avant de faire autre chose.

EDIT : Au redémarrage (de macOS), j'ai eu droit au même écran noir+curseur clignotant qui ne veut pas partir. Donc j'ai forcé l'extinction, puis redémarrage+option et là, en plus des Windows et Mac, une partition "EFI Boot" est apparue.
J'ai quand même redémarré sur Mac.


----------



## alex-rcs (13 Octobre 2016)

Et voilà la réponse au 


```
sudo gpt show /dev/disk0
```


```
gpt show: /dev/disk0: Suspicious MBR at sector 0
      start       size  index  contents
          0          1         MBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6        
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  779781456      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  780191096    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  781460632        872        
  781461504  195311616      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773120         15        
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
```


----------



## Deleted member 1099514 (13 Octobre 2016)

Si tu tentes de démarrer sur EFI ça dit quoi?

PS : tu avais quoi comme version os x avant Sierra?


----------



## alex-rcs (13 Octobre 2016)

J'essayerais demain alors.
Yosemite.


----------



## scoliaste (14 Octobre 2016)

Ça marche chez toi EFI boot ?


----------



## macomaniac (14 Octobre 2016)

Salut *Alex*

Alors tu as bien sur le bloc *0* une « *suspicious MBR* » (selon le vocabulaire de *gpt*) : càd. en d'autres termes une *HMBR* (*H*ybrid_*MBR*) qui ne doit plus contenir la désignation de la partition *BOOTCAMP* comme partition bootable de type Windows.

Tu peux toujours tenter de démarrer sur le volume *EFI Boot* > mais en cas de non démarrage > je te suggère de télécharger l'outil de la dernière chance : l'utilitaire ☞*GPT fdisk*☜ créé par _Roderick Smith, _le développeur du gestionnaire de boot «rEFInd» (clique sur le lien rouge). Tu obtiens un paquet d'installation intitulé : *gdisk-1.0.1.pkg* qu'il suffit de double-cliquer pour lancer l'installation d'un binaire *gdisk* at: /usr/local/bin/*gdisk*.

Une fois cette installation opérée > tu peux appeler *gdisk* en ligne de commande dans le «Terminal».

Afin de récolter quelques informations utiles (aucun usage de *gdisk* en mode _écriture_ pour l'instant > seulement en mode _lecture_) > lance le «Terminal» et passe les commandes successives :

*- a)* d'abord :

```
sudo gdisk /dev/disk0
```
 et ↩︎ --> renseigne ton mot-de-passe admin à l'aveugle à la demande de password et ↩︎ à novueau. En retour, tu vas voir s'afficher le scan des tables de partitions présente sur le secteur d'amorcage de ton disque.

=> peux-tu le poster ici en copier-coller ? Histoire de confirmer que tu as bien une *MBR: hybrid* sur le bloc *0*.

--------------------​
*- b)* en fin de retour d'affichage, tu as obtenu ceci :


```
Found valid GPT with hybrid MBR; using GPT.

Command (? for help):
```
 où le *Command (? for help):* est l'invite de commande interactive de *gdisk*. Tu tapes :

```
x
```
 (comme e*x*pert_mode) et ↩︎ --> en retour, tu obtiens l'affichage :

```
Expert command (? for help):
```
 qui est l'invite de commande spécifique de l'e*x*pert_mode.

--------------------​
*- c)* tu tapes :


```
o
```
 (lettre minuscule *o*) et ↩︎ --> en retour, tu vas obtenir la carte des partitions de la *GPT* principale qui ont été "intégrées en écho" dans la table *HMBR* - partitions décrites par leur numéro > boot_flag > secteur de blocs > statut > code.

=> peux-tu faire un copier-coller encore de ce tableau ? C'est pour vérifier ici en quoi consiste la carte actuelle de ta *HMBR* > si la partition *BOOTCAMP* y est toujours décrite > et si oui, si elle supporte un *boot_flag* ou non.

--------------------​=> En ayant terminé avec ce round d'observation de *gdisk* > tu tapes :


```
q
```
 (comme *q*uit) et ↩︎ --> tu récupères l'invite de commande régulière du «Terminal» à ton nom d'utilisateur. Tu peux quitter le «Terminal» (tu n'as pas oublié de poster les 2 tableaux auparavant, n'est-ce pas ?).


----------



## alex-rcs (15 Octobre 2016)

Bonjour,

Du coup j'ai relancé ma machine sur l'EFI Boot, ça me met une fenêtre avec 4 utilitaires (disque, mise à jour, restaurer sauvegarde, ...).

Sinon pour la première commande :


```
MacBook-Pro-de-Alexandre:~ Alex$ sudo gdisk /dev/disk0
sudo: gdisk: command not found
```


----------



## Deleted member 1099514 (15 Octobre 2016)

alex-rcs a dit:


> Bonjour,
> 
> Du coup j'ai relancé ma machine sur l'EFI Boot, ça me met une fenêtre avec 4 utilitaires (disque, mise à jour, restaurer sauvegarde, ...).
> 
> ...


Donc EFI correspond à la partition Recovery.
Pour gdisk, comme expliqué par @macomaniac  l'as-tu téléchargé et installé ? : https://sourceforge.net/projects/gptfdisk/


----------



## alex-rcs (15 Octobre 2016)

En effet, j'ai tapé cette étape :/

Voilà le résultat après installation du soft :

```
GPT fdisk (gdisk) version 1.0.1

Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
NOTE: Write test failed with error number 1. It will be impossible to save
changes to this disk's partition table!
You may need to deactivate System Integrity Protection to use this program. See
https://www.quora.com/How-do-I-turn-off-the-rootless-in-OS-X-El-Capitan-10-11
for more information.

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with hybrid MBR; using GPT.
```

Et le résultat de l'expert command :


```
Disk size is 976773168 sectors (465.8 GiB)
MBR disk identifier: 0x23491213
MBR partitions:

Number  Boot  Start Sector   End Sector   Status      Code
   1                     1       409639   primary     0xEE
   2                409640    780191095   primary     0xAF
   3             780191096    781460631   primary     0xAB
   4      *      781461504    976773119   primary     0x0C
```


Merci de votre aide.


----------



## macomaniac (15 Octobre 2016)

alex-rcs a dit:


> j'ai relancé ma machine sur l'EFI Boot, ça me met une fenêtre avec 4 utilitaires



Il me revient, effet, que le volume de la *Recovery HD* apparaît parfois sous l'intitulé *EFI Boot* - je n'ai jamais cerné exactement à la suite de quelles circonstances.

--------------------​
Pour ce qui est du résultat de la commande *gdisk* :

- il y a bien une *HMBR* (*H*ybrid_*MBR*) sur le bloc *0* du disque - table de partition hybridée qui commande le boot sur la partition *BOOTCAMP* en mode « *Legacy* » (car Système installé = Win-7).

- cette table de partition est un hybride de la *GPT* principale, au sens où elle décrit en écho, en mode *MBR*, les partitions de la *GPT* :

- l'*ESP* (ou *E*FI_*S*ystem_*P*artition) est décrite en pseudo-mode, comme si elle n'occupait qu'un seul bloc : le bloc *409639*.

- la partition *Macintosh HD* est décrite exactement par l'alignement de ses blocs : *409640*  >  *780191095
*
- la partition *Recovery HD* est aussi décrite exactement par l'alignement de ses blocs : *780191096*  >  *781460631
*
- la partition *BOOTCAMP* est enfin décrite exactement par l'alignement de ses blocs : *781461504*  >  *976773119*​
=> il n'y a donc aucune erreur de blocs sur les partitions principales (par rapport à la description *GPT* qui est le paradigme). De surcroît, la partition *BOOTCAMP* dans la *HMBR* est reconnue porteuse du *boot_flag* (indicateur de caractère démarrable) > ce qui se voit à son *** dans la colonne *Boot*.

=> le seul point qui m'apparaisse suspect est le *code* de la partition *BOOTCAMP* dans la *HMBR* : *0x0C*. D'après des tests que j'ai menés de mon côté > il semblerait que ce devrait être *0x07*. Cela suffit-il à invalider la représentation de la partition *BOOTCAMP* comme disque démarrable selon la description *HMBR* ? - pas impossible... C'est le seul point foireux que je détecte.

Dans cette optique > ce qui serait envisageable est la chose suivante (sans aucune garantie que cela récupère le caractère démarrable de *BOOTCAMP*) - tout par l'intermédiaire de *gdisk* :

*- a)* reconvertir dans un premier temps la *HMBR* (*H*ybrid_*MBR* reflétant les partitions de la *GPT* en mode *MBR*) du bloc *0* en *PMBR* (*Protective_MBR* mono-partitionnée = représentant le disque entier comme constitué d'une unique partition).

*- b)* régénérer à partir de cette *PMBR* une nouvelle *HMBR* intégrant notamment la description de la partition *BOOTCAMP* avec le bon *code* de partition si possible cette fois  et évidemment le *boot_flag*.​
--------------------​
ÉDITION: rétrospectivement si > quelque chose d'autre me paraît suspect dans cette *HMBR*. Normalement, une *HMBR* comporte une limitation du nombre de partitions de la *GPT* paradigme auxquelles elle peut légitimement faire écho : à savoir *3* (c'est le chiffre limitatif d'une hybridation *MBR* valide sur un disque Mac). Or le scan de *gdisk* révèle *4* partitions décrites dans l'actuelle *HMBR* - soit une de trop. À supposer que soient validées les partitions décrites en mode *HMBR* à partir de celle de départ > la limite de validité tomberait juste avec la *Recovery HD* décrite au rang n°*3* --> la partition *BOOTCAMP* décrite au rang n°*4* ayant alors toutes les chances d'être non validée.

=> Il conviendrait donc, en cas de régénération d'une *HMBR*, de ne pas tomber dans le piège de faire écho aux *4* partitions de la *GPT*, mais seulement de *3* grand maximum incluant la *BOOTCAMP*.

Une édition de la *HMBR* a-t-elle pu être occasionnée par la génération d'un *CoreStorage* sur la partition n°*2* *Macintosh HD* > sachant qu'un *CoreStorage*, même non chiffré, requiert le *boot_loader boot.efi* de la *Recovery HD* comme *booter* de *macOS* > ce qui aurait pu avoir pour effet d'intercaler au rang n°*3* de la *HMBR* la partition *Recovery HD* (solidaire désormais du boot de la *Macintosh HD*) qui en était exclue au départ > et donc rejetant en position indue n°*4* la description de *BOOTCAMP* ?

--------------------​


----------



## Deleted member 1099514 (15 Octobre 2016)

Si tu fais :
*sudo gdisk /dev/disk0*
là taper *p*
Et donner le résultat.


----------



## alex-rcs (17 Octobre 2016)

Merci de vos réponses !


```
Command (? for help): p
Disk /dev/disk0: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 080EB604-1C9A-4FB1-8AEC-0A7A500BA179
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 893 sectors (446.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition
   2          409640       780191095   371.8 GiB   AF00  Macintosh HD
   3       780191096       781460631   619.9 MiB   AB00  Recovery HD
   4       781461504       976773119   93.1 GiB    0700  BOOTCAMP
```


----------



## Deleted member 1099514 (17 Octobre 2016)

alex-rcs a dit:


> Merci de vos réponses !
> 
> 
> ```
> ...


Tes partitions ont bien le bon code (0700) pour Windows.


----------



## macomaniac (17 Octobre 2016)

*Alex*

En effet : le code de la *BOOTCAMP* est correct. En plus, il apparaissait précédemment qu'elle porte le *boot_flag ** (indicateur de caractère démarrable).

Il ne me reste plus que la conjecture : *4* partitions décrites dans la *H*ybrid_*MBR* alors que *3* seules sont validables (s'il s'agit des 3 premières dans l'ordre logique > alors la partition *BOOTCAMP*, quoique décrite correctement, est non valide en tant que n°4).

Donc la question est : est-ce que tu veux tenter un effacement suivi d'une recréation de la *H*ybrid_*MBR* du bloc *0* en s'arrangeant pour que la *BOOTCAMP* tombe dans les 3 partitions validables ?


----------



## alex-rcs (17 Octobre 2016)

Qu'il y a-t-il dans la *H*ybrid_*MBR* ?
Qu'est-ce que je risque à la supprimer ?


----------



## macomaniac (18 Octobre 2016)

Sur le secteur d'amorçage de ton disque (les blocs *0* à *32* d'en-tête), tu as *2* cartes de partitions :

- la principale = la *GPT* (*G*UID *P*artition *T*able) 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* (*H*ybrid_*M*aster_*B*oot_*R*ecord) 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*.

- 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* (*P*rotective_*M*aster_*B*oot_*R*ecord). 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* (*E*FI_*S*ystem_*P*artition) *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* : *H*ybrid_*M*aster_*B*oot_*R*ecord. 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*​
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*​
=> 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*​


----------



## alex-rcs (28 Octobre 2016)

Bonjour,
Désolé du délai, j'étais un peu occupé cette semaine...

J'ai attentivement relu vos explications, mais toujours pas compris ce que je dois faire en pratique pour supprimer la partition en trop ? Elle n'apparait pas dans l'utilitaire de disque.

Merci !


----------



## Deleted member 1099514 (28 Octobre 2016)

Tu peux tenter de démarrer en mode recovery et dans le terminal taper :
diskutil repairdisk /dev/disk0


----------



## alex-rcs (28 Octobre 2016)

Mode recovery ; c'est à dire EFI ?


----------



## Deleted member 1099514 (29 Octobre 2016)

alex-rcs a dit:


> Mode recovery ; c'est à dire EFI ?


Yes


----------

