# Windows ne démarre plus (Boot Camp)



## The Lynx (27 Novembre 2016)

Bien le bonsoir à tous, je vous explique mon soucis:

Depuis que j'ai interverti mes disques internes (le HDD à l'emplacement d'origine et le SSD dans l'optibay) windows ne se lance plus... 
Quand je fais alt au démarrage je me retrouve bien avec les disques OSX et Bootcamp, mais lorsque je lance Windows j'ai un écran noir avec le petit tiret blanc en haut à gauche qui clignote sans cesse.

Windows 10 et OSX sont tous deux installés sur le SSD (2 partitions différentes) et OSX fonctionne à merveille. D'ailleurs je peux accéder à tous les fichiers présents sur la partition Boot Camp. Donc à priori les connexions se font bien! 
Je précise qu'avant, windows via Boot Camp fonctionnait parfaitement!

Est-ce possible que windows ne trouve plus l'emplacement du SSD? (ce qui serait logique haha, mais bon, osx l'a bien retrouvé tout seul comme un grand) comment faire pour réattribuer le bon chemin? J'espère que je m'avance pas trop.. mais je vois que ça..


----------



## Deleted member 1099514 (27 Novembre 2016)

Salut

Tu l'as copié comment ton windows?
C'est winclone qui permet normalement ce genre de manip.


----------



## The Lynx (27 Novembre 2016)

jeanjd63 a dit:


> Salut
> 
> Tu l'as copié comment ton windows?
> C'est winclone qui permet normalement ce genre de manip.


Salut, eh bien le windows je l'ai installé y'a plus d'un an via la procédure normale d'apple avec Boot Camp sur une partition dédiée du SSD, ça marchait très bien.. en fait j'ai juste inversé physiquement les disques dans le mac et depuis on dirait que windows n'arrive pas à trouver le bon emplacement pour booter. Mais je n'ai pas touché au contenu des disques, les OS se trouvent toujours au même endroit sur le SSD.

Depuis le bureau d'OSX je vois bien la partition Boot Camp, le volume est bien monté, j'accède aux fichiers, j'ai tenté des vérifications/réparations de disque et apparement aucune erreur, mais toujours impossible de booter windows.


----------



## Deleted member 1099514 (27 Novembre 2016)

Ok. Et quel intérêt d'inverser les disques?


----------



## The Lynx (27 Novembre 2016)

Car j'ai un stock de fichiers lourds audio/vidéo sur le HDD et il arrivait qu'il se déconnecte tout seul lors des accès lecture/écriture, mais je suis tombé sur un article préconisant de mettre les disques dans cette position et effectivement c'est stable maintenant. 
...le truc c'est que windows s'y retrouve plus du coup!


----------



## Deleted member 1099514 (27 Novembre 2016)

Tenter une réparation de windows peut être via le DVD?????


----------



## Locke (27 Novembre 2016)

Pour être sûr de ne rien perdre, je remettrais les disques dans la position ou ils fonctionnaient correctement. Si tout est correct, alors je ferais un clone avec Winclone de la partition Boot Camp qui permettra à 100% de faire un rétro clonage garanti sur n'importe quel disque interne ou USB.


----------



## macomaniac (27 Novembre 2016)

Salut *The Lynx*.

- Quelle est la version de Windows que tu as installée  : W-7 ou W-10 ?

- Par ailleurs, pour avoir une idée des paramètres logiques de tes 2 disques > peux-tu aller à : _Applications_ > _Utilitaires_ > lancer le «Terminal» > dans la fenêtre qui s'ouvre saisir la commande :

```
diskutil list
```
 et ↩︎ (presse la touche "_Entrée_" du clavier pour activer la commande) --> tu vas obtenir le tableau des disques de ton Mac > avec leurs tables de partition > et leurs partitions décrites en format > nom > taille > device (appareil logique) => poste ce tableau ici par copier-coller (sans faire de capture d'écran).


----------



## The Lynx (27 Novembre 2016)

J'ai installé windows 10, voici le tableau ci-dessous.
Par ailleurs, j'ai essayé de booter windows en machine virtuelle à partir d'osx avec le logiciel parallels et ça marche! (ça rame un peu mais tout est intact, ça me laisse le temps de trouver une solution du coup)

/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 ssd                     351.2 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:       Microsoft Basic Data BOOTCAMP                148.0 GB   disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            ssd                    +350.9 GB   disk2

                                Logical Volume on disk0s2

                                9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96

                                Unlocked Encrypted


----------



## Deleted member 1099514 (27 Novembre 2016)

Tu as réinstallé W10 et ça fonctionne maintenant?
Oups, en fait tu as ta config d'origine, mais ton SSD est passé de disk1 à disk0.

As-tu tenté de réparer en démarrant sur le DVD ou l'iso W10


----------



## The Lynx (27 Novembre 2016)

Non je n'ai pas réinstallé, tout à l'heure j'ai réussi à lancer windows via une machine virtuelle (logiciel parallels) sous osx et ça marche, tout est intact, mais ça rame.. Toujours impossible de booter direct dessus, j'ai essayé de réparer avec l'iso d'origine mais rien de plus..


----------



## The Lynx (27 Novembre 2016)

Locke a dit:


> Pour être sûr de ne rien perdre, je remettrais les disques dans la position ou ils fonctionnaient correctement. Si tout est correct, alors je ferais un clone avec Winclone de la partition Boot Camp qui permettra à 100% de faire un rétro clonage garanti sur n'importe quel disque interne ou USB.


oui au pire je tenterai ça, 'faut que je vois l'espace dispo..


----------



## Deleted member 1099514 (27 Novembre 2016)

Regarde ceci : https://bsilverstrim.blogspot.fr/2015/12/bootcamp-windows-10no-boot-device.html


----------



## macomaniac (27 Novembre 2016)

Tu peux encore fournir une autre sorte d'information, *The Lynx*.

Saisis la commande :

```
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 de nouveau ↩︎.

En retour, tu vas voir s'afficher le tableau de la distribution des blocs sur ton SSD > mais aussi (ce qui m'intéresse) une désignation du type de table de partition secondaire *MBR* inscrite sur le bloc *0* du disque.

=> peux-tu encore poster ici ce tableau ?


----------



## The Lynx (27 Novembre 2016)

oui biensur

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  686031456      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

  686441096    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

  687710632       1624         

  687712256  289060864      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

  976773120         15         

  976773135         32         Sec GPT table

  976773167          1         Sec GPT header


----------



## macomaniac (28 Novembre 2016)

Ad-mi-ra-ble ! (eurêka !)

Je vais enfin en avoir le cœur net : W-10 boote-t-il en mode « *Legacy* » ou en mode « *UEFI* » sur Mac ?

Je pars ici de l'hypothèse (qui me semble raisonnable) que «Windows-10» boote en mode « *UEFI* » --> voici alors l'argumentation démontrant pourquoi ton volume *BOOTCAMP* ne boote pas actuellement :

Sur le bloc *0* de ton SSD > tu as une « *suspicious MBR* », en d'autres termes : une *Hybrid_MBR* dont la caractéristique est de décrire en mode *MBR* les mêmes partitions (dans une limite de 3 maximum) que décrit de son côté la table *GPT* principale inscrite sur les *32* blocs suivants.

Donc ta partition *BOOTCAMP* se trouve décrite 2 fois : une fois en mode *GPT* > une fois en mode *Hybrid_MBR*. Or admis que la particularité de l'OS «Windows-10» est de booter en mode « *UEFI* » > cela veut que le Programme Interne du Mac (*EFI*) appelé à exécuter son *boot_loader* de type *.efi* doit résolument passer par la description *GPT* de cette partition et par elle seule.

Or s'il existe en alternation une table *MBR* secondaire de type *Hybrid* qui décrit la même partition *BOOTCAMP* selon les descripteurs *MBR* > alors elle prend le dessus sur (_override_) la *GPT* en ce qui concerne le boot de Windows > donc l'*EFI* accèdera au volume *BOOTCAMP* en mode *MBR* (mode « *Legacy* ») et pas en mode *GPT* (mode *UEFI*). Mais dans le volume *BOOTCAMP* (s'il s'agit bien d'un OS *UEFI*) > il n'y a pas de *boot_loader* « *Legacy* » > il y a un *boot_loader UEFI* de type *.efi*. L'*EFI* du Mac ne pourra donc pas le reconnaître et l'exécuter via son accès *MBR* > mais a besoin de l'exécuter via un accès *GPT*.

Il conviendrait alors de convertir la *HMBR* (*H*ybrid_*MBR*) du bloc *0* en une *PMBR* (*P*rotective_*MBR*) ne décrivant aucune partition mais traitant le disque comme un espace uniforme indifférencié > alors l'*EFI* serait forcée de passer par la *GPT* pour booter le *boot_loader .efi* de W-10.

--------------------​
Pour effectuer cette conversion *HMBR* > *PMBR* sur le bloc *0* du SSD > il faut utiliser l'utilitaire de tierce-partie (non fourni avec l'OS) de _Roderick Smith_ : *gdisk*.

Je te décris la procédure complète :

*- a)* si ton OS est «El Capitan 10.11» ou «Sierra 10.12» > il vaut mieux d'abord d'abord désactiver le *SIP* (*S*ystem *I*ntegrity *P*rotection) qui se met en place au démarrage de ces OS en verrouillant des pans entiers de répertoires du Système mais aussi la *NVRAM* - ce pour avoir les coudées franches _occasu_ (_solis_)...

Pour cela > tu re-démarres ton Mac > tu tiens pressées les 2 touches *⌘R* à partir de l'écran noir jusqu'à la  > tu ouvres une session (*root* par défaut) dans un Système *Recovery* > va à la barre supérieure de menus de l'écran > menu _Utilitaires_ > sous-menu «Terminal» > dans la fenêtre ouverte tu passes la commande :

```
csrutil disable
```
 > tu re-démarres normalement sur ton OS et tu réouvres ta session admin => le *SIP* est désactivé.

--------------------​
*- b)* tu télécharges depuis le site SourceForge l'installateur de ☞*GPT fdisk*☜ > tu récupères un paquet d'installation : *gdisk-1.0.1.pkg* > tu le double-cliques > et l'exécutable *gdisk* va se trouver installé at: /usr/local/bin/*gdisk* qui lui permet d'être appelé directement désormais dans le «Terminal».

--------------------​
*- c)* tu repasses par précaution la commande :

```
diskutil list
```
 pour toi > afin de bien vérifier que ton SSD est toujours identifié comme */dev/disk0* (s'il était identifié comme */dev/disk1* > tu changerais le n° de disque dans ma commande ci-après).

--------------------​
*- d)* tu passes la commande :

```
sudo gdisk /dev/disk0
```
 qui appelle *gdisk* à ouvrir les tables de partition de ton SSD et tu devrais en retour obtenir ceci :

```
GPT fdisk (gdisk) version 1.0.1

Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with hybrid MBR; using GPT.

Command (? for help):
```
 qui te confirme que tu as une *HMBR* sur le bloc *0* > la mention terminale *Command (? for help):* étant l'invite de commande interactive du programme *gdisk*.

--------------------​
*- e)* tu tapes dans la fenêtre du «Terminal» la lettre seule :

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

```
Expert command (? for help):
```
 qui est l'invite de commande interactive du mode expert.

--------------------​
*- f)* tu tapes la lettre seule :

```
n
```
 (comme *n*ew Protective_MBR at sector 0) et ↩︎ --> et tu obtiens en retour :

```
Expert command (? for help):
```
 càd. le ré-affichage de l'invite de commande (la commande précédente n'ayant opéré qu'une mise-en-cache de l'instruction de création d'une *PMBR*).

--------------------​
*- g)* tu tapes la lettre seule :

```
w
```
 (comme *w*rite) et ↩︎ --> et tu obtiens en retour :

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

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

--------------------​
*- h)* tu tapes la lettre seule :

```
y
```
 (comme *y*es) et ↩︎ --> et tu obtiens en retour :

```
OK; writing new GUID partition table (GPT) to /dev/disk5.

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 à la fin de l'invite de commande régulière du «Terminal» à ton nom d'utilisateur > montrant que le programme *gdisk* a quitté mission accomplie.

=> le _laïus_ qui s'est trouvé inscrit t'invite à re-démarrer ton Mac > sinon le *kernel* qui a monté le volume du SSD continuera de prendre en compte l'ancienne table de partition *HMBR* du bloc *0* et non la nouvelle *PMBR* qui l'a remplacée sur ce même bloc > tu *re-démarres* donc une fois.

--------------------​​=> tu n'as plus qu'à tester si le volume *BOOTCAMP* est toujours affiché à l'écran obtenu avec la touche "_alt_" > et si tu peux le démarrer.

- si *oui* : vérification faite du boot en mode *UEFI* de W-10.

- si *non* : conjecture à résilier > il te restera (toujours grâce à *gdisk* - je te dirais comment) à reconstituer une *HMBR* _ad hoc _décrivant correctement la partition *BOOTCAMP* en mode *MBR* avec apposition du *boot_flag* (indicateur de caractère démarrable) > et à vérifier si Windows boote dans ces conditions.​
[Je n'arrive pas à concevoir cette seconde hypothèse, que le papier cité par *Jean* exploite contre toute raison (en gros le gars récupère le caractère démarrable du Windows-10 du Mac de son fils en reconstruisant les conditions de boot de cet OS en mode « *Legacy* », càd. via la reconstitution _ad hoc_ d'une *H*ybrid_*MBR* sur le bloc *0* > d'après son témoignage ça marche > ça ne doit pas si bien marcher que ça s'il boote un OS *UEFI* via le mode désuet qui servait à W-7...]


----------



## Deleted member 1099514 (28 Novembre 2016)

macomaniac a dit:


> Ad-mi-ra-ble ! (eurêka !)
> 
> Je vais enfin en avoir le cœur net : W-10 boote-t-il en mode « *Legacy* » ou en mode « *UEFI* » sur Mac ?
> 
> ...


Ce qui est quand même bizarre, c'est que cette organisation fonctionnait bien semble-t-il quand le disque système était dans le rack "lecteur dvd" donc reconnu comme disk1


----------



## macomaniac (28 Novembre 2016)

Ce qui m'a fait me poser la question (_in petto_) : le changement d'emplacement de connexion du SSD (de la position SATA principale dans un caddie à la place du Super-Drive : je crois que c'est ça la situation actuelle) serait-il susceptible de convertir une *PMBR* du bloc *0* en *HMBR*  en bloquant un boot *UEFI* ? et reconversion à une *PMBR* en cas de replacement en position SATA principale ?

Ou bien dois-je basculer sur l'autre conjecture (qui offusque ma raison) : ce W-10 bootait dès le départ via une *HMBR* du bloc *0* (en mode « *Legacy* » donc) et alors le changement d'emplacement du disque affecterait la description de la partition *BOOTCAMP* en mode *MBR* de cette *H*ybrid_*M*BR conservée : parce qu'un identifiant-*device* de partition bootable se trouverait inscrit dans cette *HMBR*, qui ne correspondrait plus lorsqu'on change l'emplacement du disque à cause d'un changement de n° de device ?


----------



## The Lynx (28 Novembre 2016)

macomaniac a dit:


> Ad-mi-ra-ble ! (eurêka !)
> 
> Je vais enfin en avoir le cœur net : W-10 boote-t-il en mode « *Legacy* » ou en mode « *UEFI* » sur Mac ?
> 
> ...


J'ai effectué avec succès toutes les étapes, et le volume Boot Camp a disparu lors du démarrage avec alt.
...en attente des tes instructions, dont j'admire la clarté!


----------



## Deleted member 1099514 (28 Novembre 2016)

Et je continue à penser qu'il faut suivre ceci : https://bsilverstrim.blogspot.fr/2015/12/bootcamp-windows-10no-boot-device.html

Et surtout faire ces opérations depuis le mode Recovery.


----------



## macomaniac (28 Novembre 2016)

Petit intermède nocturne​
 *The Lynx*



The Lynx a dit:


> J'ai effectué avec succès toutes les étapes, et le volume Boot Camp a disparu lors du démarrage avec alt.



Je vois que tu as le sens de l'humour : les commandes de *gdisk* ont réussi à... faire disparaître le volume *BOOTCAMP* de l'écran de choix des volumes de démarrage (tu vas me dire : de toute façon > il ne démarrait plus quoique affiché).

Alors je suis obligé (apparemment) de réviser toutes les conjectures que j'ai exposées dans mon message précédent. Il devrait falloir une *H*ybrid_*MBR* (décrivant bien la partition *BOOTCAMP* dans son rang dans la table > son type de système de fichiers > son caractère démarrable) pour que l'*EFI* puisse démarrer Window-10 en passant par la *HMBR*. Ce qui me dérange, puisque Windows-10 est annoncé booter en mode *UEFI* et pas *Legacy*.

[Je n'ai pas pu vérifier, sur des disques où est installé un Windows-10 démarrable formellement installé par l'«Assistant BootCamp», si la *MBR* du bloc *0* était indiquée *PMBR* ou *HMBR*. Ce serait une preuve décisive. Car, si je m'en tenais à mon hypothèse de boot *UEFI*, il faudrait alors un *blessing* de l'en-tête du volume *BOOTCAMP* comme avec un volume *macOS* > pour que le *Boot_Manager* déclenché par la touche "_alt_" repère le volume comme démarrable en mode *GPT* et qu'il y ait un chemin au *boot_loader .efi* de W-10 que l'*EFI* puisse suivre - comme quoi, ma conjecture a du plomb dans l'aile, mais elle volète encore...]

Je proposerai donc demain matin (je ne suis pas du soir) un mode d'emploi de *gdisk* analogue au précédent > permettant de reconstruire une *H*ybrid_*MBR* sur le bloc *0* avec tous les paramétrages _ad hoc_ pour que la partition *BOOTCAMP* y soit décrite. On verra bien.

[Quand bien même W-10 booterait de cette façon > cela ne prouverait pas décisivement que ce soit le boot *UEFI* requis - si l'on suppose que la possibilité d'un boot *Legacy* (avec un *boot_loader MBR* à l'ancienne) y soit implémentée en parallèle. Comme quoi > un succès pourrait entraîner une erreur d'interprétation > comme un échec (celui de ta tentative avec une *PMBR*) peut ne pas avoir la valeur d'erreur radicale qu'on serait enclin à lui prêter.]

--------------------​ *Jean*

Je connais bien la procédure pour créer une *HMBR* ciblant une partition *BOOTCAMP* (le gars dans le papier que tu cites : il bat la compagne dans tous les sens à pas mal d'opérations inutiles).

Quant à opérer en mode *Recovery* (comme il fait) > ce n'est pas nécessaire, pour la raison suivante : *gdisk* opère sur les tables de partition (ici la *MBR* du bloc *0*) après que le *kernel* ait eu accès aux tables de partition de départ > opéré la probation des systèmes de fichiers > monté les volumes. Comme _Roderick Smith_ l'explique en toutes lettres > une conversion de table de partition comme la *MBR* du bloc *0* est totalement incapable de modifier en direct la prise en charge initiale par le *kernel* qui va, imperturbablement, continuer de _faire comme si_ rien n'était changé. C'est après re-démarrage seul que le *kernel* relancé prendra en charge les nouveaux paramètres logiques du disque.

J'ai opéré naguère l'expérimentation suivante : sur une clé USB montant plusieurs volumes > zapper totalement les 2 tables de partition de ce disque (la *GPT* et la *MBR*) > eh bien ! rien ne change en apparence > les volumes continuent d'être montés > preuve que le *kernel* garde en mémoire le paramétrage lu au départ > c'est seulement après démontage des volumes > détachement du disque > réattachement > que le *kernel* ne trouve plus aucune table de partition à partir de laquelle accéder à des système de fichiers de partitions.

J'en infère que *gdisk* peut opérer en direct sur une table de partition de disque dont un volume recèle le Système démarré.

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


----------



## The Lynx (28 Novembre 2016)

Oula alors je dois avouer que je comprend pas tout à fait tout, mais ça à l'air complexe haha..
je laisse le mac en l'état en attendant ce que tu me proposes demain. 
merci pour votre aide!


----------



## macomaniac (29 Novembre 2016)

Alors voici le le mode d'emploi pour reconstruire sur le bloc *0* du SSD une *H*ybrid_*MBR* (*HMBR*) décrivant la partition *BOOTCAMP* comme bootable :

*- a)* tu repasses la commande classique :

```
diskutil list
```
 afin de vérifier que le SSD est bien toujours identifié comme *disk0* (sinon, tu modifies à *disk1* la cible de la commande qui suit).

--------------------​
*- b)* tu appelles *gdisk* à ouvrir les tables de partition du SSD par la commande :

```
sudo gdisk /dev/disk0
```
 et ↩︎ + password à l'aveugle et ↩︎ encore --> tu obtiens le retour :

```
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help):
```
 (où tu notes que la *MBR* du bloc *0* est bien une *PMBR* (*P*rotective_*MBR* ne décrivant aucune partition mais traitant l'espace du disque comme un ensemble indifférencié - ce, suite à ton expérimentation précédente avec *gdisk*).

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

```
r
```
 (comme *r*ecovery_mode) et ↩︎ --> en retour tu obtiens :

```
Recovery/transformation command (? for help):
```
 qui est l'invite de commande interactive du *recovery_mode*.

--------------------​
*- d)* tu tapes :

```
h
```
 (comme *h*ybrid_MBR) et ↩︎ --> en retour tu obtiens :

```
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:
```
 (qui t'avertit qu'avoir une *Hybrid_MBR* sur le bloc *0* du disque d'un Mac : c'est comme avoir une _Épée de Damoclès_ suspendue sur la tête à un crin de cheval > et puisque tu persistes dans ta décision stoïque [qui dira jamais l'intrépidité logique de ceux qui installent Windows sur Mac ? 
	

	
	
		
		

		
			





 ] > de taper le n° de rang de la - ou des - partitions dans la table *GPT* que tu veux voir décrite(s) en écho dans la *HMBR* - une *HMBR*, à la différence d'une *PMBR*, décrivant des partitions prédéterminées de la *GPT* selon la modalité *MBR*).

--------------------​
*- e)* tu tapes :

```
4
```
 et ↩︎ puisque, tu t'en souviens, la partition *BOOTCAMP* occupe le rang n°*4* dans la table *GPT* d'après ce tableau retourné par *diskutil* :

```
/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 ssd               351.2 GB     disk0s2
3:           Apple_Boot Recovery HD       650.0 MB     disk0s3
4: Microsoft Basic Data BOOTCAMP          148.0 GB     disk0s4
```
 --> en retour tu obtiens :

```
Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N):
```
 (qui te demande si tu veux que l'*ESP* = *E*FI *S*ystem *P*artition occupant le rang n°*1* de la *GPT* soit placée en tête des partitions décrites en écho dans la *HMBR*).

--------------------​
*- f)* tu tapes :

```
y
```
 (comme *y*es) et ↩︎ --> en retour tu obtiens :

```
Creating entry for GPT partition #4 (MBR partition #2)
Enter an MBR hex code (default 07):
```
 (te proposant de créer une entrée dans la *HMBR* pour la partition *BOOTCAMP* de rang n°*4* dans la *GPT* qui va, dans la *HMBR*, occuper le rang n°*2* après l'*ESP* qui a été précédemment inscrite au rang n°*1* --> puis te demandant d'associer un code de partition à cette partition *BOOTCAMP* en te proposant le "default" =* 07*).

--------------------​
*- g)* tu tapes :

```
07
```
 (toujours suivre ici les préconisations de _Roderick_) et ↩︎ --> en retour tu obtiens :

```
Set the bootable flag? (Y/N):
```
 (te demandant si tu veux inscrire le *boot_flag* ou indicateur de caractère démarrable sur le header ou en-tête du volume *BOOTCAMP* -> bien sûr que tu veux, et même tu le dois, donc...).

--------------------​
*- h)* tu tapes :

```
y
```
 (comme *y*es) et ↩︎ --> en retour tu obtiens :

```
Unused partition space(s) found. Use one to protect more partitions? (Y/N):
```
 (te demandant si tu veux utiliser une bande d'espace libre trouvée pour décrire une partition supplémentaire).

--------------------​
*- i)* tu tapes :

```
n
```
 (comme *no* - j'attire tout spécialement ton attention sur ce point crucial et décisif, où je trouve que _Roderick_ pèche par excès de légèreté en ne faisant pas intervenir de texte d'avertissement assorti de points d'exclamations !!!! => si tu ne veux pas ficher en l'air par "effet_boomerang" la table *GPT* principale de ton disque *il ne faut absolument pas répondre Yes = y à cette demande : il faut absolument et décisivement répondre No = n* --> ne te loupe surtout pas ici par effet de la force d'inertie des réponses Yes = y précédentes. Cette invite anodine de *gdisk* est aussi explosive à manier que la commande *rm* = *r*e*m*ove dans le «Terminal») et ↩︎ --> en retour de ton *n *(= *n*o - je le réitère) tu obtiens :

```
Recovery/transformation command (? for help):
```
 (qui est le ré-affichage de l'invite de commande interactive du *r*ecovery_mode - te montrant implicitement que la mise-en-cache des instructions précédentes est terminée. La définition de la nouvelle *HMBR* est complète en mode seulement virtuel et en attente d'un acte d'écriture au disque).

--------------------​
*- j)* tu tapes :

```
w
```
 (comme *w*rite) et ↩︎ --> en retour tu obtiens :

```
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
Do you want to proceed? (Y/N):
```
 (qui te dit que *gdisk* est prêt à écrire la nouvelle table *HMBR* au bloc *0* en sur-écriture de l'actuelle *PMBR* toujours intouchée pour l'instant et te demandant si tu veux exécuter cet acte d'écriture).

--------------------​
*- k)* tu tapes :

```
y
```
 (comme *y*es) et ↩︎ --> en retour tu obtiens :

```
OK; writing new GUID partition table (GPT) to /dev/disk0.

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.
```
 (où _Roderick _explique noir sur blanc que le *kernel* va continuer en mode résilient à se référer sans changement aux descriptions de partitions préalablement chargées aussi longtemps qu'il n'y aura pas eu re-démarrage ou détachement > ré-attachement du disque).

--------------------​
*- l)* tu récupères l'invite de commande régulière du «Terminal» à ton nom d'utilisateur - signe que *gdisk* a quitté mission accomplie --> tu fermes le «Terminal» --> tu *re-démarres impérativement ton Mac* pour que le nouveau dispositif de la *HMBR* sur le bloc *0* soit prise en compte par le Système au démarrage.

--------------------​​
=> il te reste plus qu'à vérifier si tu as récupéré un volume *BOOTCAMP* : 1° affiché à l'écran de choix du disque de démarrage obenu par la touche "_alt_" > 2° démarrable par l'*EFI*.


----------



## The Lynx (29 Novembre 2016)

macomaniac a dit:


> Alors voici le le mode d'emploi pour reconstruire sur le bloc *0* du SSD une *H*ybrid_*MBR* (*HMBR*) décrivant la partition *BOOTCAMP* comme bootable :
> 
> *- a)* tu repasses la commande classique :
> 
> ...


Ok j'ai effectué toutes les étapes, bootcamp est bien revenu à l'écran de choix mais toujours le même soucis lorsque je le sélectionne: écran noir, avec tiret qui clignote


----------



## macomaniac (29 Novembre 2016)

On a donc réussi à boucler la boucle en revenant à la case départ : affichage du volume à l'écran des volumes démarrables > mais volume non démarrable. Avec une *HMBR* sur le bloc *0* (ce que tu avais d'entrée de jeu).

