problème avec bootcamp

hash123

Membre confirmé
22 Décembre 2018
11
0
28
Bonsoir,j'ai un souci avec l'installation de windows 10 a l'aide de bootcamp qui maffiche ce message au debut
"Ce disque de démarrage ne peut pas être partitionné car l’espace y est insuffisant."
Priere de m'aider svp j'en serai entierement reconnaissant
 
Dernière édition par un modérateur:
On va faire ce que l'on peut, mais avant tout il faut toujours commencer par indiquer quel est le modèle exact de Mac que l'on possède, quelle version de Windows on tente de faire l'installation et/ou as-t-elle été téléchargée ?

Que dis /A propos de ce Mac ? Une copie écran de la fenêtre serait la bienvenue. Pour rappel le fichier .iso doit avoir pour nom exact . Tu as lu ce message... https://forums.macg.co/threads/installation-de-windows-10-1803.1310171 ... ?
"Ce disque de démarrage ne peut pas être partitionné car l’espace y est insuffisant."
Ce message est assez clair, à la base tu n'as pas assez d'espace disque dur de libre.

Par curiosité, tu lances le Terminal, tu fais un Copier/Coller de cette commande...
Bloc de code:
diskutil list
...en validant avec la touche Entrée, puis en donnant le résultat.

Petit rappel...
Pour diffuser un rapport EtreCheck ou un retour de commandes via le Terminal dans les forums, dans votre réponse, un clic sur cette icône ⊞, sélectionnez les Balises </> Code, dans la fenêtre qui s’ouvrira faites un Copier/Coller du rapport et/ou du résultat du Terminal, un clic sur Insérer et validez votre réponse.
 
Bonjour , merci pour l'intérêt que vous portez a ma question , voila j'ai un mac book pro mi 2014 et je tente d'installer windows 10
Bloc de code:
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         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Sans titre              187.1 GB   disk1s1
   2:                APFS Volume Preboot                 43.7 MB    disk1s2
   3:                APFS Volume Recovery                517.0 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
 
Bonjour hash

Tu disposes théoriquement de 61 Go d'espace libre dans le Conteneur apfs. Mais il existe peut-être des snapshots (instantanés du volume) qui retiennent à l'état occupé dans le volume les blocs correspondant aux fichiers qu'ils imagent. Pour peu que quelques-uns de ces blocs soient situés en queue d'espace de Conteneur > suppose-le sur les blocs correspondant au 247è Go dans la numérotation des blocs --> alors ce n'est plus 61 Go d'espace que tu as en disponible > mais 4 Go (du 247è Go au 251è Go).

- normalement > quand on demande un repartitionnement et que des blocs sont occupés par des écritures vers la queue d'espace de la partition concernée > un mécanisme clandestin de clonage des fichiers des blocs de queue sur les blocs libres de haut de partition s'effectue > ce qui fait qu'une bande continue de blocs libres se trouve dégagée en bas de partition > qui peut servir à créer une nouvelle partition. C'est un mécanisme de défragmentation interne, en somme. Avec des snapshots verrouillant des blocs de queue de Conteneur apfs --> cette opération est rendue impossible.​

Passe donc la commande (copier-coller) :
Bloc de code:
tmutil listlocalsnapshots /

  • qui liste les snapshots existants

Poste le retour, si retour il y a. On verra si des snapshots sont impliqués dans ton problème.
 
Bonjour ,mais cette commande ne me donne rien comme résultat!

Voila plus précisément le message que je reçois de la part de bootcamp:

Capture d’écran 2018-12-22 à 10.47.05.webp
 
Dernière édition par un modérateur:
Alors aucun snapshot n'existe > qui retienne de l'espace de blocs. Passe la commande expérimentale (copier-coller) :
Bloc de code:
diskutil ap resizeContainer 200g jhfs+ Brol 0b

  • cette commande rétrécit le Conteneur apfs à 200 Go et crée une partition indépendante de 50 Go environ > montant un volume intitulé Brol

