# Restaurer DD Interne en une partition



## Iletaitunefois (14 Février 2017)

Bonsoir tout le monde,

Heureusement qu'il y a des forums comme ça pour les gens qui n'y comprennent pas grand chose au final.

Je vous explique mon projet je veux mettre Windows 10 sur mon MacBook Pro (13 pouces, fin 2011),
et je rencontre un problème lors de la phase d'introduction de l'assistant bootcamp il me dit :

Le disque de démarrage ne peut être ni partitionné, ni restauré en une seule partition
Le disque de démarrage doit être formaté en un seul volume Mac OS étendu (journalisé) ou avoir déjà été partitionné par Assistant Boot Camp pour l’installation de Windows."
Je ne sais pas comment faire je lis des messages de partout sur les forums je sais qu'il y a pleins de sujet similaires mais aucunes solutions ne semble adaptée à mon problème, je compte sur vous pour me guider dans la réparation de mon disque dur interne et à la bonne installation du Windows 10, à savoir que j'avais déjà installé Windows 7 par le passé et que j'avais fini par formater la partition allouée à Windows 7 (BootCamp), mais apparement je m'y suis mal pris on dirais.

J'ai pris l'initiative de lancer un "diskutil list"


```
MacBook-Pro-de-Alexezer:~ Alex$ diskutil list
/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_HFS Alexezer                199.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                  Apple_HFS Stock                   299.9 GB   disk0s4
```


Merci de votre aide.




*Note de la modération*: pas trop de rapport avec les portables Mac, je déplace dans le forum adéquat.


----------



## Locke (15 Février 2017)

C'est simple, Boot Camp ne lancera pas la préparation d'une partition temporaire si le disque dur interne est partitionné, ce qui est le cas chez toi. Partant de constat, soit tu mets tes données dans un autre disque dur USB, puis tu effaces cette partition et Boot Camp pourra préparer la partition temporaire.

Soit, en fonction de ce que tu souhaites faire avec Windows, de passer par une machine virtuelle en utilisant Parallels Desktop, VMware _(logiciels payants)_ ou VirtualBox _(gratuit)_. Ce dernier est moins convivial que les 2 logiciels payants.

Ce n'est pas la peine de tenter une installation sur un disque externe USB, ça ne fonctionnera pas non plus. 

Si *jeanjd63* ou *macomaniac* passent dans les parages, nul doute qu'ils te viendront en aide pour retirer les 2 partitions Apple_HFS Alexezer et Apple_HFS Stock si c'est ton souhait, en sachant quand même que tu peux passer par Utilitaire de disque en prenant les précautions de ne pas te tromper.


----------



## macomaniac (15 Février 2017)

Salut *iletaitunefois* dans l'Ouest

Si tu veux installer Windows en te servant de l'«Assistant Boot Camp» > alors tu dois supprimer au préalable l'actuelle partition de queue du disque :

```
4:                    Apple_HFS Stock                   299.9 GB   disk0s4
```
 parce que ce logiciel requiert un disque sur lequel n'existent a priori que les 3 premières partitions constituant le « groupe du Système » :

```
/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_HFS Alexezer                199.2 GB   disk0s2
   3:                Apple_Boot Recovery HD             650.0 MB   disk0s3
```

Càd. :

*- a)* la partition *EFI* n°1 créée automatiquement avec une table de partition *GUID* pour pouvoir receler des fichiers exécutables au démarrage par le Programme Interne du Mac (l'« *EFI* » : *E*xtensible_*F*irmware_*I*nterface) --> d'où l'autre nom de cette partition d'en-tête : *ESP* = *E*FI_*S*ystem_*P*artition) ;

*- b)* la partition *Alexezer* n°2 qui est la partition de l'OS (OS X ou macOS selon la version installée) dont tu as personnalisé l'intitulé ;

*- c)* la partition *Recovery HD* n°3 qui est la partition de secours située régulièrement juste en-dessous de la partition de l'OS.​
Cette tri-partition qui forme un ensemble logique (le « groupe du Système ») est considérée par l'«Assistant BootCamp» comme la condition logique stricte de départ. Aucune partition ne doit se situer en-dessous de la *Recovery HD* n°3. C'est l'«Assistant BootCamp» qui se réserve la faculté de repartitionner la partition de l'OS n°2 pour exporter un volume dédié à «Windows» en position n°4 > dans le format d'accueil requis en préalable à l'installation..

Comme tu as vraisemblablement (vu son intitulé et sa taille) des données personnelles résidentes du volume *Stock* de la partition n°4 > je te conseille de les sauvegarder sur un DDE > puis d'effacer la partition n°4 en récupérant son espace à la partition n°2 de l'OS qui devrait revenir à une taille de *499 Go*.

Si tu n'y arrives pas avec l'«Utilitaire de Disque» > il te suffira de demander ici des commandes à passer dans le «Terminal» --> c'est ultra-facile > à la condition qu'il n'y ait plus de données à préserver dans la partition *Stock* n°4.

Je peux même te donner par avance la paire de commandes (à passer l'une après l'autre) capables d'effectuer cette opération :

```
diskutil eraseVolume free NULL disk0s4
diskutil resizeVolume disk0s2 0b
```
 mais elles ne doivent être passées que si (et seulement si) tu as opéré au préalable la sauvegarde des données contenues dans le volume *Stock*.

