# Partition Bootcamp disparue et impossible à supprimer



## Argusis (9 Février 2015)

Bonsoir à tous,

Je rencontre actuellement quelques problèmes avec *BOOTCAMP.*
Depuis quelque temps déjà je ne l'utilisais plus car Windows ne démarrait plus à la suite d'une mise à jour.

Hier, je lance la partition *Recovery* pour essayer de régler le problème.
Je voulais *restaurer* l'image de ma partition Bootcamp avec la *clé USB *contenant W7 mais de toute évidence je n'y suis pas arrivé.

J'ai donc abandonné et redémarré et surprise la *partition BOOTCAMP à disparue* !! Aussi bien dans le finder qu'au démarrage que dans l'utilitaire de disque.

Donc je me dis que je vais utiliser l'*assistant bootcamp pour la supprimer*, puisque je ne peux la trouver. Et non ça ne fonctionne pas j'ai ce message : *"votre disque ne peut être restauré sur une partition simple".*

Voilà et dans l'histoire ma partition *Mac OS X n'a pas regagné en volume.* J'ai donc perdu 120GO de disque dur. Si ce n'est que c'est de l'espace libre (je ne peux agrandir ma partition mais je peux en créer une autre).

Donc j'ai plusieurs questions :
- Que faire ? 

- Est-il possible que la partition BOOTCAMP existe toujours, mais fusionnée (ou sous forme de dossier) dans celle de MAC OS X. Puisque l'assistant me propose de la supprimer (il pense qu'elle existe donc) ?


Merci à tous, tout ça me dépasse


----------



## Deleted member 1099514 (10 Février 2015)

Salut

Que revoie depuis un terminal la commande:
*diskutil list
*
@+


----------



## macomaniac (10 Février 2015)

Salut *Argusis* - dont les cent yeux ne parviennent pas à apercevoir une Partition BootCamp drôlement fûtée dans l'art de la dissimulation






 ☜ 
	

	
	
		
		

		
		
	


	




Avec cet exorde mythologique, bienvenue en "_argutie_" : le terrain verbal favori du facétieux *macomaniac*...

Je pense que l'espace correspondant à la Partition BootCamp existe bien toujours "en soi", mais que plusieurs événements le rendent graphiquement invisible actuellement :


lorsque tu démarres ton Mac avec l'option 'alt' qui affiche l'écran de choix des disques de démarrage possibles, il faut savoir que seuls les volumes qui supportent un Système de fichiers (apparemment) démarrable se trouvent affichés --> si tes manœuvres à partir de la «Recovery HD» ont affecté (voir supprimé) le filesystem de Windows au point qu'il n'apparaît plus démarrable, alors le volume correspondant n'est pas affiché comme disque de démarrage potentiel ;


si corrélativement le volume de cette partition ne _monte _plus au démarrage du Mac, alors aucune image-disque de volume ne s'affiche bien évidemment sur le Bureau de session et ton «Utilitaire de Disque» (dont je soupçonne l'option "secrète" : _Déboguer_ de n'avoir pas été activée) ne "voit" rien pour la même raison qu'il n'aperçoit pas en mode standard la «Recovery HD» : volume _non-monté_ au démarrage.
♤
​Pure spéculation de ma part qui, pour compliquer à plaisir ce que les bons esprits protestent toujours devoir être la belle _simplicité_ du réel et qui s'avère toujours l'_imbroglio_ du réel, pousse un appendice sur le terrain de l'_argutie philologique_ : l'intrigant message "votre disque ne peut être restauré sur une partition simple". Je te soupçonne de lire : votre "Système-Windows" ne peut être restauré sur une "Partition-BootCamp" indépendante, ce qui t'amène à te demander où a bien pu passer ladite partition qui manifestement n'a pas été agglutinée à celle de l'OS (car la taille du volume de ce dernier n'a pas augmenté) et qui pourtant a tout l'air de ne plus exister non plus en mode indépendant (d'où ton imagination d'une sorte de "poche secrète" dans le volume d'OSX où existerait un dossier Partition-BootCamp --> impossible : s'il existait, il ajouterait l'équivalent de 120 Go à la taille du volume de l'OS).

Je pense que l'indication-clef est la suivante : «_J'ai donc perdu 120GO de disque dur. Si ce n'est que c'est de l'*espace libre* (je ne peux *agrandir ma partition* mais je peux en *créer une autre*)_». Je suppose que c'est là ce que montre l'image-graphique que donne l'«Utilitaire de Disque» du dispositif des partitions du disque de ton Mac : tu aperçois la partition massive d'OSX (sans apercevoir la petite partition existante de la «Recovery HD» parce que le logiciel n'est pas _débogué_), et en-dessous, tu dois voir un espace _grisé_ déclaré "_espace libre_" correspondant à la Partition BootCamp antérieure.

Lorsque tu as demandé à l'«Assistant BootCamp» de supprimer ta Partition-BootCamp et de la ré-agréger au volume de l'OS (ce qu'il est capable de faire de manière régulière), il n'a pas obtempéré comme tu l'espérais : il a bien *supprimé* la Partition-BootCamp en détruisant le Système de fichiers de Windows et en résiliant le statut de partition indépendante de cette Partition-BootCamp, mais il n'a pas complété son opération en recollant l'espace correspondant au volume d'OSX comme attendu. Non. Au lieu de cela, il a laissé en plan à l'emplacement de la ci-devant Partition-BootCamp un '_espace libre_' (Free Space) d'une taille équivalente (120 Go) et il a abdiqué dans son entreprise en déclarant : "votre disque ne peut être restauré sur une partition simple" - ce qui, dans le contexte que je viens de brosser, doit signifier : je ne peux pas restaurer le partitionnement du disque de votre Mac en fusionnant l'espace de la ci-devant Partition-BootCamp à celle d'OSX pour donner une *partition simple unique*. Et, donc, laissant tomber ses outils, il s'est défilé comme un tire-au-flanc en laissant tout en chantier. C'est l'histoire du verre à ½ plein et à ½ vide : à ½ plein, car la moitié de la tâche a été remplie (suppression de la Partition-BootCamp), mais à ½ vide, car la tâche n'a pas été remplie complètement (agrégation à la Partition-OSX).

♧​
La question est alors : _pourquoi_ dette abdication en cours de route? Se pourrait-il que ce soit dû à la présence intercalaire de la partition de récupération «Recovery HD» qui, pour n'être pas graphiquement visible, n'en existe pas moins *entre* la partition d'OSX et celle de la ci-devant Partition-BootCamp? - Non, car l'«Assistant BootCamp» dispose d'un programme spécial lui permettant de transférer l'espace libéré d'une Partition-BootCamp que l'on veut supprimer, "par-dessus la tête" de la partition intercalaire de la «Recovery HD», pour le re-coller au volume d'OSX. Ce n'est donc pas par refus du "saute-mouton" que «BootCamp» a abdiqué.

Alors _pourquoi_? Voici ma supputation : il existe sous «Yosmite 10.10» une *inconsistance logique majeure* qui met en contradiction la *capacité* de l'«Assistant BootCamp» à ré-agréger une Partition-BootCamp supprimée au volume d'OSX et le *format* que l'installateur de «Yosemite» s'obstine à greffer sur la partition d'OSX avant même l'écriture du filesystem et/ou que l'option d'activer «FileVault-2» sur le volume d'OSX greffe de la même façon sur cette partition (quand il ne s'agit pas de la présence d'un Fusion Drive) --> il s'agit du format CoreStorage qui crée un artefact logique : la construction d'un Groupe de Volumes Logiques qui, dès lors qu'il existe à l'emplacement de la partition d'OSX, verrouille litéralement le partitionnement du disque. L'«Assistant BootCamp» à qui on demande la suppression-réagrégation d'une Partition-BootCamp au volume d'OSX butte sur ce format CoreStorage comme contre un mur en béton et couramment la conséquence est la production d'un "déchet" : le virement de la ci-devant Partition-BootCamp au statut de Free Space (espace libre hors partitionnement actuel) sans ré-agréagation au volume verrouillé logiquement d'OSX.

[Sachant que le Volume Logique du format CoreStorage est rejeté uniquement à partir d'un Disque Physique Virtuel qui a été greffé sur la partition d'accueil (/dev/disk0S2), alors ce Disque Physique Virtuel qui sert de support exclusif étant inextensible, le Volume Logique qu'il rejette - où est installé l'OS - est lui aussi inextensible.]

♡​

Ayant donné carrière à ma faculté d'_argutie spéculative_, il serait temps de la soumettre à l'épreuve expérimentale. Je te propose 3 outils pour ce faire :



Va à : _Applications/Utilitaires_ et lance le «Terminal» --> dans le fenêtre qui s'affiche, fais un copier-coller direct de la ligne :
	
	



```
defaults write com.apple.DiskUtility DUDebugMenuEnabled 1
```
et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande), puis quitte le «Terminal» et re-démarre ton Mac. Lance à présent l'«Utilitaire de Disque» --> tu aperçois un nouveau menu dans la barre de menus supérieure du logiciel (la commande opère son démasquage) : _Déboguer_--> déroule ses sous-menus et coche l'option : _Afficher chaque partition_ (en bas) --> désormais ton «Utilitaire de Disque» "voit" toutes les partitions des disques attachés à un moment donné au Mac, qu'elles soient visibles ou invisibles, que les volumes soient montés ou non montés.


Relance le «Terminal» et passe la commande : 
	
	



```
diskutil list
```
 --> peux-tu en poster ici le résultat? Cette commande demande l'affichage du partitionnement complet du disque du Mac (et de tout autre disque attaché) --> si ma conjecture est juste, tu as un format Apple Core_Storage sur la partition /dev/disk0s2 où est installé OSX.


Enfin, toujours dans le «Terminal», passe la commande 
	
	



```
diskutil cs list
```
 --> peux-tu là encore poster le résultat ici? Toujours si ma conjecture est valide, tu obtiens en réponse : Apple Corestorage Logical Volume Groups : 1 found suivi d'un imposant tableau décrivant l'architecture du Groupe de Volumes Logiques avec notamment l'information critique : s'il est ou non revertible (réversible).
♢
​Je soupçonne ton problème loin d'être résolu à cause de la partition de la «Recovery HD» en /dev/disk0s3 qui, l'«Assistant BootCamp» ne pouvant plus servir à présent qu'un filesystem Windows n'existe plus sur une Partition-BootCamp, ne peut plus être "shuntée" par une opération "saute-mouton" simple permettant au free space correspondant potentiellement à une partition /dev/disk0s4 (que tu peux t'amuser à re-créer par l'«Utilitaire de Disque») d'être transféré dynamiquement "par-dessus sa tête" au volume de l'OS en /dev/disk0s2 (l'«Utilitaire de Disque», non plus que la commande diskutil dans le «Terminal», n'ont les ressources pour "passer par-dessus la tête" de la «Recovery HD» sans opérer sa suppression au passage). Mais chaque chose en son temps, n'est-ce pas? 
	

	
	
		
		

		
		
	


	




♘​


----------



## Argusis (10 Février 2015)

Merci pour ta réponse macromaniac qui est fort intéressante, et merci à jeanjd63 qui en avait anticipé un résumé 

*Je voudrais tout d'abord ajouter deux petits détails :*
- Je suis sur Moutain Lion 10.8.5 (si cela à son importance)
- Je pouvais déjà voir (avant toute manip) la partition disk04 dans l'utilitaire, ainsi qu'au démarrage et qui correspond à ma Recovery.

*Voici les résultats obtenus suite à la manipulation :*
1ère étape :
Je vois désormais les 4 partitions que l'on retrouve à l'étape 2. Seul OS X est montée.

2ème étape et 3ème étape :






Donc comme je m'y attendais, pas trace de BOOTCAMP.

Edit : Le problème n'est pas résolu, étant nouveau sur le forum je ne pensais pas que le bouton "meilleur réponse" changeait le statut de ma question.


----------



## bompi (10 Février 2015)

macomaniac a dit:


> <...>





macomaniac a dit:


> La question est alors : _pourquoi_ *dette *abdication en cours de route?
> <...>


Un _lapsus calami_ [ou un _lapsus clavium_] dû à la sonorité grecque du pseudo de notre camarade ?

On déménage dans Ouinedoze sur Mac, parce que c'est là que les problèmes de Bootcamp doivent être (bien) traités.


----------



## Argusis (10 Février 2015)

Merci, désolé pour l'erreur de rubrique


----------



## Deleted member 1099514 (10 Février 2015)

@Argusis 

Finalement tu en es où? Résolu ou pas? espace récupéré ou pas?

@+


----------



## macomaniac (10 Février 2015)

Mon hypothèse de la présence d'un format CoreStorage sur la partition d'OSX (la /dev/disk0s2 : volume Macintosh HD) pour expliquer l'échec de l'«Assistant BootCamp» à supprimer/réagréger le Partition-BootCamp est donc infirmée (tu es sous «Mountain Lion 10.8» : autant dire une ère édénique qui ignorait les méfaits du CoreStorage





). La raison du plantage semble destinée à demeurer obscure...

Mais n'empêche que tu en subis une conséquence amusante drastique : le brutal rétrécissement d'un volume _Windows_ de 120 Go à un maigrichon _Microsoft Basic Data_ de 16 Go. D'où la question : mais où sont donc passés mes 104 Go qui n'apparaissent plus nulle part? 
	

	
	
		
		

		
		
	


	




Puisque j'ai commencé dans ce fil par des conjectures fantasques, pourquoi m'arrêter en si bon chemin? Je suppose que ton _Microsoft Basic Data_ en /dev/disk0s4 est un petit volume au format ntfs totalement inservable en l'état, et que les 104 Go disparus constituent un Free Space hors partitionnement, mais qui pourraient s'y ré-inscrire en queue de peloton si l'on demandait un re-dimensionnement du volume _Microsoft Basic Data_ en /dev/disk0s4 pour le faire s'augmenter de tout l'espace libre disponible. L'inconvénient étant qu'aussi longtemps qu'un volume est au format ntfs, il est insusceptible de re-dimensionnement.

Tu vois ce qui te reste à faire? 1° convertir le volume _Microsoft Basic Data_ en /dev/disk0s4 dans un format susceptible de re-dimensionnement, càd. jhfs+ (Mac OS étendu journalisé) ; 2° re-dimensionner ce volume au maximum qu'il est susceptible de récupérer, càd. l'augmenter de tout l'espace libre disponible.

♤​
Pour ce faire, je te propose de passer 2 commandes dans le «Terminal» garanties sans danger pour le volume de ton OS (Macintosh HD en /dev/disk0s2) non plus que pour ta partition de récupération (Recovery HD en /dev/disk0s3) -->







d'abord, tu fais un copier-coller dans la fenêtre du «Terminal» de : 
	
	



```
sudo diskutil eraseVolume jhfs+ Sans\ Titre /dev/disk0s4
```
 et ↩︎ --> 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 ↩︎ --> cette commande demande l'effacement du petit volume _Microsoft Basic Data_ de 16 Go au format ntfs sur /dev/disk0s4 et son remplacement par un volume de la même taille, intitulé Sans Titre et au format jhfs+ autorisant les re-dimensionnements --> tu devrais en retour de commande voir s'afficher progressivement quelque chose ressemblant à ce qui suit : 
	
	



```
Started erase on disk0s4 Microsoft Basic Data
Unmounting disk
Erasing
Initialized /dev/rdisk0s4 as a 16.0 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Finished erase on disk0s4 Sans Titre
```


Au réaffichage de l'invite de commande : camille:~ Camille$, tu fais alors un copier-coller de :
	
	



```
sudo diskutil resizeVolume /dev/disk0s4 R
```
 et ↩︎ --> dans les 5' suivant une première authentification pour une commande sudo, tu reste de droit sudoer et n'a pas besoin de redonner ton mot-de-passe pour de nouvelles commandes sudo --> cette commande demande l'extension rétrograde du volume Sans Titre de 16 Go en /dev/disk0s4, viré au format jhfs+ qui permet son extensivité, à tout le Free Space potentiellement disponible (option R) --> en retour de commande, tu devrais voir progressivement s'afficher : 
	
	



```
Started partitioning on disk0s4 Sans Titre
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume new appears to be OK
File system check exit code is 0
Resizing
```


Si tu termines en repassant la commande : 
	
	



```
diskutil list
```
 tu devrais obtenir en retour de commande quelque chose comme : 
	
	



```
/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:                  GUID_partition_scheme            *500.1 GB   disk0
1:                        EFI EFI                     209.7 MB   disk0s1
2:                  Apple_HFS Macintosh HD            349,2 GB   disk0s2
3:                  Apple_Boot Recovery HD            650.0 MB   disk0s3
4:                  Apple_HFS Sans Titre              120.0 GB   disk0s4
```



♧​

☞ si tu pouvais confirmer qu'il en bien désormais ainsi, tu n'aurais franchi que la 1ère étape de la fin de tes ennuis, parce que la partition «Recovery HD» en /dev/disk0S3 fait obstacle, en l'état, à toute ré-agrégation *directe* des 120 Go de «Sans Titre» en /dev/disk0s4 à la partition maîtresse de l'OS : Macintosh HD en /dev/disk0s2. 

Mais comme le disait toujours _Rudyard Kipling_ : «C'est là une autre histoire» (demandant d'écrire un nouvel épisode)... 
	

	
	
		
		

		
		
	


	




♡​


----------



## Argusis (10 Février 2015)

Encore merci pour cette réponse rapide et plus que sur mesure.

J'ai donc effectué chaque étape et *j'ai obtenu le résultat attendu à chaque fois*.

J'ai donc désormais ceci dans mon _Utilitaire de disque_ :


Bloc de spoiler: Screen











La partition _Sans Titre_ est visible dans le_ Finder_.


----------



## Deleted member 1099514 (10 Février 2015)

Il te suffit de renommer ta partition "Sans Titre" en Data ou autre et tu peux l'utiliser pour y ranger tes fichiers (photos, documents etc...)


----------



## Argusis (10 Février 2015)

Oui, c'est une possibilité.

Mais j'aimerai quand même essayer de "réparer" tout le désordre, induit par ma mauvaise manipulation, afin de pouvoir recréer une partition BootCamp si besoin.
Puisque l'état actuel du disque ne permet par à l'assistant BootCamp de supprimer/installer windows.


----------



## Deleted member 1099514 (10 Février 2015)

Si tu supprimes la partition "Sans nom" et tu lances l'assistant Boot Camp, tu ne peux pas créer une partition BootCamp?


----------



## Argusis (10 Février 2015)

Je ne pense pas que cela soit aussi simple d'après macomaniac :


macomaniac a dit:


> ☞ si tu pouvais confirmer qu'il en bien désormais ainsi, tu n'aurais franchi que la 1ère étape de la fin de tes ennuis, parce que la partition «Recovery HD» en /dev/disk0S3 fait obstacle, en l'état, à toute ré-agrégation *directe* des 120 Go de «Sans Titre» en /dev/disk0s4 à la partition maîtresse de l'OS : Macintosh HD en /dev/disk0s2.


----------



## Deleted member 1099514 (10 Février 2015)

Ben faut quand même essayer 

En fait ce qui serait compliqué, c'est d'ajouter l'espace libéré à la partition Mackintosh HD car entre l'espace libre et cette partition tu as la partition de recovery.
Mais si le but est de recréer une partition bootcamp ça doit pouvoir se faire.

@+


----------



## macomaniac (10 Février 2015)

Ni l'«Utilitaire de Disque» (qui ne fait que piloter graphiquement le programme UNIX diskutil), ni ce même programme diskutil invoqué en ligne de commande dans le «Terminal», ne possèdent les ressources permettant d'opérer un "saute-mouton" par-dessus la tête d'une «Recovery HD» intercalée, d'un volume situé "après" elle (dans la série numérotée des devices) à un volume situé "avant" elle (celui de l'OS).

Il faut donc chercher à procéder autrement. On peut recourir à un 3è terme : un DDE, sur lequel on commence par cloner le volume de l'OS + celui de la «Recovery HD» (utiliser le logiciel «Carbon Copy Cloner» pour cela), avant re-démarrage sur le clone, re-partionnement à 1 partition principale du disque du Mac par l'«Utilitaire de Disque» du clone, puis rétro-clonage par «CCC», logiciel capable non seulement de recopier l'OS sur la nouvelle partition principale du disque (/dev/disk0s2), mais aussi de créer une mini-partition à la suite (en /dev/disk0S3) pour rétro-cloner dessus la «Recovery HD». À l'arrivée, 3 partitions : 1 = EFI, 2 = OSX, 3 = RECOVERY et tout baigne.

Oui mais : où est la _satisfaction de l'esprit_, là-dedans, de pouvoir opérer sans va-et-vient par un auxiliaire externe, mais en mode purement interne au disque du Mac - je le demande? Je te propose donc, dans ce qui suit, une méthode purement _logique_ qui implique l'utilisation d'un _outil logique_ ésotérique : le programme dmtest. 

Fut un temps, en effet, où Apple proposait un utilitaire toujours téléchargeable : le ☞Lion Recovery Update☜ qui permettait de créer sur le disque interne d'un Mac qui en aurait été privé une «Recovery HD» _sui generis_. Il s'agit d'un paquetage composite, impliquant notablement le .dmg du Système de la «Recovery HD 10.7» (qui bien évidemment ne correspond pas aux attentes d'un utilisateur de «Mountain Lion» et >).