Poste l'affichage complet retourné par la commande.
 
Ah pardon ! j'ai omis l'indicateur du disque dans la commande. Voici la commande corrigée :
Bloc de code:
diskutil ap resizeContainer disk1 200g jhfs+ Brol 0b
 
Bloc de code:
Started APFS operation
Aligning shrink delta to 50 790 436 864 bytes and targeting a new physical store size of 200 000 000 000 bytes
Determined the minimum size for the targeted physical store of this APFS Container to be 195 143 176 192 bytes
Resizing APFS Container designated by APFS Container Reference disk1
The specific APFS Physical Store being resized is disk0s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l -S /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Sans titre was formatted by hfs_convert (748.57.19) and last modified by apfs_kext (945.230.6)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
error: btn: invalid btn_btree.bt_key_count (expected 5096547, actual 5096596)
fsroot tree is invalid
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Shrinking APFS Physical Store disk0s2 from 250 790 436 864 to 200 000 000 000 bytes
Shrinking APFS data structures
Shrinking partition
Modifying partition map
Initialized /dev/rdisk0s3 as a 47 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
1 new disk created or changed due to APFS operation
Disk from APFS operation: disk0s3
Finished APFS operation
 
Malgré une erreur constatée dans l'apfs à la vérification préalable -->
Bloc de code:
fsroot tree is invalid

  • l'opération s'est bien effectuée. Passe la commande :
Bloc de code:
diskutil list

  • et poste le tableau des disques --> pour nous le mettre sous les yeux.
 
Bloc de code:
/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         200.0 GB   disk0s2
   3:                  Apple_HFS Brol                    50.7 GB    disk0s3

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +200.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Sans titre              186.3 GB   disk1s1
   2:                APFS Volume Preboot                 43.7 MB    disk1s2
   3:                APFS Volume Recovery                517.0 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
 
Comme tu le vois ici -->
Bloc de code:
   3:                  Apple_HFS Brol                    50.7 GB    disk0s3

  • la création d'une partition de 50,7 Go est supportée > ce qui laisse 12 Go d'espace libre dans le Conteneur apfs. Trop peu à mon sens pour un usage confortable de macOS.

Pour revenir à l'état antérieur en supprimant cette création expérimentale > passe la commande :
Bloc de code:
diskutil eraseVolume free null disk0s3 ; diskutil ap resizeContainer disk1 0b ; diskutil list

  • la commande supprime la partition Brol > récupère son espace au Conteneur apfs > réaffiche le tableau des disques

Poste l'affichage retourné.
 
Bloc de code:
Started erase on disk0s3 Brol
Unmounting disk
Finished erase on disk0
Started APFS operation
Aligning grow delta to 50 790 436 864 bytes and targeting a new physical store size of 250 790 436 864 bytes
Determined the maximum size for the targeted physical store of this APFS Container to be 250 789 408 768 bytes
Resizing APFS Container designated by APFS Container Reference disk1
The specific APFS Physical Store being resized is disk0s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l -S /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Sans titre was formatted by hfs_convert (748.57.19) and last modified by apfs_kext (945.230.6)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
error: btn: invalid btn_btree.bt_key_count (expected 5101564, actual 5101613)
fsroot tree is invalid
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Growing APFS Physical Store disk0s2 from 200 000 000 000 to 250 790 436 864 bytes
Modifying partition map
Growing APFS data structures
Finished APFS operation
/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         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Sans titre              186.5 GB   disk1s1
   2:                APFS Volume Preboot                 43.7 MB    disk1s2
   3:                APFS Volume Recovery                517.0 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
 
Le Conteneur a bien récupéré l'espace. Tout fonctionne sans problème.

Quelle est la taille que tu demandes pour une partition BOOTCAMP ?
 
