# Windows 7: 'no bootable device' lorsque demarré avec Alt



## flotow (12 Mars 2018)

Bonjour

J'ai installé Windows 7 avec l'assistant BootCamp ce weekend. Tout va bien.
Tout est a jour sur Windows et les pilotes BootCamp sont bien installés.

Si je démarre sur le Mac, j'ai 100% de réussite.
Si je re-démarre sur Windows avec les preferences Systèmes, pas de soucis.
Par contre si je démarre sous Windows en appuyant sur Alt au démarrage (Mac OS étant défini comme système principal), alors j'ai 'no bootable device'

Si j'eteins et que je redemarre Mac OS puis Pref. Systèmes pour démarrer sous Windows, alors c'est bon.

Mac OS 10.11.6/W7 SP1 sur un iMac 2011.
Aussi bien Windows que Mac OS sont frais de ce weekend (tout comme le SSD sur lequel ils sont installés).

Une idée ?


----------



## Locke (12 Mars 2018)

Un problème de boot que notre ami macomaniac va surement voir quelque part.


----------



## macomaniac (14 Mars 2018)

*flotow* & *Locke*

C'est du genre : "Casse-tête chinois".

Choisir un volume dans le panneau du *Startup-disk Manager* (Disque de démarrage) --> revient à inscrire en *NVRAM*, à la variable *efi-boot-device*, un chemin de démarrage automatique pour l'*EFI* sur le volume-cible. Après > c'est le chemin de boot inscrit sur l'en-tête du volume-cible > qui fait que l'*EFI* va pouvoir accéder à un *boot_loader* pour l'exécuter.

La complication surgit, avec Windows-7, du fait que cet OS se démarre en mode "*Legacy*" (à l'ancienne) > et pas en mode "*UEFI*" (à la moderne). Ce qui signifie : le *boot_loader* de W-7 est un fichier *bootmgr* qui n'est pas exécutable par un programme interne de type "*EFI*" (comme celui, natif, du Mac) > mais par un programme interne de type "*BIOS*" (comme celui des anciens PC). Un *BIOS* a besoin d'accéder au disque supportant le volume-cible par une table de partition de type *MBR* > lui décrivant la partition de boot par un descripteur "ancien mode Windows". Il faut de surcroît dans la table *MBR* que le "*bootable_flag*" (le fanion : "je suis démarrable !") > soit apposé en regard de la partition-cible.

Les ingénieurs de la  avaient donc implémenté des fonctionnalités complexes : tout disque Mac est toujours porteur de *2* tables de partitions sur l'en-tête (secteur d'amorçage : blocs *0* à *32*) et pas d'une seule : la *GPT* principale et une *MBR* alternative. La *MBR* alternative, inscrite sur le seul bloc *0*, est par défaut une *PMBR* (*P*rotective_*MBR*) ne décrivant aucune partition spécifique sur le disque > mais emballant l'ensemble de l'espace du disque dans une "super-partition" dotée du *hex code* : *0xEE* --> càd. partition de type *EFI GPT*. Autant dire inutilisable. Mais, dès qu'une partition se trouve créée dans un format Windows (comme le *FAT-32* ou le *NTFS*) --> alors la *PMBR* du bloc *0* se trouve automatiquement convertie (***) à une *HMBR* (*H*ybrid_*MBR* : table *MBR* fonctionnelle > empruntant la description de *3* partitions au plus à la table *GPT* principale --> donc une *MBR* "hybridée" de la définition *GPT* des partitions).


(***) ce mécanisme de conversion automatique de la *PMBR* du bloc *0* à une *HMBR* dès la création de toute partition dans un format Windows sur le disque --> a été abandonné à partir de l'OS Sierra 10.12. Parce que le nouveau W-10 bootant en mode "*UEFI*" (*EFI* --> *GPT* --> *boot_loader bootmgr.efi*) a rendu obsolète cette problématique d'un boot "*Legacy*" de Windows.

À la détection d'une *HMBR* sur un en-tête de disque > le programme interne *EFI* a été implémentée d'une capacité à « émuler un *BIOS* » --> on obtient alors le mécanisme logique : *EFI* --> *BIOS_émulé* --> *HMBR* --> *boot_loader bootmgr*.

