OS X : Partition récupération (infos/problèmes)

[lebossonnet]

Salut

C'est sous El Capitan et non SL qu'il faut passer les commandes.

@+

Bonjour,
Eh oui… merci beaucoup résultat ok.

 

[Deleted member 1099514]

Bonjour,
Eh oui… merci beaucoup résultat ok.

Pas de quoi.

 

[lebossonnet]

Salut Ardienn.

Le type d'affichage dans l'«Utilitaire de Disque» que tu décris me parais un effet induit par un format CoreStorage que l'installateur d'«El Capitan» aurait greffé automatiquement ("à l'insu de ton plein gré") sur la partition d'accueil de cet OS (l'installateur de «Yosemite» ayant déjà fréquemment créé ce type de format sur la partition d'accueil de cet OS - il semble que celui d'«El Capitan» persévère dans la même voie...).

Le format CoreStorage encapsule la partition d'accueil concernée dans un dispositif logique complexe = Groupe de Volumes Logiques consistant en 3 instances superposées : à la base, la partition physique du disque se trouve convertie en un Physical Volume (Disque Physique Virtuel) ; au milieu, une Logical Volume Family (Famille de Volumes Logiques) est créée qui est l'interface de pilotage du groupe ; au sommet, un Logical Volume (Volume Logique) se trouve exporté, qui a l'apparence pour l'utilisateur d'un volume standard.

Dès qu'une formation CoreStorage se trouve greffée sur une partition de disque, quel que soit le rang de cette partition dans le dispositif d'ensemble de la Table de Partition GUID du disque, alors elle induit un "effet d'affichage graphique" spécial dans l'«Utilitaire de Disque» : le Disque Physique Réel (ici : ton SSD matériel) cesse de pouvoir être représenté graphiquement, et ce qui se substitue à lui en tête d'affiche comme "Disque Unique Apparent", c'est le Groupe de Volumes Logiques entier qui se trouve encapsuler la partition partitulière de la Table de partition GUID. Ce Groupe de Volumes Logiques (l'architecture globale) emprunte son intitulé au Volume Logique qui s'en trouve exporté au final. Si donc le Volume Logique dans lequel se trouve installé ton «El Capitan» s'intitule Macintosh HD, alors tu vois s'afficher une redondance nominale en tête d'affiche de l'«Utilitaire de Disque» de type :

Macintosh HD
---Macintosh HD

où le 1er Macintosh HD représente le Groupe de Volumes Logiques global qui joue un rôle d'écran dissimulant le Disque Physique Réel du SSD et le soustrayant à l'affichage ; et le 2è Macintosh HD représente le Volume Logique exporté en 3è instance par le groupe CoreStorage entier.

Suppose qu'à la racine la Table de Partition GUID de ton SSD corresponde à ceci ("dev" abrège "devices" : support d'écriture ; "disk0" désigne par défaut le disque en connexion SATA ; "s" désigne le "secteur" du disque = partition) :

SSD = /dev/disk0
---EFI (petit en-tête par défaut de 209 Mo) = /dev/disk0s1
---Macintosh HD (le volume de ton «Yosemite») = /dev/disk0s2
---Recovery HD (la partition de récupération 10.10.3 de ton «Yosemite) = /dev/disk0s3
---Macintosh HD (le volume de ton «El Capitan») = /dev/disk0s4
---Recovery HD» (le volume de récupération 10.11.bêta de ton «El Capitan») = /dev/disk0s5