=> cela fait > le dispositif du disque ramené à 3 partitions > la partition *Alexezer* remontée à *499 Go* de taille > tu pourras lancer l'«Assistant BootCamp» > en espérant que ce logiciel assez "susceptible" t'installe «Windows» sans rechigner....


----------



## Iletaitunefois (15 Février 2017)

Ah merci, je pensais que je ne pouvais pas re-fusionner mon dd interne vu le message que me disais l'Assistant BootCamp, voilà j'ai réussi à supprimer la partition de trop et augmenter la taille de ma partition dédiée à MacOS, je l'ai fais à l'aide de l'*utilitaire de disque *je précise que j'avais au préalable vidé la partition *STOCK* sur un *DD Externe*


```
MacBook-Pro-de-Alexezer:~ Alex$ diskutil list
/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_HFS Alexezer                499.2 GB   disk0s2
   3:                 Apple_Boot                         650.0 MB   disk0s5
```

Cependant je remarque du changement au niveau de la partition n°3, on dirais qu'elle a changé de *TYPE NAME* elle ne s'appelle plus *Apple_Boot Recovery HD *mais *Apple_Boot* et au niveau de l'*IDENTIFIER* elle est passée en *disk0s5 *au lieu de *disk0s3
*
Alors j'ai 2-3 questions


Ce détail a t'il de l'importance ?
Faut t'il repartir sur un MacOS ou DD INTERNE fraichement reformaté pour jouer sur le bon fonctionnement du futur dual boot ?
Je suis du genre minutieux


----------



## macomaniac (16 Février 2017)

Salut *iletaitunefois -*

Technique​
Je te conseille de *re-démarrer* ton Mac > puis, ta session ré-ouverte, de revérifier l'état des partitions par un :

```
diskutil list
```

=> le re-démarrage, en effet, va permettre la re-numérotation suivie des partitions et - s'il n'y a pas eu d'anicroche - la ré-identification d'un volume *Recovery HD* correspondant à la partition de queue re-numérotée *disk0s3*.

--------------------​
Théorie​
*Pourquoi re-démarrer* ? - c'est que la distribution logique du disque est enregistrée « *en-kernel* » (le noyau opérateur du Système) > et lorsqu'on opère des manipulations qui modifient l'existence de partitions du disque > il arrive qu'il n'y ait pas une mise-à-jour définitive des paramètres logiques « *en-kernel* ».

La distribution restituée à titre d'instantané par la commande *diskutil list* est remarquable pour un point de détail : si la suppression de la partition de queue originaire n°4 = *Stock* a bien été enregistrée « *en-kernel* » > et si la partition de secours apparaît bien toujours en position n°3 comme au départ (juste en-dessous de celle de l'OS) > tu as bien noté que cette partition avait momentanément perdu son indicateur de nom de volume = « *Recovery HD* ». Mais il y a un point de détail beaucoup plus intéressant, qui constitue une preuve expérimentale : c'est que cette partition de secours en 3è position n'a plus le n° de device *disk0s3* qu'elle avait au départ > mais le n° de device *disk0s5* = *s*lice (tranche) *5* du disque *0* (ou premier disque).

La bonne question est : comment se fait-il que mon disque, qui n'avait au départ que *4* « slices » (tranches logiques ou partitions) enregistrées > se trouve à l'arrivée avec *3* tranches don la *3è* est numérotée comme un *5è* device, alors qu'il n'y a jamais eu *5* tranches logiques ?

Ce *s5* du *disk0s5* est la preuve expérimentale, enregistrée momentanément « *en-kernel* », de la façon dont l'utilitaire *diskutil* (que tu as appelé en mode graphique via l'«Utilitaire de Disque» - lequel a... passé en coulisses les commandes que je t'avais proposées en direct, car l'«Utilitaire de Disque» est une interface graphique d'exécution du binaire *diskutil*) s'y est pris pour opérer le repartitionnement.

Il a donc dans un 1er temps passé la commande :

```
diskutil eraseVolume free NULL disk0s4
```
 effaçant le système de fichiers de l'en-tête de la partition n°*4* = *Stock* > et par là désenregistrant cet espace du disque comme partition de la table de partition *GUID* d'en-tête du disque > pour convertir cet espace à du « *free_space* » : alignement de blocs ayant le statut d'espace libre hors partitionnement.

Tu aperçois à présent le problème logique : comment est-il possible de recoller cet espace libre qui existait *en-dessous* de la *Recovery HD disk0s3* à la partition *du-dessus* *Alexezer disk0s2* > étant donné qu'une partition = *Recovery HD disk0s3* *s'intercale* entre l'espace libre de queue et la partition bénéficiaire *disk0s2* ? Il est impossible de faire _sauter_ des blocs "_par-dessus_" la tête de la partition intercalaire *Recovery HD* (on n'est pas chez des jongleurs de balle à la Foire du Trône, ici) > et il n'est pas possible de faire _glisser_ la *Recovery HD* existante comme sur un tapis roulant vers le bas du disque non plus, car la définition de cette partition consiste en un *système de fichiers* *ancré* sur les blocs de têtre de la partition et constituant un amarrage logique de type fixe.

Puisque tu m'as dit que tu es « minutieux » > j'ai pensé que ces minuties théoriques t'intéresseraient > car en matière de théorie > c'est toujours à partir de *points de détail* minuscules que s'exerce la faculté spéculative.