Est-ce que tu peux passer la commande (après l'actif > retour à l'informatif) :

```
sudo gdisk /dev/disk1
```
 et poster le tableau retourné ? C'est pour vérifier ce qu'il en est de la *MBR* du bloc *0* de l'autre disque (le HDD).

[pour quitter *gdisk* : tu tapes *q* et ↩︎]


----------



## The Lynx (29 Novembre 2016)

yes

GPT fdisk (gdisk) version 1.0.1


Warning: Devices opened with shared lock will not have their

partition table automatically reloaded!

Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present


Found valid GPT with protective MBR; using GPT.


Command (? for help):


----------



## macomaniac (29 Novembre 2016)

Bon : ton HDD (comme attendu, vu l'absence de partition dans un format Windows) a une *MBR* tout ce qu'il y a de neutre sur le bloc *0* : une *PMBR* qui ne peut pas introduire un facteur de perturbation.

Il faudrait (pour étoffer les données expérimentales) que tu te livres à des interventions mécaniques (ce qui ne va sans doute pas trop te plaire) :

*- a)* si tu enlèves le HDD (actuellement en position naturelle) > sans changer de place le SSD (en position super-drive) = 1 seul disque -->

=> est-ce que tu arrives à démarrer ton Windows ou toujours pas ? Si tu y arrives > que renvoie une commande :

```
sudo gdisk /dev/disk0
```
 - histoire de vérifier l'hypothèse tordue d'une répercussion de l'ablation du HDD sur la *MBR* du SSD ?

--------------------​
*- b)* si tu intervertis les 2 disques (SSD > emplacement naturel du disque et HDD > en position super-drive) = 2 disques croisés -->

=> est-ce que tu récupères le démarrage sur Windows ? Si tu y arrives, que renvoie une commande :

```
sudo gdisk /dev/disk0
```
 (ou *disk1* : il s'agit du SSD --> vérifie par un *diskutil list* quel est son identifiant en position primitive) - histoire de vérifier l'hypothèse tordue _bis_ d'une répercussion de l'emplacement du disque sur la *MBR* du bloc *0 *?

--------------------​
*- c)* si tu laisses le SSD en position naturelle mais enlèves le HDD de la position super-drive = 1 disque -->

=> est-ce que tu récupères le démarrage sur Windows ? Si tu y arrives > que renvoie une commande :

```
sudo gdisk /dev/disk0
```
 - histoire de vérifier l'hypothèse tordue _ter_ d'une répercussion de l'emplacement du disque + absence de l'autre disque sur la *MBR* du bloc *0* ?
--------------------​​=> si tu décidais de faire ces petites expérimentations horlogères > attention dans la manipulation des nappes.

J'aurais besoin de la confirmation que sans l'action pertubatrice de l'autre disque > ou loggé à l'emplacement disque naturel > ton Windows démarre (ou pas) - sachant que le SSD a actuellement une *H*ybrid_*MBR* décrivant cette partition en mode « *Legacy* »...


----------



## The Lynx (30 Novembre 2016)

Bon je vais tester tout ça, je te fais un retour dans la semaine!


----------



## The Lynx (9 Décembre 2016)

Finalement je vais tenter une réinstallation complète de windows avec bootcamp, non pas que j'ai la flemme de faire les manips mais je dois absolument garder les disques dans cette configuration.. Une petite question: si je n'ai pas moyen de désinstaller proprement windows, qu'est-ce que je risque à supprimer la partition bootcamp? (après avoir sauvegardé mes données sur un autre disque bien sûr)


----------



## Deleted member 1099514 (9 Décembre 2016)

The Lynx a dit:


> Finalement je vais tenter une réinstallation complète de windows avec bootcamp, non pas que j'ai la flemme de faire les manips mais je dois absolument garder les disques dans cette configuration.. Une petite question: si je n'ai pas moyen de désinstaller proprement windows, qu'est-ce que je risque à supprimer la partition bootcamp? (après avoir sauvegardé mes données sur un autre disque bien sûr)


Bootcamp doit te permettre de supprimer la partition Windows.


----------



## macomaniac (9 Décembre 2016)

*The Lynx*



The Lynx a dit:


> qu'est-ce que je risque à supprimer la partition bootcamp?



Rien, car tu es ici dans un garage où alternent deux spécialistes _ès_ nettoyage des résidus de partitions Windows > il suffit de poster le résultat d'un : *diskutil list* & d'un *diskutil cs list*






Le logiciel «Winclone» (payant) est capable de faire une image-archive *Win.winclone* (clone) du volume Windows > puis de la rétro-cloner à une partition vide au format *FAT-32* créée par l'utilisateur > je me demande s'il serait capable de restaurer via cette opération de va-et-vient le caractère démarrable d'un volume *BOOTCAMP* comme le tien...


----------



## The Lynx (9 Décembre 2016)

Oui jean, ça devrait fonctionner mais bon sait-on jamais.
Je vais tenter ce que maco dit avec winclone, juste pour voir, mais dans le futur je pense faire une nouvelle install bien clean (je dispose d'une autre version de windows 10, allégée avec le strict minimum, ça me donnera l'occasion de tester en machine virtuelle depuis OSX). J'ai découvert il'y a peu Crossover qui permet d'installer des applis win sous mac, donc ça remet en cause l'intérêt de bootcamp pour moi... ceci dit ça n'a pas l'air hyper stable avec toutes les applis.

résultats diskutil list et diskutil cs 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_CoreStorage ssd                     351.2 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:       Microsoft Basic Data BOOTCAMP                148.0 GB   disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            ssd                    +350.9 GB   disk2

                                Logical Volume on disk0s2

                                9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96

                                Unlocked Encrypted










CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group C5875627-3EE3-40AB-B3F1-9AC5FE047A30

    =========================================================

    Name:         ssd

    Status:       Online

    Size:         351248105472 B (351.2 GB)

    Free Space:   311296 B (311.3 KB)

    |

    +-< Physical Volume C1E36D08-2B3D-47E5-A258-93E3089B786B

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     351248105472 B (351.2 GB)

    |

    +-> Logical Volume Family 71F250BB-4E66-4FC6-AD8C-6602F7CF371E

        ----------------------------------------------------------

        Encryption Type:         AES-XTS

        Encryption Status:       Unlocked

        Conversion Status:       Complete

        High Level Queries:      Fully Secure

        |                        Passphrase Required

        |                        Accepts New Users

        |                        Has Visible Users

        |                        Has Volume Key

        |

        +-> Logical Volume 9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96

            ---------------------------------------------------

            Disk:                  disk2

            Status:                Online

            Size (Total):          350895472640 B (350.9 GB)

            Revertible:            Yes (unlock and decryption required)

            Revert Status:         Reboot required

            LV Name:               ssd

            Volume Name:           ssd

            Content Hint:          Apple_HFS


----------



## macomaniac (9 Décembre 2016)

Comme tu as un format *CoreStorage Chiffré* sur la partition *disk0s2* [la *Recovery HD* en *disk0s3*, ayant un statut logique solidaire, est échappée lors des repartitionnements] > je conjecture que l'«Assistant BootCamp» va planter si tu lui demandes de supprimer l'actuelle partition *BOOTCAMP* en *disk0s4*...

... pas grave : les spécialistes _ès_ nettoyage de résidus *BOOTCAMP* finiront le travail


----------



## The Lynx (9 Décembre 2016)

arf.. impossible de démarrer winclone (je suis sous Sierra), carbon copy cloner et super duper ne peuvent pas cloner de partition bootcamp, je vais voir si il y'a d'autres alternatives.

Je vais quand même essayer de virer windows avec bootcamp, pouvez-vous me confirmer que je ne risque pas d'accidenter ma partition OSX? c'est le terme "restaurer" qui me fait douter:


----------



## macomaniac (9 Décembre 2016)

Pour supprimer la partition *BOOTCAMP disk0s4* et virer ses blocs au statut d'espace libre > tu passes la commande (copier-coller) :

```
diskutil eraseVolume free NULL disk0s4
```


Pour tenter de ré-intégrer cet espace libre à la partition *ssd disk0s2*  (ce qui implique un re-dimensionnement du *CoreStorage* de cette partition) > tu passes la commande (copier-coller) :

```
diskutil coreStorage resizeStack 9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96 0b
```

--> une vérification du système de fichiers *jhfs+* ancré sur le *Volume Logique* terminal du *CoreStorage* sera lancée en préalable :

- si le résultat est : *exit code = 0* (pas d'erreur) > la commande de re-dimensionnement sera engagée ;

- si le résultat est : *exit code > 0* (erreurs) > la commande de re-dimensionnement avortera.​
=> tu n'as qu'à rendre compte du résultat en postant le retour d'affichage.


----------



## The Lynx (9 Décembre 2016)

Dac mais j'aimerai profiter de l'occasion pour réduire la partition windows à 100go pas plus, est-ce possible via une commande? (je me doute que ça doit l'être )


----------



## macomaniac (9 Décembre 2016)

Tu peux adapter la commande n°*2* que je t'ai donnée > en la transformant en ceci :

```
diskutil coreStorage resizeStack 9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96 400g fat32 BOOTCAMP 0b
```

Cette commande instruit un redimensionnement de la partition *ssd* de *351 Go* actuels à *400 Go* par récupération de *49 Go* d'espace libre dégagé par la suppression de la partition *BOOTCAMP* > et instruit la recréation d'une partition *disk0s4* de *99 Go* environ au format *FAT-32* montant un volume intitulé *BOOTCAMP* (l'option *0b* = *0*_*b*yte finale signifie : "_ne laisser aucun bloc libre inemployé pour la création de la partition de queue_").

Pour la passer > tu dois nécessairement passer d'abord la commande :

```
diskutil eraseVolume free NULL disk0s4
```
 qui vire l'actuelle partition *BOOTCAMP* au statut de *free_space* : c'est la condition _sine qua non_ de la commande de re-dimensionnement, laquelle requiert toujours l'existence d'espace libre sous la partition bénéficiaire.

[La partition *disk0s3 Recovery HD*, logiquement solidaire de la *disk0s2* (d'autant plus si un format *CoreStorage* y est présent car elle joue alors le rôle de « *booter* » du *CoreStorage*), se trouve déplacée par clonage sur les blocs pour permettre l'extension de la partition principale.]


----------



## The Lynx (9 Décembre 2016)

Merci de la précision, j'ai passé les commandes et voici le retour ci-dessous

edit: j'ai vérifié dans utilitaire de disque et effectivement la partition Boot Camp est effacée et celle d'OSX fait bien 400go. Cependant je remarque qu'il y'aurait 10,53go purgeable, comment le faire?

The Core Storage Logical Volume UUID is 9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96

Started CoreStorage operation

Checking prerequisites for resizing Logical-Physical volume stack

Growing Logical-Physical volume stack

Verifying file system

Using live mode

Performing live verification

Checking Journaled HFS Plus volume

Checking extents overflow file

Checking catalog file

Checking multi-linked files

Checking catalog hierarchy

Checking extended attributes file

Checking volume bitmap

Checking volume information

The volume ssd appears to be OK

File system check exit code is 0

Growing Core Storage Physical Volume from 351 248 105 472 to 400 352 632 832 bytes

Copying booter

Growing disk partition

Modifying partition map

Growing Core Storage data structures

Resizing Core Storage Physical Volume structures

Resized Core Storage Physical Volume to 400 352 632 832 bytes

Growing Logical Volume

Resizing Core Storage Logical Volume structures

Resized Core Storage Logical Volume to 400 000 000 000 bytes

Growing file system

Finished CoreStorage operation


----------



## macomaniac (9 Décembre 2016)

Est-ce que tu peux passer une commande :

```
diskutil list
```
 et poster le tableau que je vérifie l'état des lieux, en ce qui concerne le partitonnement ?


----------



## The Lynx (10 Décembre 2016)

voici:
/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 ssd                     399.9 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:       Microsoft Basic Data                         99.2 GB    disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            ssd                    +399.5 GB   disk2

                                Logical Volume on disk0s2

                                9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96

                                Unlocked Encrypted


J'ai essayé d'installer windows sur la partition de 99go à partir d'une clé bootable (testée auparavant sur machine virtuelle et un autre pc, tout marche), au menu d'installation windows j'ai un message qui me dit "Impossible d'installer windows sur ce disque..." lorsque je clique sur la partition 0s4, et même si je la formate en ntfs depuis l'installeur windows, j'obtiens: "windows ne peut pas être installé sur ce disque. le materiel de cet ordinateur peut ne pas prendre en charge le démarrage sur ce disque. Vérifiez que le contrôleur de ce disque est activé dans le menu du Bios de L'ordinateur"

Dans disk utility j'ai "type de disque: non initialisé" (pour la partition windows en question)

Bon je vais me calmer un peu et attendre tes instructions


----------



## The Lynx (10 Décembre 2016)

Il me semble avoir compris que le disque ssd sur lequel est installé OSX étant en gpt, la partition destinée à windows de 99go l'est aussi, mais windows installer a besoin d'une partition ntfs en mbr.. à voir si il est possible de convertir une partition gpt en mbr sans toucher à la partie OSX présente sur le disque.


----------



## macomaniac (10 Décembre 2016)

Le partitionnement s'était bien opéré.

Qu'est-ce que tu as comme Mac (modèle, année) ?

C'est bien Windows-10 que tu cherches à installer ? L'installateur de ta clé démarrable n'a rien de spécial ?


----------



## The Lynx (10 Décembre 2016)

alors mon mac c'est un macbook pro 9,2 sous Sierra (mid 2012, non retina)
J'ai tenté une install de Windows 7 cette fois-ci, c'est vrai j'aurai dû le préciser plus tôt.
J'ai lu des articles sur le sujet (windows 10 démarrant sur gpt) et c'est peut-être là que le bât blesse car windows 7 aurait besoin d'une mbr. Ceci dit je peux réessayer avec windows 10 voir si ça marche déjà, mais si je pouvais installer W7 ce serait le top!

Qu'entends-tu par "L'installateur de ta clé démarrable n'a rien de spécial ?"? à priori il à l'air classique.. ça ressemble à ça:
(ce n'est pas mon screenshot, mais j'ai le même message d'erreur)


----------



## macomaniac (10 Décembre 2016)

N'oublie pas que le secteur d'amorçage d'un disque Mac comporte toujours 2 tables de partition : *MBR* sur le bloc *0* & *GPT* sur les blocs *1* > *32*. La *MRB* du bloc *0* peut à son tour être de 2 types : *PMBR* (*P*rotective_*MRB* mono-sectorielle = ne décrivant aucune partition et ne jouant donc aucun rôle d'amorçage > rôle monopolisé par la *GPT*) vs *HMBR* (*H*ybrid_*MBR* = faisant écho à 3 partitions au plus de la *GPT* > donc jouant un rôle d'amorçage *MBR* d'une partition Windows).

Windows-7 a besoin de booter en mode « *Legacy* », càd. par l'intermédiaire d'une table *H*ybrid_*MBR* sur le bloc *0* du disque. Le problème actuel de ta partition *disk0s4* : c'est qu'elle doit être en *ntfs* alors qu'elle doit être en *fat32* au départ pour que l'installateur de W-7 la prenne en charge > et qu'elle n'est pas associée à un volume montable avec un nom de volume.

Passe la commande :

```
diskutil eraseVolume fat32 BOOTCAMP disk0s4
```
 > qui va reformater en *FAT-32* la partition *disk0s4* de *99 Go* en montant un volume intitulé *BOOTCAMP* > tout en répercutant automatiquement cette partition dans une *H*ybrid_*MBR* sur le bloc *0*.

Re-démarre sur ta clé bootable de Windows > indique la partition *BOOTCAMP disk0s4* comme destination sans la reformater en *ntfs* (laisser faire l'installateur) --> est-ce que cette destination est validée ?


----------



## The Lynx (10 Décembre 2016)

J'ai passé la commande et re-tenté l'install depuis la clé mais toujours un message d'erreur.


----------



## macomaniac (10 Décembre 2016)

Est-ce que tu peux faire une capture d'écran du panneau de l'installateur montrant les partitions choisissables et la poster ici ?


----------



## The Lynx (10 Décembre 2016)

Ok j'ai pris des photos car je vois pas comment faire des screenshots depuis l'installateur:


----------



## macomaniac (10 Décembre 2016)

Alors voici un nouveau test :

*- a)* tu passes la commande :

```
diskutil eraseVolume free NULL disk0s4
```
 qui supprime l'actuelle partition *BOOTCAMP* > en virant son espace au statut de *free_space* > mais sans réallouer cet espace à la partition OS X => ainsi une bande d'espace_libre de *99 Go* existe en queue de disque sous la *Recovery HD disk0s3*.

*- b)* tu démarres sur ton installateur Windows > tu sélectionnes comme _destination_ d'install ce qui doit apparaître comme espace non alloué *99 Go* > sans reformater cet espace en *ntfs* => est-ce que cette destination est validée ? Ou bien est-ce qu'un message t'est retourné objectant encore qu'une table *GPT* est présente alors que Windows requiert une *MBR* ?​


----------



## The Lynx (10 Décembre 2016)

Toujours le même message qui dit que "windows ne peut pas être installé sur ce disque.Le disque sélectionné est du style de partition GPT."


----------



## macomaniac (10 Décembre 2016)

Aucune partition de format Windows n'existant plus actuellement sur le disque > la *MBR* du bloc *0* a été virée nécesairement au type *PMBR* (*P*rotective_*MBR* monosectorielle) ne jouant aucun rôle d'amorçage > donc c'est la *GPT* qui monopolise le rôle d'amorçage sur le disque.

La preuve est ainsi faite que l'installateur requiert sur le bloc *0* une *HMBR* (*H*ybrid_*MBR*) décrivant la partition de destination de l'installation > de telle sorte que cette partition relève d'un mode *MBR* d'amorçage.

Je te propose en premier instance de recréer la partition *BOOTCAMP* en 2 commandes :

- d'abord par la commande :

```
diskutil coreStorage resizeStack 9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96 0b
```
 > tu récupères l'espace libre de *99 Go* à la partition *disk0s2* ;

- puis par la commande :

```
diskutil coreStorage resizeStack 9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96 400g fat32 BOOTCAMP 0b
```
 > tu rétrécis la partition *disk0s2* à *400 Go* (avec le *CoreStorage* impliqué) > et tu exportes une partition *BOOTCAMP* de *99 Go* au format *FAT-32*.​
(il vaut mieux ne pas abuser des commandes "tout en un" avec un *CoreStorage Chiffré* sur la partition principale.)

=> retour à la case départ donc. Repasse un :

```
diskutil list
```
 et poste le tableau retourné > histoire de vérifier que tout est en ordre.

En seconde instance > il faudra ré-appeler l'utilitaire *gdisk* de _Roderick Smith_ pour manipuler la *HMBR* du bloc *0* > afin que la partition *BOOTCAMP* relève de sa description...


----------



## The Lynx (10 Décembre 2016)

hop le tableau:
/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 ssd                     400.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:       Microsoft Basic Data BOOTCAMP                98.9 GB    disk0s5


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            ssd                    +400.0 GB   disk2

                                Logical Volume on disk0s2

                                9CDB51C6-D8FB-4663-AE3B-CB4E9808FD96

                                Unlocked Encrypted


----------



## macomaniac (10 Décembre 2016)

Tout est en ordre.

Reporte-toi à présent à mon message antérieur #24 car les instructions d'emploi de *gdisk* s'appliquent de _a_ jusqu'à _z_.

Tu n'as simplement pas besoin de répéter le *§ a)* (car tu viens de passer le *diskutil list*) > et évidemment il n'est pas question (tout à la fin) que tu vérifies si ton *BOOTCAMP* est bootable puisqu'il n'a pas actuellement de Système installé.

À la place (une fois toute la séquence *gdisk* opérée) > tu re-démarres sur ton installateur de Windows > tu lui indiques la partition *BOOTCAMP* comme partition de _destination_ > et tu vois si elle est validée de coup-ci...


----------



## The Lynx (10 Décembre 2016)

Après l'étape *-k) *j'obtiens un retour différent de celui que je devrais avoir:
Do you want to proceed? (Y/N): y

OK; writing new GUID partition table (GPT) to /dev/disk0.

Warning: Devices opened with shared lock will not have their

partition table automatically reloaded!

*Unable to open device '/dev/disk0' for writing! Errno is 1! Aborting write!*


Recovery/transformation command (? for help):




Je me suis arrêté là


----------



## macomaniac (11 Décembre 2016)

The Lynx a dit:


> Unable to open device '/dev/disk0' for writing! Errno is 1! Aborting write!



Gasp !

(Windows sur Mac va finir par me faire émettre des borborygmes dignes de phylactères... Pourquoi diantre, moi qui n'ai jamais utilisé Windows - et qui ne l'utiliserai jamais - me suis-je fourvoyé dans cette galère : les problèmes de l'installation de Windows sur Mac et vice-versa de la désinstallation de Windows sur Mac ? Sachant que, ce qui peut bien pousser des personnes ayant l'incomparable avantage d'avoir *macOS* sur Mac à désirer permuter à Windows sur Mac - m'échappe complètement et échappera toujours mon entendement ?)

Si tu te réfères au message #24 par lequel tu rendais compte de ton application de mon petit tuto du #23 naguère, le même disque = SSD installé à l'emplacement super-drive étant concerné, tu déclarais :


The Lynx a dit:


> Ok j'ai effectué toutes les étapes,


=> donc *gdisk* n'avait aucunement rencontré d'obstacle à éditer la *MBR* du bloc *0* du SSD, le volume *ssd* de l'OS démarré étant monté...

Alors sache que toute ta manœuvre avant validation de la commande *w* (*w*rite) > n'avait qu'un caractère virtuel et rien d'opératoire. Tu peux (et je suppose que tu l'as fait) quitter *gdisk* en saisissant :

```
q
```
 et ↩︎ > ce qui ramène l'invite de commande régulière du «Terminal» que tu peux quitter à son tour.

Je te propose d'envisager la simple conjecture suivante :

- peut-être que toutes tes manipulations de re-partitionnement antérieures n'avaient pas été adéquatement prises en charge par le *kernel*

--> alors *re-démarre* ton Mac un bon coup > et récidive toute l'opération décrite à mon message #23...​
=> encore un message d'erreur à l'écriture de la table de partition *HMBR* ou validation cette fois-ci ?


----------



## The Lynx (11 Décembre 2016)

J'ai réessayé après redémarrage de l'ordi mais toujours le même message d'erreur à l'étape K. Une question: dois-je effectuer ces opérations depuis le mode recovery ou depuis mon bureau?

(eh oui j'ai besoin de windows car plusieurs logiciels MAO ne sont disponibles que sur windows, et lorsqu'on m'envoie des projets à mixer je dois bien pouvoir les ouvrir )


----------



## macomaniac (11 Décembre 2016)

Alors tu peux essayer en démarrant en mode *Recovery* (redémarrer > tenir pressées les touches *⌘R *de l'écran noir à l'affichage de la ) > où tu trouveras un «Terminal» au menu _Utilitaires_ de la barre de menus supérieure de l'écran.

Voici pour démarrer les choses :

*- a*) tu vérifies par un :

```
diskutil list
```
 préalable que ton SSD est bien identifié comme *disk0* (sinon adapter le n° de disque dans les commandes qui suivent).

*- b)* tu démontes le volume *ssd* (automatiquement monté) par la commande :

```
diskutil umount force disk0s2
```

*- c)* tu démontes le volume *BOOTCAMP* (lui aussi automatiquement monté) par la commande :