Mais, bien caché dans les replis du paquetage, se trouve un programme binaire, Apple_natif, qui est précisément le programme désiré pour générer une partition «Recovery HD» de 650 MB et faire écrire les fichiers-système correspondants, pour autant qu'on fournisse à l'exécutable les ressources attendues et qu'on l'invoque avec les options adéquates (malheureusement ce binaire n'est pas documenté par un man).

J'ai chargé dans le dossier public de ma «DropBox» sous forme zippée ce programme Appel_natif dmtest que j'ai extrait à l'origine du «Lion Recovery Update» toujours en téléchargement légal et gratuit depuis les serveurs Apple. Je te propose dans ce qui suit d'utiliser ses services pour régler ton problème de partitionnement de disque, par copie des ressources requises de ta «Recovery HD» sur ton Bureau de session, re-partitionnement dynamique supprimant à la fois tes volumes «Recovery HD» et «Sans Titre» pour les ré-agréger à celui de l'OS sans danger pour ce dernier, et enfin re-création grâce à dmtest d'une partition de «Recovery HD» avec installation de son dossier de _boot _: com.apple.recovery.boot (avec quelques fioritures logiques chemin faisant)... [testé de nombreuses fois, en mode _live_, sur mon Mac, sans sauvegarde préalable, avec plein succès].

♤​

Télécharge le binaire Apple que j'ai chargé sous forme zippée dans le dossier public de ma DropBox : ☞dmtest☜ Arrange-toi pour que ce fichier exécutable dézippé se retrouve *absolument* sur ton *Bureau* : petite icône anthracite avec le sigle exec inclus et l'intitulé subalterne : dmtest . Une fois fait, relance ton vieil ami le «Terminal».


Commence par saisir : 
	
	



```
sudo su
```
 et ↩︎ --> password --> ↩︎ --> tu es désormais en mode sh-3.2# (droits root continus).


copie-colle à présent  : 
	
	



```
mv ~/Desktop/dmtest /bin/dmtest
```
et ↩︎ --> déplacement du binaire : dmtest dans /bin.


À présent : 
	
	



```
chown 0:0 /bin/dmtest
```
 et ↩︎ --> rétablissement des accédants au binaire à root:wheel.


Puis : 
	
	



```
diskutil mount /dev/disk0s3
```
 et ↩︎ --> montage du volume de la «Recovery HD» non monté par défaut.


Enchaîne par : 
	
	



```
cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg ~/Desktop && cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist ~/Desktop
```
 et ↩︎  (déroule la fenêtre d'affichage pour sélectionner toute la commande) --> recopie sur le Bureau de session des 2 ressources clés pour la recréation d'une «Recovery HD» : le fichier BaseSystem.chunklist et le disque-virtuel BaseSystem.dmg à partir du volume monté de la «Recovery HD». Sois un peu patiente. Il y a environ 500 MB à copier. Attends le ré-affichage de sh-3.2# avant d'enchaîner [Ne t'inquiète pas si tu ne vois pas le .dmg : il est graphiquement invisible mais bien présent à la fin].


Suite : 
	
	



```
chown 0:0 ~/Desktop/BaseSystem.dmg && chown 0:0 ~/Desktop/BaseSystem.chunklist
```
 et  ↩︎ --> rétablissement des accédants root:wheel sur les 2 ressources copiées sur le Bureau (au cas où...).


Drastique : 
	
	



```
diskutil mergePartitions jhfs+ Macintosh\ HD /dev/disk0s2 /dev/disk0s4
```
 et ↩︎ --> ré-agrégation au volume de l'OS de la partition «Recovery HD» ainsi que de la «Sans Titre», en mode conservateur des données de la partition réceptrice de l'OS (/dev/disk0s2) et destructeur des partitions additives (/dev/disk0s3 & /dev/disk0s4). C'est ce qu'on appelle «brûler ses vaisseaux» . Sois patiente encore mais pas longtemps : le re-partitionnement en mode 'live' s'effectue. Il n'y a plus que 2 partitions sur ton disque : n°1 = EFI, n°2 = OSX.


Re-création : 
	
	



```
/bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
```
et  ↩︎ --> invocation du binaire dmtest pour qu'il repartitionne le volume de l'OS (point de montage /) en re-créant une «Recovery HD» de 650 MB avec les ressources d'écriture des 2 éléments copiés sur le Bureau (double option _booléenne_ : 0 0 de vérification du .dmg). Sois patiente, la plus patiente ici --> tu as du moins du spectacle  car ça trime dur comme le signalent les lignes d'affichage kilométriques dans la fenêtre du «Terminal». Attends absolument le retour de l'invite de commande : sh-3.2# sans toucher à rien.


Nettoyage : 
	
	



```
rm ~/Desktop/BaseSystem.dmg && rm ~/Desktop/BaseSystem.chunklist
```
 et  ↩︎ --> suppression des deux ressources copiées sur le Bureau.


Il ne te reste plus qu'à faire un : 
	
	



```
diskutil list
```
 et ↩︎ --> et je te prédis que l'affichage en réponse est :



```
/dev/disk0
#:            TYPE NAME                   SIZE       IDENTIFIER
0:            GUID_partition_scheme       500,1 GB   disk0
1:            EFI EFI                     209.7 MB   disk0s1
2:            Apple_HFS Macintosh HD      499 GB     disk0s2
3:            Apple_Boot Recovery HD      650.0 MB   disk0s3
```



--> mission accomplie.





​


----------



## Argusis (10 Février 2015)

Merci pour la réponse. *Je rencontre cependant un problème.*

En copiant collant chaque commande et en ayant bien mis le fichier "dmtest" (déjà dézippé au téléchargement) sur mon bureau j'ai ce message :

"camille:~ Camille$ sudo su
Password:
sh-3.2# mv ~/Desktop/dmtest /bin/dmtest
mv: rename /var/root/Desktop/dmtest to /bin/dmtest: No such file or directory
sh-3.2# chown 0:0 /bin/dmtest
chown: /bin/dmtest: No such file or directory"

Et du coup à l'étape 9 j'ai ça aussi :

"sh-3.2# /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
sh: /bin/dmtest: No such file or directory
sh-3.2# "

Le problème viendrait-il d'une erreur d'interprétation de la consigne (j'ai téléchargé le fichier et glisser/déposer sur le bureau) ?


----------



## Deleted member 1099514 (11 Février 2015)

Salut

Il faut remplacer la commande :

*mv ~/Desktop/dmtest /bin/dmtest*
par
*mv  /Users/*_*ton_user/*_*Desktop/dmtest   /bin/dmtest       *_(en remplaçant bien entendu *ton_user* par le nom réel)_

@+


PS: La procédure donnée par macomaniac ne te permettra pas de recréer une partition BootCamp.
Elle te permet de réorganiser ton disque en additionnant à ta partition Macintosh HD l'espace libéré par la suppression (accidentelle ?) de ta partition bootcamp.


----------



## macomaniac (11 Février 2015)

[Pendant que je m'échinais matutinalement sur ma prose, *jeanjd63*





 a parfaitement aperçu la _boulette_ dont je m'étais rendu coupable 
	

	
	
		
		

		
		
	


	




. Mais comme je le décortique ci-dessous, *Argusis* ayant vaillamment passé la totalité des commandes que j'ai préconisées, il est trop tard pour des rattrapages "en interne" - d'où l'apport "en externe" que je propose... 
	

	
	
		
		

		
		
	


	




]

Bonjour *Argusis*.

J'ai toujours été frappé par cette affirmation de _Descartes_ : «La précipitation est la source de toutes les erreurs». Il entend par "précipitation", un emportement de la _Volonté_ qui nous fait affirmer des idées avant d'en avoir inspecté suffisamment la _Validité Intellectuelle_. Parce que voulons le "Meilleur" _tout de suite_, nous ne prenons pas suffisamment le temps de _vérifier_ les idées que nous nous faisons de ce "Meilleur". En somme, nous avons plus de _Volonté_ que d'_Entendement_, par suite le désir du _Bien_ domine le souci du _Vrai_. 

Eh bien ! Dans cette partie de la journée (passé midi) où mon attention intellectuelle fait progressivement naufrage (je suis du matin, et même de l'aube), j'ai nonobstant _voulu _te tirer d'affaire _sans attendre_. J'ai donc commis une bévue de précipitation (qui fera sourire Maître *bompi* quand il me lira). 

Pour te faciliter la tâche en ne préfixant pas chaque commande de sudo, je t'ai proposé d'entrée de jeu par sudo su de te loger rien moins qu'en shell : root de manière à détenir a priori en continu le privilège des droits du Super Administrateur Système. Mais, par routine d'utiliser le tilde : ~ dans le «Terminal» comme désignation de l'utilisateur admin en tant qu'opérateur des commandes, j'ai fait _comme si_ ~/Desktop valait comme _chemin relatif_ à ton Bureau, ce qui n'eût été vrai que si tu étais restée l'opératrice admin : Camille$ dans le shell. Or, à la suite de sudo su, il n'en était plus rien, car c'était désormais sh-3.2# l'opérateur du shell, c'est-à-dire l'utilisateur : root. 

Or root possède (comme tout utilisateur) un dossier de compte qui est son dossier de départ. Mais ce dossier n'est pas localisé dans le répertoire ordinaire des /Users comme les dossiers de comptes des utilisateurs courants de l'OS ; il réside, au contraire, à l'adresse : /private/var/root, càd. dans un répertoire invisible protégé. Par conséquent, toute commande que je t'ai donnée où se trouvait inscrit : ~/Desktop en départ de chemin relatif à l'utilisateur, tandis que par précipitation d'esprit je me la figurais désigner le Bureau de l'utilisatrice admin : Camille parce que c'est l'ordre courant des choses dans le «Terminal» ; en réalité, l'utilisateur actuellement opérant se trouvant être sh-3.2#, ne pouvait que désigner en chemin relatif le Bureau de  root, càd. abréger l'adresse : /private/var/root/Desktop.

Cette _bévue _(digne des _boulettes_ de _Gaston Lagaffe_ - lequel, sous la plume du génial dessinateur _Franquin_, incarne mieux que quiconque cet anti-héros _cartésien_ : celui qui pèche par précipitation à vouloir le bien sans prendre le temps d'en avoir une idée exacte) a eu, puisque tu as suivi mes 11 commandes en m'accordant ta confiance, des conséquences plus ou moins fâcheuses sans heureusement aucune d'irrattrapable. 

♤​
Puisque ton pseudo annonce l'aptitude d'*Argus* à scruter les _arguties_ d'autrui, voici donc de quoi satisfaire ce talent :



● La commande n°3 : mv ~/Desktop/dmtest /bin/dmtest était forcée de planter, puisque le fichier dmtest était réellement à l'adresse /Users/Camille/Desktop/dmtest et que mon ~/Desktop renseignait en chemin relatif l'adresse : /private/var/root/Desktop où forcément il ne se trouvait pas.

● La commande n°4 : chown 0:0 /bin/dmtest n'aurait donc pu être valide que si la n°3 (déplacement du fichier dmtest à partir du Bureau de l'utilisateur) avait marché, ce qui n'était pas le cas.

● La commande n°5 : diskutil mount /dev/disk0s3, étant indépendante d'un chemin relatif au Bureau d'utilisateur opérant, a elle marché et monté le volume de la «Recovery HD».

● La commande n°6 : cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg ~/Desktop && cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist ~/Desktop a marché, mais pas dans le sens attendu, car elle  déplacé les 2 ressources tirées du volume monté de la «Recovery HD» sur le Bureau de root at: /private/var/root/Desktop, non sur le Bureau de Camille at: /Users/Camille/Desktop.

● La commande n°7 : chown 0:0 ~/Desktop/BaseSystem.dmg && chown 0:0 ~/Desktop/BaseSystem.chunklist a marché, en s'appliquant aux 2 éléments déplacés sur le Bureau de root (ce qui en faisait une instruction redondante, puisque root n'avait nul besoin de se déclarer propriétaire de fichiers déjà en sa possession).

● La commande n°8 : diskutil mergePartitions jhfs+ Macintosh\ HD /dev/disk0s2 /dev/disk0s4 a marché, étant indépendante d'un chemin relatif à l'utilisateur, et a opéré la suppression des 2 partitions : «Recovery HD» + «Sans Titre» en en ré-agrégeant l'espace-disque à la partition majeure de l'OS : le volume «Macintosh HD» sur /dev/disk0s2.

● La commande n°9 : /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist aurait pu marcher, si la commande n°3 : mv ~/Desktop/dmtest /bin/dmtest l'avait fait au préalable, ce qui n'a pas été le cas --> le programme dmtest attendu à l'emplacement /bin/dmtest brillait par son absence, étant resté scotché sur le Bureau de Camille --> donc aucune partition de récupération «Recovery HD» n'a été créée.

● La commande n°10 : rm ~/Desktop/BaseSystem.dmg && rm ~/Desktop/BaseSystem.chunklist a marché (trop bien marché!), car elle a supprimé les 2 ressources présentes sur le Bureau de root --> sans qu'une «Recovery HD» n'ait donc été re-créée, les ressources permettant de le faire ont donc disparu de ton OS.

● La commande n°11 : diskutil list a marché, elle aussi, dans son indépendance de tout chemin relatif, sans que le résultat affiché soit celui escompté, mais au contraire ceci : 
	
	



```
/dev/disk0
#:            TYPE NAME                   SIZE       IDENTIFIER
0:            GUID_partition_scheme       500,1 GB   disk0
1:            EFI EFI                     209.7 MB   disk0s1
2:            Apple_HFS Macintosh HD      499,8 GB   disk0s2
```
 --> d'où il s'avère que, si un re-partitionnement massif en faveur du volume de l'OS s'est bien opéré, la partition de récupération «Recovery HD» manque à l'appel, sans qu'il existe encore dans l'OS de ressources permettant de la re-créer.​

♧​

Comme je ne suis pas du style à laisser quelqu'un se noyer 
	

	
	
		
		

		
		
	


	




 après l'avoir plongé involontairement dans le bouillon 
	

	
	
		
		

		
		
	


	




, j'ai trouvé la parade --> j'ai chargé dans le dossier public de ma «DropBox» les 2 ressources qui te font actuellement défaut pour re-créer une «Recovery HD» grâce au programme dmtest toujours en souffrance sur ton Bureau : il s'agit de la BaseSystem.chunklist et du BaseSystem.dmg correspondant exactement à la «Recovery HD» de «Mountain Lion 10.8.5» qui est ta version actuelle de ton OS (j'ai plein d'OS avec leurs «Recovery» et plein d'installateurs d'OSX sur des DDE). Alors voici ce que je te propose pour finaliser les choses (re-création d'une partition de récupération «Recovery HD 10.8.5» sur ton disque) -->


*1°* Télécharge le dossier zippé ☞Dossier Recovery Mountain Lion 10.8.5.zip☜ comme tu l'as déjà fait pour le programme dmtest. Le poids est de 455 Mo, donc ça va être un téléchargement plus long. Une fois téléchargé, dézippe le dossier et arrange-toi pour déplacer sur *ton Bureau* (le /Users/Camille/Desktop) les 2 ressources contenues : le fichier BaseSystem.chunklist et le disque virtuel : BaseSystem.dmg. Ces 2 éléments doivent donc désormais cotoyer sur ton Bureau le programme dmtest resté en souffrance.

*2°* À présent relance le «Terminal» et copie-colle : 
	
	



```
sudo mv ~/Desktop/dmtest /bin
```
 et ↩︎ --> mot-de-passe admin à l'aveugle --> ↩︎ (comme le préfixe sudo ne change pas l'identité d'utilisatrice qui est toi = Camille, le ~/Desktop désigne ce coup-ci sans erreur ton Bureau.

*3°* Enchaîne par : 
	
	



```
sudo chown 0:0 /bin/dmtest
```
 et ↩︎ (sans avoir besoin de se ré-authentifier dans les 5').

*4°* Puis la décisive : 
	
	



```
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
```
 et ↩︎ --> attends en contemplant les lignes qui défilent - preuve du succès de la manœuvre - jusqu'au ré-affichage de l'invite de commande.

*5°* Tu conclus par : 
	
	



```
diskutil list
```
 et ↩︎ et ce coup-ci tu dois obtenir : 
	
	



```
/dev/disk0
#:            TYPE NAME                   SIZE       IDENTIFIER
0:            GUID_partition_scheme       500,1 GB   disk0
1:            EFI EFI                     209.7 MB   disk0s1
2:            Apple_HFS Macintosh HD      499 GB     disk0s2
3:            Apple_Boot Recovery HD      650.0 MB   disk0s3
```
​--> si tout est bien qui finit bien, tu pourras mettre à la corbeille les 2 éléments résiduels BaseSystem.chunklist et BaseSystem.dmg.

<NB. Si tu tenais à ré-installer _Windows_ sur ton disque, après seulement la recréation correcte de la partition de récupération «Recovery HD», tu pourrais relancer l'«Assistant BootCamp» et lui demander la re-création d'une Partition-BootCamp sur laquelle installer _Windows. _Ai-je parlé du _Tonneau des Danaïdes_? - Moi? jamais...



>

♡​


----------



## bompi (11 Février 2015)

Une méthode relativement simple devrait permettre de s'en tirer sans rien télécharger.
a) faire une sauvegarde de la partition de secours
b) la supprimer ainsi que la partition libre
c) tatouiller son partitionnement comme souhaité et recréer une partition destinée à la partition de secours
d) recopier la sauvegarde dans la partition destinée à la partition de secours.

La clef étant la fabrication de la sauvegarde avec l'utilitaire _dd_ (dans Terminal), qui fait une copie par bloc de données (donc, qui ignore, fort heureusement dans le cas présent, le sens de ce qui est copié).

Pour le a) il "suffit" d'avoir de la place sur son disque, moins de 1 GB.
En admettant que ce que je lis ci-dessus est la réalité (que la partition de secours est la troisième partition du disque numéroté '0') :

```
sudo dd if=/dev/disk0s3 of=${HOME}/Partition_de_secours bs=1m
```
(précision : comme la commande est passé depuis "chez moi", la variable d'environnement HOME pointe bien chez moi).

Une fois le partitionnement souhaité effectué, on copie dans l'autre sens :

```
sudo dd if=${HOME}/Partition_de_secours of=/dev/disk0sX bs=1m
```
(remplacer le X par la bonne valeur).

Ce que je ne peux pas vérifier pour l'instant, c'est l'éventuel besoin de "bénir" (!) la partition de secours de nouveau (_bless_).

Une fois que tout est vérifié, on peut supprimer le fichier "${HOME}/Partition_de_secours".


----------



## Deleted member 1099514 (11 Février 2015)

bompi a dit:


> Une méthode relativement simple devrait permettre de s'en tirer sans rien télécharger.
> a) *faire une sauvegarde de la partition de secours*
> b) la supprimer ainsi que la partition libre
> c) tatouiller son partitionnement comme souhaité et recréer une partition destinée à la partition de secours
> ...




Salut

Sauf que dans le cas présent la partition de secours a déjà été supprimée... 

@+


----------



## bompi (11 Février 2015)

Ce qui est ballot, en effet. Mais au moment où l'idée m'est venue, elle ne l'était pas encore...


----------



## Argusis (11 Février 2015)

Merci pour la solution macomaniac.

Il faut toutefois ajouter que je m'étais arrêt*é*, par prudence, à l'étape 9 suite à son échec.
Je n'ai donc pas supprimé les deux fichiers car il s'agissait de l'étape 10.

Est-il possible d'utiliser la première solution, corrigée ?
J'ai en fait essayé, mais je ne suis pas certain que le résultat soit bon car j'obtiens un _"Error".
_
Voici ce que j'ai entré, j'ai peut-être fait trop de raccourcis :
_




_

Si ce n'est pas possible, j'utiliserais bien sûr la "méthode de secours"


----------



## macomaniac (11 Février 2015)

Hé! Hé! Pas folle, la guêpe : tu es drôlement malin(e), d'avoir senti l'embrouille avec la commande rm ... Donc tu as toujours les 2 ressources nécessaires à la re-création de la «Recovery HD» "en interne" (= sur le Bureau de root at: /private/var/root/Desktop en chemin absolu, soit ~/Desktop en chemin relatif si et seulement si tu es logé(e) dans le shell en tant que root --> sh-3.2#).

Tu as parfaitement corrigé le tir en restituant le chemin absolu à ton Bureau pour déplacer le programme dmtest dans le répertoire à binaires UNIX /bin puis pour rectifier les accédants au fichier à user=root & group=wheel (ces manœuvres ne sont pas en soi nécessaires, mais vu le caractère exceptionnel du programme dmtest, j'estime qu'il mérite d'être installé bien au chaud tout prêt à resservir à l'occasion. Comme /bin fait partie des répertoires à binaires de ta variable d'environnement PATH$, tu dois pouvoir l'invoquer directement dans le «Terminal» par dmtest tout court).

Ta commande de recréation de la partition «Recovery HD» : 


```
/bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
```
 passée en tant qu'opérateur sh-3.2# (root) me paraît sans faute aussi. D'ailleurs, la preuve : le programme dmtest s'est exécuté.

Il ne te reste plus qu'à vérifier par diskutil list si tu as bien listée une 3: Apple_Boot Recovery HD  650.0 MB  disk0s3 ou pas. Si oui, ça semble bon (si non, tu peux poster le résultat complet de la commande diskutil list?). Si tu as bien ta «Recovery HD», re-démarre ton Mac avec 'alt' et choisis de démarrer sur ta partition de récupération (autre option : démarrage avec ⌘R directement) --> est-ce que tu accèdes à l'environnement affichant la fenêtre Utilitaires OS X (le _boot_ est lent sur la «Recovery)?


----------



## Argusis (11 Février 2015)

Voici ce que j'obtient en tapant la commande de recréation de la partition Recovery HD :






Donc j'ai toujours la même ligne d'erreur : _"Error (async) : Couldn't attach disk image (-69736)"_
Ce qui est étrange c'est que la création semble se faire d'après la ligne juste au dessus.

Quand à _diskutil list_ voici ce que j'ai après opération :

_



_
Il n'y a donc toujours pas de partition Recovery HD.


----------



## macomaniac (11 Février 2015)

En cas de succès réel, les lignes affichées sont beaucoup plus nombreuses. La 7è ligne que tu obtiens :


```
->-[Local dmAsyncMessageForDisk:string:dictionary:]: del callback: DADR=0x7fa57840c840=disk0s2 str=Attaching disk image /var/root/Desktop/BaseSystem.dmg dict=(null)
```

me paraît constater dès le départ un échec pour attacher l'image-disque BaseSystem.dmg, ce qui se trouve rappelé au final :  Error (async) : Couldn't attach disk image (-69736)--> il n'est pas interdit de penser que l'inhérence des 2 ressources (BaseSystem.dmg & BaseSystem.chunklist) au répertoire : /private/var/root/Desktop n'est peut-être pas une bonne chose, comme si cette localisation dans une arborescence d'utilisateur verrouillée intrinsèquement (aussi longtemps qu'une session d'utilisateur root n'est pas graphiquement ouverte) bloquait la possibilité pour le disque virtuel BaseSystem.dmg d'être attaché et par suite neutralisait la suite des opérations.

Alors je te suggère un déplacement des 2 ressources sur ton Bureau de session : le /Users/Camille/Desktop en espérant qu'à cette localisation il n'y aura plus d'empêchement d'attacher le disque virtuel. Donc pas de sudo su ce coup-ci, mais des invocations simples de sudo qui préservent ton identité d'utilisateur admin -->

*1°*  À partir de ton invite de commande régulière camille:~ Camille$, tu commences par : 
	
	



```
sudo mv /private/var/root/Desktop/BaseSystem.dmg ~/Desktop && sudo mv /private/var/root/Desktop/BaseSystem.chunklist ~/Desktop
```
 et ↩︎ + password à l'aveugle + ↩︎ --> si l'invite de commande se ré-affiche sans protester (après un laps d'attente : environ 500 Mo à déplacer), les 2 items atterrissent sur ton Bureau, sans normalement que tu les voies , car le flag:hidden (l'attribut d'invisibilité graphique) est fixé sur eux.

*2°*  Si tu voulais vérifier leur présence _de visu _sur ton Bureau de session, passe alors la commande d'affichage des fichiers invisibles : 
	
	



```
defaults write com.apple.finder AppleShowAllFiles 1 | killall Finder
```
 et ↩︎ --> tu devrais les apercevoir. Quand tu voudras re-masquer les fichiers normalement invisibles, tu feras un : 
	
	



```
defaults write com.apple.finder AppleShowAllFiles 0 | killall Finder
```
 et ↩︎ (comme tu vois, il n'y a qu'une différence de valeur de 1 à 0 - autant dire TRUE vs FALSE).

*3°*  Eh bien, retour aux choses sérieuses à présent. Tu passes la commande  : 
	
	



```
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
```
 et ↩︎ (sans mot-de-passe - tu es toujours sudoer) et tu vas bien voir si les choses vont mieux. Un gage de succès serait déjà un processus beaucoup plus long, avec des centaines de lignes qui défilent. Si tu n'as pas de message d'erreur grave (sauf une minuscule déclarée mineure et non invalidante à la fin), refais un diskutil list pour vérifier l'état des lieux.​


----------



## Argusis (11 Février 2015)

L'étape 1 échoue et j'ai ce message :


```
mv: rename /private/var/root/Desktop/BaseSystem.dmg to /Users/Camille/Desktop/BaseSystem.dmg: Not a directory
```


----------



## Deleted member 1099514 (11 Février 2015)

Un doute m'assaille Le répertoire Desktop existe-t-il dans l'environnement root ?
Que te renvoie un :

```
sudo  ls  -la  /var/root
```


----------



## Argusis (11 Février 2015)

Il semble exister :


----------



## Deleted member 1099514 (11 Février 2015)

C'est bien ce que je pensais.
/var/root/Desktop est un fichier pas un répertoire

Il a été créé par la commande :

```
cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg ~/Desktop && cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist ~/Desktop
```

qui a donc copié les 2 fichiers sous le nom de /var/root/Desktop et tu n'as plus qu'un seul fichier (le dernier copié qui a écrasé le premier).

Il ne te reste plus qu'à télécharger les 2 fichiers mis à ta disposition par macomaniac post #18 et suivre les instructions suivantes :

_1° Télécharge le dossier zippé ☞Dossier Recovery Mountain Lion 10.8.5.zip☜ comme tu l'as déjà fait pour le programme dmtest. Le poids est de 455 Mo, donc ça va être un téléchargement plus long. Une fois téléchargé, dézippe le dossier et arrange-toi pour déplacer sur ton Bureau (le /Users/Camille/Desktop) les 2 ressources contenues : le fichier BaseSystem.chunklist et le disque virtuel : BaseSystem.dmg. Ces 2 éléments doivent donc désormais cotoyer sur ton Bureau le programme dmtest resté en souffrance._

Puis faire :



```
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0  ~/Desktop/BaseSystem.chunklist
```


----------



## macomaniac (11 Février 2015)

Je vois que *jeanjd63* a réglé le point : ton -rw-r--r--  root wheel  Desktop annonce un fichier, et pas un répertoire qui serait préfixé par d. Tu peux toujours vérifier en faisant un : 
	
	



```
ls /private/var/root/Desktop
```
 et tu verras bien.

Je crois qu'il convient que tu télécharges les ressources dont je t'ai donné le lien. Une fois les 2 sur ton Bureau (j'ai supprimé le flag:hidden sur chacune, comme ça tu les verras), comme tu as bien installé le programme dmtest dans /bin, il ne te reste qu'à faire un : 
	
	



```
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
```
 ainsi que rappelé par mon habile devancier et ça devrait marcher comme sur des roulettes.

[Je me suis amusé à créer des «Recovery HD» à tout va, soit sur mon disque après réagréation d'icelle au volume de mon OS, soit sur des volumes quelconques de DDE (en ayant bien sûr sauvegardé les 2 ressources su rmon Bureau), et ça marche à tous les coups...]


----------



## Deleted member 1099514 (11 Février 2015)

macomaniac a dit:


> Je vois que jeanj




La mise au point (visuelle) n'est pas trop difficile? layful:


Maintenant que le message est complet ça va mieux.


----------



## Argusis (11 Février 2015)

_*Bingo ! *_​





Je viens juste de tester tout ça, au redémarrage, et ça fonctionne correctement.

Un grand merci à *macomaniac* et* jeanjd63* pour votre disponibilité ainsi que pour le service rendu.

Mention spéciale au "maniaque du mac" pour l'aspect mythologique, philosophique, ludique (si si) et pédagogique des réponses.

Tout ça était presque parfait. 
Mais une chose t'a échappée, et ce malgré un tout petit indice glissé dans une de mes réponses.
Peut-être était-ce cette fameuse précipitation citée un peu plus haut ? 

Oui car en fait Camille est bien mon prénom (bien observé cela dit), et je ne suis absolument "pas folle" (là encore, c'est acceptable _stricto sensu_). Par contre je suis absolument certain, patient (pour ne citer que ces deux).

Tu l'auras donc compris, je suis un monsieur Argusis.

Encore merci  !


----------



## Deleted member 1099514 (11 Février 2015)

Super. 
Mais si maintenant tu veux réinstaller une partition bootcamp, ça va pas être coton (déjà dit).
Bonne continuation.


----------



## macomaniac (11 Février 2015)

Super Monsieur *Argusis* (le _Camille_ tribun militaire et la _Camille_ de l'Enéide réclamaient chacun leur dû à mon imagination humaniste) 
	

	
	
		
		

		
		
	


	




Tu as tiré ton épingle du jeu au travers de ce feuilleton rocambolesque : ta table de partition est absolument impeccable à la fin. Garde bien à l'abri le petit dmtest - ça peut toujours resservir.

Si je n'avais pas fait ma _gaffe_ d'hier après-midi (me tromper de sujet désigné par l'~/), tu serais déjà dépanné - mais comme dit, passé midi, hop! mes yeux ne sont plus qu'à demi en face des trous... *Jean* veillait au grain heureusement. Car le coup du dossier de départ de root sans arborescence complète a priori de sous-dossiers (dont un Desktop), ça fait partie des choses que je ne "vois" pas non plus : mon «Yosemite 10.10» actuel étant l'_aggiornamento_ final de mon «Jaguar 10.2» (_sic_) des origines 
	

	
	
		
		

		
		
	


	




, root est activé chez moi en tant qu'utilisateur de session graphique depuis lors et je tiens pour "naturel" qu'il y ait dans son dossier à /private/var/root une arborescence de compte d'utilisateur complète. Sauf qu'elle ne se crée, apparemment, une fois l'activation d'user graphique avec mot-de-passe opérée, qu'à partir d'une première ouverture de session et n'existe pas par défaut.


----------



## archibaldi91 (23 Septembre 2015)

Salut à tous, 
Je souhaitais revenir sur cet épisode de la ré-agreggation de la partition Bootcamp avec le recovery. Effectivement on retrouve un Corestorage en lieu et place des deux partitions. Pour ma part je ne vois malheureusement pas la partition disk0s4 comme Argusis. Comment peut-on scinder le CoreStorage repasser en hfs+ et resizer la partition dite "sans titre".
Merci pour votre aide.


----------



## macomaniac (23 Septembre 2015)

Salut *archibaldi*.

Tu remontes ce fil où un petit cafouillage du fantasque *macomaniac *avait fait traîner les choses en longueur pour *Argusis* et dans lequel *Jean* s'était révélé pour la première fois avant de devenir l'acteur de premier ordre des forums que l'on sait.

J'interprète ainsi ton message : un format CoreStorage sur la partition «Macintosh HD» du disque de ton Mac a empêché l'«Assistant BootCamp», à qui tu as dû demander d'opérer la réagrégation d'une partition «Windows» (/dev/disk0s4) à celle de l'OS (/dev/disk0s2) en contournant la partition intercalaire de la «Recovery HD» (/dev/disk0s3), d'effectuer la tâche demandée. En conséquence, dans l'«Utilitaire de Disque» (menu "_Partitionner_"), tu as dû sélectionner la partition «Windows» en pressant le bouton "*-*" afin de la "supprimer", ce qui revient à virer son espace-disque au statut de "Free_Space" (espace libre hors partitionnement GUID --> c'est pour cela que la commande diskutil list ne te renvoie aucune ligne /dev/disk0s4, le Free_Space, par définiton, étant hors affectation à une partition). Mais, quand tu as essayé de tirer vers le bas la ligne de base du rectangle figurant le volume de l'OS, afin de récupérer l'espace libre grisé, tu t'es heurté à un blocage - à cause de la rigidité du format CoreStorage. "_Et voilà_" - comme aiment dire les Américains (qui n'ont retenu que cette expression de leur cours de Français de la _High School_)...

Je t'invite à passer dans le «Terminal» de ton OS (peux-tu, incidemment, préciser s'il s'agit de «Yosemite» ?) la commande :


```
diskutil cs list
```
 qui va te retourner l'affichage du tableau composite du Groupe de Volumes Logiques empilé sur la partition /dev/disk0s2 d'OS X. Sélectionne au pointeur toutes les lignes de ce tableau, par ⌘C copie-les dans le presse-papier et par ⌘V colle-les en réponse dans ce fil --> les informations de ce tableau devraient permettre de t'indiquer comment régler ton problème.


----------



## archibaldi91 (23 Septembre 2015)

Salut Macomaniac,
Merci pour ta réponse rapide et pertinente. Effectivement je suis sous Yosemite. J'avais fait des partitions Bootcamp sur d'ancien OSX sans avoir eu ce problème de ré-affectation de la partition windows après suppression de cette dernière.
En fait j'avais créé un bootcamp qui fonctionnait correctement, et en voulant le supprimer par la procédure classique de l'assistant bootcamp, j'ai effectivement eu le même message : comme quoi il ne pouvait ré-affecter l'espace au Macintosh HD.*"votre disque ne peut être restauré sur une partition simple".
*

MacBook-Pro-de-M-Systemes:~ fpel$ diskutil cs list

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group 3A4C8213-5F48-4CF8-826F-1EB34C0B59AD

    =========================================================

    Name:         Macintosh HD

    Status:       Online

    Size:         200140435456 B (200.1 GB)

    Free Space:   0 B (0 B)

    |

    +-< Physical Volume CD356D77-5503-453A-B418-A0AC19B0DD9D

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     200140435456 B (200.1 GB)

    |

    +-> Logical Volume Family A4400E96-27A4-42B2-BBD1-C30B9E023472

        ----------------------------------------------------------

        Encryption Status:       Unlocked

        Encryption Type:         None

        Conversion Status:       NoConversion

        Conversion Direction:    -none-

        Has Encrypted Extents:   No

        Fully Secure:            No

        Passphrase Required:     No

        |

        +-> Logical Volume 35554EEE-EC71-41D4-8ADB-4DA253B7976E

            ---------------------------------------------------

            Disk:                  disk1

            Status:                Online

            Size (Total):          199821664256 B (199.8 GB)

            Conversion Progress:   -none-

            Revertible:            Yes (no decryption required)

            LV Name:               Macintosh HD

            Volume Name:           Macintosh HD

            Content Hint:          Apple_HFS


----------



## macomaniac (23 Septembre 2015)

La chance est avec toi, *archibaldi*.

Tu peux lire, en effet, dans les informations de la dernière instance du Groupe de Volumes Logiques : CoreStorage de la partition /dev/disk0s2 de ton OS : revertible: Yes (no decryption required). Ce qui signifie en clair qu'une simple commande dans le «Terminal» de ton OS démarré, à destination du Volume Logique qui encapsule son système de fichiers terminal jhfs+, peut volatiliser le Groupe de Volumes Logiques en mode "_live_", sans perte de données de l'OS ni obligation de démarrage sur un disque externe.

Depuis ta session de «Yosemite», fais donc sans crainte un copier-coller dans la fenêtre du «Terminal» de :


```
sudo diskutil coreStorage revert 35554EEE-EC71-41D4-8ADB-4DA253B7976E
```
 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 ↩︎ --> le CoreStorage va être "_déconstruit_" (comme eût dit le sieur _Derrida_) et le système de fichiers jhfs+ de l'OS, qui était recelé dans l'enveloppe du Groupe de Volumes Logiques va atterrir en douceur sur le plancher des vaches de la partition /dev/disk0s2 sous forme de volume standard intitulé «Macintosh HD». *Re-démarre* ton Mac quand même, si tu ne veux pas que le kernel continue de garder chargé l'ancien dispositif de partitionnement.

À partir de là, ta session réouverte, si tu relances l'«Utilitaire de Disque», nul doute que tu vas pouvoir (menu "_Partitionner_") étirer jusqu'en bas la ligne inférieure du rectangle du volume «Macintosh HD» pour lui faire récupérer le Free_Space grisé. En effet, un système de fichiers jhfs+ est techniquement doté d'une extensibilité remarquable (et supporte le mode "_live_" pour ce faire).

[Tu remarqueras que la partition de récupération «Recovery HD» (non affichée, mais sise en /dev/disk0s3 en position intercalaire entre le volume «Macintosh HD» en /dev/disk0s2 et le Free_Space qui, quoique hors partitionnement GUID, correspond nonobstant à une série de blocs numérotés en-dessous de ceux de la partition de récupération) ne va pas sauter dans la manœuvre (une commande diskutil list te permettra de vérifier à l'issue de l'opération l'existence d'une Apple_Boot Recovery HD en /dev/disk0s3). En effet, une fonctionnalité récente du programme diskutil mis en œuvre par l'«Utilitaire de Disque» permet d'opérer une mise-à-jour de l'emplacement de la partition de récupération sur les blocs de queue du disque, en permettant de ce fait le ressoudage d'un seul tenant du volume «Macintosh HD» avec l'espace libre remonté au-dessus de la «Recovery HD».]


----------



## archibaldi91 (4 Octobre 2015)

Merci mille fois, Macomaniac, pour tes judicieux conseils. Les choses se sont exactement passées comme décrit.
Il semble donc que l'utilitaire de disque sache repasser l'espace libre au dessus de la recovery. Je craignais suite à la manoeuvre de déconstruction du corestorage que l'espace ne reste derrière le recovery, et qu'ainsi je récupère une deuxième partition exploitable certes..mais pas idéale.
En fait il n'en est rien, j'ai récupéré suite au reboot, l'espace total de mon SSD.
Merci encore


----------



## eless974 (28 Octobre 2015)

Bonjour à tous !

je relance le sujet car j'ai moi aussi une fois sombrer dans le cotés obscure, me retrouvant avec 350 giga "perdu" dans les ténèbres. J'ai donc taper  : "diskutil cs list" dans mon terminal pour afficher comme archibaldi les disques. Cependant, mon message est bien plus court, et je ne suis pas sur de quelle " physical volume" je dois taper la suite de chiffre/lettre pour unifier mon disque, afin de retrouver la force pure.


CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group DC3258C8-A7B2-47A7-ADC4-7A89ABE9007B

    =========================================================

    Name:         Macintosh HD

    Status:       Online

    Size:         649318764544 B (649.3 GB)

    Free Space:   0 B (0 B)

    |

    +-< Physical Volume 42EFA084-83FB-4CF8-B090-ACB450369B58

    |   ----------------------------------------------------

    |   Index:    0

    |   Disk:     disk0s2

    |   Status:   Online

    |   Size:     649318764544 B (649.3 GB)

    |

    +-> Logical Volume Family 2335E9AE-9CB4-4DC1-B2BA-AADDAC4F0BD8

        ----------------------------------------------------------

        Encryption Type:         None

        |

        +-> Logical Volume 75B64473-D988-40E6-B0C3-79CB0EE42C73

            ---------------------------------------------------

            Disk:                  disk1

            Status:                Online

            Size (Total):          648999993344 B (649.0 GB)

            Revertible:            Yes (no decryption required)

            LV Name:               Macintosh HD

            Volume Name:           Macintosh HD

            Content Hint:          Apple_HFS


Alors si jamais un seigneur jedi passe par là, je suis preneur 

Que la force soit en vous

edit :  je penses que je dois coller votre commande avec ce numéro de disque, si j'ai bien compris ?     75B64473-D988-40E6-B0C3-79CB0EE42C73


----------



## Deleted member 1099514 (28 Octobre 2015)

Salut @eless974 
Que te renvoie un : 
diskutil list 
@+


----------



## eless974 (28 Octobre 2015)

voila mon seigneur !


MBP-de-Martin:~ LS$ diskutil list

/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            649.3 GB   disk0s2

  3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

  4:                  Apple_HFS BOOT CAMP               350.2 GB   disk0s4


j'ajoute 2 screen si sa peut aider..


----------



## macomaniac (29 Octobre 2015)

Ô *eless*, ceux qui se sont forlongés du côté des _Ténèbres _sont pardonnés une fois, quand les anime un désir sincère de retrouver la _Lumière_. Mais les _relaps_, eux, encourent la réprobation.

Ton message n° #40 montrait qu'un format CoreStorage existait sur la partition /dev/disk0s2 de ton SSD. Mais ton message n° 42 révèle que tu as agi entre temps, puisque la partition /dev/disk0s2 de ton OS Macintosh HD n'a plus le format Apple_CoreStorage initial, mais le format standard Apple_HSF. Tu as donc passé avec succès la commande de réversion de ton format CoreStorage, commande qui à n'en pas douter a été :


```
sudo diskutil coreStorage revert 75B64473-D988-40E6-B0C3-79CB0EE42C73
```

--------------------​
Tu veux donc te débarrasser de la partition 4: Apple_HFS BOOT CAMP 350.2 GB disk0s4. Rien de plus simple, en 2 temps :

- a) Dans le «Terminal», passe d'abord la commande (copier-coller) :


```
sudo diskutil eraseVolume free null /dev/disk0s4
```
 --> par cette commande, tu invoques le programme diskutil avec le verbe eraseVolume (effacer_volume) et une mention de format free (abrégé de "Free Space" : statut d'espace libre hors partitionnement GUID), un intitulé null (fantaisiste : il faut mentionner un nom de "volume", même s'il est fantôme en tant que free_space comme ici) et la désignation de la cible : /dev/disk0s4 (= identifiant de la partition dans la table des devices).

- b) Une fois que tu as obtenu un :


```
Started erase on disk0s4 BOOT CAMP
Unmounting disk
Finished erase on disk0
MBP-de-Martin:~ LS$
```
 enchaîne avec la commande de redimensionnement de la partition majeure /dev/disk0s2 (copier-coller) :


```
sudo diskutil resizeVolume /dev/disk0s2 0b
```
 --> cette commande convoque le même programme diskutil avec le verbe resizeVolume (re-dimensionner_volume), la désignation de la partition bénéficiaire : /dev/disk0s2 et l'argument 0b pour "0_byte" (qui équivaut en abrégé à l'option : récupérer jusqu'à épuisemment du dernier byte tout espace vacant en-dessous de la partition-cible, ce sans obstacle d'une partition de récupération «Recovery HD» au format Apple_Boot incidemment sur le chemin). Tu devrais toucher en retour l'affichage suivant :


```
Resizing to full size (fit to fill)
Started partitioning on disk0s2 Macintosh HD
Verifying the disk
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume mac appears to be OK
File system check exit code is 0
Resizing
Finished partitioning on disk0s2 Macintosh HD
/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.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
MBP-de-Martin:~ LS$
```

--------------------​
☞ NB: si tu obtenais à l'issue du processus de vérification du filesystem de la partition /dev/disk0s2 un : File system check exit code is *1* (équivalant à : "error found"), ce qui ferait avorter le redimensionnement qui ne peut être effectué que sur une partition supportant un système de fichiers intègre logiquement, alors par *⌘R* tu devrais re-démarrer au préalable sur ta partition de récupération «Recovery HD»  pour : a) soit lancer l'«Utilitaire de Disque», sélectionner le volume Macintosh HD et activer le menu "_SOS_" (la ridicule option "tout-en-un" sous «El Capitan») afin d'amender le système de fichiers de ton OS ; soit b) alller au menu "_Utilitaires_" de la barre supérieure pour lancer le «Terminal» et dans la fenêtre affichée saisir la commande :


```
diskutil repairVolume /dev/disk0s2
```
 en vérifiant que tu touches bien en sortie un : File system check exit code is *0* --> alors, re-démarrer sur ton OS Macintosh HD  et repasser la commande (ou tout aussi bien depuis le «Terminal» ouvert de ta «Recovery HD») :


```
sudo diskutil resizeVolume /dev/disk0S2 0b
```

--------------------​


----------



## eless974 (29 Octobre 2015)

Merci pour votre patience et votre indulgence maître? Grâce à vous, j'ai pu retrouver l'intégralité de ma force, tout en comprenant ( je penses) votre explications. Je ferai en sorte de ne plus sombrer, ma route d'apprentissage est encore longue.


1001 merci


----------



## paul.dure59 (23 Avril 2016)

j'aimerai recréer une partition Boot Camp de 100gb sur mon disque dur 251gb mais 50 gb ont été perdu au démarrage choix des disque avec cmd+alt j'ai 2 disque :
-Windows que quand je démarre me dis qu'il est vide et qu'il faut que j'installe windows avec une clé usb 
-recovery HD 
je suis sous Yosemite 

lors de l'exécution des commandes dans terminal j'ai sa:





j'espère avoir de vos réponse rapidement merci


----------



## paul.dure59 (23 Avril 2016)




----------



## macomaniac (23 Avril 2016)

Salut *Paul
*
Tu as effectivement environ 46 Go de ton disque constitué par de l'espace libre = des blocs non gérés par un système de fichiers dans le cadre d'une partition. Ces blocs se situent sans aucun doute en-dessous de la partition listée en N°3 : Recovery HD.

Par ailleurs, ayant activé «FileVault», tu as un dispositif *CoreStorage Chiffré* sur la partition *disk0s2* de ton OS, qui exporte un volume intitulé Macintosh HD. À mon avis, c'est lui que tu vois affiché quand tu démarres avec "_alt_", et non pas une Recovery HD, car, en cas de *CoreStorage* sur la partition de l'OS, la partition de récupération ne peut pas être affichée à l'écran de choix du disque de démarrage (tu as dû faire un _lapsus calami_ : Recovery HD pour Macintosh HD - pour démarrer sur la «Recovery HD» dans ce contexte => *⌘R* obligé). Ce *CoreStorage Chiffré* peut faire échouer la manœuvre de re-dimensionnement de ta partition Macintosh HD => tu verras bien.

Le problème, c'est que tes clichés ont tous les 2 tronqué l'*UUID* du *Logical Volume* du *CoreStorage* (il faut la suite intégrale des *32* caractères alpha-numériques, or je n'en lis que *28* en haut et *29* en bas). Peux-tu faire un *diskutil list* dans le «Terminal» et surtout ne pas faire un cliché du tableau, mais un copier-coller intégral (montrant les 32 caractères de l'*UUID* du *Logical Volume*) ?


----------



## paul.dure59 (23 Avril 2016)




----------



## paul.dure59 (23 Avril 2016)

sa affiche seulement sa


----------



## macomaniac (23 Avril 2016)

Tu as désactivé «FileVault» entre temps ? Car il n'y a pas plus de *CoreStorage* désormais sur la partition *disk0s2* de l'OS que de beurre en broche - ce qui est une excellente chose, car le repartitionnement devrait en être facilité.

Fais un copier-coller direct de la commande :

```
diskutil resizeVolume /dev/disk0s2 0b
```
 --> tu vois que l'utilitaire *diskutil* est appelé avec le verbe *resizeVolume* (redimensionner le volume) sur la cible du *device* : partition *disk0s2* avec pour option de taille *0b* : *zéro_byte*, qui équivaut en abrégé à dire : "récupérer jusqu'à épuisement du dernier byte l'espace libre situé en-dessous de la partition-cible (*disk0s2*), ce sans obstacle d'une partition de récupération *Apple_Boot* éventuellement sur le chemin dont l'emplacement sera mis-à-jour sur les blocs" (ouf !).

En préambule de cette opération, l'utilitaire *fsck_hfs* est appelé à fin de vérification de l'intégrité du système de fichiers de la partition bénéficaire du re-dimensionnement (*disk0s2*), ce, sans pouvoir de réparation, car pour ce faire il faudrait pouvoir démonter le système de fichiers, ce qui est impossible puisque c'est celui du volume monté de ton OS démarré.

- a) en cas d'erreur trouvée (*exit code > 0*), la commande de re-dimensionnement est avortée. Si tu avais un tel message d'erreur, il faudrait que tu re-démarres sur ta partition de récupération «Recovery HD» par *⌘R*, que tu lances l'«Utilitaire de Disque», que tu sélectionnes le volume MacintoshHD dans la colonne de gauche du logiciel et que tu presses le bouton : "_Réparer le disque_" => si tu obtenais après réparations un "_Le Volume Macintosh HD paraît en bon état_", alors il te faudrait re-démarrer sur ton OS et repasser la commande qui devrait être honorée.

- b) en cas d'absence d'erreur trouvée (*exit code = 0*), le re-dimensionnement du système de fichiers de la partition *disk0s2* va s'opérer en mode "_live_" = conservativement pour le système de fichiers de l'OS Macintosh HD démarré. Tu devrais toucher à la fin un tableau de partitionnement te montrant que ton volume Macintosh HD fait désormais 250 Go.​


----------



## paul.dure59 (23 Avril 2016)

un grand merci a toi sa marche genial


----------



## Hugo-pblm (23 Mai 2016)

Bonjour, je viens demander de l'aide sur ce forum, en déterrant un peu le topic mais j'ai un problème un peu similaire (enfin je crois). J'ai voulu installer windows, j'ai d'abord créé une partition pour ensuite installer l'os via une clé usb bootable, j'ai redémarré le macbook white (2006 Snow Leopard) et à ma surprise je n'avais plus 2 partitions mais une seule qui avait prit 20Go. La partition nommée "windows" n'est plus visible or quand j'allume l'ordinateur en pressant Alt je vois bien les 2 partitions. En cherchant des solutions sur le net j'ai lu qu'il fallait reformater l'ordinateur, or le lecteur dvd est HS et je rencontre des soucis en utilisant une image ISO montée sur une clé usb.. Je me demandais donc s'il était réellement nécessaire de reformater l'ordinateur ou il y avait moyen de supprimer la partition "windows" ?

Merci d'avance pour les réponses qui pourront m'aider.  
Hugo


----------



## Deleted member 1099514 (23 Mai 2016)

Hugo-pblm a dit:


> Bonjour, je viens demander de l'aide sur ce forum, en déterrant un peu le topic mais j'ai un problème un peu similaire (enfin je crois). J'ai voulu installer windows, j'ai d'abord créé une partition pour ensuite installer l'os via une clé usb bootable, j'ai redémarré le macbook white (2006 Snow Leopard) et à ma surprise je n'avais plus 2 partitions mais une seule qui avait prit 20Go. La partition nommée "windows" n'est plus visible or quand j'allume l'ordinateur en pressant Alt je vois bien les 2 partitions. En cherchant des solutions sur le net j'ai lu qu'il fallait reformater l'ordinateur, or le lecteur dvd est HS et je rencontre des soucis en utilisant une image ISO montée sur une clé usb.. Je me demandais donc s'il était réellement nécessaire de reformater l'ordinateur ou il y avait moyen de supprimer la partition "windows" ?
> 
> Merci d'avance pour les réponses qui pourront m'aider.
> Hugo


Salut. 
Que te renvoie dans le terminal un :
diskutil list


----------



## Hugo-pblm (23 Mai 2016)

jeanjd63 a dit:


> Salut.
> Que te renvoie dans le terminal un :
> diskutil list


J'ai ceci : 
 diskutil list

/dev/disk0

#: TYPE    NAME    SIZE    IDENTIFIER

0: GUID_partition_scheme *60.0 GB disk0

1: Apple_HFS Macintosh HD 59.7 GB disk0s1


----------



## Deleted member 1099514 (23 Mai 2016)

Hugo-pblm a dit:


> J'ai ceci :
> diskutil list
> 
> /dev/disk0
> ...


Tu n'as plus de partition Windows. 
Tu peux tenter un reset smc et reset nvram.


----------



## r e m y (23 Mai 2016)

Il vaudrait mieux utiliser l'assistant BootCamp

(Celà dit, sur un disque de 60 Go seulement, est-ce bien raisonnable d'un prendre une partie pour installer Windows?)


----------



## Locke (23 Mai 2016)

Déjà qu'il est conseillé de réserver une partition de 60 Go pour Windows, si ton disque dur de base ne fait que cette taille de 60 Go, il te faudra au minimum réserver 30 Go pour Windows. Aie, aie, aie, ça va craindre, car tu risques d'avoir un blocage total du au manque d'espace dans une des deux partitions.


----------



## Hugo-pblm (23 Mai 2016)

Ah d'accord, je vois pour ce qui est de la taille du disque néanmoins je vais tenter un reset smc et reset nvram pour essayer de retrouver les 20Go perdu... Je vous dis les résultats


----------



## Hugo-pblm (23 Mai 2016)

Après les 2 resets c'est pareil, en pressant alt j'ai toujours la partition windows de visible et le disque dur presque rempli..


----------



## Deleted member 1099514 (23 Mai 2016)

Hugo-pblm a dit:


> Ah d'accord, je vois pour ce qui est de la taille du disque néanmoins je vais tenter un reset smc et reset nvram pour essayer de retrouver les 20Go perdu... Je vous dis les résultats


Quels 20 go ? 
Ton hdd fait 60 go.


----------



## Hugo-pblm (23 Mai 2016)

jeanjd63 a dit:


> Quels 20 go ?
> Ton hdd fait 60 go.


En essayant de mettre la partition windows, celle ci a disparu (dans l'utilitaire de disque) mais la partition macintosh HD a prit 20Go d'un coup..


----------



## macomaniac (23 Mai 2016)

Salut *Hugo
*


Hugo-pblm a dit:


> essayer de retrouver les 20Go perdu...



Ton problème n'est pas celui que tu déclares. Tu n'as aucun 20 Go perdu. Comme l'as montré le résultat de la commande *diskutil list* donnée par *Jean* :

```
/dev/disk0
   #:                  TYPE NAME             SIZE       IDENTIFIER
   0: GUID_partition_scheme                 *60.0 GB    disk0
   1:             Apple_HFS Macintosh HD     59.7 GB    disk0s1
```

ton disque *disk0* a une taille totale de 60 Go, et ta partition-Système *Macintosh HD* en *disk0s1* fait 59,7 Go => il ne manque donc pas 20 Go au tableau, il manque 0,3 Go : 300 Mo.

Cette lacune de 300 Mo provient de ce qu'il manque dans ta table de partition l'en-tête régulier de l'*ESP* : *E*FI *S*ystem *P*artition, nommée *EFI*, dont la taille est de 209 Mo. Tu devrais normalement avoir le tableau de partition suivant :

```
/dev/disk0
   #:                  TYPE NAME             SIZE       IDENTIFIER
   0: GUID_partition_scheme                 *60.0 GB    disk0
   1:                   EFI EFI              209.7 MB   disk1s1
   2:             Apple_HFS Macintosh HD     59.7 GB    disk0s2
```

Je pense que cette partition de boot a été sucrée par l'action de ton installateur de Windows et que cette disparition a peut-être un corollaire en ce qui concerne les Tables de Partition elles-mêmes.

--------------------​
Une Table de Partition consiste en une série de "descripteurs" logiques, qui comportent la numérotation des blocs du disque de 1 à n, leur répartition en secteurs logiques de tel boc à tel bloc constituant les partitions, la définition des formats de systèmes de fichiers gestionnaires de ces secteurs de partitions notamment. Ce sont ces descripteurs qui permettent à l'*EFI* (le *Programme Interne* du Mac) d'opérer sur le disque au démarrage.

Le disque de démarrage d'un Mac comporte régulièrement *2* Tables de Partition :

- a) la table de partition principale, ou *GPT* (*G*UID *P*artition *T*able) dont les descripteurs occupent les 32 premiers blocs du disque, avec un backup (sauvegarde) sur les 32 derniers.

- b) la table de partition secondaire, ou *PMBR* (*P*rotective *M*aster *B*oot *R*ecord) dont les descripteurs résident sur le bloc *0*, et qui sert de pare-feu protecteur de la *GPT* contre les interventions de Systèmes opérateurs non-Apple.​
Une Table de Partition *PMBR* est "mono-sectorielle" : càd. qu'elle ne décrit l'espace du disque, d'un point de vue *MBR*, que comme constitué d'une seule partition globale.

Mais il arrive, sous l'effet d'intervention de Systèmes opérateurs non-Apple, qu'une modification se produise de la *PMBR* qui la convertit en *HMBR* = *H*ybrid *M*aster *B*oot *R*ecord, laquelle n'est plus mono-sectorielle, mais cartographie l'espace du disque en plusieurs partitions distinctes qui sont la transposition en écho de partitions pré-existantes de la *GPT* dans le schéma *MBR*. Ce type de table de partition *MBR* "*hybridée*" sur le secteur *0* d'un disque Mac est toujours problématique.

--------------------​Ton problème se résume donc (si j'ai bien compris) à l'affichage d'une partition Windows fantôme à l'écran de choix du disque de démarrage affiché par la touche "_alt_", tandis qu'aucune partition correspondante n'existe actuellement sur ton disque d'après la Table de Partition *GPT*.

Ce problème me paraît un écho de celui qui a été évoqué dans ce fil assez récent : ☞*Partition BootCamp*☜ et qui n'a malheureusement pas connu un dénouement intellectuellement satisfaisant.

Pour essayer de clarifier le dispositif actuel des blocs du disque de ton Mac, je t'invite à aller à : _Applications_ > _Utilitaires_ pour lancer le «Terminal». Dans la fenêtre qui s'affiche, saisis exactement 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, tu vas voir s'afficher le tableau de distribution des blocs du disque de ton Mac, aussi bien dépendants de la partition unique *Macintosh HD* qu'en-dehors de cette partition.

Peux-tu faire un copier-coller de ce tableau ici ?

Je suis curieux de vérifier la nature de la partition *MBR* du secteur *0*. Mais je laisserai à *Jean*  le plaisir de te redonner la suite de commandes te permettant de re-créer la partition *EFI* disparue à partir de ses blocs précédant la *1 GPT part /dev/disk0s1* *Macintosh HD*. Il sera intéressant de voir si cette re-création permet de résilier la partition fantôme...


----------



## Deleted member 1099514 (23 Mai 2016)

macomaniac a dit:


> Salut *Hugo
> *
> 
> 
> ...


Salut @macomaniac 
S'il y a des commandes à passer, je te laisse la main. Je suis sur smartphone et c'est pas très commode.


----------



## macomaniac (23 Mai 2016)

jeanjd63 a dit:


> S'il y a des commandes à passer, je te laisse la main. Je suis sur smartphone et c'est pas très commode


Je me disais aussi que tu te faisais rare depuis quelque temps et j'en avais induit que tu étais en vacances - ce que le coup du smartphone me semble confirmer 
	

	
	
		
		

		
			



​


----------



## Hugo-pblm (23 Mai 2016)

macomaniac a dit:


> Je me disais aussi que tu te faisais rare depuis quelque temps et j'en avais induit que tu étais en vacances - ce que le coup du smartphone me semble confirmer
> 
> 
> 
> ...


Merci pour ta réponse! J'ai donc rentré la commande et obtenu ceci : 
gpt show: unable to open device '/dev/disk0': No such file or directory


----------



## macomaniac (23 Mai 2016)

Hé ! Hé ! Ça ne va pas être possible.

J'ai un _MacBook Pro 17" Late_2011_ avec un SSD *disk0* de 1 To multi-partitionné, avec la série des OS démarrables de «Snow Léopard 10.6» (ton OS) à «El Capitan 10.11» installés sur des partitions distinctes.

J'ai eu la curiosité de re-démarrer alternativement sur chacun de ces OS et de passer dans leur «Terminal» la commande que je t'ai proposée :

```
sudo gpt show /dev/disk0
```
*- a)* pour la série des OS allant de «Snow Léopard 10.6», en passant par «Lion 10.7» et jusqu'à «Mountain Lion 10.7» compris, cette commande n'est pas honorée à destination d'un disque dont au moins une partition comporte un système de fichiers monté en volume et actif (ce qui est forcément le cas lorsqu'on opère à partit de l'OS démarré d'une de ses partitions). Soit le retour est le tien : 
	
	



```
gpt show: unable to open device '/dev/disk0': No such file or directory
```
 en cas d'adresse */dev/disk0*, soit en cas d'adresse abrégée *disk0* c'est le retour :

```
gpt show: unable to open device 'disk0': Resource busy
```
 (ressource en fonction).

*- b)* pour la série des OS allant de «Mavericks 10.9», en passant par «Yosemite 10.10» et jusqu'à «El Capitan 10.11», cette commande par contre est directement honorée à destination du même disque *disk0* dont le système de fichiers de la partition de l'OS démarré est monté et actif => le tableau de répartition des blocs est affiché en retour.​=> j'en déduis que l'utilitaire *gpt* des OS 10.6 => 10.8 est un programme ancien associé à un *framework DiskManagement.framework* incapable de gérer la commande en cas de système de fichiers actif sur le disque [grâce à toi, j'ai appris quelque chose 
	

	
	
		
		

		
		
	


	




 ]

--------------------​On est donc bloqués en ce qui concerne *gpt* - qui impliquerait de démarrer sur un clone de ton Système résidant sur un DDE, afin de pouvoir démonter tous les systèmes de fichiers du *disk0* du Mac avant de passer la commande.

Mais ça me donne l'idée d'une manœuvre un tantinet "chronophage", mais assurée à 100% de la réussite à la fin : recréation d'un partition *EFI* et disparition d'une partition Windows fantôme - je pense. Je te la décris :

*- a)* il te faut un DDE USB que tu attaches à ton Mac. Le disque, inspecté dans l'«Utilitaire de Disque» de ton «Snow Léopard», doit impérativement avoir une *Table de Partition GUID* générale. Comme le volume de ton «Snow Léopard» ne fait que 60 Go, dont pas plus de 40 Go de données puisque 20 Go sont venus fraîchement s'y adjoindre, il te suffit, si le volume du DDE comporte déjà des données, d'opérer une re-partition (non destructive) de ce volume.

Dans l'«Utilitaire de Disque», tu sélectionnes le disque global du DDE > menu "_Partition_" > tu vois s'afficher plein centre le rectangle du volume > tu le sélectionnes > presse le bouton "*+*" en bas > un re-découpage potentiel en 2 rectangles de volumes est proposé (conservatif pour le volume déjà occupé par des données) > tu peux déplacer la ligne médiatrice en la pinçant au milieu > choisis pour le volume neuf un volume de 60 Go maximum, un format "*Mac OS étendu (journalisé)*" et un nom parlant du genre : *SNOW-CLONE* > "_Appliquer_" => ton DDE est prêt.

--------------------​
*- b)* tu télécharges et installes la version ☞*Carbon Copy Cloner 3.5*☜ compatible «Snow Léopard» (logiciel payant, mais démo utilisable un mois sans limitations fonctionnelles). C'est un logiciel de clonage qui permet de créer un copie démarrable du volume d'un OS sur le volume externe d'un périphérique. Tu me vois venir ?