Eh bien ! théoriquement parlant > il n'y a qu'une solution au problème > c'est que le programme *diskutil* commence par créer un *repartitionnement* de la partition de queue *disk0s4 Stock* > pour générer une partition n°*5* de type *Apple_Boot* > dans le volume de laquelle se trouve *cloné* le contenu du volume de la *Recovery HD disk0s3* ayant valeur de paradigme (le dossier de démarrage du *Recovey OS* : *com.apple.recovery.boot*). Cette création de partition *disk0s5* suivie d'un clonage opérée > la partition paradigme *disk0s3 Recovery HD* a été *supprimée* > et cet obstacle logique intercalaire ôté > la bande de blocs libres s'est trouvée désormais "toucher" littéralement par son départ la limite basse de la partition bénéficiaire *disk0s2 Alexezer*. Il a suffi alors d'opérer un *étirement* du système de fichiers *JHFS+* de cette partition > pour qu'il s'étende à tout l'espace libre disponible en-dessous > jusqu'à la limite constituée par le clone de la partition de secours créé en queue du disque.

Ce qui explique « théoriquement » pourquoi tu te retrouves avec *3* partitions dont la *3è* est numérotée comme une *disk0s5* (une *5è* tranche logique) > c'est cette partition de secours clonée sur les blocs de queue qui a gardé momentanément, « *en-kernel* », son idendification de partition n°*5* qu'elle avait à sa *création par clonage*. Et si elle n'a pas "encore" son identification de nom de volume : « *Recovery HD* » > c'est pour la même raison : le *kernel* n'a pas "encore" enregistré en mode _live_ l'identité de volume de ce clone de la *Recovery HD disk0s3* paradigme qui a été supprimée.

=> dans de pareils cas > un *re-démarrage* > rebootant le Système de l'OS > permet de faire prendre en charge par un *kernel* relancé de neuf l'état logique « actuel » du disque du Mac...

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


----------



## Iletaitunefois (16 Février 2017)

Merci macomaniac ou macovirtuose .

J'ai aimé la petite explication qui m'a donné l'image du fonctionnement interne de ces bêtes de technologie (avec l'image de l'intercalaire) et de la procédure pour arriver à rendre au disque Alexezer son volume malgrès l'obstacle entre les deux.

Résultat final,


```
#:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Alexezer                499.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
```

Comme prédit... Je vais lancer l'installation de Windows j'espère ne pas avoir de problème pour la suite..


----------



## macomaniac (16 Février 2017)

Ta table de partition est nickel.

J'ai trouvé que le tableau retourné par ton *diskutil list* du message #4 était si exemplaire > que j'en ai profité pour faire un petit _laïus_.


----------



## Iletaitunefois (16 Février 2017)

_Et c'est pas fini..._
​
La création de la partition BOOTCAMP effectuée.
http://imageshack.com/a/img923/5706/nnWykP.png​

L'image .iso du fameux software Windows 10 en main et gravée sur un CD, les fichiers de prise en charge de Windows 10 téléchargés et mis sur clé USB, on se lance dans l'installation avec un redémarrage.

http://imageshack.com/a/img924/1632/fDJ1Ay.jpg​(Désolé pour la qualité d'image, je ne sais pas prendre des screenshot, hors Mac OS... j'ai fais avec les moyens du bord)


Et puis arrive le moment fatidique lors du choix de partition où il me dit qu'il veut que la partition BOOTCAMP soit en NTFS. (Windows OS Allergique au format MS_DOS ?) .
Pourquoi l'assistant Boot Camp ne prévoit pas le coup... (De la formater en NTFS) lors de la création de partition, Mac OS pas connaître format NTFS ? Car NTFS est licence de Microsoft ?
http://imageshack.com/a/img923/6158/WRkp6D.jpg
http://imageshack.com/a/img923/6877/aQECmF.jpg​Je n'ai évidemment pas franchis le pas au vu de mes antécédents, j'ai déjà fais l'erreur sur l'iMac tout neuf d'un ami *de supprimer et de formater la partition BOOTCAMP à ce moment précis *sans pour autant pouvoir poursuivre l'installation (si mes souvenirs sont bons). L'espace perdu de cet iMac ne semble pas récupérable... L'assistant Boot Camp lance le même message que celui pour lequel je suis venu ouvrir le sujet, j'avais trifouiller dans l'utilitaire de disque pour essayer de le re-fusionner avec Mac OS (sans succès) m'enfin c'est une autre histoire on y viendra peut être bientôt quand j'en aurais fini avec le MacBook Pro je m'occuperais de cet iMac.

Que faire ?
​
Formater la partition en NTFS par l'outil Windows ? (Sans pour autant appuyer sur le bouton supprimer au préalable comme j'avais fais avec l'iMac)
Je peux formater en NTFS sous Mac OS http://imageshack.com/a/img922/7215/iet1H2.png
_Les minuties théoriques m'intéressent..._

​



_
​_


----------



## macomaniac (17 Février 2017)

Ah ! «Windows» sur Mac : un feuilleton aussi fertile en épisodes scabreux que l'_Odyssée_ d'_Ulysse... -



_

Tu n'as qu'à passer les 3 commandes :

```
diskutil list
diskutil info disk0s4
sudo gpt show /dev/disk0
```
 (en ce qui concerne la 3è commande > après validation > une demande de password va s'afficher à cause de sudo en tête de commande --> tape ton mot-de-passe de session admin à l'aveugle - aucun caractère ne se montrant à la frappe - et valide de nouveau)


