Impossible supprimer partition Mac

Maxime-B

Membre enregistré
31 Août 2014
9
0
Cognac
Bonsoir tout le monde !

J'ai un petit soucis avec mon Macbook Pro, il m'est en effet impossible de supprimer la partition en question. Pour tout vous expliquer lorsque j'étais sous Mavericks, j'ai créé une partition pour installer Yosemite, mais il m'est maintenant impossible de supprimer la partition de Mavericks ( aujourd'hui également sous Yosemite ... )

Pourriez-vous m'aider? :)

Bonne soirée. :cat:
 
Comment t'y prends-tu et quel est l'ordre des partitions ?
 
Comment t'y prends-tu et quel est l'ordre des partitions ?

Donc mes partitions sont dans cet ordre:

Macintosh Yosemite
Macintosh Yosemite
Partition 1
Partition 1

C'est l'ensemble Partition 1 que je souhaiterais totalement supprimer de mon disque, car il occupe quand même 100 des 256Go dispo...
J'utilise d'habitude l'utilitaire de disque, mais les petites icônes pour supprimer ou ajouter une partition sont grisées, du coup je peux rien faire, ni les redimensionner. iPartition ne peux non plus supprimer cette partition ... :( Et c'est la même chose dans sur Recovery HD.
 
Si tu tapes :
Bloc de code:
diskutil list
dans Terminal, ça te répond quoi ?
 
Fais une sauvegarde avec Time Machine, reboote en mode recovery, efface les deux partitions, et recrée une partition pour Yosemite, puis restaure ta sauvegarde

En gros tu ne peux pas déplacer le début d'un partition non vide.
 
Si tu tapes :
Bloc de code:
diskutil list
dans Terminal, ça te répond quoi ?

/dev/disk0

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *251.0 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_CoreStorage 100.6 GB disk0s2

3: Apple_Boot Recovery HD 650.0 MB disk0s3

4: Apple_CoreStorage 148.9 GB disk0s4

5: Apple_Boot Recovery HD 650.0 MB disk0s5

/dev/disk1

#: TYPE NAME SIZE IDENTIFIER

0: Apple_HFS Macintosh Yosemite *148.5 GB disk1

Logical Volume on disk0s4

F61B7044-35CC-4B63-88F5-2839B19EC709

Unencrypted

/dev/disk2

#: TYPE NAME SIZE IDENTIFIER

0: Apple_HFS Partition 1 *100.2 GB disk2

Logical Volume on disk0s2

FE004B8A-4034-4C18-96D0-4438AA23FCCE

Unencrypted

ou ca
Bloc de code:
diskutil cs list
qui indique la hierarchie des groupes logiques

CoreStorage logical volume groups (2 found)

|

+-- Logical Volume Group 18C2886D-5D44-45A4-AFD8-14EF430379B9

| =========================================================

| Name: Macintosh Yosemite

| Status: Online

| Size: 148882632704 B (148.9 GB)

| Free Space: 18919424 B (18.9 MB)

| |

| +-< Physical Volume 0F00F057-E529-4F94-87CC-7E12B709B4FE

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

| | Index: 0

| | Disk: disk0s4

| | Status: Online

| | Size: 148882632704 B (148.9 GB)

| |

| +-> Logical Volume Family 31940217-7BF6-497D-B786-BA44697F88C1

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

| Encryption Status: Unlocked

| Encryption Type: None

| Conversion Status: NoConversion

| Conversion Direction: -none-

| Has Encrypted Extents: No

| Fully Secure: No

| Passphrase Required: No

| |

| +-> Logical Volume F61B7044-35CC-4B63-88F5-2839B19EC709

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

| Disk: disk1

| Status: Online

| Size (Total): 148511391744 B (148.5 GB)

| Conversion Progress: -none-

| Revertible: Yes (no decryption required)

| LV Name: Macintosh Yosemite

| Volume Name: Macintosh Yosemite

| Content Hint: Apple_HFS

|

+-- Logical Volume Group 2FA4FA9F-2EC7-4017-A05D-7ECE1B5D51E1

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

Name: Partition 1

Status: Online

Size: 100607799296 B (100.6 GB)

Free Space: 18952192 B (19.0 MB)

|

+-< Physical Volume 8BE2393F-82C3-438D-AD43-A08872129F37

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

| Index: 0

| Disk: disk0s2

| Status: Online

| Size: 100607799296 B (100.6 GB)

|

+-> Logical Volume Family 127937BB-8AF6-4D8F-AB5D-5E0F2C2B6FBA

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

Encryption Status: Unlocked

Encryption Type: None

Conversion Status: NoConversion

Conversion Direction: -none-

Has Encrypted Extents: No

Fully Secure: No

Passphrase Required: No

|

+-> Logical Volume FE004B8A-4034-4C18-96D0-4438AA23FCCE

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

Disk: disk2

Status: Online

Size (Total): 100236525568 B (100.2 GB)

Conversion Progress: -none-

Revertible: Yes (no decryption required)

LV Name: Partition 1

Volume Name: Partition 1