Tu crées une tâche de clonage où la "_source_" = le volume entier *Macintosh HD* du disque de ton Mac et la "_destination_" = le volume neuf *SNOW-CLONE* de ton DDE.

--------------------​
- c) à complétion du clonage, tu re-démarres ton Mac avec "_alt_" et tu choisis de booter sur le Système *SNOW-CLONE* où tu ouvres uen session-miroir de celle de ton OS du disque du Mac. Tu lances l'«Utilitaire de Disque», tu sélectionnes le disque global de ton Mac et le menu "_Effacer_" qui va recréer une *Table de Partition GUID* neuve, avec un volume *Macintosh HD* reformaté en "*Mac OS étendu (journalisé)*".

Il ne te reste plus qu'à lancer «Carbon Copy Cloner» (qui s'est copié lui-même dans les Applications du clone) et à créer une tâche inverse de rétro-clonage où "_source_" = le volume entier *SNOW-CLONE* et "_destination_" = le volume reformaté *Macintosh HD* du disque du Mac.

--------------------​
- d) à complétion, tu re-démarres avec "_alt_" et tu bootes sur *Macintosh HD* où tu ouvres une session miroir de celle de ton clone, elle-même miroir de celle de l'OS original du disque du Mac. Normalement, tu auras dû observer la disparition de la partition Windows fantôme à l'écran de choix du disque de démarrage. Dans ton OS *Macintosh HD*, une commande *diskutil list* dans le «Terminal» doit afficher 2 partitions du *disk0* : *1 = EFI 209 Mo disk0s1*  & *2 = Macintosh HD 59,7 Go disk0s2*.