la 1ère commande va donc ré-afficher la distribution des partitions du disque ;
la 2è > les paramètres logiques de la partition créée par l'«Assistant BootCamp» ;
la 3è > le dispositif du secteur d'amorçage et la distribution des blocs du disque.

=> avant toute considération « spéculative » > c'est pour que l'état des lieux soit exactement connu.


----------



## Iletaitunefois (17 Février 2017)

​

```
/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_HFS Alexezer                298.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:       Microsoft Basic Data BOOTCAMP                201.0 GB   disk0s4
/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            Win10.AIO.v1607.Fr.x64 *4.7 GB     disk1
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *62.0 GB    disk2
   1:             Windows_FAT_32 USB DISK                62.0 GB    disk2s1
/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            Boot Camp              +1.4 GB     disk3
```





```
MacBook-Pro-de-Alexezer:~ Alex$ diskutil info disk0s4
   Device Identifier:        disk0s4
   Device Node:              /dev/disk0s4
   Whole:                    No
   Part of Whole:            disk0
   Device / Media Name:      BOOTCAMP

   Volume Name:              BOOTCAMP

   Mounted:                  Yes
   Mount Point:              /Volumes/BOOTCAMP

   File System Personality:  MS-DOS FAT32
   Type (Bundle):            msdos
   Name (User Visible):      MS-DOS (FAT32)

   Partition Type:           Microsoft Basic Data
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified
   Volume UUID:              5885CAD4-A083-399C-8142-3A2C9D7D7635
   Disk / Partition UUID:    2AFE6E14-396C-4F26-A85C-F3F7E5ED37D1

   Total Size:               201.0 GB (200999436288 Bytes) (exactly 392577024 512-Byte-Units)
   Volume Free Space:        200.9 GB (200947597312 Bytes) (exactly 392475776 512-Byte-Units)
   Device Block Size:        512 Bytes
   Allocation Block Size:    32768 Bytes

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

   Device Location:          Internal
   Removable Media:          No

   Solid State:              No
```



```
Password:
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  582515840      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  582925480    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  584195016       1080        
  584196096  392577024      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773120         15        
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
```


----------



## macomaniac (17 Février 2017)

La partition *BOOTCAMP* créée en *disk0s4* par l'«Assistant BootCamp» pour une installation de «Windows-10» existe actuellement sous le signe du paradoxe :

*- a)* elle a bien le  format *FAT-32* de système de fichiers régulièrement attendu en format d'accueil.  Car c'est classiquement à l'installateur de «Windows» d'opérer par lui-même le reformatage en *NTFS* > pas d'arguer qu'il faudrait du *NTFS* en accueil ;

*- b)* mais elle existe en tant que partition non seulement pour la table *GPT* (*G*UID *P*artition *T*able) inscrite sur les blocs *1* à *32* du secteur d'amorçage du disque > mais aussi pour une table de partition alternative *Hybrid_MBR* inscrite sur le seul bloc *0* du secteur d'amorçage.​
... et c'est reparti (pour un laïus).

----------

[LAÏUS]
Les disques des Macs définis par une *GPT* ne portent pas une seule table de partition > mais toujours deux :

- la *GPT* des blocs *1* > *32* qui décrit l'espace du disque en définissant les partitions de manière numérale (du bloc n° tant au bloc n° tant) > et logique (en enregistrant le type de système de fichiers gestionnaire de l'espace de chaque partition) selon un schéma spécifique. Un *bloc* (ou cluster) est un regroupement de 512 octets (ou bytes = 8 bits chacun) constituant l'unité logique minimale en terme de fichier inscriptible --> une table de partition > étant orientée systèmes de fichiers gestionnaires de partition > et par là fichiers terminaux > décrit donc le disque en mode blocs.

- une *MBR* (*M*aster *B*oot *R*ecord) parallèle sur le seul bloc *0*. Cette *MBR*, ou table de partition conforme à un schéma «Windows», peut exister sur le bloc *0* sous 2 formes :

- la forme *P*rotective_*MBR* (*PMBR*) par défaut > qui décrit le disque entier comme mono-espace sans système de fichiers d'aucun type --> càd. ne définit en mode *MBR* aucune des partitions particulières décrites par la *GPT*. En gros : ce type de *MBR* est absolument inutilisable pour un accès disque de type *BIOS* > d'où son sobriquet de "*Protective*".

- la forme *H*ybrid_*MBR* (*HMBR*) qui décrit le disque entier en empruntant à la *GPT* la définition d'au plus 3 partitions > lesquelles auront dans le schéma *MBR* exactement la même localisation au bloc près et le même type de format reconnu. C'est donc une *MBR hybridée* d'après la *GPT* concurrente pour ce qui est de la définition des partitions. Étant une table décrivant des partitions valides selon le schéma *MBR* > elle est donc utilisable pour un accès disque de type *BIOS*.​
D'où vient cette conversion de la *P*rotective_*MBR* inscrite par défaut sur le bloc *0* au type *H*ybrid_*MBR* ? C'est une création absolument originale des ingénieurs de la  > qui ont créé ce schéma hybridé > et implémenté un mécanisme logique tel que, dès qu'une partition au moins se trouve créée sur un disque *GPT* du Mac avec un format "de type Windows" (quel que soit sa formule : *MS-DOS* = *FAT-32* ou *exFAT* ou *NTFS* - peu importe) > alors automatiquement la *PMBR* par défaut du bloc *0* se trouve convertie à un type *HMBR* faisant écho (echoing) dans le schéma *MBR* à 3 au plus des partitions existantes en mode *GPT*.