Content Hint: Apple_HFS
Fais une sauvegarde avec Time Machine, reboote en mode recovery, efface les deux partitions, et recrée une partition pour Yosemite, puis restaure ta sauvegarde

En gros tu ne peux pas déplacer le début d'un partition non vide.

Dans le mode Recovery je peux effacer le contenu de l'une ou l'autre partition, mais pas supprimer la partition en question ... :/
 
Salut

Utilises-tu Fusion Drive ou FileVault 2?
Si non tu peux regarder ICI pour supprimer Core Storage qui t'empêche de supprimer ta partition de 100 Go.
Vérifies quand même que ça ne va pas "bousiller" ton système. Une sauvegarde préalable serait la bienvenue.

@+
 
Salut Maxime.

Lorsque tu as installé «Yosemite» d'une part sur ta partition /dev/disk0s2 de 100 Go (volume dénommé : Partition 1), d'autre part sur ta partition /dev/disk0s4 de 148 Go (volume dénommé Macintosh Yosemite) - dans les 2 cas l'installateur en a profité pour greffer un format CoreStorage sur chacune des partitions, comme il en a l'instruction préalable. Ce format asseoit un Disque Physique Virtuel sur chacune des partitions d'accueil qui "écrase" de sa présence le Disque Physique Réel tout en servant de support à un Volume Logique - le tout solidarisé dans une structure globale dite Groupe de Volumes Logiques. L'inconvénient que tu subis est que le Disque Physique Réel est inadressable aussi longtemps qu'il supporte un CoreStorage - d'où tes échecs à opérer un repartitionnnement.

Heureusement pour toi, chacun des
CoreStorages actuellement en place sur les 2 partitions /dev/disk0s2 et /dev/disk0s4 est déclaré réversible, ce qui veut dire qu'une paire de commandes dans le «Terminal» peut supprimer ce format en restaurant le format standard jhfs+ (Mac OS étendu journalisé) de manière non_destructrice pour les Systèmes de fichiers en place --> tu peux donc appliquer une telle commande non seulement à ton Partition 1 mais aussi à ton Macintosh Yosemite, sans problème pour les OS ni pour leurs données. Tu es forcé de supprimer les 2 CoreStorages, sans quoi tu ne pourrais pas manipuler les partitions de ton disque (effet de verrouillage).


Donc, va à Applications/Utilitaires et lance le «Terminal». Dans la fenêtre de type traitement de texte spartiate qui s'affiche, saisis d'abord exactement la commande suivante (copier-coller) :

Bloc de code:
sudo diskutil coreStorage revert FE004B8A-4034-4C18-96D0-4438AA23FCCE

et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande) --> une demande de
password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> en retour de commande, tu vois s'afficher progressivement :

Bloc de code:
Started CoreStorage operation on disk2 Partition 1
[FONT=Arial]Switching partition from Core Storage type to original type
Reclaiming space formerly used by Core Storage metadata
Ejected Logical Volume
Removing Physical Volume
Destroying Logical Volume Group
Remounting former Physical Volume as normal disk
Core Storage LV UUID: FE004B8A-4034-4C18-96D0-4438AA23FCCE
Core Storage disk: disk0s2
Finished CoreStorage operation on disk2 Partition 1

suite à quoi le format CoreStorage greffé sur la partition /dev/disk0s2 et correspondant au volume Partition 1 vient d'être logiquement oblitéré. Comme le volume concerné n'a pas encore "ré-atterri" sur l'emplacement correspondant du disque réel suite à l'élimination du Disque Physique Virtuel (situation instable à prolonger), je préconise qu'avant de passer la 2è commande tu re-démarres ton Mac.


Cela fait, et retourné dans le «Terminal», enchaîne par un copier-coller de :

Bloc de code:
sudo diskutil coreStorage revert F61B7044-35CC-4B63-88F5-2839B19EC709

et ↩︎ +
password + ↩︎ --> tu obtiens cette fois-ci le retour de commande progressif suivant :

Bloc de code:
Started CoreStorage operation on disk1 Macintosh Yosemite
[FONT=Arial]Switching partition from Core Storage type to original type
Reclaiming space formerly used by Core Storage metadata
Ejected Logical Volume
Removing Physical Volume
Destroying Logical Volume Group
Remounting former Physical Volume as normal disk
Core Storage LV UUID: F61B7044-35CC-4B63-88F5-2839B19EC709
Core Storage disk: disk0s4
Finished CoreStorage operation on disk1 Macintosh Yosemite

suite à quoi le format
CoreStorage greffé sur la partition /dev/disk0s4 et correspondant au volume Macintosh Yosemite vient d'être logiquement oblitéré (la reversion du format CoreStorage est supportée en mode 'live' sur le Système de fichiers de l'OS démarré) --> pour la même raison que précédemment, je préconise que sans attendre tu re-démarres ton Mac encore.


--> J'avais envisagé pour terminer de te proposer une commande de fusionnement de partitions, mais je viens de m'aviser que le volume que tu souhaites conserver (Macintosh Yosemite] est situé en 4è position (
/dev/disk0s4) --> si c'est bien le cas, il ne t'est pas possible directement de ré-agréger à son volume celui qui le précéde (Partition 1 en /dev/disk0s2), car il y a toujours un ordre "ascendant" et pas "descendant" à respecter pour ce faire. Il conviendrait pour repréciser les choses que tu repasses la commande diskutil list pour confirmer l'état des lieux et ce que tu souhaites vraiment faire à ce point.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Maxime-B
Salut Maxime.