Quand on démarre la touche "*alt*" pressée > on déclenche le programme interne *EFI* avec une "option de suspension" : un sous-programme appelé le *Boot_Manager* va scanner tous les volumes montés dans le temps du boot > afin de détecter et d'afficher ceux qui ont un caractère démarrable par l'*EFI*. Ce qui fait que l'*EFI* > au lieu de lire l'entrée de la variable *efi-boot-device* (appareil de démarrage automatique de l'*EFI*) en *NVRAM* > se retrouve en "stand-by" > tandis que son *Boot_Manager* affiche à l'écran le sous-ensemble des volumes démarrables. Le choix fait par l'utilisateur de tel volume affiché > inscrit en *NVRAM* à une variable *efi-next-only* (appareil de démarrage "seulement pour cette fois") l'adresse au volume-cible > avec valeur de surclassement de la variable *efi-boot-device* (appareil de démarrage "régulier" de l'*EFI*).

Bref : le choix du volume Windows à l'écran du *Boot_Manager* écrit une adresse à une variable *efi-next-only* en *NVRAM* > là où le choix de ce même volume à l'écran du *StartupDisk Manager* écrit une adresse à la variable *efi-boot-device* en *NVRAM*.

A priori --> on attendrait que les 2 adresses soit équivalentes > ce qui fait que l'*EFI* > « s'apercevant » que le volume-cible lui est désigné via un descripteur *MBR* de l'en-tête du disque --> hop ! émule un *BIOS* à la volée pour adresser ledit volume et pouvoir exécuter le *boot_loader* "*Legacy*" : *bootmgr*. La question est donc : à quel moment une variation s'introduit-elle dans le schéma directeur qui fait que -->


si un choix via le *StartupDisk Manager* a inscrit à la variable *efi-boot-device* de la *NVRAM* l'adresse au volume Windows --> alors le boot se fait en mode "*Legacy*" (*EFI* --> *BIOS_émulé* --> descripteur *HMBR* > *boot_loader bootmgr*)

si un choix via le *Boot_Manager* a inscrit à la variable *efi-next-only* de la *NVRAM* l'adresse au volume Windows --> alors le boot en mode "*Legacy*" avorte. Le "*no bootable device*" évoquant un programme interne *EFI* adressant en tant qu'*EFI* et pas *BIOS_émulé* le disque de résidence du volume Windows.

Il faut donc mener une enquête pour -->


vérfier s'il y a bien une *HMBR* sur le bloc *0* du disque > signe que le boot de W-7 s'opère bien en mode *Legacy* (par un *BIOS_émulé*)

examiner l'inscription valide à la variable *efi-boot-device* après un choix de Windows dans le panneau du *StartupDisk  Manager* - le problème étant que l'entrée *efi-next-only* en cas de choix à l'écran du *Boot_Manager* reste inscrutable > puisque cette variable est effacée de la *NVRAM* après usage

Si le *SIP* d'El Capitan ne proscrivait pas encore la lecture du secteur d'amorçage du disque de démarrage --> *après avoir fait le choix du volume de boot Windows* dans le panneau du *StartupDisk Manager* --> passer les 2 commandes :

```
sudo gpt show /dev/disk0
nvram -p
```


la 1ère affiche la distribution des blocs du disque > dont l'identification du type de *MBR* du bloc *0*

la 2è affiche le tableau des variables de la *NVRAM*

Tu n'as qu'à, *flotow*, poster les 2 retours dans une fenêtre de code > dont je te rappelle le procédé -->


dans la page de ce fil de MacGé > presse le bouton *⌹* (carré avec un + inscrit - juste au milieu de la largeur de la fenêtre totale) dans la barre de menus au-dessus du champ de saisie d'un message > menu  : *</> Code* > par *⌘V* colle dans la fenêtre *Code* > presse le bouton *Insérer* (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

[Note: c'est le genre de problème où je pars battu d'avance > parce qu'à la simple lecture de sa description > je n'ai aucune "anticipation intuitive" d'une issue possible. Bref : je ne "vois" rien.]


----------



## flotow (14 Mars 2018)

Merci @macomaniac !
L'iMac est dans un carton, de retour vers "Paris".
Dès qu'il arrive à bon port, je demanderai à ce que les deux commandes soient passées.


----------



## macomaniac (14 Mars 2018)

flotow a dit:


> Dès qu'il arrive à bon port, je demanderai à ce que les deux commandes soient passées.



N'ouble pas de stipuler : avant la commande *nvram -p* (qui affiche le tableau des variables de la *NVRAM*) --> il faut aller au panneau des Préférences Système : Disque de démarrage > et sélectionner le volume Windows (sans re-démarrer dessus). Cette sélection graphique va inscrire un *NVRAM* l'adresse au volume > à la variable : *efi-boot-device*.


----------



## flotow (17 Mars 2018)

Alors la table de partition :


```
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  342188976      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  342598616    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  343868152       1288      
  343869440  156248064      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  500117504        655      
  500118159         32         Sec GPT table
  500118191          1         Sec GPT header
```

Valeur de efi-boot-device AVANT de sélectionner le volume Windows (démarrage Mac OS sélectionné) :

```
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
```

Et après (démarrage Windows sélectionné) :

```
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
```


----------



## macomaniac (20 Mars 2018)

Cette ligne -->

```
0          1         MBR
```


montre qu'il existe une vraie table de partition *MBR* (ce que j'avais appelé une *H*ybrid_*MBR*) sur le bloc *0* --> décrivant des partitions.

La sélection du volume Windows n'affecte en rien la variable *efi-boot-device* --> ce qui (rétrospectivement) m'apparaît évident > car *efi-boot-device* signifie : appareil de démarrage automatique de l'*EFI*. Càd. de l'*EFI* en tant qu'*EFI* > procédant à un *EFI boot* --> or il est évident que W-7 bootant en mode *Legacy* > ne boote pas par l'*EFI* mais par un *BIOS* émulé de l'*EFI* --> donc ce n'est certainement pas à la variable *efi-boot-device* que doit se trouver inscrite une préférence de boot sur Windows (C.Q.F.D.).

En complément de test : poster les tableaux complets de la *NVRAM* retournés chaque fois par la commande :

```
nvram -p
```

une fois après avoir sélectionné le volume macOS dans le panneau *Disque de démarrage* > l'autre fois après avoir sélectionné le volume Windows --> il doit y avoir une autre variable > spécifique d'un boot de Windows > qui se trouve affectée et qui aurait la prééminence sur l'*efi-boot-device* si renseignée.


----------



## flotow (20 Mars 2018)

macomaniac a dit:


> En complément de test : poster les tableaux complets de la *NVRAM* retournés chaque fois par la commande :



J'y ai pensé et puis je me suis dit que comme tu ne voulais que cette ligne...
Bref, ce soir


----------



## flotow (20 Mars 2018)

Avant:


```
nvram -p
EFIBluetoothDelay    %b8%0b
efi-boot-device-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%b0ce%14%00%00%00%00%cbm6%f8}%0c%9bB%b8%f9X%c2%17%0a %14%02%02%7f%ff%04%00
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
BootCampHD    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%7f%ff%04%00
bluetoothInternalControllerInfo    %15%82%ac%05%00%10%11%fa%10@%f3%e7%f1%01
fmm-mobileme-token-FMM    bplist00%da%01%02%03%04%05%06%07%08%09%0a%0b%0c%17%18%19%1a%1b%1c%1d$Vuserid_%10%13dataclassPropertiesYauthTokenXpersonIDXusernameWaddTime_%10%12enabledDataclassesTguidXuserInfo_%10%11osUserDisappeared%11%01%f5%d1%0d%0e_%10!com.apple.Dataclass.DeviceLocator%d4%0f%10%11%12%13%14%15%16VapsEnvXhostname]authMechanismVschemeZProduction_%10%13p60-fmip.icloud.comUtokenUhttps_%10%ccIAAAAAAABLwIAAAAAFqjGWIRDmdzLmljbG91ZC5hdXRovQCF9bDznW7cXA_sfxZqG-bc8cUxC72ufELH5lREVOSr4Chvl6kqV7Gj3Ol8rZMM6ZPt7hIUoSRzfZsyGxnHPkT0cZNrREtkHtRVcBxuFR21XkZFV_HJAiP2F2YaawGCiGRXN6EJJ7oiIJS0kLAJ51T4qVO56A~~Y108381215_%10%12xxx@zzz.com#A%d6%a8%c6[%81%b7%1c%a1%0d_%10$F83936A2-36F9-49D4-97C0-7B9412AE5E3A%d3%1e%1f !"#_%10%15InUseOwnerDisplayName_%10%13InUseOwnerFirstName_%10%12InUseOwnerLastName_%10%17YYY ZZZ^YYYXZZZ%09%00%08%00%1d%00$%00:%00D%00M%00V%00^%00s%00x%00%81%00%95%00%98%00%9b%00%bf%00%c8%00%cf%00%d8%00%e6%00%ed%00%f8%01%0e%01%14%01%1a%01%e9%01%f3%02%08%02%11%02%13%02:%02A%02Y%02o%02%84%02%9e%02%ad%02%b6%00%00%00%00%00%00%02%01%00%00%00%00%00%00%00%25%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%b7
prev-lang:kbd    fr:1111
SystemAudioVolumeDB    %e4
fmm-computer-name    Maricopa
bluetoothActiveControllerInfo    %15%82%ac%05%00%00%00%10%11%fa%10@%f3%e7%f1%01
aht-results    <dict><key>_name</key><string>spdiags_aht_value</string><key>spdiags_last_run_key</key><date>4018-03-10T08:51:02Z</date><key>spdiags_result_key</key><string>spdiags_passed_value</string><key>spdiags_version_key</key><string>3A215</string></dict>
backlight-level    E%00
SystemAudioVolume    :
LocationServicesEnabled    %01
```

Après


```
nvram -p
EFIBluetoothDelay    %b8%0b
efi-boot-device-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%b0ce%14%00%00%00%00%cbm6%f8}%0c%9bB%b8%f9X%c2%17%0a %14%02%02%7f%ff%04%00
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
BootCampHD    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%7f%ff%04%00
bluetoothInternalControllerInfo    %15%82%ac%05%00%10%11%fa%10@%f3%e7%f1%01
fmm-mobileme-token-FMM    bplist00%da%01%02%03%04%05%06%07%08%09%0a%0b%0c%17%18%19%1a%1b%1c%1d$Vuserid_%10%13dataclassPropertiesYauthTokenXpersonIDXusernameWaddTime_%10%12enabledDataclassesTguidXuserInfo_%10%11osUserDisappeared%11%01%f5%d1%0d%0e_%10!com.apple.Dataclass.DeviceLocator%d4%0f%10%11%12%13%14%15%16VapsEnvXhostname]authMechanismVschemeZProduction_%10%13p60-fmip.icloud.comUtokenUhttps_%10%ccIAAAAAAABLwIAAAAAFqjGWIRDmdzLmljbG91ZC5hdXRovQCF9bDznW7cXA_sfxZqG-bc8cUxC72ufELH5lREVOSr4Chvl6kqV7Gj3Ol8rZMM6ZPt7hIUoSRzfZsyGxnHPkT0cZNrREtkHtRVcBxuFR21XkZFV_HJAiP2F2YaawGCiGRXN6EJJ7oiIJS0kLAJ51T4qVO56A~~Y108381215_%10%12xxx@zzz.com#A%d6%a8%c6[%81%b7%1c%a1%0d_%10$F83936A2-36F9-49D4-97C0-7B9412AE5E3A%d3%1e%1f !"#_%10%15InUseOwnerDisplayName_%10%13InUseOwnerFirstName_%10%12InUseOwnerLastName_%10%17YYY ZZZ^YYYXZZZ%09%00%08%00%1d%00$%00:%00D%00M%00V%00^%00s%00x%00%81%00%95%00%98%00%9b%00%bf%00%c8%00%cf%00%d8%00%e6%00%ed%00%f8%01%0e%01%14%01%1a%01%e9%01%f3%02%08%02%11%02%13%02:%02A%02Y%02o%02%84%02%9e%02%ad%02%b6%00%00%00%00%00%00%02%01%00%00%00%00%00%00%00%25%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%b7
prev-lang:kbd    fr:1111
SystemAudioVolumeDB    %e4
fmm-computer-name    Maricopa
bluetoothActiveControllerInfo    %15%82%ac%05%00%00%00%10%11%fa%10@%f3%e7%f1%01
aht-results    <dict><key>_name</key><string>spdiags_aht_value</string><key>spdiags_last_run_key</key><date>4018-03-10T08:51:02Z</date><key>spdiags_result_key</key><string>spdiags_passed_value</string><key>spdiags_version_key</key><string>3A215</string></dict>
backlight-level    E%00
SystemAudioVolume    :
LocationServicesEnabled    %01
```

Edit: ce sont les données de la dernière fois (j'en avait extrait la ligne). J'ai fait un diff... et rien n'est différent !


----------



## macomaniac (21 Mars 2018)

J'avoue que je n'y conçois rien -->


les 2 tableaux des variables de la *NVRAM* sont strictement identiques > pourtant est intervenu entre le 1er le 2è un acte graphique de sélection du volume Windows comme volume de démarrage. Sélection qui doit nécessairement se trouver enregistrée en *NVRAM* --> pour qu'elle prenne effet au re-démarrage > l'*EFI* devant en consultant la *NVRAM* en mode *pre-boot* lire une instruction qui surclasse (overrides) l'instruction de l'*efi-boot-device* (simplifiée ci-après) --> 
	
	



```
efi-boot-device <key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string> <string>disk0s2</string>
```



or rien n'est écrit nulle part --> instruisant ce surclassement de l'adresse de boot automatique au volume de la partition *disk0s2* > soit le volume de macOS

=> tu es sûr que le Mac bootait sur le volume Windows > en l'état n°*2* du tableau de la *NVRAM* ?


----------



## flotow (21 Mars 2018)

macomaniac a dit:


> => tu es sûr que le Mac bootait sur le volume Windows > en l'état n°*2* du tableau de la *NVRAM* ?



Je n'ai pas redémarré après l'avoir sélectionné, pensant que c'était bon. Je n'ai fait le diff qu'hier soir. 
Je ne sais pas exactement quand la nvram se met à jour, mais à priori, pas seulement lors de la sélection...
Étant donné que les préférences sont verrouillées, il se peut que ce soit écrit lorsque le cadenas se verrouille. Je n'en sais rien, mais je vais essayer ca, ce soir.


----------



## flotow (22 Mars 2018)

Bon, j'avais vu juste (mais un peu tard) : il faut verrouiller les preferences systèmes pour que la nvram soit mise a jour.

Donc, de nouveau...

Avant :

```
aht-results    <dict><key>_name</key><string>spdiags_aht_value</string><key>spdiags_last_run_key</key><date>4018-03-10T08:51:02Z</date><key>spdiags_result_key</key><string>spdiags_passed_value</string><key>spdiags_version_key</key><string>3A215</string></dict>
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
SystemAudioVolume    %1d
fmm-mobileme-token-FMM    bplist00%da%01%02%03%04%05%06%07%08%09%0a%0b%0c%17%18%19%1a%1b%1c%1d$Vuserid_%10%13dataclassPropertiesYauthTokenXpersonIDXusernameWaddTime_%10%12enabledDataclassesTguidXuserInfo_%10%11osUserDisappeared%11%01%f5%d1%0d%0e_%10!com.apple.Dataclass.DeviceLocator%d4%0f%10%11%12%13%14%15%16VapsEnvXhostname]authMechanismVschemeZProduction_%10%13p60-fmip.icloud.comUtokenUhttps_%10%ccIAAAAAAABLwIAAAAAFqjGWIRDmdzLmljbG91ZC5hdXRovQCF9bDznW7cXA_sfxZqG-bc8cUxC72ufELH5lREVOSr4Chvl6kqV7Gj3Ol8rZMM6ZPt7hIUoSRzfZsyGxnHPkT0cZNrREtkHtRVcBxuFR21XkZFV_HJAiP2F2YaawGCiGRXN6EJJ7oiIJS0kLAJ51T4qVO56A~~Y108381215_%10%12xxx@xxx.com#A%d6%a8%c6[%81%b7%1c%a1%0d_%10$F83936A2-36F9-49D4-97C0-7B9412AE5E3A%d3%1e%1f !"#_%10%15InUseOwnerDisplayName_%10%13InUseOwnerFirstName_%10%12InUseOwnerLastName_%10%17YYY ZZZ^YYYXZZZ%09%00%08%00%1d%00$%00:%00D%00M%00V%00^%00s%00x%00%81%00%95%00%98%00%9b%00%bf%00%c8%00%cf%00%d8%00%e6%00%ed%00%f8%01%0e%01%14%01%1a%01%e9%01%f3%02%08%02%11%02%13%02:%02A%02Y%02o%02%84%02%9e%02%ad%02%b6%00%00%00%00%00%00%02%01%00%00%00%00%00%00%00%25%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%b7
bluetoothInternalControllerInfo    %15%82%ac%05%00%10%11%fa%10@%f3%e7%f1%01
BootCampHD    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%7f%ff%04%00
prev-lang:kbd    fr:1111
SystemAudioVolumeDB    %d5
fmm-computer-name    Maricopa
bluetoothActiveControllerInfo    %15%82%ac%05%00%00%00%10%11%fa%10@%f3%e7%f1%01
efi-boot-device-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%b0ce%14%00%00%00%00%cbm6%f8}%0c%9bB%b8%f9X%c2%17%0a %14%02%02%7f%ff%04%00
backlight-level    E%00
EFIBluetoothDelay    %b8%0b
LocationServicesEnabled    %01
```

Apres :

```
aht-results    <dict><key>_name</key><string>spdiags_aht_value</string><key>spdiags_last_run_key</key><date>4018-03-10T08:51:02Z</date><key>spdiags_result_key</key><string>spdiags_passed_value</string><key>spdiags_version_key</key><string>3A215</string></dict>
efi-boot-device    <array><dict><key>MemoryType</key><integer size="64">0xb</integer><key>StartingAddress</key><integer size="64">0xff981000</integer><key>IOEFIDevicePathType</key><string>HardwareMemoryMapped</string><key>EndingAddress</key><integer size="64">0xffc8ffff</integer></dict><dict><key>IOEFIDevicePathType</key><string>MediaFirmwareVolumeFilePath</string><key>Guid</key><string>2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7</string></dict><dict><key>IOEFIBootOption</key><string>HD</string></dict></array>
SystemAudioVolume    %1d
fmm-mobileme-token-FMM    bplist00%da%01%02%03%04%05%06%07%08%09%0a%0b%0c%17%18%19%1a%1b%1c%1d$Vuserid_%10%13dataclassPropertiesYauthTokenXpersonIDXusernameWaddTime_%10%12enabledDataclassesTguidXuserInfo_%10%11osUserDisappeared%11%01%f5%d1%0d%0e_%10!com.apple.Dataclass.DeviceLocator%d4%0f%10%11%12%13%14%15%16VapsEnvXhostname]authMechanismVschemeZProduction_%10%13p60-fmip.icloud.comUtokenUhttps_%10%ccIAAAAAAABLwIAAAAAFqjGWIRDmdzLmljbG91ZC5hdXRovQCF9bDznW7cXA_sfxZqG-bc8cUxC72ufELH5lREVOSr4Chvl6kqV7Gj3Ol8rZMM6ZPt7hIUoSRzfZsyGxnHPkT0cZNrREtkHtRVcBxuFR21XkZFV_HJAiP2F2YaawGCiGRXN6EJJ7oiIJS0kLAJ51T4qVO56A~~Y108381215_%10%12XXX@XXX.COM#A%d6%a8%c6[%81%b7%1c%a1%0d_%10$F83936A2-36F9-49D4-97C0-7B9412AE5E3A%d3%1e%1f !"#_%10%15InUseOwnerDisplayName_%10%13InUseOwnerFirstName_%10%12InUseOwnerLastName_%10%17YYY ZZZ^YYYXZZZ%09%00%08%00%1d%00$%00:%00D%00M%00V%00^%00s%00x%00%81%00%95%00%98%00%9b%00%bf%00%c8%00%cf%00%d8%00%e6%00%ed%00%f8%01%0e%01%14%01%1a%01%e9%01%f3%02%08%02%11%02%13%02:%02A%02Y%02o%02%84%02%9e%02%ad%02%b6%00%00%00%00%00%00%02%01%00%00%00%00%00%00%00%25%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%b7
bluetoothInternalControllerInfo    %15%82%ac%05%00%10%11%fa%10@%f3%e7%f1%01
BootCampHD    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%7f%ff%04%00
prev-lang:kbd    fr:1111
SystemAudioVolumeDB    %d5
fmm-computer-name    Maricopa
bluetoothActiveControllerInfo    %15%82%ac%05%00%00%00%10%11%fa%10@%f3%e7%f1%01
efi-boot-device-data    %01%03%18%00%0b%00%00%00%00%10%98%ff%00%00%00%00%ff%ff%c8%ff%00%00%00%00%04%06%14%00%eb%85%05+%b8%d8%a9I%8b%8c%e2%1b%01%ae%f2%b7%7f%ff%04%00
backlight-level    E%00
EFIBluetoothDelay    %b8%0b
LocationServicesEnabled    %01
```

Et parce que je suis sympa :O

```
< efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>F8366DCB-0C7D-429B-B8F9-58C2170A2014</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00
---
> efi-boot-device    <array><dict><key>MemoryType</key><integer size="64">0xb</integer><key>StartingAddress</key><integer size="64">0xff981000</integer><key>IOEFIDevicePathType</key><string>HardwareMemoryMapped</string><key>EndingAddress</key><integer size="64">0xffc8ffff</integer></dict><dict><key>IOEFIDevicePathType</key><string>MediaFirmwareVolumeFilePath</string><key>Guid</key><string>2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7</string></dict><dict><key>IOEFIBootOption</key><string>HD</string></dict></array>
13c13
< efi-boot-device-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00%b0ce%14%00%00%00%00%cbm6%f8}%0c%9bB%b8%f9X%c2%17%0a %14%02%02%7f%ff%04%00
---
> efi-boot-device-data    %01%03%18%00%0b%00%00%00%00%10%98%ff%00%00%00%00%ff%ff%c8%ff%00%00%00%00%04%06%14%00%eb%85%05+%b8%d8%a9I%8b%8c%e2%1b%01%ae%f2%b7%7f%ff%04%00
```

Note que j'ai changé le nom de la partition Windows depuis Windows pour qu'elle change de nom sous Mac OS, de Untitled à Windows.


----------



## macomaniac (22 Mars 2018)

Comme tu t'en es aperçu --> il y a bien un changement d'adresse inscrit en *NVRAM* après sélection du volume *Windows* dans la panneau du *StartupDisk* (et verrouillage de la préférence). Ce changement d'adresse affecte finalement la variable *efi-boot-device* (appareil de démarrage automatique pour l'*EFI*).

L'adresse initiale est "classique" dans sa forme --> une clé *UUID* à laquelle est associé en valeur de chaîne l'*UUID* = *F8366DCB-0C7D-429B-B8F9-58C2170A2014* de la partition-cible > suivie d'une clé "dernier intitulé BSD valide" à laquelle est associé en valeur de chaîne l'index de device *disk0s2* de la partition-cible.


je dis "classique" > en passant sur une complexité de détails dans la syntaxe (par rapport à un fichier *plist* de préférence) que je ne me suis jamais soucié de scruter à ce niveau de précision. Car on retrouve ici la problématique "classique" de l'école cartésienne : comment combiner le critère de clarté et celui de distinction dans les idées > sachant que la clarté est la saisie cohérente d'un ensemble et que la distinction est la précision au niveau des détails de ce même ensemble ? - parce que, dès qu'on s'enfonce intellectuellement dans les détails d'un ensemble > on perd de ce fait même la saisie cohérente du tout. Cette cohabitation problématique de l'intuition (globale) et de l'analyse (locale) se retrouve partout : stratégie vs tactique dans les opérations militaires > esprit de finesse vs esprit de géométrie dans les mathématiques etc.

L'adresse ultérieure est "non-classique" dans sa forme > avec une série de déterminations initiales qui ne me sont absolument pas famlières > mais le final davantage intelligible que voici --> un clé intitulée *Guid* à laquelle est associé en valeur de chaîne l'*UUID* = *2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7* qui doit correspondre à une partition  > suivie d'une clé *IOEFIBootOption* (option de boot de l'*EFI* en entrée / sortie) à laquelle est associé en valeur de chaîne l'index = *HD* (décevant dans sa brièveté mais qui doit avoir partie liée avec l'émulation d'un *BIOS* absolument nécessaire au boot de Windows-7 via la table de partition alernative *MBR* du bloc *0* du disque.


alors de 2 choses l'une --> soit cet *UUID* correspond directement à la partition Windows (*disk0s4* ?) du disque > soit cet *UUID* correspond médiatement à l'*ESP* (*E*FI_*S*ystem_*P*artition) *disk0s1* dans le volume *EFI* de laquelle résideraient des exécutables auxiliaires d'un boot de l'*EFI* en mode *BIOS_émulé* (le format du volume *EFI* étant *FAT-32*)

Passe la commande informative -->

```
diskutil list
```


et poste le tableau retourné des partitions du disque --> que je voie quel est l'index de device de la partition *Windows* (logiquement *disk0s4* mais il arrive qu'il y ait des complications de partitionnement). Avec ce renseignement > on pourra s'enquérir des *UUID* des 2 partitions *EFI* & *Windows*.