--------------------​


----------



## Deleted member 1099514 (23 Mai 2016)

macomaniac a dit:


> Je me disais aussi que tu te faisais rare depuis quelque temps et j'en avais induit que tu étais en vacances - ce que le coup du smartphone me semble confirmer
> 
> 
> 
> ...


Hé oui. Vive les vacances.


----------



## Hugo-pblm (23 Mai 2016)

macomaniac a dit:


> il te suffit, si le volume du DDE comporte déjà des données, d'opérer une re-partition (non destructive) de ce volume.


Quand tu dis Non destructive je peux garder mes données dessus ? 
J'effectue la manip demain, j'ai pleins de contrôles en ce moment, je suis pas mal occupé... J'ai téléchargé le logiciel et j'ai du prendre la v2 car la 3.5 n'était pas compatible (je ne sais pas pourquoi) enfin la version 2 suffit ?


----------



## macomaniac (23 Mai 2016)

Hugo-pblm a dit:


> Quand tu dis Non destructive je peux garder mes données dessus ?


Oui. Le re-partitionnement en mode "live" n'est jamais destructif pour les données pré-existantes dans le volume. S'il y a assez d'espace libre dans le volume existant de ton DDE pour créer avec un 2è volume de 50 Go disons, alors tu peux sans problème le re-partitionner sans déplacer tes données.