```
diskutil umount force disk0s4
```

*- d)* tu appelles l'utilitaire *gdisk* à ouvrir les tables de partition du SSD par la commande :

```
/Volumes/ssd/usr/local/bin/gdisk /dev/disk0
```

> si tu obtiens le tableau des tables de partition et l'invite de commande interactive de *gdisk* comme d'habitude > le programme est lancé > il te reste à enchaîner les manœuvres comme décrit dans mon message #23 et à vérifier que la commande finale *w* (écrire la table de partition *HPBR*) passe sans message d'erreur.

=> cela fait > re-démarrer > tenter d'installer «Windows» à destination de la partition *BOOTCAMP*.

--------------------​
Il me vient une _arrière-pensée_ (procédé dit : « _esprit de l'escalier dominical_ » --> avoir à l'idée quand on descend l'escalier de sortie la répartie qu'on aurait dû servir au salon de l'étage) :

- et si d'anciennes tentatives d'installation de «Windows» dans un volume *BOOTCAMP* du SSD *disk0* > avaient déposé des binaires d'amorçage dans le volume de l'*ESP* (= *E*FI_*S*ystem_*P*artition : Partition Système de l'*EFI*) *disk0s1* ? - et si c'était ces binaires qui causaient le bazar lors d'une nouvelle installation, parce qu'ils n'auraient pas été supprimés ?

Avant de te lancer dans l'opération *Recovery* décrite ci-dessus > tu ferais bien depuis ta session dans l'OS de passer d'abord la commande :

```
diskutil mount disk0s1
```
 qui va te retourner un :

```
Volume EFI on disk0s1 mounted
```
 > il s'agit du volume intitulé *EFI* de la partition *ESP* que tu dois voir affiché sur ton Bureau.

Alors ne mégotons pas > passe la commande de listage récursif :

```
ls -R /Volumes/EFI
```
 qui devrait te retourner une arborescence de dossiers et de fichiers (s'il y a du monde dans ce volume *EFI*)

=> peux-tu poster ce tableau intégral ici avant de te lancer dans l'opération *Recovery* ?


----------



## The Lynx (11 Décembre 2016)

D'ac voici le tableau:
BOOTLOG    EFI


/Volumes/EFI/EFI:

APPLE


/Volumes/EFI/EFI/APPLE:

CACHES        EXTENSIONS    FIRMWARE


/Volumes/EFI/EFI/APPLE/CACHES:

CAFEBEEF


/Volumes/EFI/EFI/APPLE/CACHES/CAFEBEEF:


/Volumes/EFI/EFI/APPLE/EXTENSIONS:

Firmware.scap


/Volumes/EFI/EFI/APPLE/FIRMWARE:

MBP91_00D3_B0D_LOCKED.scap


J'attends de tes nouvelles avant de me lancer dans l'op recovery.


----------



## macomaniac (11 Décembre 2016)

Bon : pas plus de trace de binaires _microsoft_ que de beurre en broche...

Tu peux lancer l'opération *Recovery*.


----------



## The Lynx (11 Décembre 2016)

Alors le terminal me dit que le volume ssd était déjà démonté (apparemment, photo à l'appui) j'ai tout de même continué et à l'étape *- d)* de ton message #56 la commande passée ne donne rien:




J'ai exit le terminal et redémarré depuis pour te faire un retour.


----------



## Deleted member 1099514 (11 Décembre 2016)

Oups, j'ai l'impression que tu as coupé la fine branche sur laquelle tu es assis :

*diskutil umount force disk0s2*
démonte la partition CoreStorage ssd et donc :
/Volumes/ssd/usr/local/bin/gdisk n'est plus accessible.


----------



## macomaniac (11 Décembre 2016)

En fait le *CoreStorage* sur *disk0s2* est chiffré. Donc le volume ssd ne monte pas automatiquement en cas de boot externe > mais, verrouillé par le chiffrement, reste démonté. Donc *gdisk* est inaccessible. Mais si l'on monte le volume verrouillé > on se retrouve dans la situation où l'on passe la commande depuis la session de l'OS = édition de la table *MBR* du disque dont le volume-Système est monté (bref : on tourne en rond).

Je n'arrive pas à comprendre pourquoi l'écriture d'une table de partition *HMBR* par *gdisk* a marché une 1ère fois depuis le «Terminal» de la session de l'OS > et ne marche plus à présent.

Tu peux toujours, *The Lynx*, re-démarrer en mode *Recovery* et là :

*- a)* dans l'«Utilitaire de Disque» sélectionner le volume *ssd* grisé (démonté car verrouillé) > et le menu : "_Monter_" (OS antérieur à «El Capitan») ou le menu "_Fichier_" (tout en haut) > sous-menu "_Déverrouiller_" (OS «El Capitan» ou «Sierra) > renseigne ton mot-de-passe de session dans l'OS dans le panneau qui le demande > le volume *ssd* devrait être monté > donc *gdisk* accessible.

*- b)* relancer le «Terminal» et là simplement :

```
diskutil umount force disk0s4
```
 pour démonter le volume *BOOTCAMP* impliqué (mais pas le volume de l'OS) puis :

```
/Volumes/ssd/usr/local/bin/gdisk /dev/disk0
```
 pour appeler *gdisk* à ouvrir les tables de partition du SSD, son *Volume Logique ssd* toujours monté.​
=> effectuer l'opération des commandes --> vérifier si la commande *w* est honorée ou pas.


----------



## The Lynx (11 Décembre 2016)

Alors dans recovery, quand je déverrouille le ssd je ne peux plus ensuite accéder au terminal (je ne peux qu'éteindre ou redémarrer).
J'ai essayé en lançant d'abord le terminal puis en déverrouillant le ssd mais le terminal quitte et je n'ai plus moyen de le ré-ouvrir (la barre grise en haut devient vide, plus d'accès aux utilitaires, je n'ai plus que la pomme et la possibilité d'éteindre ou redémarrer l'ordinateur).


----------



## macomaniac (11 Décembre 2016)

Ce n'est absolument pas normal, le comportement que tu décris (déverrouiller le *Volume Logique* > impossibiltié de lancer le «Terminal» en mode *Recovery*).

Est-ce que tu tiens résolument à à ton chiffrement de la partition *disk0s2* ? - si ce n'était pas le cas > depuis ta session dans l'OS : _Menu_  > _Préférences Système_ > _Sécurité et confidentialité_ > _FileVault_ => choisir : "*Désactiver FileVault*". Après re-démarrage > le déchiffrement s'effectue en toile de fond sans empêcher l'utilisation de la session. On peut en suivre la progression dans le panneau _FileVault_ des _Préférences Système_. Ne pas lancer de processus lourd pour ne pas le freiner.

À complétion > après nouveau re-démarrage > il est régulier que le format *CoreStorage* qui était impliqué par le chiffrement soit déconstruit > le système de fichiers *jhfs+* se trouvant réancré sur le départ de la partition en mode standard (une commande *diskutil list* permet de le vérifier).

=> je te suggère cette opération (déchiffrement > suppression du *CoreStorage*) > dans l'idée que l'opération d'installation de Windows, manifestement problématique dans ta configuration, en serait facilitée.

PS. Au fait : quel est l'OS installé dans le volume *ssd* ?


----------



## The Lynx (11 Décembre 2016)

L'OS est Sierra (10.12.1)
Oui c'est étrange, euh le FileVault à priori si je peux le désactiver juste le temps des opérations ça poserait pas de problème?


----------



## macomaniac (11 Décembre 2016)

Est-ce volontairement que tu as activé «FileVault» - ou bien est-ce que ça s'est fait "à l'insu de ton plein gré" lors de l'installation de «Sierra» ? 

L'activation de «FileVault» n'est absolument pas requise pour le fonctionnement de «Sierra» (personnellement je ne l'active jamais sur aucune partition de mon Mac qui peut booter tous les OS de «Snow Léopard 10.6» à «Sierra 10.2-beta»).


----------



## The Lynx (11 Décembre 2016)

Eh bien je n'en ai aucune idée à vrai dire! En tout cas je ne me souviens pas l'avoir activé donc j'ai lancé le déchiffrement, et je procèderai au redémarrage dès qu'il finit (d'ici 2 heures tout au plus).


----------



## The Lynx (12 Décembre 2016)

Voici le tableau obtenu après l'op "déchiffrement > suppression du CoreStorage":

/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 ssd                     400.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:       Microsoft Basic Data BOOTCAMP                98.9 GB    disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


----------



## macomaniac (12 Décembre 2016)

*The Lynx*

La situation est apurée :

- la partition *ssd* a récupéré le dispositif logique classique = un système de fichiers *jhfs+* (noté ici : *Apple_HFS*) ancré directement sur l'en-tête de la partition *disk0s2* ;

- la partition de secours *Recovery HD* (*disk0s3*) n'est plus logiquement solidarisée de la *disk0s2* (comme c'est le cas lorsqu'il y a un *CoreStorage Chiffré* sur la partition-Système > car, alors, la *Recovery HD* joue principalement un rôle de « *booter* » du *CoreStorage* = partition de démarrage permettant le déverrouillage du *Volume Logique* et son montage > avant démarrage de son OS).​
=> tu es donc dorénavant dans la configuration la plus basique possible pour ce qui est de l'installation de «Windows».


Je te suggère, directement et sans ambages, de retenter l'opération *gdisk* depuis le «Terminal» de la session de l'OS démarré > histoire de vérifier si, abstraction faite de la configuration logique "super-sophistiquée" précédente = {*CoreStorage Chiffré* + *Recovery HD* annexée à la fonction de « *booter* » du *CoreStorage*} > *gdisk* arrive à éditer la *HMBR* du bloc *0*.

Normalement > c'est ce que cet utilitaire peut faire en mode "_live_" (le volume-Système du disque concerné laissé monté) > et c'est ce qu'il parvient à faire expérimentalement sur tous mes disques (_MacBook Pro 17" i7 Late_2011_).


----------



## The Lynx (12 Décembre 2016)

à la dernière étape, j'obtiens toujours le message "Unable to open device '/dev/disk0' for writing! Errno is 1! Aborting write!"

Mais là au moment de quitter le terminal il me dit:
"Warning! This will probably do weird things if you've converted an MBR to

GPT form and haven't yet saved the GPT! Proceed? (Y/N):"

Que dois-je répondre?


----------



## macomaniac (12 Décembre 2016)

The Lynx a dit:


> Que dois-je répondre?


Ça me paraît indifférent > puisqu'il n'y a eu aucune opération d'écriture aux tables de partition > ni la *MBR* > ni la *GPT*.

Indépendamment de ce nouvel échec de *gdisk* (j'y reviendrai > si nécessaire) => tu pourrais essayer directement une nouvelle opération d'installation de «Windows» en démarrant sur ta clé > et en choisissant la partition *BOOTCAMP* > histoire de vérifier si l'élimination du *CoreStorage Chiffré* a débloqué la situation ou si tu obtiens encore et toujours le même message d'erreur...​


----------



## The Lynx (12 Décembre 2016)

J'ai essayé une nouvelle fois l'installation de windows et toujours la même erreur (ce disque est de type gpt, windows à besoin d'un format ntfs... etc) Est-ce que j'essaye en convertissant la partition en ntfs (via l'installeur) ou je la laisse en fat?


----------



## macomaniac (12 Décembre 2016)

Alors nouvel essai avec *gdisk* =>

*- a) *tu démarres en mode *Recovery* > Terminal (le volume *ssd* est monté automatiquement ce coup-ci).

*- b)* par la commande :

```
diskutil eraseVolume hfs+ "RamDisk" `hdiutil attach -nomount ram://4096`
```
 (attention aux 2 accents graves *` *avant *hdiutil* et à la fin - pour valider la commande : une fois ↩︎ pour affirmer qu'il n'y a pas de lettre accentuable derrière affectable par le *`* mais que le *`* est bien un caractère intrinsèque > une 2è fois ↩︎ pour entrer la commande) -->

tu devrais obtenir le retour :

```
started erase on diskxx
Unmounting disk
Erasing
Initilialized /dev/diskxx as a 2 MB case-insensitive HFS Plus volume
Mounting disk
Finished erase on diskxx RamDisk
```

*- c)* par la commande :

```
ls /Volumes
```
 tu vérifies la présence d'un volume monté en *RAM* intitulé *RamDisk*.

*- d)* par la commande :

```
cp /Volumes/ssd/usr/local/bin/gdisk /Volumes/RamDisk
```
 tu copies *gdisk* dans le volume *RamDisk* en *RAM*.

*- e)* par la commande :

```
ls /Volumes/RamDisk
```
 tu vérifies que *gdisk* fait bien partie du volume *RamDisk* en *RAM*.

*- f)* par les 2 commandes successives :

```
diskutil umount force disk0s2
diskutil umount force disk0s4
```
 tu démontes les 2 volumes automatiquement montés : *ssd* et *BOOTCAMP* du SSD *disk0*.

*- g)* par la commande :

```
/Volumes/RamDisk/gdisk /dev/disk0
```
 tu appelles le *gdisk* du volume *RamDisk* en *RAM* à ouvrir les tables de partitions du SSD *disk0* => si tu obtiens le tableau des tables de partitions de *disk0* et l'invite de commande interactive de *gdisk* > tu as le pied à l'étrier pour l'opération décrite à mon message #23.​
=> s'il y a encore un échec d'écriture de *gdisk* d'une *HMBR* au bloc *0* du *disk0* (SSD) > alors qu'aucun volume de ce disque n'est monté > c'est que le blocage provient d'une autre source.


----------



## The Lynx (12 Décembre 2016)

Enfin! L'opération est un succès, j'obtiens le tableau:

OK; writing new GUID partition table (GPT) to /dev/disk0.

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.

J'ai depuis redémarré le mac, en attente de ta confirmation pour tenter une nouvelle install de windows.


----------



## The Lynx (12 Décembre 2016)

J'ai démarré le mac en appuyant sur "alt", et un nouveau volume est apparu nommé "Windows". Je n'ai pas essayé de démarrer dessus puisqu'à priori windows n'est pas encore installé.
J'ai tenté l'installation de windows (depuis ma clé), mais l'installateur me dit toujours qu'il est impossible de l'installer sur ce disque ("la partition doit être en ntfs").


----------



## macomaniac (12 Décembre 2016)

The Lynx a dit:


> Enfin! L'opération est un succès



Pfiou ! Ça fait toujours plaisir un petit succès _inutile_ de temps en temps, non ?

Tu peux toujours reformater la partition *BOOTCAMP* en *ntfs* > mais j'ai bien peur que l'installateur n'argue encore...​


----------



## The Lynx (12 Décembre 2016)

Effectivement ça n'a point changé grand chose, toujours le message d'impossibilité d'installer.


----------



## macomaniac (12 Décembre 2016)

La première fois où tu avais réussi à installer un «Windows» démarrable sur ce SDD -->

- quelle était la version de «Windows» : W-7 ou W-10 ?

- quel procédé avais-tu utilisé : l'«Assistant BootCamp» ou une clé d'install démarrable ?​
=> si tu tentes de ré-itérer cette manœuvre à l'identique > alors que la position du SSD a changé (emplacement Super-Drive au lieu d'emplacement disque naturel) --> est-ce que « les mêmes causes produisent les mêmes effets » (installation réussie) ou un effet différent (échec de l'installation) ?

=> dans le dernier cas de figure > l'emplacement actuel du disque compremettrait l'installation de «Windows». Re-placer le SSD à l'emplacement disque naturel > devrait alors recréer l'identité complète des conditions initiales > et déboucher sur une installation réussie.

Si tel était le cas > il te faudrait choisir entre : SSD à l'emplacement SuperDrive et pas de Windows vs SSD à l'emplacement naturel et Windows.

Si quelque chose te gêne dans la configuration SSD = emplacement naturel du disque & HDD = emplacement Super-Drive --> qu'est ce c'est exactement ?


----------



## The Lynx (13 Décembre 2016)

La première fois c'était Windows 10 que j'avais installé, une première fois avec une clé bootable, et voyant qu'il manquait les drivers Boot Camp je l'ai donc réinstallé via la méthode BootCamp (donc à priori les 2 méthodes marchaient avec Windows 10).

Dans le cas présent je ne peux pas utiliser l'assistant Boot Camp car il me dit qu'il ne peut installer que Windows 10, et non les versions précédentes (J'ai essayé de télécharger des versions antérieures de l'assistant Boot Camp - qui acceptait Windows 7 sur El Capitan - mais sans succès)

Je vais essayer une nouvelle fois mais avec Windows 10 cette fois-ci, je te tiendrai au courant du résultat.

La config' SSD à l'emplacement d'origine et HDD dans le superdrive avait le défaut de créer des déconnexions du HDD (sur lequel je stocke des fichiers lourds, audio/vidéo, banques de sons etc..) Il disparaissait du bureau et le seul moyen de le récupérer était de redémarrer l'ordinateur.
Je suis tombé sur un article (je vais voir si je peux remettre la main dessus) préconisant de mettre les disques dans la position actuelle, et effectivement depuis cette manip' c'est stable, plus aucune déconnexion!

Donc à choisir, je préfère me passer de Windows, ceci dit je vais réessayer avec Windows 10 via Boot Camp, ou en faire une clé bootable si ça ne marche toujours pas.


----------



## macomaniac (13 Décembre 2016)

En ce qui concerne le dispositif de tes disques, tu as le contournement suivant :

- tu remets le SSD à l'emplacement naturel du disque ;

- tu remets le HDD à l'emplacement du Super-Drive ;

- tu associes les 2 partitions principales (*disk0s2* & *disk1s2*) par le procédé *CoreStorage* Fusion Drive (il suffit de demander comment ici : c'est le garage des spécialistes du *CoreStorage*) > tes 2 disques exportent un seul volume logique pour l'utilisateur, dont la taille est la somme des 2 partitions. Comme le système s'installe toujours d'entrée sur le SSD > les opérations bénéficient de la vitesse du SSD avec la capacité de stockage du HDD ;

- l'association Fusion Drive empêche toute déconnexion d'un des 2 disques associés ;

- tu peux installer Windows (via l'«Assistant BootCamp» par exemple) > le procédé Fusion Drive est _a priori _validé et l'emplacement de la partition Windows est toujours en queue de disque de HDD (donc en-dessous de la *Recovery HD disk1s3* qui est elle aussi toujours sur le HDD --> *BOOTCAMP* = *disk1s4*).​
=> je pense que ce serait la clé de tous tes problèmes : récupérer la distribution  des disques orthodoxe (SSD = position disque naturelle > HDD = position Super-Drive) > n'avoir qu'un seul volume orienté utilisateur > éviter les déconnexions de disques > pouvoir installer Windows (le Fusion Drive étant _a priori _ logiquement validé).

=> le seul inconvénient est celui de la mise-en-place : pour créer le Fusion Drive > il faut démarrer sur un Système indépendant des 2 disques impliqués (*disk0* = SSD & *disk1* = HDD) dont les espaces sont ré-initialisés. Il faudrait donc que tu clones (avec «Carbon Copy Cloner» qui gère la *Recovery HD*) le volume *ssd* recelant ton Système dans un volume de DDE USB pour y avoir un double démarrable assurant sa sauvegarde (et permettant ensuite le clonage à rebours dans le volume vide du Fusion Drive) > et il faudrait par ailleurs que tu sauvegardes le 2è volume = celui du *HDD* (avec tes données) sur un autre DDE (ou un autre volume d'un DDE de vaste capacité). Sacrifier l'actuelle sauvegarde TimeMachine sur l'autre volume du HDD.


----------



## The Lynx (13 Décembre 2016)

Etonnant ce procédé "Fusion Drive", je ne connaissais pas... En tout cas d'après tes explications on dirait que c'est exactement ce dont j'ai besoin!

Il va falloir que je cogite à propos de la sauvegarde des données, je dispose d'un DDE USB sur lequel je pourrai cloner mon OS. Je pourrais éventuellement y copier également les fichiers du HDD mais tu précises qu'il me faudrait un 2ème DDE pour ce dernier, pour quelle raison?

Quant à la sauvegarde TimeMachine, je n'y attache guère d'importance.

Autrement, j'ai testé cet après-midi une installation de Windows 10 via l'assistant BootCamp mais j'obtiens toujours le même message d'erreur, donc je vais considérer sérieusement le contournement que tu me proposes. Merci du conseil!


----------



## macomaniac (13 Décembre 2016)

The Lynx a dit:


> je dispose d'un DDE USB sur lequel je pourrai cloner mon OS. Je pourrais éventuellement y copier également les fichiers du HDD mais tu précises qu'il me faudrait un 2ème DDE pour ce dernier, pour quelle raison?



Pas de raison spéciale - sauf si tu voulais laisser les données séparées du volume de l'OS comme c'est le cas actuellement.

Mais si tu as un volume de DDE très "volumineux" > alors tu clones le contenu de ton volume *ssd* dans le volume d'accueil > et tu peux cloner dans tels ou tels dossiers de ton dossier de compte (situé dans le répertoire *Utilisateurs* du clone) les données de ton autre volume *HDD*.

=> Ainsi, tu aurais réuni en un seul volume démarrable du clone une copie (démarrable) du Système de ton *ssd* et une copie des données de ton *HDD*. Tout ce qu'il faut avant d'envisager un Fusion Drive.

[Tu peux utiliser la démo - gratuite un mois sans limitations fonctionnelles - de ☞*Carbon Copy Cloner*☜ pour réaliser le clone de ton volume *ssd* --> car il clone aussi la *Recovery HD* sur le disque du DDE.

Tu crées une nouvelle tâche telle que "_source_" = volume *ssd* > "_destination_" = volume d'accueil vide du DDE. Désactive l'option _Safety Net_.

Tu peux aussi utiliser le logiciel pour cloner des données de ton volume *HDD* à des emplacements précis de ton dossier de compte dans le clone.]


----------



## The Lynx (14 Décembre 2016)

Ok, au moment de cloner le ssd je vois que des dossiers sont en rouge et décochés, impossible de les cloner car le DDE n'est pas en HFS+ (mais il contient déjà des données). Si je crée une image iso de mon mac pour palier à ce soucis ça ne posera pas de problème dans le processus de clonage à rebours?


----------



## The Lynx (14 Décembre 2016)

arf... une question encore; dois-je inverser les disques avant de procéder au clonage de mon OS ou cela n'a pas d'importance? (j'ai finalement choisi de copier le contenu de mon DDE sur un autre ordinateur afin de pouvoir formater le DDE en HFS+ pour le clonage).


----------



## macomaniac (14 Décembre 2016)

Il faut que le disque de ton DDE ait une *table de partition GUID* et que le volume ait un *format JHFS+* (*Mac OS étendu journalisé*) => vérifie donc aussi la table de partition générale du disque, que ce ne soit pas du *MBR* - une fois que tu auras délesté ton DDE de ses données.

Ces *2* paramètres logiques combinés sont nécessaires pour que ton clone soit démarrable.

Tu n'as pas du tout besoin d'inverser tes disques "_source_" avant clonage vers le volume du DDE "_destination_" : c'est complètement indifférent, car «CCC» va copier l'ensemble des fichiers du volume *ssd* monté, peu importe où soit situé le disque support, dans le nouveau volume du DDE.

À la fin du clonage du volume *ssd* > «CCC» te demandera si tu veux qu'il clone aussi la partition de secours *Recovery HD* sur le disque du DDE => tu réponds : *OUI*.


----------



## The Lynx (15 Décembre 2016)

Bon, le clonage du ssd à l'air de s'être bien passé, mais "CCC" ne m'a absolument pas demandé de cloner la partition Recovery HD, un moyen de vérifier qu'elle y soit bien présente?


----------



## macomaniac (15 Décembre 2016)

The Lynx a dit:


> la partition Recovery HD, un moyen de vérifier qu'elle y soit bien présente?



Oui --> ton DDE attaché au Mac > tu passes la commande :

```
diskutil list
```
 dans le «Terminal» > et tu postes ici le tableau retourné.


----------



## The Lynx (15 Décembre 2016)

Ah oui effectivement elle à l'air présente!

/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 ssd                     400.4 GB   disk0s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

   4:       Microsoft Basic Data Untitled                98.9 GB    disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *1.0 TB     disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS DDE                     999.2 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s4


J'entame maintenant la copie des données de mon HDD vers un dossier du dossier de compte utilisateur dans le DDE. Une petite question: y'aura-t-il moyen après restauration du volume de gérer l'espace disque en déplaçant les fichiers lourds sur le HDD par exemple, ou bien cela se fait-il automatiquement du coup?


----------



## The Lynx (15 Décembre 2016)

La copie des volumes SSD et HDD s'est bien opérée, je pense être prêt pour l'opération Fusion Drive, j'inverserai les disques dès que tu me donnes le feu vert.


----------



## macomaniac (15 Décembre 2016)

Oui : la *Recovery HD* est bien en place sur le disque de ton DDE.

Tu n'as plus qu'à ouvrir ton Mac > intervertir les disques (SSD > emplacement disque naturel & HDD > emplacement super-drive) > démarrer sur ton clone (touche "_alt_" > choisir volume *DDE*) > et faire signe pour la suite des opérations...


----------



## The Lynx (15 Décembre 2016)

J'ai bien inversé les disques, en démarrant avec "alt" je ne vois pas le volume DDE, en revanche j'ai un volume "EFI" j'ai tenté et ça me lance dans recovery, j'y ai ouvert l'utilitaire de disque dans lequel je vois bien mon DDE ainsi que l'image OSX reconnue.

*Rectification*: j'ai bien réussi à démarrer directement sur le clone du DDE.


----------



## macomaniac (15 Décembre 2016)

Alors repasse dans le «Terminal» du clone la commande :

```
diskutil list
```
 et poste le tableau des disques > que je sois fixé sur leurs identifiants de devices.


----------



## The Lynx (15 Décembre 2016)

J'ai quand même un doute, au moment de copier les données du HDD j'ai créé un dossier via "CCC" dans le dossier bureau de l'utilisateur nommé "DDI HDD". Dossier que je devrais retrouver actuellement sur mon bureau étant donné que j'ai démarré sur le clone. Or je ne le vois pas, (ceci dit quand je vais dans l'arborescence des disques puis dans DDE j'arrive à le retrouver). 


Le tableau que j'obtiens:

/dev/disk0 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:                  Apple_HFS HDD                     1.7 TB     disk0s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk0s3


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.1 GB   disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS ssd                     400.4 GB   disk1s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3

   4:       Microsoft Basic Data Untitled                98.9 GB    disk1s4


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *1.0 TB     disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS DDE                     999.2 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (15 Décembre 2016)

Il vaudrait mieux que tu sois certain d'avoir cloné également les données de ton HDD.

Quand tu arrives à retrouver ton dossier dans le volume du clone > quelle est son adresse ? - il te suffit de faire un glisser-déposer d'un seul de ses fichiers dans la fenêtre ouverte du «Terminal» > et le chemin absolu au dossier parent > se terminant au fichier en question > s'affichera automatiquement.


----------



## The Lynx (15 Décembre 2016)

Voici le chemin que j'obtiens pour le dossier "Audio Libraries" se situant dans le dossier "DDI HDD":
/Volumes/DDE/Users/mon_nom_d'utilisateur/Desktop/DDI\ HDD/Audio\ Libraries

à priori tous les fichiers sont là, c'est juste que ce fameux dossier "DDI HDD" n'apparait pas sur le bureau alors qu'il y est dans l'arborescence. Peut-être y'a-t-il un moyen de vérifier que j'ai bien démarré sur le clone? (pourtant ça paraît évident, depuis recovery j'ai cliqué sur "disque de démarrage" --> DDE OSX Sierra 10.12.2 --> démarrer sur ce disque.


----------



## macomaniac (15 Décembre 2016)

Un dossier "enveloppe" intitulé *DDI HDD* existe donc bien dans l'espace du sous-dossier Bureau de ton compte dans le clone. Il n'est pas graphiquement affiché par le Finder de manière visible sur le Bureau ?


----------



## The Lynx (15 Décembre 2016)

Non il n'est pas affiché par le finder sur le bureau. Peut-être y'a-t-il un moyen de vérifier que j'ai bien démarré sur le clone? Pourtant ça paraît évident, depuis recovery j'ai cliqué sur "disque de démarrage" --> DDE OSX Sierra 10.12.2 --> démarrer sur ce disque.


----------



## macomaniac (15 Décembre 2016)

The Lynx a dit:


> Peut-être y'a-t-il un moyen de vérifier que j'ai bien démarré sur le clone?



À mon avis > tu n'es pas actuellement démarré sur ton clone > car tu obtiens l'adresse suivante de ton fichier :

```
/Volumes/DDE/Users/mon_nom_d'utilisateur/Desktop/DDI\ HDD/Audio\ Libraries
```
 > or si tu étais démarré sur ton clone l'adresse serait :

```
/Users/mon_nom_d'utilisateur/Desktop/DDI\ HDD/Audio\ Libraries
```

En effet, si le volume du clone était actuellement démarré > il ne serait pas désigné comme un volume externe (*/Volumes/DDE*) > mais par son point de montage logique direct */* - ce qui n'est pas le cas. Tu es donc actuellement démarré sur ton volume *ssd* interne.

Passe la commande :

```
sudo bless --folder /Volumes/DDE/System/Library/CoreServices
```
 qui "bénit" (*bless*) l'en-tête du volume *DDE* recelant ton clone > afin qu'il soit repérable par le Gestionnaire de Démarrage de l'*EFI* comme volume démarrable > re-démarre avec "_alt_" > si tu avises affiché un volume *DDE* > choisis-le comme disque de démarrage.


----------



## The Lynx (15 Décembre 2016)

J'ai passé la commande et redémarré avec "alt", les seuls volumes proposés sont "ssd", "windows" et "efi".
Ceci dit je peux réessayer depuis reovery en sélectionnant le DDE comme disque de démarrage (étonnant qu'il ne me l'affiche pas au démarrage avec "alt").

edit: d'ailleurs même depuis ma session sur le ssd, quand je vais dans "préférences système" ==> "disque de démarrage" je vois bien le DDE. J'ai redémarré dessus mais j'obtiens toujours ce retour du terminal: "/Volumes/DDE/Users/mon_nom_d'utilisateur/Desktop/DDI\ HDD/Audio\ Libraries" qui prouve que je suis encore sur le ssd.


----------



## macomaniac (15 Décembre 2016)

«Carbon Copy Cloner» a dû louper quelque chose (une occurrence rare) lors du clonage.

Ce que tu peux faire > c'est, démarré normalement sur ton volume *ssd* > relancer «CCC» > recloner le volume *ssd* dans le volume *DDE*.

Je t'invite, à la rubrique "_Source_" > à choisir à : Cloner > l'option : *Fichiers sélectionnés* > à parcourir l'arborescence du volume *ssd* > et à décocher la case de *Utilisateurs* > afin de ne pas risquer d'effacer sur la "_Destination_" le dossier *DDI HDD* du Bureau de ton compte dans le clone (attention ! important !).

Mets bien l'option "_Safet Net_" sur *OFF*. En mode "clonage incrémentiel" > ça devrait aller assez vite.

Procède à ce nouveau clonage > normalement «CCC» termine toujours par une énième bénédiction du *header* du volume de "_destination_" et par une mise-à-jour des caches de démarrage.

=> re-démarre avec "_alt_" > vois si tu avises le volume *DDE* affiché comme disque démarrable.

[Je n'arrive pas à comprendre comment «CCC» a pu se louper en générant un clone indétectable comme volume démarrable par le *Boot_Manager* de l'*EFI*...]


----------



## The Lynx (15 Décembre 2016)

D'ac, juste besoin d'une précision par rapport à Safety Net, les options proposées sont: "SafetyNet activé", "SafetyNet désactivé", et "ne rien supprimer". Je dois bien sélectionner l'option "SafetyNet désactivé" ?
Tu parles aussi de "clonage incrémentiel", c'est par rapport au réglage de SafetyNet ou bien c'est une option à cocher quelque part?


----------



## macomaniac (15 Décembre 2016)

Oui : *Safety net désactivé*_.
_
Le clonage incrémentiel est un automatisme de «CCC» après le premier clonage complet : seules les différences de la "_source_" sont copiées sur la "_destination_" > ce qui permet au logiciel de parcourir rapidement des pans entiers d'arborescence (s'il repère comme marque d'un dossier _source_ éventuel une absence de différence temporelle d'accès et modification par rapport au dossier correspondant de la _destination_ > il l'échappe entièrement sans y entrer et hop ! au suivant...).


----------



## The Lynx (15 Décembre 2016)

Bon j'ai bien recloné SSD vers DDE en prenant soin de décocher la case "utilisateurs", j'ai effectivement vu le message de mise-à-jour des caches de démarrage à la fin de l'opération de clonage (réalisée à priori avec succès).

Mais DDE n'apparait toujours pas lors du démarrage avec "alt". Une précision, mon DDE USB est un Verbatim Desktop Hard Drive 1TO USB 3.0 47658 (je ne sais pas si ça a son importance).


----------



## macomaniac (15 Décembre 2016)

Si tu vas à : _Menu _ > _Préférences Système_ > _Disque de démarrage_ => est-ce que tu vois le volume *DDE* affiché ?


----------



## The Lynx (15 Décembre 2016)

Oui tout à fait! 
J'ai même essayé de redémarrer dessus du coup mais rien n'y fait, l'ordinateur redémarre normalement et quand ma session s'ouvre je ne peux que constater que je suis toujours sur le SSD.


----------



## macomaniac (15 Décembre 2016)

Bon : il y a là un mystère inscrutable.

Passe dans le «Terminal» la commande :

```
df -H
```
 et poste le tableau retourné.

L'utiliaire *df* (*d*isplay_*f*ree_space) est appelé avec l'option *-H* (*H*uman --> retourner des valeurs humainement lisibles en multiples du *byte*) pour afficher les espaces : complet > occupé > libre des volumes montés.

=> c'est pour te mitonner un contournement au caractère non démarrable de ton *DDE*.


----------



## The Lynx (15 Décembre 2016)

dac, (oui c'est étrange..) voici le tableau:
Filesystem      Size   Used  Avail Capacity   iused      ifree %iused  Mounted on

/dev/disk1s2    400G   280G   120G    71%   1526423 4293440856    0%   /

devfs           195k   195k     0B   100%       660          0  100%   /dev

/dev/disk0s2    1.7T   551G   1.1T    34%    200514 4294766765    0%   /Volumes/HDD

/dev/disk1s4     99G   102M    99G     1% 18446744073613073808   96477808  100%   /Volumes/Untitled

map -hosts        0B     0B     0B   100%         0          0  100%   /net

map auto_home     0B     0B     0B   100%         0          0  100%   /home

/dev/disk0s3    349G   435M   349G     1%        90 4294967189    0%   /Volumes/Time Machine

/dev/disk2s2    999G   826G   174G    83%   1699993 4293267286    0%   /Volumes/DDE


----------



## macomaniac (15 Décembre 2016)

Donc ton volume *ssd* contient pour *280 Go* de données.

Alors voici l'idée générale de la manœuvre : reformater le volume *Time Machine* de *349 Go* de ton HDD en un volume intitulé disons *BROL* > cloner le contenu de *ssd* dans *BROL* > démarrer sur *BROL* > créer le Fusion Drive solidarisant le SSD complet réinitialisé et la partition (reformatée) *HDD* seule du HDD (= partition de tête de ce disque : décisif) > cloner (toujours à partir de *BROL*) le volume *DDE* dans le volume du Fusion Drive > démarrer sur le volume du Fusion Drive > supprimer la partition *BROL* et récupérer son espace au *Volume Logique* du Fusion Drive (car un *CoreStorage Fusion Drive* est logiquement extensible, et pas à taille fixe).

Un peu complexe mais logiquement sans faille.

Pour reformater la partition *disk0s3 Time Machine* > tu passes la commande :

```
diskutil eraseVolume jhfs+ BROL /dev/disk0s3
```

S'il n'y a pas de message d'erreur retourné > tu relances «CCC» et tu crées une nouvelle tâche où : "_Source_" = *ssd* > "_Destination_" = *BROL* (pas de *Safety Net*) > et tu clones.

Cela opéré > tu re-démarres avec "_alt_" > si *BROL* est affiché > tu démarres dessus > tu signales ce succès (mineur mais prometteur).

[Ton Mac > c'est pas de la tarte pour lui faire gérer des disques...]


----------



## The Lynx (15 Décembre 2016)

Ok je vais essayer ces manips dans les prochaines heures.



macomaniac a dit:


> [Ton Mac > c'est pas de la tarte pour lui faire gérer des disques...]


Oui  d'ailleurs je te remercie de ta patience et de ton entrain, ça fait déjà 6 pages qu'on est dessus et qu'on navigue d'imprévu en imprévu, je suppose que ça doit devenir rageant de ton côté aussi!


----------



## The Lynx (15 Décembre 2016)

Oups on dirait que la commande "diskutil eraseVolume jhfs+ BROL /dev/disk0s3" a effacé une mauvaise partition: lorsque je l'ai passé j'ai cru lire "recovery hd" quelquepart (je ne peux pas te transmettre le résultat car j'ai fermé le terminal entre temps).

Le volume Time Machine est toujours présent mais j'ai un nouveau volume sur le bureau nommé "BROL" et qui fait 650mo.

Voici un "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 ssd                     400.4 GB   disk0s2

   3:                  Apple_HFS BROL                    650.0 MB   disk0s3

   4:       Microsoft Basic Data Untitled                98.9 GB    disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *1.0 TB     disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS DDE                     999.2 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (15 Décembre 2016)

Apparemment > la numérotation des disques a pemuté depuis le tableau que tu avais posté. Ce petit incident n'est pas grave > car un clone de ta *Recovery HD* existe sur le DDE et parce que le SSD est destiné de toutes façons à être ré-initialisé.

Reposte le retour actuel d'un :

```
diskutil list
```
 > je parie que le ssd qui était reconnu comme *disk1* est actuellement *disk0*.


----------



## The Lynx (15 Décembre 2016)

ouff!

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *500.1 GB   disk0

   1:                        EFI EFI                     209.7 MB   disk0s1

   2:                  Apple_HFS ssd                     400.4 GB   disk0s2

   3:                  Apple_HFS BROL                    650.0 MB   disk0s3

   4:       Microsoft Basic Data Untitled                98.9 GB    disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS Time Machine            349.4 GB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *1.0 TB     disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS DDE                     999.2 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (15 Décembre 2016)

Passe l'une après l'autre les 2 commandes :

```
diskutil rename disk0s3 Sans\ titre
diskutil eraseVolume jhfs+ BROL /dev/disk1s3
```
 > la 1ère qui renomme *Sans titre* la petite partition ex-*Recovery HD* du SSD > la 2è qui reformate le volume *Time Machine* en un volume *BROL* ce coup-ci.

=> cela fait, s'il n'y a pas de lézard > tu peux enchaîner sur le clonage.


[Rassure-toi : il y a quelques autres fils que celui-ci qui ont pris peu à peu l'allure d'une _Odyssée_ logique. On finit toujours par toucher terre (même si ce n'est pas exactement celle où vous attend une _Nausicaa_ en train de jouer à la balle)...]


----------



## The Lynx (16 Décembre 2016)

J'ai cloné avec succès le SSD sur le volume "BROL", et j'ai pu démarrer avec alt sur le volume sans soucis (après vérification dans l'utilitaire de disque: Le volume BROL est bien désigné par son point de montage logique direct */ *et le SSD comme volume interne).


----------



## macomaniac (16 Décembre 2016)

Enfin une bonne nouvelle : terre en vue !

La suppression accidentelle de la *Recovery HD* du SSD aura même eu un effet vertueux (je pense que la « _Main Invisible de la Providence_ » est en train d'œuvrer dans ce fil) : c'est que «CCC», faute de modèle, ne l'aura pas clonée tout en queue de HDD > ce qui facilitera la manœuvre finale de récupération du seul espace du volume *BROL* au *Volume Logique* du Fusion Drive.

Quand tu seras de retour aux affaires > ton DDE attaché au Mac > démarre sur ton volume *BROL* > passe une fois de plus la commande :

```
diskutil list
```
 et poste le tableau retourné.

[La numérotation des disques est sujette à variations : c'est l'ordre dans lequel le *kernel* (noyau) démarré enregistre l'attachement des disques au Système > avant d'exécuter la probation des systèmes de fichiers > et le montage des volumes.]


----------



## The Lynx (16 Décembre 2016)

hop le tableau:
/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 ssd                     400.4 GB   disk0s2

   3:                  Apple_HFS Sans titre              650.0 MB   disk0s3

   4:       Microsoft Basic Data Untitled                98.9 GB    disk0s4


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:                  Apple_HFS HDD                     1.7 TB     disk1s2

   3:                  Apple_HFS BROL                    349.4 GB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *1.0 TB     disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS DDE                     999.2 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


----------



## macomaniac (16 Décembre 2016)

Alors si tu es bien démarré sur *BROL* actuellement :

*- a)* par la commande :

```
diskutil partitionDisk disk0 gpt jhfs+ SSD 100%
```
 > tu ré-initialises le SSD en exportant un seul volume utile intitulé *SSD*.

--------------------​
*- b)* par la commande :

```
diskutil eraseVolume jhfs+ HDD disk1s2
```
 > tu reformates le partition *disk1s2* du HDD en remontant un volume vide intitulé toujours *HDD*.

--------------------​
*- c)* par la commande :

```
diskutil coreStorage createLVG FUSION disk0s2 disk1s2
```
 > tu solidarises les 2 partitions *disk0s2* (*SSD*) & *disk1s2* (*HDD*) en un *Groupe de Volumes Logiques* Fusion Drive > en fin d'opération > tu vas obtenir un *UUID* (IDentifiant Unique Universel) de 32 caractères alpha-numériques : celui du *Logical Volume Group* généré, de la forme : *xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx* > tu le sélectionnes > et par *⌘C* tu le copies provisoirement dans le presse-papier.

--------------------​
*- d)* par la commande :

```
diskutil coreStorage createLV xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx jhfs+ "Macintosh HD" 100%
```
 > tu exportes un *Volume Logique* unique intitulé *Macintosh HD*.

--> pour passer cette commande : tu colles par *⌘V* le réel *UUID* de ton presse-papier à la place exacte de mon *xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx* dans la commande. Là où j'ai écris *"Macintosh HD"* (le nom du volume exporté) tu peux mettre en remplacement un nom de volume qui a ta préférence (si tu veux) entre les *""*. Respecte les espaces entre tous les termes dans la commande.
--------------------​
*- e)* par les commandes (à saisir l'une après l'autre) :

```
diskutil list
diskutil cs list
```
 > tu affiches les tableaux : *1)* des disques avec leurs partitions actuelles ; *2)* de l'architecture logique du *Groupe de Volumes Logiques CoreStorage* du Fusion Drive.

