# bootcamp, une partition-copy sur SSD externe reste non-bootable



## jetlag (15 Octobre 2020)

Bonjour,
J'ai passe pas mal de temps en essayant de resoudre ce probleme, si qq'un a une idee de comment si prendre/ et quelle est la raison de ce flop ...

J'ai parcouru au moins 40-50 blogs et messages - sur un SSD externe il parlent tous _d'installer_ Windows. Ici j'essayes de faire une partition-copy sur un SSD externe, d'un bootcamp qui fonctionne en SSD interne (win7). La nouvelle partition win7 est visible, mais reste non-bootable. Que ce soit en Alt/Option, ou via un disk raw vmdk mapped en virtualbox.

*Donc voila le descriptif:*
- MB Air 2011 avec HSierra 10.13.6, tourne OSX (APFS) and Win7 en Bootcamp. SSD interne 256GB, a court d'espace ...

- je veux copier tout, OSX et Bootcamp en disk SSD externe (500G), et idealement pouvoir booter du SSD externe les deux. 
  Pour ensuite faire des manips sur le disk interne. 
  Pour la win7, c'est acceptable de la monter en -raw disk sur virtualbox

- Pourquoi me donner la peine de "copy" et pas une "nouvelle installation bootcamp" ? 
J'ai plus le disk d'installation de win7 et ni les licenses/DVD de Office (j'ai des vieux plans d'electricite en Visio que je veux pas perdre et leur transfer vers des nouvelles apps n'est pas donne.

- j'ai donc commence par partionner en 4, osx en premier, une fat32 au milieu (a la place de "unallocated"), ntfs en dernier.
 Ensuite j'ai fait le transfert de partitions par SuperDuper pour OSX, et AOMEI backupper (a partir du Win7, "partition copy") pour la ntfs. 
 Tout se fait sans erreur

*Etat actuel: *
- (Alt/Option enfonce) =>  OSX peux booter du disk externe (la partition apparit dans la liste), par contre la Win 7 reste invisible au moment du boot. 
   Il y a que la BOOTCAMP originale seulement qui apparait dans les choix.

- Je suis revenu sur OSX/SSD interne, j'ai monte une virtualbox vmdk en "raw" qui pointe vers le SSD externe/win7  - et je n'arrive pas a booter. 
j'ai un message d'erreur "non-bootable"


Un "gpt show" du OSX,  montre bien une PMBR sur le disk externe win7, je pense que la partition n'a pas le flag
Bref - J'ai peur de tester la meme operation avec virtualbox avec la parttion BOOTCAMP originale (donc mapper un disk raw vmdk sur la partition BOOTCAMP du SSD interne), pour tester mon coup. Je crains que l'ecriture se fera avec des erreurs et que la partition NTFS sera perdue par la suite
 
- J'ai une autre option, acheter Winclone 8. Je crains perdre mes sous car j'ai lu sur leur forums sur pas mal des cas d'insucces

*Bref - avez vous des intutions a ce qui peut se passer? *
Si je dois poster des output de commandes pour arriver a un diagnostique ... n'hesitez pas.  Merci d'avance
Je reviens avec qque show des commandes, car j'ecris a p d'un autre laptop maintenant


----------



## jetlag (15 Octobre 2020)

Voila, c'est le disk2, 
BOOTCAMP c'est le SSD interne, WINEXT est le SSD externe (copie du BOOTCAMP).

==========  diskutil list ======================
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         102.5 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                148.3 GB   disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +102.5 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            70.8 GB    disk1s1
   2:                APFS Volume Preboot                 20.9 MB    disk1s2
   3:                APFS Volume Recovery                512.0 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *480.1 GB   disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                 Apple_APFS Container disk3         171.8 GB   disk2s2
   3:       Microsoft Basic Data UNTITLED                135.8 GB   disk2s3
   4:       Microsoft Basic Data WINEXT                  172.2 GB   disk2s4

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +171.8 GB   disk3
                                 Physical Store disk2s2
   1:                APFS Volume HSIERRA                 85.9 GB    disk3s1
   2:                APFS Volume Preboot                 20.9 MB    disk3s2
   3:                APFS Volume Recovery                514.4 MB   disk3s3
   4:                APFS Volume VM                      1.1 GB     disk3s4

=========== sudo gpt show /dev/disk2 - SSD externe =============
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  335558616      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  335968256  265328628      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  601296884          4         
  601296888  336402104      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  937698992       4063         
  937703055         32         Sec GPT table
  937703087          1         Sec GPT header

============ df-H, disk2s4 est la WINEXT  ===============
df -H
Filesystem      Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk1s1    102G    71G    30G    71%  953749 9223372036853822058    0%   /
devfs           352k   352k     0B   100%    1191                   0  100%   /dev
/dev/disk1s4    102G   1.1G    30G     4%       2 9223372036854775805    0%   /private/var/vm
map -hosts        0B     0B     0B   100%       0                   0  100%   /net
map auto_home     0B     0B     0B   100%       0                   0  100%   /home
/dev/disk0s3    124G   103G    21G    84%  489334            20224186    2%   /Volumes/BOOTCAMP
/dev/disk3s1    172G    86G    84G    51%  947971 9223372036853827836    0%   /Volumes/HSIERRA
/dev/disk2s3    136G   3.2M   136G     1%       0                   0  100%   /Volumes/UNTITLED
/dev/disk2s4    172G    93G    79G    55%  489823            77311221    1%   /Volumes/WINEXT


----------



## Locke (15 Octobre 2020)

jetlag a dit:


> *Bref - avez vous des intutions a ce qui peut se passer? *
> Si je dois poster des output de commandes pour arriver a un diagnostique ... n'hesitez pas. Merci d'avance
> Je reviens avec qque show des commandes, car j'ecris a p d'un autre laptop maintenant


Aucune intuition, tu n'es pas un cas de figure particulier, mais ta seule et unique possibilité est de faire une sauvegarde avec *Winclone*... https://twocanoes.com/products/mac/winclone/ ...et non, sous macOS il n'y a aucun autre logiciel capable de faire une telle sauvegarde qui sera sous forme de fichier image ayant une extension .winclone.

Sortie de là, tout ce que tu tenteras sera voué à un échec total. Avec Winclone et un disque dur USB 3.0, USB-C ou Thunderbolt, il faudra à la base faire impérativement le formatage en Table de partition GUID et obligatoirement en FAT32, pendant la restauration c'est le logiciel Winclone qui fera à la volée la conversion en NTFS. Donc je vais insister en mentionnant qu'il ne faudra jamais faire un formatage en NTFS, c'est Winclone qui s'en chargera. Ah oui, l'éditeur recommande l'utilisation d'un SSD.


----------



## jetlag (15 Octobre 2020)

Merci de la reponse....  the plot thickens.

Je voulais poster pour reference les memes commandes pour la BOOTCAMP interne qui marche ... et, apres avoir "csrutil disable"/SIP, surprise:

=== sudo gpt show /dev/disk0  (BOOTCAMP Interne) =======
sudo gpt show /dev/disk0
gpt show: /dev/disk0: Suspicious MBR at sector 0   <------!!!  j'attendais autre chose
gpt show: error: bogus map
gpt show: unable to open device '/dev/disk0': Undefined error: 0

pourtant elle fonctionne sans problemes.   Une idee ?
C'est cette partition que j'ai copie en bit-copy


----------



## Locke (15 Octobre 2020)

jetlag a dit:


> pourtant elle fonctionne sans problemes. Une idee ?
> C'est cette partition que j'ai copie en bit-copy


Moi je vais en rester là, c'est-à-dire sur ma réponse précédente. Fais ce que tu veux en bidouillant avec le Terminal, mais c'est à tes risques et périls, je ne m'aventurerais jamais sur un tel terrain !


----------



## jetlag (15 Octobre 2020)

Oubliez le message d'ouverture... 

Vu la decouverte, j'en deduis que j'ai un probleme sur le disk interne maintenant - c'est soit gpt qui perd les pedales, soit il y a un conflit reel entre la GPT et le MBR du bootcamp - dans la table de partition GPT.

A mentioner que l'installation du Bootcamp/win7 a ete fait il y a 6-7 ans, a l'epoque d'un OSX 10.10/11 peu-etre. 
Ensuite l'OSX a ete upgraded de version en version, et c'est l'installation de ces versions OSX qui a perpetue l'ancienne version Bootcamp. Qui fonctionne toujours sans erreurs....

Dernierement, j'ai fait un "ntfs shrink" sous Windows pour recuperer de l'espace - ca a continue de fonctionner mais il m'a mis un "unallocated" en fin de disk et apres Bootcamp - qui n'est pas utilisable.  Donc j'ai rien recupere pour OSX. C'est comme cela que ma quete de demenager temporairement Bootcamp sur SSD externe, a commence.

*Maintenant* - 
(1) comment refaire la PMBR sur la GPT du disk0?  ...et 
(2) Est-ce que la Bootcamp/win7 restera lisible/bootable sur le disk interne, apres #1?


----------



## Locke (15 Octobre 2020)

jetlag a dit:


> *Maintenant* -
> (1) comment refaire la PMBR sur la GPT du disk0? ...et
> (2) Est-ce que la Bootcamp/win7 restera lisible/bootable sur le disk interne, apres #1?


Comme je ne connais pas l'état de la structure de ton disque dur et des partitions, je ne vais pas m'aventurer et te répondre tout simplement que je ne sais pas.


----------



## jetlag (15 Octobre 2020)

Locke a dit:


> Moi je vais en rester là, c'est-à-dire sur ma réponse précédente. Fais ce que tu veux en bidouillant avec le Terminal, mais c'est à tes risques et périls, je ne m'aventurerais jamais sur un tel terrain !


Merci Locke - je comprends. Pourtant vu les erreurs de GPT je crains que Winclone ne fera pas son boulot correctement et je reviens a la command line ou reinstallation totale.
Je bidouille avec le Terminal seulement pour des operations sur le SSD externe


----------



## macomaniac (20 Octobre 2020)

Bonjour *jetlag*

Je n'avais pas suivi ton fil. Soushaites-tu des élucidations concernant la *HMBR* (*H*ybrid_*MBR*) présente sur le bloc n° *0* de ton SSD interne vs la *PMBR* (*P*rotective_*MBR*) du bloc n° *0* du SSD externe ?


----------



## jetlag (21 Octobre 2020)

Bonjour macomaniac,

En fait je voulais comprendre pourquoi je n'arrive pas a booter Win7 sur un MacOs, a partir d'un disk externe.
En sachant que ce meme Win7 boot correctement de la partition Bootcamp - dont la copie se trouve maintenant sur un SSD usb.
Comme je n'ai plus les disk d'install de Win7, je voulais faire une bit-copy de la partition Bootcamp, sur ce disk externe.
Don je ne peux pas dire qu'une nouvelle installation avec les drivers de Bootcamp (plutot qu'une partition-copy), sur un disk externe ne fonctionnerait pas - car je n'ai pas essaye.