Pourquoi avoir eu l'idée (assez monstrueuse) de ce mécanisme logique générant un *HMBR* sur le bloc *0* à la moindre création d'une partition dans un format «Windows» ? - la réponse est : pour permettre le démarrage éventuel d'un OS «Windows» de type *Legacy* (héritage) installé sur une partition n°4 du disque. Car ? - car de telles versions *Legacy* de «Windows» (dont l'archétype est «Windows-7») bootent par l'intermédiaire d'un *BIOS* et absolument pas d'un Programme Interne de type *EFI*, comme l'est celui des Macs Intel. Mais > dès qu'une table de partition de type *H*ybrid_*MBR* est détectée sur le secteur d'amorçage du disque du Mac > le Programme Interne *EFI* du Mac est capable de susciter un *BIOS_émulé* > capable d'amorcer le disque par la table de partition *HMBR* > et par le biais de ses descripteurs > d'accéder à la partition-Système «Windows» à booter via l'exécution de son *boot_loader Legacy*.

Mais ce dispositif logique exceptionnel est strictement incompatible avec la version «Windows-10» > car cet OS ne boote plus en mode *Legacy* (via un *BIOS*) > mais en mode *UEFI* (par une variante de l'*EFI*). Le problème étant que > la génération automatique d'une *H*ybrid_*MBR* sur le bloc *0* dès la création d'une partition d'accueil pour «Windows» au format *FAT-32* (mécanisme logique hérité du passé) > est incompatible avec  l'installation et le boot de «Windows-10» > lesquels exigent l'utilisation d'une table de partition *GPT* exclusive (seule compatible avec le mode *UEFI*) > ce que compromet la présence concurrente d'une *H*ybrid_*MBR* suscitant un boot de type *Legacy* via un *BIOS_émulé*.

Dès lors qu'il est question d'installer «Windows-10» sur Mac requérant un boot *UEFI* > alors la condition requise est l'existence d'une simple *P*rotective_*MBR* sur le bloc *0* > et pas d'une *H*ybrid_*MBR* perturbatrice du boot *UEFI* > *HMBR* pourtant générée d'office sur le bloc *0* par le format "de type Windows" de la partition dédiée à l'installation de «Windows».

Cette contradiction est normalement résolue par l'«Assistant BootCamp» lui-même - lequel a été implémenté d'une fonction de reconversion de la *MBR* du bloc *0* du type *H*ybrid_*MBR* généré par le format *FAT-32* de la partition d'accueil > au type *P*rotective_*MBR* par défaut compatible avec le boot *UEFI* de «Windows-10».
[/LAÏUS]

----------

Eh bien ! - l'«Assistant BootCamp» n'a pas fait son travail chez toi > car la mention :

```
gpt show: /dev/disk0: Suspicious MBR at sector 0
```
 n'a qu'une acception : la *MBR* actuellement inscrite sur le bloc *0* est une *H*ybrid_*MBR* (« *suspicious_MBR* ») compatible avec le boot de «Windows-7» mais incompatible avec le boot de «Windows-10».

La bonne question devient : pourquoi l'«Assistant BootCamp» n'a-t-il pas opéré la reconversion programmée pour «Windows-10» ?

Allez ! - un pas de plus dans la spéculation --> je note d'après cette capture que tu as eu le choix de démarrage sur le programme d'installation de «Windows» :




​je conjecture qu'il s'agit de 2 modes de démarrage du même Programme d'installation > l'icône «Windows» ayant des chances de signifier : "en mode *BIOS_émulé*" et l'icône *EFI boot* de signifier : "en mode *EFI*". Tu sembles avoir choisi le mode "*BIOS_émulé*" > cela expliquerait-il l'existence résiduelle de la *H*ybrid_*MBR* requise par ce mode de boot *Legacy* ? Faut-il en tirer comme implication que la requête de format préalable *NTFS* de l'installateur (contre toute attente) provient de ce « faux départ » de démarrage (il lirait le disque via la *HMBR*) ?

[Arrivé à ce point du raisonnement > je suis excessivement engoncé par le fait suivant : je n'ai jamais eu de PC > jamais utilisé de PC > jamais utilisé «Windows» > jamais installé «Windows» sur mes Macs > n'ayant jamais ressenti le manque quelconque de cet OS et par suite jamais souhaité l'installer --> je manque donc totalement de base expérimentale et je suis le plus mauvais conseiller possible > n'ayant aucune autre ressource à ma disposition que la pure « imagination intellectuelle ».]

----------

Il y aurait plusieurs options envisageables en pratique :

*- a)* supprimer la partition actuelle *disk0s4* sans réallouer son espace à la partition *macOS disk0s2* (= laisser en *free_space*) > cette suppression du format *FAT-32* > re-convertirait automatiquement la *HMBR* actuelle du bloc *0* > au type *PMBR* neutre => une bande d'espace libre étant choisissable par le programme d'installation de «Windows» en tant qu'« *espace non-alloué* » > il faudrait la lui désigner comme destination, l'installateur ne pouvant lire le disque que via la *GPT*. À lui de se débrouiller avec.