--------------------​​=> il serait prudent à ce stade que tu postes ici les 2 tableaux retournés > que je vérifie que tout est exactement en ordre sans erreur.


----------



## The Lynx (16 Décembre 2016)

J'ai effectué toutes les manips avec succès. Voici les tableaux:

*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_CoreStorage FUSION                  499.8 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:          Apple_CoreStorage FUSION                  1.7 TB     disk1s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s5

   4:                  Apple_HFS BROL                    349.4 GB   disk1s3


/dev/disk2 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *1.0 TB     disk2

   1:                        EFI EFI                     209.7 MB   disk2s1

   2:                  Apple_HFS DDE                     999.2 GB   disk2s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk2s3


/dev/disk3 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +2.1 TB     disk3

                                Logical Volume on disk0s2, disk1s2

                                B19AEA47-C949-4172-ACF5-C9827C366954

                                Unencrypted Fusion Drive


*diskutil cs list*:
CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group 9FB135A5-3304-432F-AF8B-3E57542CC554

    =========================================================

    Name:         FUSION

    Status:       Online

    Size:         2150293295104 B (2.2 TB)

    Free Space:   45056 B (45.1 KB)

    |

    +-< Physical Volume 07C38366-9429-496C-BE6E-AA354FE9466A

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     499763888128 B (499.8 GB)

    |

    +-< Physical Volume 06AF92DC-FFDD-4842-BD87-2B70DEA1E541

    |   ----------------------------------------------------

    |   Index:    1

    |   Disk:     disk1s2

    |   Status:   Online

    |   Size:     1650529406976 B (1.7 TB)

    |

    +-> Logical Volume Family E2E54DBA-FE9F-4FA4-88DA-184126E02D68

        ----------------------------------------------------------

        Encryption Type:         None

        |

        +-> Logical Volume B19AEA47-C949-4172-ACF5-C9827C366954

            ---------------------------------------------------

            Disk:                  disk3

            Status:                Online

            Size (Total):          2142364499968 B (2.1 TB)

            Revertible:            No

            LV Name:               Macintosh HD

            Volume Name:           Macintosh HD

            Content Hint:          Apple_HFS

            LVG Type:              Fusion, Sparse