----------



## flotow (22 Mars 2018)

```
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *256.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            175.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data WINDOWS                 80.0 GB    disk0s4
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Données                 249.7 GB   disk1s2
```


----------



## macomaniac (22 Mars 2018)

Donc le volume *WINDOWS* est bien sur la partition *disk0s4* > mais les choses se compliquent sans doute à cause de la présence d'un *2è disque interne* = *disk2* (je pense que je tiens peut-être une piste ici).

Pour rester sur l'exploration engagée --> passe les commandes :

```
diskutil info disk0s1
diskutil info disk0s4
```


qui vont retourner les tableaux d'informations sur les 2 partitions avec les *UUID*

=> poste ces 2 tableaux.

----------


Et tant qu'on y est --> passe les commandes :

```
diskutil mount disk0s1
ls -R /Volumes/EFI
```


la 1ère monte le volume *EFI* du disque *0*

la 2è liste récursivement son contenu

=> poste encore le tableau retourné.

----------

Et puisqu'une fois lancé > il devient difficile de s'arrêter --> passe les commandes :

```
diskutil umount force disk0s1
sudo gpt show /dev/disk1
```


la 1ère démonte le volume *EFI* resté monté sur la partition *disk0s1*

la 2è retourne le tableau des blocs du disque *2*

=> poste enfin ce dernier tableau.