Lorsque tu as installé «Yosemite» d'une part sur ta partition /dev/disk0s2 de 100 Go (volume dénommé : Partition 1), d'autre part sur ta partition /dev/disk0s4 de 148 Go (volume dénommé Macintosh Yosemite) - dans les 2 cas l'installateur en a profité pour greffer un format CoreStorage sur chacune des partitions, comme il en a l'instruction préalable. Ce format asseoit un Disque Physique Virtuel sur chacune des partitions d'accueil qui "écrase" de sa présence le Disque Physique Réel tout en servant de support à un Volume Logique - le tout solidarisé dans une structure globale dite Groupe de Volumes Logiques. L'inconvénient que tu subis est que le Disque Physique Réel est inadressable aussi longtemps qu'il supporte un CoreStorage - d'où tes échecs à opérer un repartitionnnement.

Heureusement pour toi, chacun des
CoreStorages actuellement en place sur les 2 partitions /dev/disk0s2 et /dev/disk0s4 est déclaré réversible, ce qui veut dire qu'une paire de commandes dans le «Terminal» peut supprimer ce format en restaurant le format standard jhfs+ (Mac OS étendu journalisé) de manière non_destructrice pour les Systèmes de fichiers en place --> tu peux donc appliquer une telle commande non seulement à ton Partition 1 mais aussi à ton Macintosh Yosemite, sans problème pour les OS ni pour leurs données. Tu es forcé de supprimer les 2 CoreStorages, sans quoi tu ne pourrais pas manipuler les partitions de ton disque (effet de verrouillage).


Donc, va à Applications/Utilitaires et lance le «Terminal». Dans la fenêtre de type traitement de texte spartiate qui s'affiche, saisis d'abord exactement la commande suivante (copier-coller) :

Bloc de code:
sudo diskutil coreStorage revert FE004B8A-4034-4C18-96D0-4438AA23FCCE

et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande) --> une demande de
password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> en retour de commande, tu vois s'afficher progressivement :

Bloc de code:
Started CoreStorage operation on disk2 Partition 1
[FONT=Arial]Switching partition from Core Storage type to original type
Reclaiming space formerly used by Core Storage metadata
Ejected Logical Volume
Removing Physical Volume
Destroying Logical Volume Group
Remounting former Physical Volume as normal disk
Core Storage LV UUID: FE004B8A-4034-4C18-96D0-4438AA23FCCE
Core Storage disk: disk0s2
Finished CoreStorage operation on disk2 Partition 1

suite à quoi le format CoreStorage greffé sur la partition /dev/disk0s2 et correspondant au volume Partition 1 vient d'être logiquement oblitéré. Comme le volume concerné n'a pas encore "ré-atterri" sur l'emplacement correspondant du disque réel suite à l'élimination du Disque Physique Virtuel (situation instable à prolonger), je préconise qu'avant de passer la 2è commande tu re-démarres ton Mac.


Cela fait, et retourné dans le «Terminal», enchaîne par un copier-coller de :

Bloc de code:
sudo diskutil coreStorage revert F61B7044-35CC-4B63-88F5-2839B19EC709

et ↩︎ +
password + ↩︎ --> tu obtiens cette fois-ci le retour de commande progressif suivant :

Bloc de code:
Started CoreStorage operation on disk1 Macintosh Yosemite
[FONT=Arial]Switching partition from Core Storage type to original type
Reclaiming space formerly used by Core Storage metadata
Ejected Logical Volume
Removing Physical Volume
Destroying Logical Volume Group
Remounting former Physical Volume as normal disk
Core Storage LV UUID: F61B7044-35CC-4B63-88F5-2839B19EC709
Core Storage disk: disk0s4
Finished CoreStorage operation on disk1 Macintosh Yosemite

suite à quoi le format
CoreStorage greffé sur la partition /dev/disk0s4 et correspondant au volume Macintosh Yosemite vient d'être logiquement oblitéré (la reversion du format CoreStorage est supportée en mode 'live' sur le Système de fichiers de l'OS démarré) --> pour la même raison que précédemment, je préconise que sans attendre tu re-démarres ton Mac encore.


--> J'avais envisagé pour terminer de te proposer une commande de fusionnement de partitions, mais je viens de m'aviser que le volume que tu souhaites conserver (Macintosh Yosemite] est situé en 4è position (
/dev/disk0s4) --> si c'est bien le cas, il ne t'est pas possible directement de ré-agréger à son volume celui qui le précéde (Partition 1 en /dev/disk0s2), car il y a toujours un ordre "ascendant" et pas "descendant" à respecter pour ce faire. Il conviendrait pour repréciser les choses que tu repasses la commande diskutil list pour confirmer l'état des lieux et ce que tu souhaites vraiment faire à ce point.