*- b)* grâce à l'utilitaire de tierce partie *gdisk* (à utiliser en ligne de commande) > reconvertir de force la *HMBR* actuelle du bloc *0* > au type *PMBR* malgré le format *FAT-32* de la partition *disk0s4* > et voir si l'installateur se satisfait de ce dispositif : choix de la partition *BOOTCAMP* lue via la *GPT*.

*- c)* installer «Windows-7» en mode *Legacy* (utilisation de la *H*ybrid_*MBR* pour lire le disque) > puis procéder ensuite "en interne" à une mise à jour à «Windows-10»> et voir si ça continue de booter (ce qui impliquerait que la *HMBR* du bloc *0* ait été reconvertie à une *PMBR* neutre).​
=> les options *a)* ou *b)* sont combinables avec le choix du boot sur le disque d'installation : *Windows* ou *EFI boot* (ce qui trouble la tactique).

=> je me demande pourquoi tu n'utilises pas un *ISO* de «Windows-10», résidant sur ton Bureau de session, comme c'est préconisé avec l'«Assistant BootCamp» ?


----------



## Locke (17 Février 2017)

macomaniac a dit:


> => je me demande pourquoi tu n'utilises pas un *ISO* de «Windows-10», résidant sur ton Bureau de session, comme c'est préconisé avec l'«Assistant BootCamp» ?


Avec son modèle de 2011 je ne pense pas que ça marche, perso je n'ai jamais réussi avec mon iMac de 2011 et je ne sais plus depuis quelle année une version de Boot Camp le permet. Il peut toujours essayer, on ne sait jamais ?


----------



## macomaniac (17 Février 2017)

Locke a dit:


> Avec son modèle de 2011 je ne pense pas que ça marche


... c'est ce que je subodorais. 

Mais il me semble avoir lu que certains auraient réussi en commençant par installer «W-7» à l'ancienne > puis en effectuant une MÀJ à W-10 _à partir de Windows_.


----------



## Locke (17 Février 2017)

Oui, j'avais testé cette possibilité qui fonctionne bien, donc on commence par installer Windows 7, puis on fait la MAJ vers Windows 10, mais pas depuis le fichier .iso, mais depuis Windows Update.

Il y avait la possibilité de le faire, mais la MAJ gratuite de Windows pour le public a pris fin le 29 juillet 2016. 

Il peut tenter sa chance ici... https://www.microsoft.com/fr-fr/accessibility/windows10upgrade ...mais c'est sans garantie.


----------



## Iletaitunefois (17 Février 2017)

> => je me demande pourquoi tu n'utilises pas un *ISO* de «Windows-10», résidant sur ton Bureau de session, comme c'est préconisé avec l'«Assistant BootCamp» ?



Je suis un peu perdu là... J'ai tout simplement graver l'iso de Windows 10 sur un CD ... Je ne comprend pas cette question.

Je crois que je vais tester la solution a)


> *- a)* supprimer la partition actuelle *disk0s4* sans réallouer son espace à la partition *macOS disk0s2* (= laisser en *free_space*) > cette suppression du format *FAT-32* > re-convertirait automatiquement la *HMBR*actuelle du bloc *0* > au type *PMBR* neutre => une bande d'espace libre étant choisissable par le programme d'installation de «Windows» en tant qu'« *espace non-alloué* » > il faudrait la lui désigner comme destination, l'installateur ne pouvant lire le disque que via la *GPT*. À lui de se débrouiller avec.


----------



## Locke (17 Février 2017)

Iletaitunefois a dit:


> Je suis un peu perdu là... J'ai tout simplement graver l'iso de Windows 10 sur un CD ... Je ne comprend pas cette question.


En clair, ton modèle avec le SuperDrive intégré ne permet l'installation de Windows que depuis un DVD, chose que tu as bien faite. Mais l'option d'utiliser le fichier .iso n'est pas possible avec ton modèle de 2011.

Te souviens-tu si lors du lancement de Boot Camp si ce dernier proposait l'utilisation d'un fichier .iso ? Pour moi, non.


----------



## Iletaitunefois (17 Février 2017)

Il y avait deux cases celle qui permet de telecharger tout les pilotes de prise en charge de windows sur un disque externe, et celle qui partitionne le disque.

Je suis entrain d'installer Windows 7 pour tester par Win Update comme dit précedemment, j'aurais préférer une clean install sans passer par Windows 7 mais à ce que j'ai compris ce n'est pas possible en l'etat actuel de ma partition.

Windows 7 aussi m'a dit qu'il voulais que la partition soit formatée en NTFS et je l'ai formatée l'instal est presque finie. _Je précise que j'installe Windows 7 avec le CD_


----------



## Locke (17 Février 2017)

Iletaitunefois a dit:


> Windows 7 aussi m'a dit qu'il voulais que la partition soit formatée en 1) NTFS et je l'ai formatée l'instal est presque finie. 2) _Je précise que j'installe Windows 7 avec le CD_


1) C'est normal, de plus il faut obligatoirement formater en NTFS depuis l'installeur de Windows sinon l'installation ne continuera pas
2) Non, c'est un DVD

Sur le lien que je cite en réponse #14, c'est vraiment sans garantie et normalement réservé pour le non public. Mais comme a priori Microsoft ne fait pas de contrôle, ça devrait passer.