Pour reprendre le contexte de ma Q - sur le MacOS, et sur le disk externe SSD :

apres une partition-copy du MacOS, je peux booter OSX (il apparait apres un restart/alt-option), mais pas Win7 ...
apres une partition-copy du Win7 bootcamp sur disk externe, je sais comment transformer la HMBR en PMBR et inversement, et la marquer "bootable" sur la partition Win7 externe - et ca ne change rien. 
(Entre temps j'ai resolu mon probleme de "gpt show: error: bogus map" qui est dans un des derniers messages - je pense que j'ai utilisé Paragon Camptune, je me rappelle meme plus)
encore, pour eliminer la  "windows ne boot pas d'un disk externe" - je sais comment mapper une partition d'un SSD en disk raw sur virtual box - et le faire apparaitre donc comme "disk" pour une virtual machine (windows).
Cette procedure marche pour lire un iso installation windows, ou faire tourner linux - mais pas pour faire fonctionner Win7 externe dans une virtual machine ...
En plus, concernant, WinClone - c'est vrai qu'il peut faire de copies de la partition BootCamp. Mais je doute qu'il peut les restaurer en disk externe. Il peut le faire sur une partition interne Bootcamp ... ce n'est pas mon but.
Donc tout cela m'interpelle...
Il doit y avoir qque chose lie a la partition EFI du disk externe (qui le fait bootable sous OSX), qui fait qu'elle ne pointe pas correctement sur les secteurs du depart de la partition Win7 du disk externe - qu'elle soit en HMBR or PMBR, peut importe.  