1: APFS Volume Sans titre 186.3 GB disk1s1
Pour moi ce n'est pas jouable, il ne reste plus que 64 Go de disponible, or si tu as attribues 40 Go pour Windows (ce que je déconseille), il ne reste plus que 24 Go pour macOS qui va très vite se retrouver à l'étroit et incessamment va se bloquer faute de place.
 
Locke est ce que vous voulez dire par ca que je risque d'endommager mon mac si je procède a l'installation de windows ?
Pas de l'endommager, mais de bloquer faute de place dans macOS. Officiellement voilà ce que recommande Apple avec les nouveaux Mac... https://support.apple.com/fr-fr/HT201468 ...soit maintenant un minimum de 64 Go pour la partition Windows. Avant 2015, on peut mettre un minimum de 40 Go selon la version d'Assistant Boot Camp et de la carte mère.

Pourquoi je mets en garde ? Si après une installation de Windows, celui-ci n'occupe qu'environ 8 Go, cet espace va grossir avec le temps et ultra rapidement sans que l'utilisateur ne s'en rende compte. Après utilisation des logiciels intégrés d'une version de Windows, tous les fichiers .dll qui sont inclus dans chaque application seront copiés en 1, 2, 3, 5 voire plus dans le dossier WinSxS, car Microsoft estime que c'est la meilleure méthode pour un démarrage rapide de Windows. Que dire lorsque des jeux ou gros logiciels sont installés en plus ? Ce dossier continuera de gonfler, gonfler, gonfler...

A la base beaucoup d'utilisateurs ont une méconnaissance de macOS, mais c'est encore pire avec Windows ! Non content d'avoir ce dossier WinSxS, la moindre mise à jour officielle provenant de chez Microsoft sera téléchargée et stockée. Quand j'entends stocker, après installation cette version 1803 elle ne sera pas effacée, ce sera à l'utilisateur de décider ou pas de la garder, mais beaucoup d'utilisateurs de Windows ne savent même pas que c'est possible !

Pour exemple, j'ai fait la mise à jour de la version de Windows 1803 vers la 1809 sans aucun problème. Bien, le problème est que tous les anciens fichiers de la version 1803 sont stockés dans un répertoire/dossier bien spécifique. Microsoft n'est pas très prolixe pour dire comment effacer définitivement ces fichiers si la nouvelle version convient et surtout comment effacer définitivement ces fichiers ! Il y a bien un utilitaire qui permet d'effacer pas mal de fichiers et lorsqu'on sélectionne les anciens fichiers, pour exemple de la version 1803, ce seront entre 20/25 Go qui seront effacés d'un seul coup !

Il faut donc bien imaginer la place totale que cela représente. Si à la base après utilisation/installation des logiciels Windows 1803 et tiers, que le disque dur occupe disons 25 Go, si on fait une mise à jour majeure vers la 1809, cet espace fait un bond vers 45/50 Go d'occupation. Soit on a suffisamment d'espace pour faire cette mise à jour, soit elle ne se fera pas et on va encore pester en accusant Apple et Microsoft !
 
Merci bcp a vous deux pour ces informations très utiles , seulement voila par une tentative inespéré j'ai tente de supprimer une machine virtuelle qui occupait 40g et je m'aperçoit que le problème est résolu en raison peut-être de 144 go libéré ,du coup je me demande est ce qu'il est temps de procéder a l'installation de windows 10?
Cordialement
 
j'ai tente de supprimer une machine virtuelle qui occupait 40g et je m'aperçoit que le problème est résolu en raison peut-être de 144 go libéré ,
Voilà surement l'explication du taux d'occupation élevé de ton disque dur. Si oui, une machine virtuelle se met directement à la Corbeille, tu peux laisser le logiciel Parallels Desktop où VMware en place, ce ne sont pas eux qui prennent de la place.

Si tu as bien supprimé une machine virtuelle, relances le Terminal et recommence ce qui a été déjà été demandé...
Bloc de code:
diskutil list
...histoire de voir ce que tu as récupéré en taille de disponible. ;)