Si tu peux faire cette MAJ, il faut savoir que ta version de Windows 7 ne sera pas effacée, mais mise dans un dossier bien spécifique. En cas de problème ou si Windows 10 ne convient pas, on peut donc revenir sous Windows 7 sans aucune difficulté.


----------



## Iletaitunefois (18 Février 2017)




----------



## Iletaitunefois (18 Février 2017)

Magique d'avoir Windows 10 Gratuit, merci à Microsoft pour ce Windows version faux handicapés... https://www.microsoft.com/fr-fr/accessibility/windows10upgrade 

Procédure​
Installation de Windows 7 avec formatage NTFS du disk0s4
Téléchargement logiciel du lien ci-dessus
Lancement logiciel Windows qui va télécharger Windows 10, (nécessite clé activation Windows 7 tout de même)
Patience...


----------



## macomaniac (18 Février 2017)

*Iletaitunefois*

... je vois que tout roule pour toi-

Par curiosité --> dans ta session *macOS* > peux-tu repasser la commande (simplement informative - n'agit qu'en lecture seule et ne va rien perturber) :

```
sudo gpt show /dev/disk0
```
 et poster le tableau retourné ? - c'est histoire de vérifier si la « *suspicious MBR at sector 0* » (= *H*ybrid_*MBR*) a bien disparu du secteur d'amorçage > pour être remplacée par une *PMBR* (*P*rotective_*MBR*) - comme la « théorie » le pronosti-que...


----------



## Locke (18 Février 2017)

Iletaitunefois a dit:


> Magique d'avoir Windows 10 Gratuit, merci à Microsoft pour ce Windows version faux handicapés...





Locke a dit:


> Si tu peux faire cette MAJ, il faut savoir que ta version de Windows 7 ne sera pas effacée, mais mise dans un dossier bien spécifique. En cas de problème ou si Windows 10 ne convient pas, on peut donc revenir sous Windows 7 sans aucune difficulté.


Ne pas oublier que cette MAJ créer un dossier de Windows 7, cherche bien dans les options _(je ne me souviens plus où)_, mais il est possible d'effacer ce dossier correctement si Windows 10 convient.


*Edit :* Attention, l'effacement ne doit pas se faire n'importe comment. Donc, je maintiens il y a bien une option propre que je viens de retrouver en lecture ici... http://forums.cnetfrance.fr/topic/1...-windows-old-pour-liberer-de-l-espace-disque/ ...


----------



## Iletaitunefois (21 Février 2017)

macomaniac a dit:


> *Iletaitunefois*
> 
> ... je vois que tout roule pour toi-
> 
> ...



Salut ami,


```
MacBook-Pro-de-Alexezer:~ Alex$ sudo gpt show /dev/disk0
Password:
gpt show: /dev/disk0: Suspicious MBR at sector 0
gpt show: error: bogus map
gpt show: unable to open device '/dev/disk0': Undefined error: 0
```


----------



## macomaniac (21 Février 2017)

Salut *Iletaitunefois
*
Est-ce que tout fonctionne bien sur ton disque ? --> possibilité de démarrer alternativement sur *macOS* et sur *Windows* ?


----------



## Iletaitunefois (22 Février 2017)

Salut macomaniac

Oui tout fonctionne bien.


----------



## macomaniac (23 Février 2017)

Alors garde ce _statu quo_. Mais je te conseillerais de faire des sauvegardes régulières du volume de *macOS* (clone ou TM).

Car l'utiltaire *gpt* (*g*uid_*p*artition_*t*able_utility) repère une « *suspicious MBR at sector 0* » = *Hybrid_MBR* sur le bloc *0*. Avec le commentaire : « *bogus map* » = fausse table de partition (ou : table de partition bidonnée).

C'est que ton «Windows» devrait normalement être booté par l'*EFI* via la description *GPT* du disque > mais comme tu as fait une mise à niveau de Windows-7 à Windows-10 à partir de Windows --> la table de partition *Hybrid_MBR* qui servait à booter W-7 par un *BIOS_émulé* est restée apparemment en place. Sans être reconvertie à une *Protective_MBR* neutre et non-opératoire.

Résultat : il y a des chances que ton Windows-10 boote en mode "*Legagy*" = "hérité" (via un *BIOS_émulé* et la table *Hybrid_MBR*). Il ne serait pas impossible alors que cet OS Windows-10 comporte des limitations opératoires suite à ce boot "à l'ancienne".

Je note par ailleurs que l'utilitaire *gpt* est incapable d'ouvrir en lecture la table de partition *GPT*  principale (résidant sur les blocs *1* > *32*) pour en lire les caractéristiques et afficher la distribution des blocs en partitions. Comme si la « *bogus map* » du bloc *0* en bloquait l'accès.

_Roderick Smith_, le développeur du gestionnaire de démarrage «rEFInd» et de l'utilitaire *gdisk* - un spécialiste des tables de partition - prévient que les tables *Hybrid_MBR* sont « flaky and dangerous » ("tirées par les cheveux" et potentiellement dangereuses). C'est pourquoi je te conseille de faire des sauvegardes régulières du volume de *macOS* - au cas où la table principale *GPT* viendrait à être corrompue par sa concurrente.


----------



## Iletaitunefois (4 Mars 2017)

Salut *macomaniac*

je ferais ce que tu me dis de sauvegarder ma partition mac (par* time machine ?*) .