----------



## The Lynx (16 Décembre 2016)

J'ai commencé le clonage du volume DDE sur le volume FusionDrive "Macintosh HD" tel que décrit dans ton message #107.
J'ai pris l'initiative (en espérant ne pas trop m'avancer) car ayant démarré sur BROL (HDD), OSX fonctionne plus lentement, et la tâche de clonage comprend aussi le clonage du dossier lourd "DDI HDD". 
Cela devrait prendre quelques heures..


----------



## macomaniac (16 Décembre 2016)

*Lynx*

J'ai été hors ligne un moment.

Ton Fusion Drive est impeccable. Effectivement > l'étape suivante consistait à cloner le contenu du volume *DDE* dans le volume *Macintosh HD* du Fusion Drive.

Il restera quelques manœuvres de finition : créer une *Recovery HD* sur le HDD (en-dessus de l'actuelle partiiton *BROL*) si «CCC» ne la propose pas de lui-même > supprimer *BROL* et réallouer son espace au volume *Macintosh HD*.


----------



## macomaniac (16 Décembre 2016)

---


----------



## The Lynx (16 Décembre 2016)

Parfait alors, le clonage sur FusionDrive vient de se terminer, j'éjecte le DDE si plus besoin. (il a bien chauffé ces jours-ci )


----------



## macomaniac (16 Décembre 2016)

*The Lynx
*
Poste le retour d'un :

```
diskutil list
```
 > histoire de vérifier si «CCC» ta cloné une *Recovery HD* sur le HDD *disk1* ou pas...


----------



## The Lynx (17 Décembre 2016)

/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 FUSION                  499.8 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:          Apple_CoreStorage FUSION                  1.7 TB     disk1s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s5

   4:                  Apple_HFS BROL                    349.4 GB   disk1s3


/dev/disk3 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +2.1 TB     disk3

                                Logical Volume on disk0s2, disk1s2

                                B19AEA47-C949-4172-ACF5-C9827C366954

                                Unencrypted Fusion Drive


----------



## macomaniac (17 Décembre 2016)

Comme je m'y attendais > «Carbon Copy Cloner» n'a pas cloné la *Recovery HD* du DDE. Le logiciel de _Mike Bombich_ ne sait pas gérer un format *CoreStorage* sous ce rapport.

--------------------

Intermède théorique​
Tu remarqueras qu'à l'emplacement où devrait résider la *Recovery HD* : la partition *disk1s5* (d'après ton tableau > logiquement *disk1s3* après re-démarrage) du DDE > existe déjà une petite partition intitulée : *Boot OS X* de *124 Mo*. Il s'agit d'une partition « *booter* » (démarreur) de la seconde bande du *CoreStorage* Fusion Drive = la partition immédiatement précédente *2: Apple_CoreStorage FUSION 1.7 TB disk1s2*.

Instaurer une *Recovery HD* à cet emplacement même du « *booter* » de la 2è bande du *CoreStorage* Fusion Drive > ne doit donc pas résilier purement et simplement cette partition ayant fonction de « *booter* » > mais doit intégrer à la *Recovery HD* cette fonctionnalité même de « *booter* ». On obtient alors une partition *Recovery HD* qui assume une double fonction : prioritaire de « *booter* » de la bande *CoreStorage* qui la précède > secondaire de Système *Recovery OS* démarrable.

Pour ce faire > 2 dossiers se trouvent créés en coexistence dans le volume *Recovery HD* : un dossier *com.apple.recovery.boot* qui recèle le Système démarrable *Recovery OS* > un dossier *com.apple.boot.S* qui recèle le « *booter* » de la bande *CoreStorage* supérieure. Une hiérarchie logique doit exister entre ces 2 dossiers > telle que le dossier « *booter* » *com.apple.boot.S* (démarreur du *CoreStorage*) doit avoir absolument la pré-éminence sur le dossier *com.apple.recovery.boot* du Système *Recovery OS*.

Ce problème se trouve résolu par un *blessing*  (bénédiction) du *header* (en-tête) du volume *Recovery HD* qui pointe exclusivement au dossier « *booter* » *com.apple.boot.S* en échappant le dossier *com.apple.recovery.boot* du Système *Recovery OS* > de telle sorte que la priorité exécutive du « *booter* » dans le volume *Recovery HD* se trouve assurée. Par ailleurs, le Système *Recovery OS* du dossier *com.apple.recovery.boot* se trouve exclusivement démarrable via la combinaison de touches *⌘R* au démarrage.

Manifestement > cette substitution complexe d'une *Recovery HD* assurant la fonction prioritaire de « *booter* » du *CoreStorage* > à la partition pré-existante du « *booter* » *Boot OS X* => surclasse la programmation de «Carbon Copy Cloner». Car il ne s'agit pas de remplacer tout à trac la partition *Boot OS X* > par une partition *Recovery HD* recelant le dossier *com.apple.recovery.boot* d'un Système *Recovery OS* > il faut de toute nécessité que cette partition *Recovery HD* de remplacement assure la fonction prioritaire de « *booter* » de la bande *CoreStorage* immédiatement supérieure > et pour cela recèle un dossier alternatif *com.apple.boot.S* pré-éminent sur le dossier *com.apple.recovery.boot* du Système *Recovery OS*.

Je crains dans ces quelques considérations théoriques d'avoir détaillé quelques subtitlités conceptuelles assez "abstruses" (malgré mon usage délibéré de la prose française).

--------------------


Pratique​​
Quoi qu'il en soit > la problématique que j'ai explorée admet 2 solutions pratiques :

*- 1°* soit le téléchargement d'un installateur complet de «Sierra» depuis l'AppStore > puis l'activation du Programme d'installation à destination du volume *Macintosh HD* du Fusion Drive (restauration). Le Programme d'installation a entièrement les ressources, en cas d'absence d'une *Recovery HD* au pied de la seconde bande *CoreStorage* d'un Fusion Drive, et de présence d'une partition « *booter* » *Boot OS X* > d'opérer la conversion de cette partition en *Recovery HD* récupérant prioritairement la fonction de « *booter* ».

*- 2°* soit le recours à l'utilitaire *dmtest* créé par Apple à l'époque de la publication du binôme : *CoreStorage* > *Recovery HD* (OS «Lion 10.7») > utilitaire *dmtest* capable à partir de 2 ressources originales d'une *Recovery HD* basique > de créer une *Recovery HD* au pied d'un volume choisi comme cible. Ce programme *dmtest* est capable d'opérer la conversion d'une partition *Boot OS X* en *Recovery HD* assurant la fonction prioritaire de « *booter* », si le volume-cible est un *Volume Logique CoreStorage*.

Je te propose le procédé *2°* = *dmtest* > beaucoup plus rapide que le procédé *1°* > dans la mesure où tu disposes des ressources d'une *Recovery HD* _ad hoc_ sur ton DDE. Voici le topo :

*- a)* démarré toujours provisoirement sur ton volume *BROL* (si jamais tu as gardé ta session active dans ce volume > *re-démarre* > et ré-ouvre cette session > pour que les disques et partitions soient bien renumérotés) > tu télécharges le binaire *dmtest* que je t'ai mis en téléchargement dans le dossier public de ma «DropBox» : ☞*dmtest.zip*☜ (16 Ko) > tu dézippes l'archive > tu t'arranges pour avoir le fichier *dmtest* sur ton *Bureau* de session (icône anthracite avec mention de *exec* en vert).
--------------------​
*- b)* tu attaches alors seulement ton DDE à ton Mac > et tu passes une commande :

```
diskutil list
```
 afin de vérifier quel est le numéro de ce disque. Je vais supposer ici que c'est */dev/disk3* > si le SSD = *disk0* > le HDD = *disk1* > le *Volume Logique Macintosh HD* = *disk2* (ayant été exporté avant l'attachement du DDE au Mac). Si le n° du disque était autre (*disk2* au lieu de *disk3*) > tu opérerais le changement idoine dans la commande qui suit.