Merci énormément cette manip a marché !!
MERCI BEAUCOUP !!!!!!!! :happy::happy::happy::)
 
Oui ! macomaniac est redoutable de pertinence et d'efficacité ! Il m'a aussi résolu deux gros problèmes récemment.
Gloire à macomaniac ! Il lui faudra au moins une statue !
 
Salut @macomaniac ! Bon, je vais t'expliquer mes problèmes, mais commencer par l'actuel... J'ai à priori le même problème sur mon Mac, j'avais fait un test de partition de 5go sous Lion en début d'après-midi, puis je l'ai supprimé, je ne le voyais plus. Je viens de réinstaller Yosemite et voici ce que mon utilitaire de disque me montre, je ne comprends pas...

http://www.hostingpics.net/viewer.php?id=434309Capturedcran20150910231415.png

http://img15.hostingpics.net/pics/699865Capturedcran20150911001959.png

http://img15.hostingpics.net/pics/563891Capturedcran20150911002059.png

Je n'arrive pas à me débarrasser de cette petite partition, et je ne comprends pas pourquoi mon SSD est affiché ainsi... Sachant que tout à l'heure sous Lion, il était affiché correctement !

Si j'ai tout formaté, c'est parce-que j'ai fait n'importe quoi hier soir en voulant installer windows 7, j'avais de gros problème au niveau de l'installation, mais ça j'y reviendrai plus tard si tu le veux bien, en t'expliquant en détail ce que j'ai fait.

Merci d'avance pour ta réponse
 
Salut Jordan.

L'installateur de «Yosemite» recèle une instruction qui lui fait greffer - à l'insu du plein gré de l'utilisateur - un format spécial sur la partition d'accueil de l'OS : le format CoreStorage. Ce format encapsule dans une architecture logique complexe (= un Groupe de Volumes Logiques) le système de fichiers terminal : jhfs+ (Mac OS étendu journalisé) qui contient les écritures de l'OS. Ce format est une "pile d'instances logiques" ("logical pool" ou "logical stack") dont l'enveloppe globale est le Logical Volume Group et dont les 3 instances constituantes (piles ou couches logiques) sont : en bas, un Physical Volume (Conteneur logique qui émule un disque dur - comme un .dmg - importé sur la partition-Système /dev/disk0s2 de la table de partition GUID) ; au milieu, une Logical Volume Family (instance qui recèle les paramètres définissant le type de volume montable à partir du disque dur émulé : chiffré ou non par exemple) ; en haut, un Logical Volume (volume logique exporté à partir des instances précédentes et qui recèle le système de fichiers terminal de l'OS).

Cette création est, disons, assez mal "perçue" par l'«Utilitaire de Disque» : ce logiciel graphique ne parvient plus à représenter le disque dur physique du Mac (le disque qui s'affiche normalement tout en haut de la colonne de gauche), comme si l'architecture logique du CoreStorage le lui cachait, mais affiche à la place un "corps de remplacement" : le Groupe de Volumes Logiques édifié sur la partition-Système du disque. C'est ce que montre ton 1er cliché, qui mentionne "Groupe de Volumes Logiques" comme type correspondant à la 1ère ligne d'affichage.

De surcroît, lorsqu'un format CoreStorage est créé automatiquement par l'installateur de «Yosemite», si le nom du Volume Logique exporté est emprunté à l'identique au nom que l'utilisateur avait choisi à l'origine pour la partition-Système de son disque (par exemple Macintosh HD, si l'utilisateur avait laissé l'intitulé par défaut) ; l'«Utilitaire de Disque» qui, comme le singe de la fable, «prend le Pirée pour un homme" (càd. confond le Groupe de Volumes Logiques avec un disque dur matériel à représenter en tête d'affiche), ne sait pas sous quel intitulé l'afficher, à la différence des disques durs réels qu'il affiche sous l'intitulé de leur taille + nom de marque fabricatrice + numéro d'usine (par exemple : 1,02 To Crucial_CT1024M550SSD1 Media) - parce que ce qu'il exhibe à l'instar d'un disque dur matériel n'en est pas un, mais un stack logique qui le recouvre --> alors, comme "solution de secours nominale", il affiche en "pseudo nom de disque" un nom emprunté à celui du Volume Logique : il va donc dénommer le Groupe de Volumes Logiques affiché en lieu & place de disque dur du même nom que le Volume Logique exporté. Ce sera donc Macintosh HD, si le nom du Volume Logique est Macintosh HD d'après l'intitulé de volume par défaut que l'utilisateur aurait laissé. Si, comme toi, la partition-Système avait été renommé SSD, alors à la création d'un CoreStorage, le Volume Logique ayant repris l'intitulé : SSD, l'«Utilitaire de Disque» va afficher le Groupe de Volumes Logiques en lieu et place de disque de tête sous le nom recopié du volume : SSD --> chaque fois que dans la colonne de gauche de l'«Utilitaire de Disque», il y a redondance nominale de l'intitulé du "disque" et de l'intitulé du "volume", alors tu peux être sûr à 100% qu'un format CoreStorage existe sur la partition-Système.

