Windows ne démarre plus (Boot Camp)

[Membre supprimé 1060554]

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]

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).

 

[Membre supprimé 1060554]

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]

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?

 

[Membre supprimé 1060554]

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]

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]

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

 

[Membre supprimé 1060554]

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]

à 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?

 

[Membre supprimé 1060554]

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]

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?

 

[Membre supprimé 1060554]

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]

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]

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").

 

[Membre supprimé 1060554]

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]

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

 

[Membre supprimé 1060554]

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]

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.

 

[Membre supprimé 1060554]

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]

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!