--------------------​*- c)* par la commande :

```
diskutil mount /dev/disk3s3
```
 tu montes le volume *Recovery HD* du DDE (dont l'icône s'affiche sur le Bureau).

--------------------​
*- d)* par la commande (copier-coller --> déroule bien complètement le tapis roulant horizontal) :

```
sudo Desktop/dmtest ensureRecoveryPartition /Volumes/Macintosh\ HD /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg 0 0 /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist
```
 tu fais créer une *Recovery HD* _ad hoc_ à l'emplacement *disk1s3* du « *booter* » *Boot OS X*. Si tu vois défiler un festival de lignes de type :

```
50d0ab40=disk1s2 pole/pct=0/55.334518
<--[Local dmAsyncProgressForDisk:barberPole:percent:]
->-[Local dmAsyncProgressForDisk:barberPole:percent:]: del callback: DADR=0x7fe450c20090=disk4s2 pole/pct=0/55.386169
....
```
 > c'est le signe que la commande passe. Il faut une minute environ en tout > avant récupération de l'invite de commande à ton nom d'utilisateur.
--------------------​
*- e)* si tout s'est déroulé conformément aux attentes > tu *re-démarres* un coup et tu postes le tableau retourné par un :

```
diskutil list
```

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


----------



## The Lynx (17 Décembre 2016)

Hello Maco

Tout s'est déroulé correctement, voici le tableau diskutil list obtenu après redémarrage (le DDE toujours connecté):

/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 FUSION                  499.8 GB   disk0s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:          Apple_CoreStorage FUSION                  1.7 TB     disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:                  Apple_HFS BROL                    349.4 GB   disk1s4

/dev/disk2 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                            Macintosh HD           +2.1 TB     disk2
                                 Logical Volume on disk0s2, disk1s2
                                 B19AEA47-C949-4172-ACF5-C9827C366954
                                 Unencrypted Fusion Drive

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                  Apple_HFS DDE                     999.2 GB   disk3s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3


--> Une question cependant: pourquoi faire une recovery HD sur le HDD plutôt que sur le SSD? Simple curiosité mais ça m'est égal. Ne serait-ce pas mieux qu'elle soit sur le SSD (par soucis de rapidité) ?


----------



## macomaniac (17 Décembre 2016)

Mer-veil-leux !

(pfouou ! manœuvre mineure > mais drôlement sophistiquée, en fait)



The Lynx a dit:


> pourquoi faire une recovery HD sur le HDD plutôt que sur le SSD?


La raison générale doit être : affecter le plus possible du SSD au *CoreStorage* pour soustraire le moins de mémoire rapide. On dira : *650 Mo* de gain : c'est un peu radiner, non ?

Il faudrait que tu re-démarres à présent sur le volume du Fusion Drive : *Macintosh HD* (si ce n'est déjà fait) > et que tu signales le succès de cette opération. Car c'est à partir de ce démarrage > qu'il va être possible de supprimer la partition *BROL* et de récupérer son espace au volume *Macintosh HD*.


----------



## The Lynx (17 Décembre 2016)

D'ac je comprends mieux, oui pour 650mo de gain on va pas en faire un fromage .

Bon alors j'ai redémarré avec "alt" et que vois-je? 2 volumes nommés tous les deux "Macintosh HD", j'ai booté au pif sur le premier avec succès (quoique l'ordi à l'air d'être un peu au ralenti). Je retrouve bien sur le bureau mon dossier "DDI HDD".

Lorsque je vais dans préférences système ==> disque de démarrage, je ne vois qu'un seul et unique volume "Macintosh HD".


----------



## macomaniac (17 Décembre 2016)

C'est normal que tu aies un double affichage de *Macintosh HD* > parce que, s'il n'y a qu'un seul *Volume Logique* exporté > il y a 2 bandes *CoreStorage* exportatrices : *disk0s2* et *disk1s2*.

Or ces bandes sont des partitions qui ont été re-définies logiquement > au sens où chacune a été transformée en un disque dur virtuel nommé : *Physical Volume*. Chacun de ces 2 *Physical Volumes* est un disque générateur du *Volume Logique* unique *Macintosh HD* (comme si tu avais 2 images-disques *DMG* montant un unique volume à elles deux).

Comme tu peux le remarquer > chacune de ces bandes *CoreStorage* (*disk0s2* et *disk1s2*) est solidaire d'un « *booter* » résidant sur une partition immédiatement subalterne : la *3: Apple_Boot Boot OS X 134.2 MB disk0s3* pour le *Physical Volume disk0s2* du SSD > et la... *3: Apple_Boot Recovery HD 650.0 MB disk1s3* pour le *Physical Volume disk1s2* du HDD (car cette partition de secours *Recovery HD* ne l'est qu'en mode second > mais en mode prioritaire c'est le second « *booter* » déguisé du *CoreStorage*).

2 « *booters* » ayant pour fonction le démarrage sur le *Volume Logique Macintosh HD* à partir de chacun des *Physical Volumes* supports --> 2 affichages d'un mode de démarrage de *Macintosh HD* : le premier, par le « *booter* » = *3: Apple_Boot Boot OS X 134.2 MB disk0s3* > le second par le « *booter* » (déguisé) = *3: Apple_Boot Recovery HD 650.0 MB disk1s3*.

=> en résumé : les 2 se valent pour démarrer le *Macintosh HD*.

--------------------​Pour ce qui est de la partition *BROL* :

*- a)* par la commande :

