Problême de disque, bootcamp ne fonctionne pas

[bilballe]

Bonjour a tous, j'ai besoin d'installer windows 10 sur mon Imac actuellement sous Sierra 10.12.1 mais j'ai un problême avec Bootcamp, en effet lorsque je le lance, un message comme ceci apparait:

Bien embêté j'ai essayé de faire un sos sur le disque de mon mac et on me dit cela:

J'avais déja installé windows sur mon mac auparavant sans soucis puis désinstallé, ensuite je n'arrivais plus a le réinstaller car lorsque je lançais le programme d'installation windows de ma clé booté, aucun disque (même le partitionné) ne semblais utilisable alors que j'avais fait comme avant (utilisé bootcamp pour partitioner le disque etc...) et en cliquant partout, j'avais supprimé le disque booté ce qui m'avais enlevé 200Gb d'espace sur mon disque de 1T, grace a l'aide de votre communauté, j'ai récuppéré mon espace mais je pense que le problème est toujours la, seulement caché et c'est a cause ce cela que j'ai des problêmes pour installer windows actuellement...

J'ai donc besoin de vous pour m'aider a résoudre ce problême de disque mais aussi si quelqu'un sais pourquoi lorsque je voulais installais windows, le disque "bootcamp" n'étais pas utilisable.

Merci d'avance.

 

[Deleted member 1099514]

Salut

Que te renvoient dans le terminal :
diskutil list
diskutil cs list

 

[bilballe]

 

[Deleted member 1099514]

Bizarre l'erreur dans ton retour de commande.
Tu pourrais recommencer et donner les retours par copier/coller texte depuis le terminal?

Pour le SOS il faudrait démarrer en mode Recovery (cmd+R lors du boot) et lancer l'utilitaire de disque.
Là faire un SOS sur le disque entier et sur la partition "Macintosh HD"

 

[bilballe]

iMac-de-Jules:~ jules$ diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk0

1: Apple_HFS Macintosh HD 999.3 GB disk0s1

2: Apple_Boot Recovery HD 650.0 MB disk0s2


/dev/disk1 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *31.2 GB disk1

1: DOS_FAT_32 WININSTALL 31.2 GB disk1s1


iMac-de-Jules:~ jules$ diskutil cs list

No CoreStorage logical volume groups found

iMac-de-Jules:~ jules$

 

[Deleted member 1099514]

Si les SOS ne donnent rien tente un :
diskutil resizevolume disk0s1 0b

 

[bilballe]

Le sos en mode recovery ne donne rien et avec la commande on me dit "The new size must be different than the existing size" le probleme de mon bootcamp ne viens peut etre pas de la...

 

[Deleted member 1099514]

Le SOS en mode Recovery te renvoie-t-il toujours l'erreur listée sur la 2ème copie d'écran du post #1 ?

 

[lb44]

Salut ! Ton mac date de quand ? Je sais qu'Apple ne permet pas d'installer Windows 10 et au delà sur les anciens mac (avant 2012 ou 21013).
Sinon pour le reste, c'est peut-être un problème de fragmentation. Ca m'ait déjà arrivé et faut formatter tout le disque...

Ah oui parce que des outils pour defrag macOS ça s'trouve pas facilement...

 

[Locke]

Sinon pour le reste, c'est peut-être un problème de fragmentation. Ca m'ait déjà arrivé et faut formatter tout le disque...

Ah oui parce que des outils pour defrag macOS ça s'trouve pas facilement...

Une habitude sur Windows qui n'existe pas et qui n'a pas lieu d'être sous macOS. Un simple clone permet de faire une défragmentation automatique et ça suffit largement.

Ah oui parce que des outils pour defrag macOS ça s'trouve pas facilement...

Bien sûr que si, mais aucun intérêt.

 

[lb44]

