Problème partitionnement Bootcamp pour install W10

IngesonRadio

Membre confirmé
28 Juin 2019
86
3
47
Bonjour,
mon iMac fin 2013 tourne sous Mojave 10.14.5
J'avais une partition Bootcamp jusqu'alors mais que j'ai effacé puisque l'ordinateur ne voulait plus faire booter Windows dessus (écran noir)
J'ai donc effacé complètement la partition Bootcamp pour la réinstaller avec W10.
Problème sur le logiciel Bootcamp, lors du partitionnage pour allocation Espace disque Bootcamp. Le process s'engage puis s'arrête en affichant la prompt suivante :
"Une erreur s'est produite lors du partitionnement du disque. Veuillez exécuter utilitaire de disque pour consulter et corriger l'erreur".
J'ai donc rebooté la machine en Cmd+R, exécuté un SOS disque du HD. Mais rien n'y fait. Je suis au point mort.
Je sais en lisant les nombreux forums que le souci vient du partitionnement apfs, format extrêmement récent.
je vous envoie l'info Terminal de mes disques si jamais vous arrivez à déchiffrer le contenu :

/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk2 121.1 GB disk0s2

/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_APFS Container disk2 3.0 TB disk1s2

/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +3.1 TB disk2
Physical Stores disk0s2, disk1s2
1: APFS Volume Macintosh HD 1.6 TB disk2s1
2: APFS Volume Preboot 51.0 MB disk2s2
3: APFS Volume Recovery 509.7 MB disk2s3
4: APFS Volume VM 2.1 GB disk2s4


En vous remerciant de votre aide .....
 

Fichiers joints

  • Capture d’écran 2019-06-28 à 20.21.58.png
    Capture d’écran 2019-06-28 à 20.21.58.png
    238,8 KB · Affichages: 173
  • J’aime
Réactions: tholei
Bonsoir Ingesonradio

Tu as un iMac avec 2 disques : SSD de 121 Go & HDD de 3 To. Les 2 associés au niveau de leurs partitions principales par un Fusion Drive de type apfs (on sait alors que Mojave - introducteur de ce type apfs de Fusion Drive - est installé). Il y a 1,6 To d'occupation de Macintosh HD. Aucune partition en-dessous de la partition apfs --> n'est présente sur le HDD (le seul disque partitionnable en cas de Fusion Drive).

Une erreur dans l'apfs bloque apparemment la recréation d'une partition BOOTCAMP. Passe la commande :
Bloc de code:
diskutil verifyVolume disk2

  • qui vérifie : le Conteneur apfs > puis ses 4 volumes dans l'ordre d'indexage

Poste l'affichage complet retourné > mais effectue ton coller dans une fenêtre de code par le procédé suivant -->
  • dans cette page de MacGé > presse le bouton
    1555929346-524315-original.png
    ici :
    1555929346-521520-original.png

    menu  : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)
 
Bonjour Macomaniac

je te remercie d'avance pour ton aide. J'ai donc fait ce que tu m'as demandé et je te copie le résultat de l'instruction de vérification :