```
diskutil eraseVolume free NULL /dev/disk1s4
```
 tu convertis la partition *BROL* au statut de *free_space* (espace libre hors partitionnement).


*- b)* par la commande :

```
diskutil coreStorage resizeStack B19AEA47-C949-4172-ACF5-C9827C366954 0b
```
 tu requiers le re-dimensionnement du *Groupe de Volumes Logiques CoreStorage* (en ciblant son instance sommitale : le *Volume Logique Macintosh HD* par son *UUID*).

L'extension du *Volume Logique* global (et l'étirement du système de fichiers *JHFS+* ancré sur son *dev node*) > vont s'opérer en corrélation avec la seule extension du *Physical Volume* n°*2* du HDD et de ce fait des limites de sa seule partition *2: Apple_CoreStorage FUSION 1.7 TB disk1s2*. La *Recovery HD* servant de « *booter* » sera clonée au préalable sur les *650* derniers *Mo* de blocs du disque > et son original supprimé de son emplacement sur les blocs > afin de permettre cette réallocation d'espace sans rester en position intermédiaire de blocage sur le chemin.

=> si tu n'as pas de message d'erreur > le tableau affiché par un :

```
diskutil list
```
 devrait permettre de vérifier le succès de l'opération (qui s'opère en mode "_live_", sans démontage du volume démarré *Macintosh HD*).


----------



## The Lynx (17 Décembre 2016)

(finalement le mac est toujours aussi rapide qu'auparavant, juste le démarrage qui est un peu plus long)

eh bien.. 
Voici le "diskutil list" après avoir viré BROL et étendu le volume FusionDrive:

/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 FUSION                  499.8 GB   disk0s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk0s3


/dev/disk1 (internal, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *2.0 TB     disk1

   1:                        EFI EFI                     209.7 MB   disk1s1

   2:          Apple_CoreStorage FUSION                  2.0 TB     disk1s2

   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s4


/dev/disk2 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                            Macintosh HD           +2.5 TB     disk2

                                Logical Volume on disk0s2, disk1s2

                                B19AEA47-C949-4172-ACF5-C9827C366954

                                Unencrypted Fusion Drive


----------



## macomaniac (17 Décembre 2016)

Le port d'_Ithaque  _! (enfin...)  
	

	
	
		
		

		
			





Pour ce qui est de ton énorme dossier sur ton Bureau (*DDI HDD*) > je te conseillerais de ne pas l'y laisser > mais de le déplacer dans un autre sous-dossier de ton répertoire de compte (*Documents* ou autre) > et de le remplacer par un alias sur le Bureau. À moins que tu ne préfères trier ses données pour les ventiler dans plusieurs sous-dossiers.

La raison : le Finder n'aime pas avoir à gérer un dossier Bureau (*Desktop*) excessivement chargé.

----------

_Ithaque_, certes > reste le _Prétendant_ : le Système Windows qui aimerait bien s'installer à domicile...

Alors ton dispositif actuel Fusion Drive est entièrement agréé d'un point de vue logique pour que l'«Assistant BootCamp» te crée une partition *BOOTCAMP* de la taille que tu souhaites (elle occupera la position du ci-devant volume *BROL* en queue de HDD) > puis installe Windows-10 si tu as un fichier *ISO* de ce Système sur le Bureau que tu puisses lui désigner en source (et si par ailleurs tu télécharges les pilotes dans le volume d'une clé USB).


----------



## The Lynx (17 Décembre 2016)

Eh bien le dossier "DDI HDD" contient 5 dossiers principaux, eux-mêmes divisés en une multitude de sous-dossiers, mais si tu penses que ça allègerait tout de même le Finder alors je le déplacerai.

Quant au Prétendant, je pense installer Windows 7 plutôt que le 10. Donc j'utiliserai "assistant Boot Camp" pour créer la partition, et j'installerai Windows 7 manuellement via une clé bootable sur la partition dédiée (sans oublier le package Boot Camp), car l'assistant ne prend malheureusement pas en charge les versions antérieures à Windows 10.
Ceci dit j'aimerai m'assurer que la partition créée par l'assistant BootCamp (donc à destination d'un windows 10 normalement) convienne bien à Windows 7.

Mais déjà un énorme Merci pour ton aide, ce système fusion drive... c'est vraiment excellent!


----------



## macomaniac (17 Décembre 2016)

The Lynx a dit:


> l'assistant ne prend malheureusement pas en charge les versions antérieures à Windows 10



Il me semble avoir lu dans un article de MacGé récent > que la MÀJ 10.12.2 de «Sierra» avait restauré la capacité de l'«Assistant BootCamp» à installer Windows-7.

Si tu as effectué cette mise-à-jour (sinon fais-le) > il ne te coûte rien de vérifier cette rumeur...


----------



## The Lynx (17 Décembre 2016)

Génial! Cette mise à jour 10.12.2 tombe à pic! 
Je confirme que j'ai pu créer une clé d'installation Windows 7 avec l'utilitaire BootCamp sans message d'erreur.

Cependant lors de l'installation de windows 7, l'installateur me rappelle toujours qu'il est impossible d'installer windows sur ce disque, et que la partition doit être en ntfs... à moins que tu n'aies une autre idée, je vais essayer une installation de Windows 10 cette fois-ci pour voir.


----------



## macomaniac (17 Décembre 2016)

Essaie plutôt Windows-10 via l'«Assistant BootCamp» (si tu as besoin de supprimer manuellement la partition *BOOTCAMP* pour la faire recréer par l'«Assistant» > tu n'as qu'à demander).

J'ai un peu épuisé mon stock d'idées concernant «Windows»...


----------



## The Lynx (17 Décembre 2016)

Bon, ça ne marche toujours pas.. J'obtiens une fois de plus le même message d'erreur avec Windows 10, pourtant je suis passé par la procédure officielle avec l'assistant Boot Camp, c'est dingue! 

Comment ai-je bien pu l'installer auparavant? Le plus étrange c'est que je me souviens avoir installé windows 7 manuellement (création d'une partition adéquate puis d'une clé bootable avec wintobootic sur un pc) et un peu plus tard avoir fait une installation fraiche de Windows 10 en utilisant l'assistant Boot Camp, et les deux installations avaient réussi du premier coup!

[j'ai utilisé l'utilitaire de disque pour virer la partition windows, si tu as une meilleure technique je suis preneur]

Ce que je peux faire c'est essayer de dégoter un autre iso de windows pour tester (il n'y cependant aucune raison pour que ça marche mieux...)


----------



## The Lynx (17 Décembre 2016)

Ah je constate dans Logic X une forte utilisation des disques, un message de surcharge apparaît malgré le buffer qui est réglé au maximum. Saurais-tu comment savoir quels fichiers sont sur tel ou tel disque? Il me semble avoir lu que fusion drive répartissait tout seul les fichiers en fonction de leur fréquence d'utilisation. 

J'ai aussi lu quelque part que l'utilisation d'onyx était risquée avec un fusion drive, qu'en penses-tu? Car j'aimerai faire un peu de nettoyage des fichiers inutiles etc..


----------



## macomaniac (18 Décembre 2016)

Pour ce qui est du procédé du «Fusion Drive» > l'idée générale est la suivante : la partition-disque *CoreStorage* du SSD se trouve toujours remplie en données (Système & utilisateur) en priorité > jusqu'à une limite d'environ *10%* d'espace libre restant (destiné à un *buffer* permettant la mise-en-cache rapide d'écritures de fichiers > avant leur inscription à un des 2 disques). Atteinte la limite des *10%* d'espace libre restant sur la partition *CoreStorage* du SDD > toutes les écritures additionnelles sont reportées à la partition *CoreStorage* du HDD. Un mécanisme d'optimisation permet des transactions de fichiers entre SSD et HDD en fonction de l'atteinte plus ou moins grande en lecture de ces données (avec un blocage pour les très gros fichiers du HDD qui ne peuvent pas transiter au SSD).

Passé cet ordre de généralités > il n'y a aucun moyen (à ma connaissance) de savoir dans quelle partition-disque *CoreStorage* (la *disk0s2* ou la *disk1s2*) tel fichier donné se trouve actuellement écrit sur les blocs.

----------

«Onyx» intervient sur le Système installé (par exemple les caches) > or le Système installé, en ce qui concerne un Fusion Drive, est une série de fichiers relevant d'un système de fichiers ancré sur l'en-tête du *Volume Logique* unique, qui joue le rôle de container-partition virtuel comme s'il s'agissait de celle d'un disque en dur. Je ne vois pas trop a priori en quoi l'usage d'«Onyx» changerait d'un cas de figure à l'autre.

----------

Pour ce qui est de «Windows» > outre tes expérimentations personnelles > tu peux toujours tenter de suivre la piste donnée par *Skyjoke* dans ce message : ☞*Installer Windows sans BootCamp*☜.

Sinon > si tu avais un autre Mac sur lequel tu parviendrais à installer «Windows» dans une partition du disque > je te signale que le logiciel ☞*Winclone*☜ (payant malheureusement) pemet de cloner un système «Windows» bootable sous forme d'une image-archive *Win.winclone* > laquelle est copiable sur un DDE > device attachable à un autre Mac > ce qui permet (si «Winclone» est aussi installé dans les applications de cet autre Mac) de rétro-cloner cette image-archive à une partition formatée en *FAT-32* au préalable > de manière à récupérer un OS «Windows» démarrable à l'image de l'original.


----------



## The Lynx (18 Décembre 2016)

Maco

Merci pour tes liens, je regarderai ça plus en détail plus tard..
Je reviens vers toi car depuis hier l'ordi a planté 5 fois, c'est à dire qu'un élément se bloque (disons safari, mais ça l'a fait avec d'autres applications) ==> apparition de la roue multicolore, si je clique par exemple sur le dock, il va se bloquer aussi, impossible de relancer le finder. La roue tourne sans fin jusqu'a ce que la souris finisse aussi par se bloquer et là je n'ai plus que la solution de forcer l'extinction avec le bouton de mise en marche.

Le mac était stable pendant 2 heures et puis ça a commencé à freezer aléatoirement. Je me demande si ce n'est pas le HDD qui continue ses déconnexions, et étant lié au SSD via FusionDrive, finit par faire tout planter.
Je pourrai vérifier cette éventualité en ré-inversant les disques si c'est pas trop risqué. Si ça ne donne rien je pense réinstaller le système sans fusion drive (j'ai toujours mon DDE avec le clone, mais impossible de booter direct dessus).


----------



## macomaniac (18 Décembre 2016)

*Lynx*

Je trouve (en mode : bilan) que le tableau "disques" n'est pas très normal en ce qui concerne ton Mac :

- clone sur un DDE USB qui ne boote pas, alors qu'il est bien finalisé ;

- déconnexions antérieures de ton HDD en postition super-drive ;

- gels actuels de ton Fusion-Drive dûs sans aucun doute à un disque ;

 - impossibilité d'installer «Windows» quel que soit le procédé utilisé.​
--------------------​
En guise de comparaison : j'ai *2* SSD internes en SATA-3 dans mon _MacBook Pro 17" i7 Late_2011_ et *2* SSD externes dans une station Thunterbolt-1 > tous les 4 membres d'une matrice *RAID 0* qui exporte un seul volume *RAID* égal à la quadruple taille de ces disques. L'avantage de cette configuration peu courante est que j'atteins en moyenne *1400 MB/s* en lecture et en écriture.

Dans cette configuration complexe associant une paire de disques internes et une paire de disque externes > j'expérimente une totale stablité du volume unique exporté et des opérations dans ce volume. Configuration autrement plus "populeuse" en disques et hétérogène en emplacements que celle de ton Fusion Drive à 2 disques internes SATA-3 seulement .

Ce comparatif avec le comportement de ton _MacBook Pro 2012_ > me conduit à conjecturer qu'il y a quelque chose de pas normal en ce qui concerne ta bécane. Parce qu'au fond ton _MacBook Pro _est l'équivalent "portable" d'un _iMac_ à 2 disques (SSD et HDD) associés en mode Fusion Drive. Les _iMac_ de ce genre ne plantent pas à tout bout de champ. Ils sont même rapides, y compris avec un micro-SSD de *24 Go* seulement  - certes plus rapide en PCie que ton SSD en SATA-3 > mais quant à toi tu as quand même de ton côté dans les 500 Go de SSD, ce qui énorme.

--------------------​
Si tu n'es pas satisfait du procédé Fusion Drive (dont l'enjeu principal était de te permettre d'installer «Windows» - ce qui n'a pas été le cas) --> il sera aisé (et beaucoup plus rapide) pour toi de retourner à la situation initiale : l'OS sur le le SSD et les données massives sur le HDD en recroisant tes disques (HDD en position disque naturelle et SDD en position Super-Drive).

En abrégé de la manœuvre : il suffira de rétrécir l'actuel périmètre du *CoreStorage* > de manière à dégager hors *CoreStorage* une partition à la taille idoine en queue de HDD > dans laquelle tu pourras cloner le contenu de *Macintosh HD*. Quoique je me demande si y créer une assez petite partition (genre 60 Go) pour y installer «Sierra» en _clean install_ > ne serait pas une bonne chose > car tu aurais là un OS de secours démarrable (ton clone du DDE ne jouant pas ce rôle).

Une fois démarré sur ce clone interne résidant sur le HDD (ou sur cet OS vierge) > déconstruction du Fusion Drive et séparation logique des 2 disques. Pour ce qui est du clonage à rebours > il te faudra exclure du clonage en direction du volume vide du SSD l'énorme dossier de données *DDI HDD* (la "source" de ce clonage pourrait être le clone du DDE ou le clone sur le HDD si tu avais opté pour cette solution provisoire) > et réserver son clonage au volume vide du HDD précédant la partition de ton clone du HDD (ou de ton OS vierge) actuellement démarré.

=> Bref : une fois redémarré sur le volume-Système du SSD > il n'y aura plus qu'à supprimer la partition-clone de queue du HDD en affectant son espace libre à la partition supérieure du HDD recelant les données (ou s'il s'agit d'un OS de secours > laisser en l'état cette petite partition-Système). Tu n'auras qu'à demander ici > pour que je te passe les commandes opératoires permettant d'effectuer ces repartitionnements.


----------



## The Lynx (18 Décembre 2016)

Effectivement je commence à croire que le problème est matériel, donc je vais faire au mieux pour retrouver ma configuration précédente. Je me passerai de windows pour l'instant si je n'arrive toujours pas à l'installer, 'faut juste que je me dégote un petit pc qui ferait l'affaire..

J'aimerai tout de même tester tester l'inversion des disques (le HDD fonctionnant bien en position principale), penses-tu que cette manipulation pose un risque pour le système fusion drive? C'était plutôt bénéfique dans ma config précédente mais je n'ai aucune idée des conséquences dans le cas présent. 

Sinon oui je suivrais avec plaisir tes instructions pour supprimer le fusiondrive et refaire un clonage.


----------



## macomaniac (18 Décembre 2016)

Mets à jour ton clone *DDE* d'abord (en cas) > puis tu peux tenter l'opération matérielle d'interversion des disques.

En principe > elle ne devrait pas affecter la fonctionnalité du *CoreStorage*.


----------



## The Lynx (19 Décembre 2016)

Oui j'ai mis à jour le clone du DDE.
Bon j'ai interverti les disques et ça n'a plus gelé depuis, je remarque toujours des accès disque plus élevés que la normale dans mes logiciels audio mais surement dus aux transactions de fichiers du système FusionDrive.





Je vais prendre un jour ou deux de test/réflexion si ça ne t'embêtes pas, le temps de me décider pour l'éventuel re-partitionnement/clonage. Pour le moment je laisse tomber Windows car je dois en priorité avoir un système MacOS stable.


----------