----------



## flotow (26 Mars 2018)

```
pc-83:~ z$ diskutil info disk0s1
   Device Identifier:        disk0s1
   Device Node:              /dev/disk0s1
   Whole:                    No
   Part of Whole:            disk0
   Device / Media Name:      EFI System Partition

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Partition Type:           EFI
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified
   Volume UUID:              0E239BC6-F960-3107-89CF-1C97F78BB46B
   Disk / Partition UUID:    B4686985-2AE3-4AE7-8A91-7B3CAC54EBAE

   Total Size:               209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)

   Device Location:          Internal
   Removable Media:          No

   Solid State:              Yes
```


```
pc-83:~ z$ diskutil info disk0s4
   Device Identifier:        disk0s4
   Device Node:              /dev/disk0s4
   Whole:                    No
   Part of Whole:            disk0
   Device / Media Name:      BOOTCAMP

   Volume Name:              WINDOWS

   Mounted:                  Yes
   Mount Point:              /Volumes/WINDOWS

   File System Personality:  NTFS
   Type (Bundle):            ntfs
   Name (User Visible):      Windows NT File System (NTFS)

   Partition Type:           Microsoft Basic Data
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified
   Volume UUID:              EA38118A-0B22-4DCC-8382-7427CF22ECCF
   Disk / Partition UUID:    AE61FF8B-7D85-42F7-B506-4B2A5B88B971

   Total Size:               80.0 GB (79999008768 Bytes) (exactly 156248064 512-Byte-Units)
   Volume Free Space:        39.1 GB (39088037888 Bytes) (exactly 76343824 512-Byte-Units)
   Device Block Size:        512 Bytes
   Allocation Block Size:    4096 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Yes

   Device Location:          Internal
   Removable Media:          No

   Solid State:              Yes
```