et introduis dans ce schéma un format CoreStorage sur la partition : /dev/disk0s4 = Macintosh HD (le volume de ton «El Capitan») --> alors l'affichage dans l'«Utilitaire de Disque» va devenir (par l'effet de masquage du Disque Physique Réel induit par le CoreStorage) :

Macintosh HD (Groupe de Volumes Logiques global greffé sur la /dev/disk0s4 et volant l'affiche au Disque Physique Réel)
---Macintosh HD (le volume de ton «El Capitan») = /dev/disk0s4
---EFI (en-tête de 209 Mo) = /dev/disk0s1
---Recovery HD» (le volume de récupération 10.11.bêta de ton «El Capitan») = /dev/disk0s5
---Macintosh HD (le volume de ton «Yosemite») = /dev/disk0s2
---Recovery HD (la partition de récupération 10.10.3 de ton «Yosemite) = /dev/disk0s3

Comme l'«Utilitaire de Disque» dont le menu spécial "Déboguer" n'est pas activé par défaut n'affiche pas les partitions graphiquement invisibles, ce dispositif se réduit chez toi à :

Macintosh HD (Groupe de Volumes Logiques global greffé sur la /dev/disk0s4 et volant l'affiche au Disque Physique Réel)
---Macintosh HD (le volume de ton «El Capitan») = /dev/disk0s4
---Macintosh HD (le volume de ton «Yosemite») = /dev/disk0s2

Soit, si ton «Yosemite» est symbolisé par A et ton «El Capitan» par B, l'affichage :

B (Groupe de Volumes Logiques greffé sur la partition /dev/disk0s4 et volant l'affiche au Disque Physique Réel)
---B (Volume Logique «El Capitan» exporté par le Groupe de Volumes Logique)
---A (Volume Standard «Yosemite» de la partition /dev/disk0s2)

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

Comme tu vois, c'est un effet de distorsion de l'affichage graphique dans l'«Utilitaire de Disque» sous l'effet d'hégémonie du format CoreStorage sur le format jhfs+ standard.

Si tu veux y voir plus clair, je t'invite (dans ta session de «Yosemite») à aller à : Applications/Utilitaires pour lancer le «Terminal». Dans la fenêtre qui s'ouvre, si tu saisis d'abord la commande (purement informative) :

diskutil list

et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> en retour de cette commande [= invocation du programme UNIX diskutil, et impératif verbal d'action : liste ! <les devices ou supports d'écriture>], tu vois s'afficher le Tableau de partition GUID réel de ton SSD, avec la distribution de ses partitions selon leur ordre génétiquement constitué (c'est la table des devices effective).

Si à présent tu enchaînes avec la commande (encore informative) :

diskutil cs list

et ↩︎ --> en retour de cette commande [= invocation du programme UNIX diskutil, et impératif verbal d'action : liste ! restreint au domaine "cs" = abrégé de "CoreStorage" <les devices ou supports d'écriture exclusivement porteur d'un Groupe de Volumes Logiques>], tu vois s'afficher le tableau du Groupe de Volumes Logiques dont dépend ton «El Capitan».

--> si tu sélectionnais au pointeur dans la fenêtre du «Terminal» (pas de photo !) chacun de ces tableaux pour les copier l'un après l'autre dans ce fil, je pourrais gloser davantage sur la distribution logique actuelle de ton SSD (voire indiquer un moyen de faire sauter le format CoreStorage afin de faire cesser la déformation d'affichage dans l'«Utilitaire de Disque» - tout dépend des informations mentionnées).

Tant que tu es dans le «Terminal», fais donc un copier-coller de la commande :

defaults write com.apple.DiskUtility DUDebugMenuEnabled 1

et ↩︎ --> re-démarre ton Mac dans la foulée et re-boote sur ton «Yosemite» pour lancer l'«Utilitaire de Disque» --> tu t'aperçois qu'un nouveau menu s'affiche dans la barre de menus supérieure de l'utilitaire : le menu "Déboguer" (la commande dans le «Terminal» consiste à activer ce menu dormant) --> déroule les sous-menus et coche le pénultième : "Afficher chaque partition" --> désormais ton «Utilitaire de Disque» "voit" les partitions invisibles : l'«EFI», les «Recovery HD» et les cartes d'amorçage Boot OS X du dispositif CoreStorage, ce qui peut te permettre d'y voir plus clair. Sans néanmoins modifier l'effet perturbateur de l'affichage induit par le CoreStorage.

[NB. Il se pourrait qu'il y ait eu déjà un CoreStorage sur la partition /dev/disk0s2 de ton SSD - l'installateur de «Yosemite» étant coutumier de cette facétie --> j'en ai fait abstraction dans ce qui précède, en supposant que l'effet "CoreStorage" n'était introduit que par l'installateur de ton «El Capitan»...]

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

[/QUOTE
Un grand merci pour tes explications (j'ai exposé mon pb beaucoup plus loin dans la discussion) résultat ok. Seule difficulté si la commande de débug de l'utilitaire de disque marche dans snow léopard elle refuse de fonctionner dans la version d'El capitan ?

 

[Membre supprimé 1060554]

Salut lebossonnet.

L'«Utilitaire de Disque» dans «El Capitan» est la contrefaçon minable de ce qui fut une grande application. Une misère logicielle. Entre autres pertes à déplorer : l'impossibilité désormais d'y activer le mode "Déboguer" par la commande classique dans le «Terminal». Conséquence : le défaut d'affichage des partitions graphiquement invisibles, comme l'EFI System Partition ou la Recovery HD.

 

[Sly54]

J'imagine assez bien que je vais devoir jouer du Terminal, mais comme je ne sais pas quelle commande entrer je préfère demander


Sur un de mes dd encore sous Snow Leopard, OmniDisksweeper (lancé en mode root) m'indique en gros 140 Go utilisés.
cmd i sur mon disque indique 411 Go utilisés (oops), confirmé par l'affichage d'Utilitaire de disque.

Je sais que j'ai fait une boulette, sûrement la cause de ce dysfonctionnement apparent : j'ai commencé à partitionner ce dd de 500 Go en deux partitions (170 Go et 330 Go) mais devant la lenteur de la chose (plus de 12 heures à bloquer ma machine), j'ai forcé l'extinction


Du coup, mes questions(qui sont liées) :

1. comment je retrouve un affichage normal (une libération de l'espace occupé, mais je ne sais pas ou), c'est-à-dire 140 Go utilisés ?
2. est ce que dans la foulée je peux partitionner mon dd via le Terminal (deux partitions 170 et 330 Go) ?

 

[Deleted member 1099514]

Salut @Sly54
Commence par donner le retour de :
diskutil list.

 

[Sly54]

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *600.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Paire_10000_Mav 599.8 GB disk0s2

/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *600.1 GB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Imp_10000 599.8 GB disk1s2

/dev/disk2 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *512.1 GB disk2

1: EFI EFI 209.7 MB disk2s1

2: Apple_HFS SSD_512 511.8 GB disk2s2

/dev/disk3 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk3

1: EFI EFI 209.7 MB disk3s1

2: Apple_HFS TimeM_SSD 999.9 GB disk3s2

/dev/disk4 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *500.1 GB disk4

1: EFI EFI 209.7 MB disk4s1

2: Apple_HFS Interne_SL 499.8 GB disk4s2

/dev/disk5 (disk image):

#: TYPE NAME SIZE IDENTIFIER

0: Apple_partition_scheme +41.0 MB disk5

1: Apple_partition_map 32.3 KB disk5s1

2: Apple_HFS ****MdP**** 41.0 MB disk5s2

 

[Deleted member 1099514]

C'est Interne_SL que tu veux repartitioner ?

 

[Sly54]

Oui, c'est ça.

 

[Deleted member 1099514]

La partition existante devrait être retaillée à quelle contenance? 170 Go
Et l'espace restant 330 Go en format Osx journalisé?
Là je fais le devin.

Question subsidiaire : quelle est la taille occupée par la partition Interne_SL ?
sudo du -sh /Volumes/Interne_SL

 

[Sly54]

Oui pour 170 Go (pour la partition qui contient mes données).
Oui pour la nouvelle partition, environ 330 Go (il faudrait que ça tombe juste par rapport à la taille du dd).

Quant à la commande, voilà la réponse :

131G /Volumes/Interne_SL

 

[Deleted member 1099514]

Ok

Pour être plus sûr on va d'abord vérifier la partition existante :
diskutil umount /dev/disk4s2
puis
fsck_hfs -fy /dev/disk4s2
Ensuite
diskutil mount /dev/disk4s2

 

[Deleted member 1099514]

Ensuite si tout se passe bien :
après avoir refait un
diskutil list
Pour vérifier que tout est ok.
il faudra faire :
diskutil resizevolume /dev/disk4s2 170g HFS+ "Le nom que tu veux" 0g

 

[Sly54]

Apr!s le fsck ci dessous

fsck_hfs -fy /dev/disk4s2

j'ai eu ce message :

** /dev/rdisk4s2 (NO WRITE)

Can't open /dev/rdisk4s2: Permission denied

Ensuite si tout se passe bien :
après avoir refait un
diskutil list

Le résultat de la commande est :

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *600.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Paire_10000_Mav 599.8 GB disk0s2

/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *600.1 GB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Imp_10000 599.8 GB disk1s2

/dev/disk2 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *512.1 GB disk2

1: EFI EFI 209.7 MB disk2s1

2: Apple_HFS SSD_512 511.8 GB disk2s2

/dev/disk3 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk3

1: EFI EFI 209.7 MB disk3s1

2: Apple_HFS TimeM_SSD 999.9 GB disk3s2

/dev/disk4 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *500.1 GB disk4

1: EFI EFI 209.7 MB disk4s1

2: Apple_HFS Interne_SL 499.8 GB disk4s2

 

[Membre supprimé 1060554]

Sly.

Comme ce feuilleton manque furieusement de l'aimable « liant » de la prose, je te propose une version herméneutique des « Cinq Commandements » de Jean :

- Commandement 1 ("Tu courberas la tête...") :

diskutil umount /dev/disk4s2

=> l'exécutable diskutil est invoqué avec le verbe umount («démonter») sur la cible du disk4s2 (la partition recelant le système de fichiers Interne_SL) afin qu'il soit démonté en volume. Pourquoi ? Car il faut toujours que le système de fichiers d'une partition soit démonté (et pas monté en volume) pour pouvoir exécuter sur lui une commande de réparation.

✻​

- Commandement 2 ("Tu réparerais tes fautes...") :

fsck_hfs -fy /dev/disk4s2

=> l'exécutable fsck_hfs (filesystem_check "vérification de système de fichiers" - orienté hfs = "Mac OS étendu") est invoqué sur la cible du système de fichiers démonté de la partition /dev/disk4s2 avec la double option -fy ("f" = force_clean : forcer le nettoyage des erreurs + "y" : assumer une réponse automatique "yes" = oui à toute question de droits d'opérer éventuelle => pas de mode interactif). Question : pourquoi faut-il réparer le système de fichiers ? Réponse : par précaution, car lorsqu'une commande de redimensionnement d'un volume est passée, il y a toujours vérification préalable de l'intégrité du système de fichiers concerné (sans modalité de réparation automatique), de sorte qu'en cas d'erreur trouvée, la commande spécifique de redimensionnement est résiliée (aborted).

Si Sly - après avoir suivi le Commandement 1 = démonter le système de fichiers de la partition /dev/disk4s2 - obtient en réponse un :

** /dev/rdisk4s2 (NO WRITE)

Can't open /dev/rdisk4s2: Permission denied

c'est le que le Commandement 2 ("Tu réparerais tes fautes...") doit lui-même réparer sa propre faute

= il faut préfixer de sudo cette commande de réparation sans interaction, lorsqu'elle adresse un système de fichiers démarrable dont le propriétaire est root => Commandement 2 ("Tu réparerais tes fautes...") réparé :

sudo fsck_hfs -fy /dev/disk4s2

=> il faut obtenir en sortie du processus le quitus :

** The volume Interne_SL appears to be OK.

marquant le succès de la réparation.

✽​

- Commandement 3 ("Tu relèveras la tête...") :

diskutil mount /dev/disk4s2

=> l'exécutable diskutil est invoqué avec le verbe "mount" (monter) afin de remonter en volume le système de fichiers Interne_SL de la partition /dev/disk4s2. Pourquoi ? Car pour passer une commande de re-dimensionnement de volume (comme celle qui va venir), il faut que le système de fichiers soit remonté en volume afin que son format soit lisible. Remontage avéré par l'attestation en sortie de commande :

Volume Interne_SL on /dev/disk4s2 mounted

❈​

- Commandement 4 ("Tu mesureras tes dépendances") :

diskutil list

=> l'exécutable diskutil est invoqué avec le verbe "list" (lister les partitions de disque) - sans nécessité (imho) dès lors que la réponse au Commandement 3 a bien été : "Volume Interne_SL on /dev/disk4s2 mounted".

❊​

- Commandement 5 ("Tu engendreras dans la douleur...") :

diskutil resizevolume /dev/disk4s2 170g HFS+ "Le nom que tu veux" 0g

=> l'exécutable diskutil est invoqué avec le verbe resizeVolume ("re-dimensionner_volume") sur la partition-cible /dev/disk4s2 au système de fichiers remonté, avec mention de la taille = 170g (170 Go) à instaurer pour cette partition de 499,8 Go au départ dont le système de fichiers, rétréci dans son mappage de blocks, sera conservé dans l'intégrité de ses données .

Se trouve rajoutée une option de création d'une partition secondaire par description se conformant à la triplette : [FORMAT][NOM][TAILLE] =>

● format : HFS+ = Mac OS étendu

● nom : "Le nom que tu veux" = invitation à renseigner dans la commande un intitulé de volume quodlibétique à encadrer entre "" pour le cas où il comporterait des espaces devant être neutralisés afin de désigner ensemble un objet unique

● taille : 0b = "zero_byte" : mention de taille équivalant à déclarer : « récupérer tout l'espace disponible - jusqu'à épuisement du dernier byte - existant en-dessous de la partition de 170 Go instaurée en-dessus » = espace disponible consistant en free_space, càd. espace-disque hors schéma de partitionnement GUID - ce qui sera le cas, car le retaillage de la partition /dev/disk4s2 de 499 Go à 170 Go, va libérer un espace-disque hors de ce partionnement équivalant à 329.9 Go de free_space, lequel sera spécifiquement réattribué à une néo-partition /dev/disk4s3 intitulée Le nom que tu veux d'une taille de 329.9 Go.
​

☞ En cas de succès de l'opération, le nouveau périmètre du disque 4 sera donné ainsi pour l'entrée correspondante dans la liste de partitionnement de tous les disques :

#:                  TYPE NAME                     SIZE              IDENTIFIER
0: GUID_partition_scheme                         *500.1 GB          disk4
1:                   EFI EFI                      209.7 MB          disk4s1
2:             Apple_HFS Interne_SL               170 GB            disk4s2
3:             Apple_HFS Le nom que tu veux       329.9 GB          disk4s3

❉​

 

[Deleted member 1099514]

Comme l'a dit si de façon si concise Macomaniac il manque un sudo devant la commande :
fsck_hfs -fy /dev/disk4s2 qui devient donc :
sudo fsck_hfs -fy /dev/disk4s2
Bien penser avant de démonter la partition :
diskutil umount /dev/disk4s2
et en cas de redémarrage , bien vérifier que l'ordre des partitions reste le même par un petit :
diskutil list
Puis faire la suite.

 

[Deleted member 1099514]

@Sly54

Alors ça a fonctionné?

 

[Sly54]

Je ne pourrai tester que ce soir et je vous tiendrai au courant

 

[Sly54]

Y E S !
Ca a marché, vous êtes des boss

Sans rigoler, un grand merci pour la concision de jean et la verve de macomaniac

 

[Deleted member 1099514]

Ça fait un équilibre.