Enfin, pour couronner le tout, lorsqu'un format CoreStorage existe sur la partition-Système du disque du Mac, l'«Utilitaire de Disque» souffre d'une limitation dans son menu "Partitionner" qui ne peut pas cibler le disque dur matériel (comme dans le mode standard) pour manipuler la Table de Partition GUID en mode brut ; mais qui ne peut donc cibler que le Groupe de Volumes Logiques qui repousse le disque dur matériel à l'arrière-plan de l'affiche pour simplement re-partitionner le seul Volume Logique exporté (sans pouvoir manipuler la Table de Partition GUID globale mais seulement le secteur qui porte le CoreStorage, parce que l'«Utilitaire de Disque» le confond avec un disque réel du fait que le conteneur d'un Physical Volume émule logiquement un disque dur à cet emplacement --> l'«Utilitaire de Disque» n'arrive plus à voir le disque physique réel en-dessous du disque logique émulé) --> cette limitation produit des effets en cascade ainsi : il n'est jamais possible de repartitionner le Volume Logique exporté a) en plus de 2 partitions et b) plus d'une fois (croquignolet, non ?). Et, dernier effet limitatif en cascade, il arrive qu'une partition qui avait été créée hors CoreStorage par un repartitionnement du Volume Logique, puis supprimée (càd. virée en tant qu'espace-disque d'une taille déterminée au statut de "Free_Space" = espace libre hors table de partition GUID) - ne puisse pas être réallouée dans son espace-disque au Volume Logique du CoreStorage. Non parce que c'est impossible intrinsèquement, mais parce que le logiciel graphique qu'est l'«Utilitaire de Disque» voit ses scripts de coulisse (dont l'exécution est déclenchée par l'utilisateur via des clics sur des boutons de la GUI du logiciel) se prendre les pieds dans le tapis...

Il faut alors : soit recourir au «Terminal» pour passer une commande atomique de récupération de l'espace libre au Volume Logique si on ne veiut pas toucher au CoreStorage ; soit supprimer l'architecture globale du CoreStorage pour remettre l'«Utilitaire de Disque» droit dans ses bottes et récupérer des manipulations de la table de partition à même le plancher des vaches...

Dans tous les cas de figure, il faut récupérer des informations sur le CoreStorage (notamment l'UUID = IDentifiant Unique Universel de telle ou telle instance) permettant de passer une commande soit de récupération du Free_Space, soit de réversion du CoreStorage sans perte du système de fichiers terminal (à condition que ce soit possible - ce qui n'est pas toujours le cas), soit carrément de suppression destructrice (qui implique une sauvegarde préalable des données). Je t'invite donc à aller à : Applications/Utilitaires et à lancer le «Terminal» pour saisir dans le fenêtre qui s'affiche la commande :

Bloc de code:
diskutil cs list

et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> cette commande invoque le programme UNIX : diskutil (le même que pilote graphiquement l'«Utilitaire de Disque» mais susceptible d'ête invoqué par des commandes atomiques plus fines dans le «Terminal») avec la spécificité coreStorage ("cs" en abrégé) et le verbe d'orientation list (= "lister") --> en retour, tu vois s'afficher le tableau imposant du Groupe de Volumes Logiques avec ses 3 instances souscrites --> est-ce que tu peux sélectionner au pointeur les lignes de ce tableau, par ⌘C les copier dans le presse-papier et par ⌘V les coller ici (pas de cliché) ? Il sera possible de te proposer l'une ou l'autre commande permettant de résoudre ton problème.
 
Dernière édition par un modérateur:
Tout d'abord merci pour ta réponse complète qui me permet de mieux comprendre d'où vient le problème !
Voici mon résultat :

CoreStorage logical volume groups (1 found)

|

+-- Logical Volume Group 0CC268EC-8343-4731-ADAF-BB812A54E662

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

Name: SSD

Status: Online

Size: 122199588864 B (122.2 GB)

Free Space: 19005440 B (19.0 MB)

|

+-< Physical Volume 60F4D57B-E7B3-4ECF-BA28-F08E1897A5EE

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

| Index: 0

| Disk: disk0s2

| Status: Online

| Size: 122199588864 B (122.2 GB)

|

+-> Logical Volume Family B8EDB677-A3C2-4567-A677-01C8C342D1FF

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

Encryption Status: Unlocked

Encryption Type: None

Conversion Status: NoConversion

Conversion Direction: -none-

Has Encrypted Extents: No

Fully Secure: No

Passphrase Required: No

|

+-> Logical Volume 2C094683-6005-4FB4-832C-793AF83B0AAD

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

Disk: disk2

Status: Online

Size (Total): 121828261888 B (121.8 GB)

Conversion Progress: -none-

Revertible: Yes (no decryption required)

LV Name: SSD

Volume Name: SSD

Content Hint: Apple_HFS