```
pc-83:~ z$ ls -R /Volumes/EFI
EFI

/Volumes/EFI/EFI:
APPLE

/Volumes/EFI/EFI/APPLE:
EXTENSIONS

/Volumes/EFI/EFI/APPLE/EXTENSIONS:
Firmware.scap
```


```
maricopa-1:~ z$ sudo gpt show /dev/disk1
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6        
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  487725344      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  488134984     262151        
  488397135         32         Sec GPT table
  488397167          1         Sec GPT header
```


----------



## macomaniac (28 Mars 2018)

Je ne vois pas grand chose d'éclairant.

- je note un paradoxe --> la tableau d'information sur la partition *EFI disk0s1* du SDD déclare qu'il n'y a pas de système de fichiers dans cette partition (il y a régulièrement un *FAT-32*). Si c'était le cas > aucun volume ne pourrait être défini > ni montable sur cette partition. Or un volume *EFI* est bien défini sur cette partition d'après *diskutil list* > et la commande *diskutil mount disk0s1* monte très bien un volume *EFI* sur cette partition > dont une commande *ls* retourne le contenu.


je ne sais pas quoi penser de cette contradiction

----------

- le tableau de la distribution des blocs du HDD *disk1* --> montre qu'il y a une *PMBR* (*P*rotective_*MBR*) sur le bloc *0*. C'est une table *MBR* bidon > comportant un seul descripteur de type *Ex00* > càd. assimilant la totalité des blocs du disque à une pseudo partition *GPT EFI*. Absolument inservable pour un boot de type *BIOS* sur ce disque. D'où le terme "*Protective*". Alors qu'il y a une *HMBR* (*H*ybrid_*MBR*) sur le bloc *0* du SSD > décrivant au plus *3* partitions du disque empruntées à la *GPT* > et permettant un boot *Legacy* de type "*BIOS_émulé*".