Quelque chose en EFI qui peut etre edite en ecrivant directement sur cette partition - vu qu'on a des outils (gpt, gfdisk, diskutil) pour lire les donnees granulaires de n'importe quelle partition (Win7/HMBR a l'occcurence). 

Donc voila - j'ai commence a chercher l'explication sur Google et je suis tombe sur ce forum. Vu la qualite des reponses, il vallait la peine de s'incrire ...


----------



## jetlag (21 Octobre 2020)

En edit ... je prete finalement attention aux mots soulignes - oui... stp. Pourquoi j'ai une HMBR d'un cote et un PMBR d'un autre ...


----------



## macomaniac (21 Octobre 2020)

Je te répondrai plus tard en soirée à ce sujet. Je n'ai pas le loisir juste maintenant de détailler la fonction d'une *HMBR* pour le boot de type *Legacy* (héritage : vieille école) de W-7. Et donc la différence avec une *PMBR* sur le bloc *0* d'un disque Mac.


----------



## macomaniac (21 Octobre 2020)

L'OS Windows-7 est un OS qui boote en mode *Legacy* donc. C'est-à-dire via le circuit suivant : programme interne de type *BIOS* => lisant une table de partition *MBR* pour obtenir l'adresse du volume à démarrer => exécution dans ce volume du boot_loader *Legacy* : *bootmgr* (qui est le lanceur de l'OS). C'est ce circuit qu'il s'agissait de transposer sur Mac pour permettre un démarrage de W-7.