J'en profite pour te parler dès à présent du problème que j'ai eu pour installer Windows 7 sur une partition bootcamp car peut-être pourrais-tu m'aider directement avec le Terminal. Je suis sur un Macbook Pro début 2011, j'ai retiré mon lecteur disque pour y installer mon SSD et j'ai gardé ainsi mon HDD... Il m'a fallu changé le fichier info.plist de Bootcamp car quand je le lançais, j'avais un message d'erreur me disant que je ne pouvais pas installer windows sans lecteur CD. La manipulation est faite, mon bootcamp marche correctement.. Le problème que j'ai eu venait au moment de l'installation de Windows en sélectionnant ma partition bootcamp (sur mon SSD où il y avait déjà Yosemite). Je n'ai pas le message exact mais j'avais grossomodo : "Windows ne peut pas être installé sur ce disque en partition MBR. Windows ne peut être installé que sur un disque en GPT". C'est à partir de ce moment là que j'ai bidouillé dans le Terminal jusqu'à ce que je ne puisse plus du tout accéder à Yosemite. N'étant pas professionnel du tout en la matière, j'ai voulu y aller trop rapidement et résultat des courses : j'ai dû formaté mon Mac...
Si tu as des réponses quant à ce problème de partition MBR, GPT, je suis preneur !

Merci encore, j'attends tes réponses
 
Si tu te reportes aux informations de la dernière instances du Groupe de Volumes Logiques : le Logical Volume, tu lis notamment la phrase euphorisante :

Bloc de code:
Revertible: Yes (no decryption required)
qui signifie qu'il peut y avoir volatilisation du format CoreStorage sans suppression du système de fichiers jhfs+ terminal qui contient ton OS (avec ton compte d'utilisateur et tes données). Cette opération est parfaitement supportée en mode "live" (l'OS démarré à destination de sa propre partition) sans aucun souci. Je t'invite donc à faire un copier-coller direct dans la fenêtre du «Terminal» de la commande :

Bloc de code:
sudo diskutil coreStorage revert 2C094683-6005-4FB4-832C-793AF83B0AAD
et ↩︎ --> une demande de password s'affiche (commande sudo requérant des droits root) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> tu vas voir se dérouler les informations de suppression du CoreStorage [la commande invoque encore le programme diskutil - assorti d'une demande de droits root - et la spécificité coreStorage avec le verbe revert ("opérer la réversion de format") et comme cible d'objet l'UUID de 32 caractères alpha-numériques du Volume Logique]. Au réaffichage de l'invite de commande de type : jordan$ (signe de complétion de l'opération), re-démarre impérativement ton Mac (car le kernel -noyau opérateur de l'OS- n'avale pas du tout ce changement brutal de données de partitionnement, mais continue de garder chargée l'ancienne donne - ce qui est risqué en cas de prolongation des manipulations sur les partitions).

--> ta session ré-ouverte, relance l'«Utilitaire de Disque» : l'affichage du partitionnement devrait être redevenu standard, et je conjecture que tu dois pouvoir récupérer graphiquement ton espace libre de 5 Go au menu "Partitionner", simplement en abaissant la ligne de base du rectangle de ton volume SSD pour lui faire absorber l'espace grisé (un des privilèges du format HFS+ est son élasticité) --> presse le bouton "Appliquer". Si ce n'était pas le cas, déclare-le.

[Pour ce qui est de la question de ta partition «BootCamp» - j'y reviendrai plus à loisir dans un autre message (dans les limites de ce que j'en peux concevoir).]
 
  • J’aime
Réactions: Jordan Mxchxn
Merci... MERCI ! Étant donné que j'avais déjà recrée une partition Bootcamp, j'ai dû supprimer cette dernière pour avaler l'espace grisé qui se situait en dessous... Tout a marché parfaitement ! Tu viens de m'enlever une première épine du pied...

En ce qui concerne l'installation de windows 7.. J'ai préparé ma clé bootable sur Pc avec le logiciel "Rufus".. Je te donne les caractéristiques que j'ai coché, si cela peut t'aider...

"Type de partition et système de destination" : Type de partition MBR pour BIOS ou EUFI
"Système de fichiers" : NTFS

Ma clé est prête comme je te l'ai dit, mais étant donné qu'elle a été préparé en NTFS, je ne peux pas rajouté les drivers bootcamp pour Windows téléchargeables sur le site Apple. Je les ai donc mis sur une autre clé.

Je me permets de te dire que ce problème de disque en partition MBR et disque GPT est visiblement très courant, je suis loin d'être le seul à avoir ce problème (que ce soit sur Mac ou sur Windows d'ailleurs). Je me permets également de te dire qu'une personne dit que le problème viendrait peut être de la partition bootcamp crée, et que lui, il a crée manuellement une partition sur son SSD et n'a plus eut ce problème au niveau de l'installation.

Avant de me lancer dans quoi que ce soit, je préfère que tu éclaires ma lanterne à ce sujet, si possible.
 
Je reviens vers toi @macomaniac car j'ai effectué un petit test en attendant... Comme je te l'ai dit auparavant, grâce à toi mon SSD et revenu à la normal, grâce à ta commande.. MAIS, car oui il y a un MAIS, il m'est devenu compliqué de créer une partition bootcamp désormais, je t'ai fait un screenshot : http://img11.hostingpics.net/pics/534840Capturedcran20150911162914.png