je me demande si la présence d'une *PMBR* sur le 2è disque (HDD) ne serait pas de nature à "inhiber" l'émulation d'un *BIOS* par l'*EFI* via l'écran du *boot_manager* (simple conjecture). Il faudrait tester ceci --> ouvrir le Mac > enlever le HDD > vérifier si le volume Windows choisi à l'écran du *boot_manager* boote dans ces conditions du seul SSD présent.


----------



## flotow (28 Mars 2018)

macomaniac a dit:


> Je ne vois pas grand chose d'éclairant.





macomaniac a dit:


> je ne sais pas quoi penser de cette contradiction



C'est embêtant !
_'"au fond moi, je suis terriblement déçu" _



macomaniac a dit:


> je me demande si la présence d'une *PMBR* sur le 2è disque (HDD) ne serait pas de nature à "inhiber" l'émulation d'un *BIOS* par l'*EFI* via l'écran du *boot_manager* (simple conjecture). Il faudrait tester ceci --> ouvrir le Mac > enlever le HDD > vérifier si le volume Windows choisi à l'écran du *boot_manager* boote dans ces conditions du seul SSD présent.



Alors, enlever le second SDD, c'est pas quelque chose que je peux faire maintenant, ni faire faire.
Par contre, ca doit être possible de le formater de nouveau. La PMBR ne devrait plus exister ?!


----------



## macomaniac (28 Mars 2018)

On pourrait créer une *HMBR* également sur le bloc *0* du HDD > afin de vérifier si la capacité pour l'*EFI* d'émuler un *BIOS* se trouve par là "désinhibée" (si je puis dire). Ce qui ne mange pas de pain.

Pour cela > il faut que tu installes l'exécutable *gdisk* de _Roderick Smith_. Tu peux télécharger ici : ☞*GPT Fdisk*☜ (bouton : *Download*) le paquet *gdisk-1.0.3.pkg* --> double-clic dessus et un exécutable *gdisk* se trouve installé at: */usr/local/ bin/gdisk* > et devient appelable directement dans une commande du Terminal.

Tu vérifies d'abord par un : 
	
	



```
diskutil list
```
 que le HDD est toujours indexé *disk1* (sinon tu changes le n° dans la commande qui suit). Puis tu appelles *gdisk* à ouvrir le disque par la commande :

```
sudo gdisk /dev/disk1
```

ce qui t'affiche le tableau des tables de partition du disque et l'invite de commande interactive de *gdisk* -->

```
Command (? for help):
```

tu tapes :

```
r
```
 (comme *r*ecovery mode) et tu valides --> ce qui te donne l'invite de commande -->

```
Recovery/transformation command (? for help):
```

tu tapes :

```
h
```
 (comme *h*ybrid) et tu valides --> ce qui te donne -->

```
WARNING! Hybrid MBRs are flaky and dangerous! If you decide not to use one,
just hit the Enter key at the below prompt and your MBR partition table will
be untouched.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence:
```

tu tapes :

```
2
```
 (pour la partition disk1s*2*) et tu valides --> ce qui te donne :

```
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
```

tu tapes :

```
y
```
 (*y*es) et tu valides --> ce qui te donne :

```
Creating entry for GPT partition #2 (MBR partition #2)
Enter an MBR hex code (default AF):
```
tu tapes :

```
AF
```
 (pour *AF*00 = *hex code* d'un type de partition *Apple_HFS*) et tu valides --> ce qui te donne :

```
Set the bootable flag? (Y/N):
```

tu tapes :

```
N
```
 (comme *N*o) et tu valides --> ce qui te donne :

```
Unused partition space(s) found. Use one to protect more partitions? (Y/N):
```

tu tapes :

```
N
```
 (comme *N*o) et tu valides --> ce qui te donne :

```
Recovery/transformation command (? for help):
```

tu tapes :

```
w
```
 (comme *w*rite) et tu valides --> ce qui te donne :

```
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N):
```

tu tapes :

```
y
```
 (*y*es) et tu valides --> ce qui te donne :

```
OK; writing new GUID partition table (GPT) to /dev/disk1.
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.
```


avec récupération de l'invite de commande classique du Terminal > signe que *gdisk* a quitté.

Tu peux fermer le Terminal > re-démarrer une fois > et signaler que l'opération a été accomplie. Je fais une pause dans le descriptif des opérations. Le plus dur est fait.


----------



## flotow (28 Mars 2018)

macomaniac a dit:


> On pourrait créer une *HMBR* également sur le bloc *0* du HDD > afin de vérifier si la capacité pour l'*EFI* d'émuler un *BIOS* se trouve par là "désinhibée" (si je puis dire). Ce qui ne mange pas de pain.
> 
> 
> ```
> ...



Ca ne modifie que la première partition de disk1 ?
Le message "THIS WILL OVERWRITE EXISTING PARTITION*S*" n'est pas très clair.

Cela dit, ca devrait être possible de perdre le contenu du disk1, j'ai une copie ailleurs.


----------



## macomaniac (28 Mars 2018)

Dans ce cas-ci --> ça ne peut pas avoir d'impact > parce que le programme n'écrit pas à la table *GPT* principale (qui décrit les partitions du disque) > mais à la table altertive *MBR* du bloc *0* pour la convertir du type *PMBR* de départ au type *HMBR*.


----------



## flotow (4 Mai 2018)

Salut Maco, l'opération s'est bien déroulée. Je suis prêt pour la suite !

Voici ce que me donne diskutil list après avoir redémarré :

```
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Données                 249.7 GB   disk0s2
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *256.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Macintosh HD            175.2 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:       Microsoft Basic Data WINDOWS                 80.0 GB    disk1s4
```


----------



## macomaniac (4 Mai 2018)

Alors passe les commandes (informatives) :

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


qui affichent les tableaux de la distribution des blocs des 2 disques internes

Poste ces 2 tableaux.


----------



## flotow (4 Mai 2018)

```
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  487725344      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  488134984     262151        
  488397135         32         Sec GPT table
  488397167          1         Sec GPT header


gpt show: /dev/disk1: 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  342188976      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  342598616    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  343868152       1288        
  343869440  156248064      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  500117504        655        
  500118159         32         Sec GPT table
  500118191          1         Sec GPT header
```


----------



## macomaniac (4 Mai 2018)

La mention :

```
0          1         MBR
```


en tête de chaque tableau --> montre qu'il y a bien un table *HMBR* (une *MBR* décrivant vraiment des partitions) sur le bloc *0* de chacun des 2 disques.

=> est-ce que ça change quoi que ce soit à tes problèmes de démarrage de Windows ?


----------



## flotow (4 Mai 2018)

macomaniac a dit:


> La mention :
> 
> ```
> 0          1         MBR
> ...



Malheureusement, j'ai toujours le même problèmes...
Démarrage depuis les préférences systèmes, pas de soucis.
Démarrage avec Alt -> 'no bootable device'


----------