Bloc de code:
Started file system verification on disk2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the fusion superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking the Fusion data structures
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD was formatted by hfs_convert (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 19
Checking snapshot 2 of 19
Checking snapshot 3 of 19
Checking snapshot 4 of 19
Checking snapshot 5 of 19
Checking snapshot 6 of 19
Checking snapshot 7 of 19
Checking snapshot 8 of 19
Checking snapshot 9 of 19
Checking snapshot 10 of 19
Checking snapshot 11 of 19
Checking snapshot 12 of 19
Checking snapshot 13 of 19
Checking snapshot 14 of 19
Checking snapshot 15 of 19
Checking snapshot 16 of 19
Checking snapshot 17 of 19
Checking snapshot 18 of 19
Checking snapshot 19 of 19
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by hfs_convert (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by diskmanagementd (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by apfs.util (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Finished file system verification on disk2

A toi de jouer, Docteur. Que lis tu dans ces codes ? :)
 
Dernière édition:
Il n'y a aucune erreur dans l'apfs. Mais...

... tu as 19 snapshots : instantantanés du volume Macintosh HD > qui archivent chacun une image de ce volume figée dans le temps > et verrouillent les blocs portant les fichiers correspondants à l'état : "occupé". Même si tu as ensuite supprimé des fichiers qui résidaient sur ces blocs.​

- comme les blocs d'écriture verrouillés par les snapshots peuvent se balader partout dans la partition apfs du HDD (seule susceptible de repartition) > y compris en queue de blocs de cette partition => un repartitionnement est de ce fait impossible. D'ordinaire en effet un mécanisme de clonage interne des écritures des blocs mal placés => sur des blocs de haut de partiiton s'effectue --> afin de ménager une bande continue de blocs libres en fin de partition. Ici --> ce mécanisme est bloqué par les snapshots.​

=> on tient peut-être là la raison du blocage du repartitionnement.

----------

Pour fermer le robinet à snapshots > va à : Menu  > Préférences Système > Time Machine. Décoche la case de l'option : "Sauvegarder automatiquement".

----------

Pour supprimer les snapshots actuels > passe la commande (copier-coller direct) -->
Bloc de code:
sudo tmutil thinlocalsnapshots / 99000000000000 4 ; say 'ENFIN TERMINÉ LA PURGE'

  • à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide
  • la commande supprime en lot les snapshots. Attends d'entendre une voix déclarer : "Enfin ! terminé la purge..." en signal de fin.
----------

Quand c'est fait > passe la commande :
Bloc de code:
tmutil listlocalsnapshots /

  • qui liste les snapshots existants

Est-ce que tu as obtenu un retour ?
 
Oui j'ai obtenu rien du tout sur la dernière instruction
Mais il semble qu'il ait bien purgé les snapshots du Timemachine...
Je devrais avoir obtenu quelque chose ?
 
Alors il n'y a plus de snapshots. Passe la commande :
Bloc de code:
df -H /

  • qui mesure l'occupation du volume Macintosh HD démarré

Poste le retour.
 
Voici le résultat :
Bloc de code:
Filesystem     Size   Used  Avail Capacity iused               ifree %iused  Mounted on
/dev/disk2s1   3.1T   1.5T   1.6T    49% 2152603 9223372036852623204    0%   /
 
Tu as récupéré 100 Go : 1,5 To d'occupation de Macintosh HD contre 1,6 To précédemment.

On va faire un test manuel de repartitionnement. Passe la commande :
Bloc de code:
diskutil ap resizeContainer disk2 2.5t fat32 BOOTCAMP 0b

  • la commande rétrécit le Conteneur apfs du Fusion Drive à 2,5 To > et crée en fin de HDD un volume BOOTCAMP de 500 Go en format FAT-32

Poste l'ensemble de l'affichage retourné.
 
Les nouvelles ne sont pas forcément très bonnes.
Le partitionnement s'est interrompu. Et voici le retour des codes :

Bloc de code:
Started APFS operation
Aligning shrink delta to 621 506 297 856 bytes and targeting a new physical store size of 2 378 876 928 000 bytes
Determined the minimum size for the targeted physical store of this APFS Container to be 1 550 214 758 400 bytes
Resizing APFS Container designated by APFS Container Reference disk2
The specific APFS Physical Store being resized is disk1s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l -S /dev/disk0s2
Checking the container superblock
Checking the fusion superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking the Fusion data structures
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD was formatted by hfs_convert (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by hfs_convert (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by diskmanagementd (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by apfs.util (945.200.129) and last modified by apfs_kext (945.260.7)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Shrinking APFS Physical Store disk1s2 from 3 000 383 225 856 to 2 378 876 928 000 bytes
Shrinking APFS data structures
APFS Container Resize error code is 49157
Error: -69606: A problem occurred while resizing APFS Container structures

A toi, Macomaniac.
 
Un disque de 3 To > dans un attelage Fusion Drive > de type apfs encore => ce n'est pas évident à repartitionner. Peut-être FileVault est-il activé de surcroît ?

- passe la commande :
Bloc de code:
fdesetup status

  • qui affiche le statut de FileVault

Poste le retour.
 
Hello Macomaniac
voici le résultat de commande : FileVault is Off.
Est ce que mon ordinateur ne serait pas trop vieux, ou bien mon disque dur dans un sale état ?
J'ai commencé à clôner mon HD avec Carbon Copy, le process a bloqué au bout de 50 Go de copié. J'ai du redémarrer au bouton.... :( :( :(
Je m'attends à faire table rase de mon disque dur de démarrage.
 
FileVault est désactivé.

Tu peux passer les 2 commandes :
Bloc de code:
diskutil verifyDisk disk0
diskutil verifyDisk disk1

  • qui vérifient les 2 disques

Poste les retours.

Question : tu n'as pas déjà une sauvegarde intégrale des 1,5 To de données de Macintosh HD ?
 
Voici la réponse des vérification de volumes :
Bloc de code:
Started partition map verification on disk0
Checking prerequisites
Checking the partition list
Checking the partition map size
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking Core Storage Physical Volume partitions
The partition map appears to be OK
Finished partition map verification on disk0

Réponse : Non, je suis en train de la faire. J'avais des sauvegardes Time Machine mais je n'ai plus confiance en cette plateforme ... Carbon Copy Cloner est mieux, non ?
 
Oui : les clones de CCC sont très bons. Je n'utilise que des clones faits par ce logiciel.

Mais tu en as pour des heures afin de cloner 1,5 To. Si tu veux > je peux te passer une commande à exécuter dans le Terminal --> qui empêchera ton Mac de dormir pendant le clonage.

Le disk0 est sans erreur.
 
Oui : les clones de CCC sont très bons. Je n'utilise que des clones faits par ce logiciel.

Mais tu en as pour des heures afin de cloner 1,5 To. Si tu veux > je peux te passer une commande à exécuter dans le Terminal --> qui empêchera ton Mac de dormir pendant le clonage.

Le disk0 est sans erreur.
Ah oui je te remercie de me donner la commande.
Et sinon concernant notre affaire de partitionnement ? Quelle est le résultat de ton analyse ?
 
Je peux pas dire pour le repartitionnement.

- j'ai eu un cas très récemment sur les forums qui ressemblait au tien : Fusion Drive apfs dans un iMac avec un SSD de 121 Go et un HDD de 3 To aussi. Dans cet autre cas > les repartitionnements n'arrivaient pas à dépasser des tranches de 200 Go à 300 Go - sans que l'apfs ne comporte d'erreur. Il a fallu supprimer le Fusion Drive par une commande qui reconstruit dans la foulée un Fusion Drive à l'ancienne (type CoreStorage) > puis réinstaller Mojave (ce qui a converti le Fusion Drive à un type apfs). Alors les repartitionnements ont été débloqués popur de grandes tailles.​

Je subodore dans ton cas une pareille défaillance. Qui ne viendrait pas de tes disques > mais de la capacité de l'apfs à gérer un HDD de très grande taille (3 To) dans un Fusion Drive. Si ce Fusion Drive a été créé directement au lieu d'être converti depuis une version CoreStroage. Bref : une logistique boguée de l'apfs.

----------

Comme tu as un énorme paquet de données --> concentre-toi d'abord sur le clonage. Je suppose que la table de partition du disque du DDE est bien GUID ? --> pour que le clone soit démarrable ensuite.

Tu peux passer la commande (copier-coller) :
Bloc de code:
nohup caffeinate -dimsu & killall Terminal

  • la commande donne une impression de "fermeture éclair" du Terminal. Mais ce n'est que la conclusion d'un processus éclair qui consiste : a) à lancer un processus caffeinate qui va empêcher le Mac de dormir à aucun niveau > b) à détacher ce processus du terminal ouvert pour qu'il survive à sa fermture > c) à quitter l'application Terminal et par là le terminal qui était ouvert.
 
Merci à toi pour l'analyse que je partage également.
En revanche la copie est déjà en cours, est ce que t'a commande "fermeture éclair" ne va pas interférer et faire même foirer la copie ? [ Il continue celle qu'il avait commencé hier soir et qui s'était interrompue intempestivement (peut-être à cause de l'économiseur d'écran) ]
 
Pas de problème à passer la commande alors que CCC est en train de cloner. Il n'y a pas d'interférence.