- pour ce faire l'*EFI* (programme interne de boot primaire du Mac) est implémentée de la capacité à émuler un *BIOS* dans le temps du boot.​​- ensuite il faut considérer les tables de partitions d'un disque Mac. Il y en a toujours *2* en parallèle : une *GPT* (*G*UID_*P*artition_ *T*able) principale sur les blocs n°*1* > *33* (avec sauvegarde sur les *33* derniers blocs du disque) > et une *PMBR* (*P*rotective_*MBR*) par défaut sur le seul bloc n°*0* (= 1er bloc) du disque. Cette *PMBR* est un table *MBR* qui possède la structure suivante : elle ne comporte qu'un unique descripteur > qui décrit en encodage *MBR* l'entièreté du disque à partir du bloc n°*1* inclus jusqu'au dernier => comme s'il s'agissait d'une partition unique de type *EFI* (hexcode *0xEE*). Ce type de description *MBR* du disque est évidemment "bidon" > mais a l'avantage de ne pas faire ombrage à la table *GPT* principale.​​- mais dès lors qu'il s'agit qu'un *BIOS* (émulé de l'*EFI* dans le temps du boot) puisse lire dans la *MBR* du bloc n°*0* une description de la partition *BOOTCAMP* => il faut convertir la *PMBR* au type *HMBR* (*H*ybrid_*MBR*). Cette table *MBR* emprunte à la *GPT* principale les descriptions d'au plus *3* partitions > en les décrivant selon l'encodage *MBR* en pur respect du *n°* de bloc de tête > de l'extension en nombre de blocs > du type de la partition enfin (d'où l'appellation "hybride" : hybride de *GPT* et de *MBR*). Les ingénieurs de la  avait implémenté un mécanisme logique tel que > à la moindre création d'une partition de type Windows sur un disque Mac => la *PMBR* par défaut du bloc n°*0* se trouvait automatiquement convertie à une *HMBR* décrivant (entre autre) ladite partition Windows. Cet automatisme a fait les beaux jours de Windows sur Mac jusqu'à l'OS El Capitan inclus. À partir de Sierra > il a été abandonné => de sorte qu'aucune création de partition de type Windows n'induit de conversion de la table *PMBR* du bloc n°*0* à une *HMBR*. Raison : OS W-7 obsolète > OS W-10 bootant en mode *UEFI* par un circuit : *EFI* => lecture de la *GPT* principale => exécution d'un boot_loader : *bootmgr.efi*.​
Si tu as suivi ce petit topo > alors tu en déduis que l'existence d'une *HMBR* incluant un descripteur de la partition *BOOTCAMP* selon l'encodage *MBR* => est requise sur le bloc n°*0* du disque concerné. Sans quoi jamais le *BIOS* émulé de l'*EFI* ne pourra lire l'adressage de la partition *BOOTCAMP*. L'utilitaire *gdisk* de Rod Smith permet de créer à la main cette *HMBR*.


----------