Suppose que tu aies un DDE avec un volume unique de 500 Go, dont 400 Go occupés par des données => après re-partitionnement, tu peux avoir 2 volumes : l'ancien réduit à supposons 450 Go, donc 400 Go occupés par les données ; et le nouveau de 50 Go vide. C'est sur ce dernier que tu peux cloner ton volume Macintosh HD.

Tant que «Carbon Copy Cloner» se lance, alors il fera la tâche. Si tu ne peux pas installer la version 3.5, c'est peut-être que ton «Snow Léopard» n'est pas à jour de sa dernière MÀJ qui est la 10.6.8 ? Vérife dans le Menu  > À propos de ce Mac... > Informations Système ce qu'il en est.

Si ton «Snow Léopard» n'est pas en version 10.6.8, tu peux télécharger et appliquer la ☞*Mise à jour combinée Mac OS X 10.6.8*☜.​


----------



## Hugo-pblm (24 Mai 2016)

macomaniac a dit:


> Hé ! Hé ! Ça ne va pas être possible.
> 
> J'ai un _MacBook Pro 17" Late_2011_ avec un SSD *disk0* de 1 To multi-partitionné, avec la série des OS démarrables de «Snow Léopard 10.6» (ton OS) à «El Capitan 10.11» installés sur des partitions distinctes.
> 
> ...