2ème point... Ayant des difficultés pour créer une partition bootcamp depuis l'utilitaire bootcamp, j'ai crée une partition directement depuis l'utilitaire de disque pour y allouer mon Windows... Et devine quoi ? J'ai le même message d'erreur qu'avant-hier, à savoir (et je l'ai prit en photo pour avoir les termes exacts) : Windows ne peut pas être installé sur ce disque. Le disque sélectionné possède une table de partition MBR. Sur les système EFI, Windows peut uniquement être installé sur des disques GPT

Me voilà au point de départ...

Je précise que ce message s'affiche dès le début quand je sélectionne ma partition pour l'install, et s'affiche même après avoir formaté la partition en question...

Je sais qu'il y a une solution, je l'ai lu sur un forum anglais expliquant quelques manipulations à prendre avec le Terminal.. Mais je ne veux plus jouer avec ces manipulations avant d'être sûr de mon coup (malgré que je viens de sauvegarder mon disque avec Time Machine, par précaution)

Source de la solution (à priori) : http://superuser.com/questions/508026/windows-detects-gpt-disk-as-mbr-in-efi-boot
 
Dernière édition:
Salut Jordan.

Je vois que tu es tiré d'affaire en ce qui concerne le CoreStorage intempestif.

Pour ce qui est de la création d'une partition Windows bootable, je suis terriblement limité en compétence par rapport au domaine du CoreStorage, pour 2 raisons qui se composent : d'abord, mon inintérêt radical pour Windows, que je n'ai jamais utilisé ni chez moi ni hors de chez moi - ce qui n'est pas peu dire ; ensuite, mon absence complète d'expérience touchant le logiciel «BootCamp» que je n'ai jamais lancé (pour la raison susdite, qui implique que je n'ai pas de quoi installer Windows à la suite). Si tu es en quête de tuyaux pour installer Windows sur une partition créée par «BootCamp», je crois qu'il vaudrait mieux que tu poses une question sur le forum : Windows sur Mac où tu trouveras du répondant.

J'ai quand même fait tout récemment mes "grands débuts" sur le sujet dans le fil que voici : ☞Remettre à 0 un fusiondrive pour retrouver la config de départ ?☜ où tu remarqueras que le diabolique cheb avait, exactement comme toi, réussi à ferrer mon attention grâce à l'appât du CoreStorage (un Fusion Drive n'étant qu'un CoreStorage qui gère 2 disques au lieu d'un seul) pour ensuite me refiler la patate chaude « BootCamp-Windows ». Malgré l'échec dont témoigne ce dernier fil, mon intérêt pour la question "Windows" a fini par s'éveiller de la plus indirecte des manières : pas concernant l'OS qui me reste aussi indifférent qu'auparavant ; mais par rapport à la problématique des Tables de Partitions qui se trouve impliquée par son installation.

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

Je peux peut-être (très théoriquement) apporter un éclairage latéral sur ce point qui fait aussi l'objet de ta demande :

Si tu as des réponses quant à ce problème de partition MBR, GPT, je suis preneur !

Lorsqu'on a affaire à un EFI-based Computer : un Mac, dont le Programme Interne de pré-boot (firmware) est l'EFI, alors un disque démarrable (et pas de simple stockage) doit nécessairement supporter une Table de partition GPT (GUID Partition Table), qui "mappe" (cartographie) les blocs du disque en les affectant a priori à des secteurs logiques qui sont des partitions, la 1ère partition par défaut étant l'ESP (EFI System Partition de 209 Mo recelant le répertoire EFI, avec les exécutables Apple, requis par le Programme Interne du Mac pour sa connexion au disque). Cette Table GPT est inscrite sur le secteur 0 du disque, qui est son secteur d'enclenchement du démarrage logique.

Sans épiloguer, disons qu'après prise en charge du secteur 0 contenant la Table GPT, l'EFI est capable de prendre le bon aiguillage vers une partition déterminée de la table GPT qui supporte un OS X et d'exécuter le fichier démarreur de l'OS recelé dans son système de fichiers avant de replier ses gaules mission terminée.

----------
Là où les choses deviennent intéressantes en se compliquant, c'est que les ingénieurs de la  n'étaient pas sans savoir que d'autres systèmes qu'OS X existent en concurrence, qui sont susceptibles de se retrouver installables et démarrables sur un Mac (Windows, Linux) sans requérir une Table de Partition GPT, mais au contraire une Table de Partition MBR pour ce faire. Le danger étant que des logiciels d'installation de ces systèmes divergeant dans leurs requêtes de Table de Partition n'aille s'attaquer à la Table de Partition GPT du secteur 0 du disque d'un Mac afin de la convertir en MRB pour qu'un OS alternatif soit démarrable sur le Mac. Avec la conséquence qu'OS X serait par là complètement planté, l'EFI réclamant un Système installé sur un secteur déterminé d'une table GPT existante et lisible.

Pour pallier ce danger, ils ont imaginé de doubler la Table GPT directrice du disque d'un Mac d'une Table de Partition protectrice, jouant le rôle par défaut de "gilet para-balles" de la table GPT : une table "Protective MBR". Cette table "mappe" a priori les blocs du disque (sur des très gros disques : avec une limite d'extension de 2 To, au-delà dequels les blocs excédentaires deviennent pour elle de l'espace libre hors partitionnement), mais selon la spécificité suivante : pas de secteur de boot (comme l'ESP pour la table GPT), et un seul secteur en tout et pour tout = une mono-partition globale "mappant" tous les blocs cartographiables logiquement.

C'est cette partition secondaire : la "Protective MBR" qu'adressent les logiciels impliqués dans l'installation d'un système alternatif à OS X, et pas la partition GPT directrice qui doit absolument conserver son intégrité afin d'être utilisable par l'EFI. Oui, mais cette table de partition secondaire = "Protective MBR", en l'état, est inutilisable pour l'installation/démarrage d'un OS alternatif, car elle n'offre qu'une mono-partition globalisante qui concerne tous les blocs du disque, alors qu'OS X est pour sa part déjà installé en écriture sur les blocs relevant d'une partition GPT --> il ne s'agirait pas d'aller sur-écrire ces blocs, parce que "mappés" avec tous les autres par la mono-partition "Protective MBR". Non : il faut que le système alternatif s'écrive sur les blocs relevant d'une partition strictement congruente d'un secteur prédéterminé de la table GPT directrice. Il ne faut pas qu'il y ait de chevauchements indûs, mais, du moins pour la seule partition requise à l'installation d'une système alternatif, il faut, afin que le même espace-disque soit ciblé, qu'il y ait superposition logique exacte entre une partition préexistante dans la Table GPT directrice et une partition conséquente dans la table MBR : la seule que l'installateur d'un système alternatif, ou l'émulateur de BIOS pouvant le démarrer, sache reconnaître.

----------
La solution de cette "quadrature du cercle" est la génération d'une Table du 3è type, dénommée : "Hybrid MBR", qui est le produit d'une conversion de la "Protective MBR" intiale en une Table MBR qui fasse écho, dans son sous-partitionnement, au moins à une partition prédéterminée de la Table GPT : la partition d'accueil prévue pour le système alternatif. Il n'est pas besoin, en effet, que la "Protective MBR" soit convertie en un clone intégral "modo MBR" du partitionnement GPT pré-existant : il faut et il suffit qu'une au moins des partitions GPT pré-établies, celle dédiée à l'installation du système alternatif, soit "re-mappée" à l'intérieur de la table MBR pour être congruente de la partition GPT (donc qu'il n'y ait pas de divergences de blocs d'écritures concernés). Il faut donc à toute force générer une table "Hybrid MBR" dans laquelle au moins une partition existe qui soit du type : "GPT=>MBR" : lisible par l'installateur/émulateur de BIOS alternatif, mais congruente logiquement avec la partition GPT préexistante de la table GPT sous peine de corruption de cette dernière.

----------
D'après ce que j'ai compris, la tâche essentielle de l'«Assistant BootCamp» concerne justement cette problématique : il s'agit de la part de ce logiciel de faire 2 choses successives : 1° de repartitionner la Table GPT directrice pour créer une nouvelle partition GPT exactement comme l'«Utilitaire de Disque» pourrait le faire pour créer le support d'un nouveau volume (de stockage ou d'OS X) ; 2° de convertir la table "Protective MBR" en place en une table "Hybrid MBR", dans laquelle le "mappage" des blocs mono-partition de la 1ère, inexploitable en l'état, soit transformé en un "sous-mappage" spécifique, déterminant une néo-partition MBR congruente strictement de la néo-partition GPT créée au préalable. Cette tâche accomplie, un installateur de Windows par exemple, qui ne reconnaît qu'une table MBR et aucunement une GPT, est capable d'identifier l'existence d'une partition MBR (compatible GPT) comme espace d'installation de l'OS alternatif.

Apparemment, c'est lors du 2è processus (conversion "Protective MBR" => "Hybrid MBR") que l'«Assistant BootCamp» ratatouille plus souvent que voulu, en étant incapable de produire la table "Hybrid MBR" ad-hoc. Mes carences expérimentales, ici, m'empêchent d'en savoir plus sur le "pourquoi du comment". Que se passe-t-il, par exemple, lorsqu'une partition «BootCamp» préalable qui avait marché n'est pas "convenablement désinstallée" par ce même «BootCamp», mais supprimée par l'«Utilitaire de Disque» ? Il est clair qu'une table de partition "Hybrid MBR", intégrant l'ancien partitionnement, demeure en place en doublure de la GPT. Qu'arrive-t-il si l'on relance «BootCamp» pour lui demander la création d'une néo-partition destinée à Windows ne correspondant pas au mappage" précédent de la "Hybrid MBR" en place ? «BootCamp» sait-il ré-initialier une "Hybrid MBR" => "Protective MBR" par défaut, pour recommencer à zéro, ou s'embrouille-t-il les pinceaux ? Y a-t-il d'autres facteurs explicatifs des ratages de «BootCamp» ? Toujours est-il que le point d'achoppement me paraît toujours le même : plantage du processus n°2 = conversion d'une "Protective MBR" mono-partition en une "Hybrid MBR" recelant une partition "GPT-congruente"...

--------------------
 
Dernière édition par un modérateur: