Partition Bootcamp disparue et impossible à supprimer
- Créateur du sujet Argusis
- Date de début
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"
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"
M
Membre supprimé 1060554
Invité
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» :
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)?
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» :
Bloc de code:
/bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklistIl 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)?
Dernière édition par un modérateur:
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.
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.
M
Membre supprimé 1060554
Invité
En cas de succès réel, les lignes affichées sont beaucoup plus nombreuses. La 7è ligne que tu obtiens :
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 -->
Bloc de code:
->-[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 :
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 :
et ↩︎ --> tu devrais les apercevoir. Quand tu voudras re-masquer les fichiers normalement invisibles, tu feras un :
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 :
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.
Bloc de code:
sudo mv /private/var/root/Desktop/BaseSystem.dmg ~/Desktop && sudo mv /private/var/root/Desktop/BaseSystem.chunklist ~/Desktop2° Si tu voulais vérifier leur présence de visu sur ton Bureau de session, passe alors la commande d'affichage des fichiers invisibles :
Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 1 | killall Finder
Bloc de code:
defaults write com.apple.finder AppleShowAllFiles 0 | killall Finder3° Eh bien, retour aux choses sérieuses à présent. Tu passes la commande :
Bloc de code:
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
Dernière édition par un modérateur:
D
Deleted member 1099514
Invité
C'est bien ce que je pensais.
/var/root/Desktop est un fichier pas un répertoire
Il a été créé par la commande :
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 :
/var/root/Desktop est un fichier pas un répertoire
Il a été créé par la commande :
Bloc de code:
cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg ~/Desktop && cp /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.chunklist ~/Desktopqui 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 :
Bloc de code:
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist
Dernière édition par un modérateur:
M
Membre supprimé 1060554
Invité
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 :
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 :
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...]
Bloc de code:
ls /private/var/root/DesktopJe 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 :
Bloc de code:
sudo /bin/dmtest ensureRecoveryPartition / ~/Desktop/BaseSystem.dmg 0 0 ~/Desktop/BaseSystem.chunklist[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...]
Dernière édition par un modérateur:
D
Deleted member 1099514
Invité
La mise au point (visuelle) n'est pas trop difficile?
layful:Maintenant que le message est complet ça va mieux.
Dernière édition par un modérateur:
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
!
D
Deleted member 1099514
Invité
Super.
Mais si maintenant tu veux réinstaller une partition bootcamp, ça va pas être coton (déjà dit).
Bonne continuation.
Mais si maintenant tu veux réinstaller une partition bootcamp, ça va pas être coton (déjà dit).
Bonne continuation.
M
Membre supprimé 1060554
Invité
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.
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
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.
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.
M
Membre supprimé 1060554
Invité
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 :
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.
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 :
Bloc de code:
diskutil cs listSalut 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
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
M
Membre supprimé 1060554
Invité
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 :
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».]
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 :
Bloc de code:
sudo diskutil coreStorage revert 35554EEE-EC71-41D4-8ADB-4DA253B7976EÀ 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».]
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
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
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
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
Dernière édition:
Sujets similaires