Et bien voilà après ces manipulations la partition windows n'est plus visible et j'ai bien le retour de EFI. Maintenant j'aimerai juste te poser une question, puisque d'après les réponses précédentes le fait de mettre windows sur mon Macintosh HD de 60Go n'est pas bon pour les 2 systeme, est ce que je peux faire un clone de windows que j'utilise ensuite sur mon disque dur directement ?


----------



## macomaniac (24 Mai 2016)

Bonne manœuvre ! Si tu as ultérieurement d'autres problèmes de partitions insolubles, tu connais désormais le procédé : clonage => effaçage du disque du Mac => rétro-clonage.

Il me semble que pour pouvoir démarrer un Système Windows installé sur un DDE, il faut une connexion Thunderbolt, ce qui manque à ton _MacBook Blanc 2006_ (je suis totalement ignare en matière de Windows que je n'ai jamais utilisé, ni n'envisage non plus d'utiliser).

Si ton besoin de Windows est "léger", tu pourrais envisager de l'installer dans une machine virtuelle motorisée par «Parallels Desktop» vs «VMware Fusion» (payants) ou «Virtual Box» (gratuit). En ne gardant dans le volume OS X du disque de ton Mac que le logiciel de virtualisation, et en déportant le conteneur de la machine virtuelle sur un DDE, tu pourrais démarrer un Windows en mode virtualisation sans que ça prenne de la place sur ton disque.

Sinon, tu peux très bien repartitionner ton disque en 2 pour installer Windows sur une 2è partition, mais disons que 60 Go, c'est un peu juste pour le confort de 2 OS en parallèle. Mais, expérimentalement parlant, il doit être possible d'installer Win sur une partition de 20-25 Go de ton disque.

Si l'«Assistant BootCamp» ne parvient pas à faire le travail d'installation, tu peux toujours installer Win à partir d'une clé d'installation bootable (ce qui semble avoir été ta tentative). Ce procédé rencontre fréquemment de grosses difficultés, car l'installateur de Win ne parvient souvent pas à identifier la partition préparée à l'avance et ressortissant de la *Table de Partition GUID* comme une partition valide (de son point de vue).

Si tu as effectivement un installateur de Win sur une clé USB bootable, une méthode qui marche souvent consiste :

- a) à créer (par l'«Utilitaire de Disque» ou l'«Assistant BootCamp») une partition pour Win - peu importe le format.

