Windows ne démarre plus (Boot Camp)

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.
 
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 ?
 
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)
installation-windows7-uefi-partitions-recovery-38a6a9.png
 
Dernière édition:
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 (Protective_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 (Hybrid_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 Hybrid_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 :
Bloc de code:
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 Hybrid_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 ?
 
  • J’aime
Réactions: The Lynx
Est-ce que tu peux faire une capture d'écran du panneau de l'installateur montrant les partitions choisissables et la poster ici ?
 
Alors voici un nouveau test :

- a) tu passes la commande :
Bloc de code:
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 ?​
 
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 (Protective_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 (Hybrid_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 :
Bloc de code:
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 :
Bloc de code:
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 :
Bloc de code:
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...
 
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
 
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...
 
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à
 
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 :
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 (write) > 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 :
Bloc de code:
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 ?
 
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 :D)
 
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 :
Bloc de code:
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 :
Bloc de code:
diskutil umount force disk0s2

- c) tu démontes le volume BOOTCAMP (lui aussi automatiquement monté) par la commande :
Bloc de code:
diskutil umount force disk0s4

- d) tu appelles l'utilitaire gdisk à ouvrir les tables de partition du SSD par la commande :
Bloc de code:
/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 (= EFI_System_Partition : 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 :
Bloc de code:
diskutil mount disk0s1
qui va te retourner un :
Bloc de code:
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 :
Bloc de code:
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 ?
 
Dernière édition par un modérateur:
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.
 
Bon : pas plus de trace de binaires microsoft que de beurre en broche...

Tu peux lancer l'opération Recovery.
 
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:
DSC09606.webp
J'ai exit le terminal et redémarré depuis pour te faire un retour.
 
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. o_O
 
  • J’aime
Réactions: The Lynx