Oui je sais bien qu'elle n'a pas trop de raison d'être sur mac à cause du système de fichier mais ça peut quand même arrivé que le disque de fragmente quand on manipule beaucoup de gros fichiers. La preuve ca m'ait arrivé
Après le truc chiant pour faire la defrag comme tu le dis c'est qu'il faut avoir un disque suffisamment grand pour stocker un clone (chose que je n'avais pas)

Oui je sais qu'il existe des outils de defrag mais je parlais d'outil gratuits
Peut-être que maintenant c'est répondu mais à l'époque (en 2013) ca ne l'était pas et j'ai pas réussi à trouver de soft craqué ^^

 

[Membre supprimé 1060554]

Salut bilballe

Il y a une erreur dans la table de partition GPT (GUID Partition Table). Voici le tableau des partitions qu'elle décrit sur le disque :

/dev/disk0 (internal, physical):
#:                  TYPE NAME              SIZE           IDENTIFIER
0: GUID_partition_scheme                  *1.0 TB         disk0
2:             Apple_HFS Macintosh HD      999.3 GB       disk0s1
3:            Apple_Boot Recovery HD       650.0 MB       disk0s2

et voici ce que tu devrais avoir :

/dev/disk0 (internal, physical):
#:                  TYPE NAME              SIZE           IDENTIFIER
0: GUID_partition_scheme                  *1.0 TB         disk0
1:                   EFI EFI               209.7 MB       disk0s1
2:             Apple_HFS Macintosh HD      999.3 GB       disk0s2
3:            Apple_Boot Recovery HD       650.0 MB       disk0s3

=> il manque donc à l'appel l'ESP (EFI System Partition) de 209 Mo qui doit être présente en position n°1 dans la distribution des partitions d'un disque tablé en GPT. C'est la raison pour laquelle l'«Assistant BootCamp» ne valide pas le partitionnement de ton disque > et pour laquelle l'«Utilitaire de Disque» te signale une erreur dans la carte de partition du disque.

Afin de vérifier si les blocs correspondant à cette partition existent toujours en début de disque, avant la partition Macintosh HD > passe dans le «Terminal» la commande :

sudo gpt show /dev/disk0

et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> 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 derechef ↩︎.

En retour de commande > tu vas voir s'afficher le tableau de la distribution des blocs sur ton disque en : secteur d'amorçage (portant les tables de partitions) > sections (correspondant à des partitions) > bandes (d'espace libre hors partition) > backup (sauvegarde de la GPT d'en-tête) --> peux-tu poster ici ce tableau en copier-coller comme tu l'as déjà fait pour le retour de la commande diskutil list ?

 

[Deleted member 1099514]

Bien vu Maco

Si l'emplacement de l'EFI est toujours disponible :
vérifier dans la liste donnée par la commande :
sudo gpt -r show /dev/disk0
que la première partition débute bien à l'adresse 409640 et non 40.
Dans ce cas il est possible de la recréer depuis la partition Recovery en suivant ceci #28

 

[Membre supprimé 1060554]

Jean

Je n'arrivais pas à voir d'entrée ce qui clochait. Parce que l'attention saute d'emblée de la taille du disque à celle de la partition-Système pour en déduire l'existence ou non d'espace libre en-dessous de la Recovery HD. Et là : la somme de ces 2 partitions correspondait à l'espace du disque. L'échec de ta commande confirmant qu'il n'y avait pas d'espace libre en-dessous.

Je crois que c'est le « cheveu sur la soupe » (l'argument sans rapport à propos de la fragmentation) qui m'a fait une énième fois remonter à l'examen de la table de partition dans un état d'esprit « déconcentré »

> et c'est ainsi que la pièce manquante m'a sauté aux yeux...

Si l'emplacement de l'EFI est toujours disponible, il est possible de la recréer depuis la partition Recovery.

C'est ce que j'avais à l'idée en suggérant de passer la commande gpt. Recréer une petite partition de « type EFI » devrait formellement suffire (même si elle ne recèle pas de binaires dans son volume).

Ce qui encourage dans cette voie est que la partition disk0s1 Macintosh HD se trouve indexée dans la table comme n°2 > et la partition disk0s2 Recovery HD indexée comme n°3 => l'index n°1 de la table est donc toujours réservé à une partition EFI (sans avoir été transféré à la partition qui suit). Il est donc récupérable par une partition EFI recréée (qui en fait doit avoir accidentellement sauté de la table). Le maintien en réserve de cet index n°1 peut être considéré comme une quasi preuve d'existence de blocs

40      409600

disponibles avant la partition-Système. Et le gage qu'à sa recréation > cette partition EFI récupérera bien l'index n°1 attendu > sans quoi, recréée avec un index n°3 en queue de table de partition > elle n'aurait pas été validée par l'«Assistant BootCamp».

=> on peut donc admettre que le problème est résolu (théoriquement).