- b) à effacer le système de fichiers de cette partition, ce qui la supprime de la *Table de Partition GUID* mais laisse ses blocs à l'état d'espace libre (*free_space*). Tu peux très bien opérer cette manœuvre, dans l'«Utilitaire de Disque», en sélectionnant le disque global de ton Mac et le menu "_Partition_" > sélectionner le rectangle du bas de la nouvelle partition de 20 Go > presser le bouton *-* qui efface son système de fichiers et fait apparaître une zone équivalente en grisé (= *free_space*) sans le ré-allouer automatiquement à la partition du dessus (celle de «Snow Léopard»).

- c) à démarrer sur l'installateur de Win de la clé et, dans le panneau de choix de la partition de destination de l'installation, à ne pas chercher à sélectionner une partition préexistante de la *Table de Partition GUID*, mais à choisir ce qui apparaît (du point de vue de l'installateur de Win) comme une bande d'espace "*non alloué*" => l'installateur est alors capable de transformer cet espace "*non alloué*" (le *free_space* de la partition supprimée) en une partition dédiée à Win dans le format _ad hoc_.​


----------



## Hugo-pblm (24 Mai 2016)

macomaniac a dit:


> Bonne manœuvre ! Si tu as ultérieurement d'autres problèmes de partitions insolubles, tu connais désormais le procédé : clonage => effaçage du disque du Mac => rétro-clonage.
> 
> Il me semble que pour pouvoir démarrer un Système Windows installé sur un DDE, il faut une connexion Thunderbolt, ce qui manque à ton _MacBook Blanc 2006_ (je suis totalement ignare en matière de Windows que je n'ai jamais utilisé, ni n'envisage non plus d'utiliser).
> 
> ...


J'ai donc fait ce que tu m'as dit mais je suis de nouveau bloqué. Je vois bien mon espace non alloué mais l'installer me dit que windows ne peut pas être installé sur ce disque car le disque est du style de partition GPT. J'ai effectué quelques recherche et j'ai vu qu'il fallait que m'a clé soit booté en UEFI j'ai réessayé avec Rufus mais aucuns changements...


----------



## Hugo-pblm (25 Mai 2016)

macomaniac a dit:


> Bonne manœuvre ! Si tu as ultérieurement d'autres problèmes de partitions insolubles, tu connais désormais le procédé : clonage => effaçage du disque du Mac => rétro-clonage.
> 
> Il me semble que pour pouvoir démarrer un Système Windows installé sur un DDE, il faut une connexion Thunderbolt, ce qui manque à ton _MacBook Blanc 2006_ (je suis totalement ignare en matière de Windows que je n'ai jamais utilisé, ni n'envisage non plus d'utiliser).
> 
> ...


J'ai enfin réussi en créant une partition en ExFat et là l'Installer a bien voulu la formater!
Toutes tes réponses sont super claires et même quand on ne s'y connait pas vraiment on comprend vite!!
Merci beaucoup pour ton aide et le temps que tu y as dédié!


----------



## macomaniac (25 Mai 2016)

De rien, *Hugo*.

J'ai l'impression que la stratégie varie avec le type d'installateur de Win (le procédé de l'espace "non alloué" a très bien marché pour un autre membre du site qui m'avait contacté en message privé).

De tous les mystères informatiques sur Mac, la gestion des partitions par un installateur de Windows est celui qui pour moi reste enveloppé dans la plus épaisse nébulosité. J'y vois un signal de la « Main Invisible de la Providence » qui dessine cet avertissement gratuit : "n'entre pas en Windows, maco, ou perds toute espérance".  J'ai très bien reçu le message : je ne me risquerais certainement pas dans cet  _Enfer Logique_... 
	

	
	
		
		

		
		
	


	





Si tu te sens à l'étroit sur ton disque de 60 Go et si tu n'envisages pas de changer prochainement de Mac, remplacer ton HDD par un autre de plus grande capacité (voire un SSD 2,5" - vérifier les compatibilités) te permettrait d'opérer plus confortablement (ou plus rapidement).


----------