Aujourd'hui je reviens pour ce dont j'avais parler, l'ordinateur de mon ami sur lequel je veux aussi installer Windows 10 *un iMac plus récent que mon macbook pro*. 
*
iMac (Retina 4K, 21.5 pouces, fin 2015)*

J'avais il y a 2 mois essayer d'*installer Windows 10* en utilisant un cd-rom gravé avec l'iso de Windows 10 (sans succès) mais contrairement à mon macbook pro j*e n'arrive pas via l'utilitaire de disque à supprimer la partition bootcamp*, et il y a un peu le désordre dans le *terminal*


```
iMac-de-Arnaud:~ Leiko$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            748.4 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s9
   4:                        EFI NO NAME                 104.9 MB   disk0s6
   5:                  Apple_HFS SANS TITRE              16.8 MB    disk0s7
   6:                  Apple_HFS WIN                     250.3 GB   disk0s8
/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +748.0 GB   disk1
                                 Logical Volume on disk0s2
                                 40DA4E22-8C6F-4AB2-ADA0-B293D959F6F1
                                 Unencrypted
```


----------



## macomaniac (4 Mars 2017)

Salut *Iletaitunefois
*
Supprimer les partitions n°*4*, *5*, *6* > puis récupérer l'espace libéré au *Volume Logique Macintosh HD* > ne présente pas de difficulté dans le «Terminal».

Mais je note que les identifiants de *device* des partitions ont une numérotation décousue (genre partition *Recovery HD* n°*3* = *disk0s9*) > signe qu'il y a eu beaucoup de manipulations de partitions qui ont donné lieu a des enregistrements fantaisistes dans le *kernel*. Et je ne sais pas si ces n° de devices sont encore d'actualité, au cas où il y aurait eu d'autres manipulations entre temps ou des re-démarrages...

Je recommande donc de *re-démarrer* une fois l'_iMac_ > ce qui va conduire à un chargement ordonné des partitions actuelles dans le *kernel* > de repasser alors un :

```
diskutil list
```
 et de reposter le tableau retourné comme tu l'as fait ci-dessus. Je te passerai alors les commandes permettant de nettoyer le bas du disque en étant sûr des n° de devices à adresser.


----------



## Iletaitunefois (4 Mars 2017)

Oui c'est vrai je me souviens que tu as évoqué le fonctionnement du kernel dans un post



> Tu aperçois à présent le problème logique : comment est-il possible de recoller cet espace libre qui existait *en-dessous* de la *Recovery HD disk0s3* à la partition *du-dessus* *Alexezer disk0s2* > étant donné qu'une partition = *Recovery HD disk0s3* *s'intercale* entre l'espace libre de queue et la partition bénéficiaire *disk0s2* ? Il est impossible de faire _sauter_ des blocs "_par-dessus_" la tête de la partition intercalaire *Recovery HD* (on n'est pas chez des jongleurs de balle à la Foire du Trône, ici) > et il n'est pas possible de faire _glisser_ la *Recovery HD* existante comme sur un tapis roulant vers le bas du disque non plus, car la définition de cette partition consiste en un *système de fichiers* *ancré* sur les blocs de têtre de la partition et constituant un amarrage logique de type fixe.



Il est vrai que j'ai traficoté les partitions juste avant mon post et biensur sans rédémarrer, il y avais une ou deux partition en plus des "sans titre" je l'ai est viré, tout rentre dans l'ordre pour l'instant.


```
Last login: Sat Mar  4 18:41:58 on console
iMac-de-Arnaud:~ Leiko$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            748.4 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                        EFI NO NAME                 104.9 MB   disk0s4
   5:                  Apple_HFS SANS TITRE              16.8 MB    disk0s5
   6:                  Apple_HFS WIN                     250.3 GB   disk0s6
/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +748.0 GB   disk1
                                 Logical Volume on disk0s2
                                 40DA4E22-8C6F-4AB2-ADA0-B293D959F6F1
                                 Unencrypted
```


----------



## macomaniac (4 Mars 2017)

Alors -->

*- a)* pour supprimer les partitions *4*, *5*, *6* --> tu passes les commandes (l'une après l'autre - en copier-coller direct chacune) :

```
diskutil eraseVolume free NULL disk0s4
diskutil eraseVolume free NULL disk0s5
diskutil eraseVolume free NULL disk0s6
```
=> ce qui va virer leur blocs au statut d'espace libre d'un seul tenant.


*- b)* pour récupérer cet espace libre global à la partition *disk0s2* --> tu passes la commande unique (copier-coller) :

```
diskutil coreStorage resizeStack 40DA4E22-8C6F-4AB2-ADA0-B293D959F6F1 0b
```
=> cette commande est rendue particulière par la présence d'un format *CoreStorage* sur la partition *disk0s2* > lequel exporte un *Volume Logique Macintosh HD disk1*. La cible de la commande de récupération de l'espace libre est alors l'*UUID* du *Logical Volume* > et la mention finale *0b* signifie : "_récupérer tout l'espace libre disponible sans en excepter aucun byte_".

=> Une vérification d'intégrité du système de fichiers *JHFS+* porté par le *Volume Logique* va être engagée en préalable à la commande *b)* : s'il n'y a pas d'erreur > la commande va être exécutée ; s'il y a des erreurs > la commande va être avortée --> signale-le ici dans ce cas.


----------

