10.12 Sierra Problème fusion partition ssd

QuickPwn

Membre confirmé
22 Septembre 2016
91
4
Bonjour,

Désolé du titre un peu banal, mais je ne savais pas quoi rajouter d'autres comme précision.

Suite à une manipulation, je me retrouve un peu dans l'embarras.

Je vous explique :

A la base, je dispose d'un ssd, sur lequel j'ai el capitan.
Suite à la sortie de sierra, je me suis dis, pourquoi ne pas partitionner mon ssd en 2 pour y installer sierra, et garder el capitan au cas ou...
De ce fait, je scinde en 2 mon ssd, avec l'utilitaire de disque.
Je télécharge sierra depuis el capitan, et j'installe sierra sur ma seconde partition.
Ensuite, j'ai rapatrié toutes mes données de el capitan sur sierra en utilisant l'assitant de migration, proposé lors de l'installation de sierra.
Jusque la, pas de problème tout fonctionne bien.
Suite à la découverte de sierra, et ne trouvant pas de bug important m'emêpchant de bosser, je décide alors de supprimer la partition el capitan....

Problème, impossible.
Je peux l'effacer, mais pas la refusionner...
Sur Sierra, l'utilitaire de disque ne peux rien pour moi, et sur la partition recovery il me dit bien effectivement que je peux refusionner, mais lorsque je test, rien ne se passe...

Je vous montre un screen depuis sierra sur le partitionnement du ssd et ainsi que la structure via le terminal :

Capture d’écran 2016-09-22 à 14.55.27.webp Capture d’écran 2016-09-22 à 14.56.00.webp


Alors, moi j'ai quelques idées...

En voyant le schéma de partition, je considère qu'en fait, ma partition de sierra n'est pas considéré comme la principale et donc doit être limitée... Contrairement à celle d'el capitan, qui doit avoir la main sur justement celle de sierra... (c'est une hypothèse j'en sais rien)
Ce que je me dis, c'est alors de refaire une installation de sierra sur la partition el capitan, puis de remettre mes données...
Une fois ceci fait, alors j'efface mon ancienne partition de sierra...

Je pense que ça peut marcher, mais en soit, si je peux éviter je serai content, de plus ça me permettrai d'apprendre un peu à manipuler les partitions sous mac...

Merci à tous ;)
 
Salut QuickPwn

L'espace d'un disque est logiquement distribué en une suite linéraire de blocs (de 512 octets chacun) numérotés de 0 à n. Les partitions d'un disque sont des sections constituées d'un alignement de ces blocs, commençant au bloc n° tant et finissant au bloc n° tant.

Ce qui a plusieurs conséquences logiques :

- une partition A englobant une série de blocs numériquement antérieurs aux blocs de résidence d'une partition B est considérée comme « précédant » cette dernière.

- l'espace de blocs d'une partition étant géré par un système de fichiers (permettant de monter l'espace de blocs bruts en volume affichant des fichiers) > système de fichiers résidant sur les premiers blocs de ladite partition > le point de départ d'une partition équivaut à un ancrage inamovible aussi longtemps qu'on ne supprime pas la partition.

- on ne peut donc pas ajouter "à partir du dessus" (en terme de numérotation des blocs) l'espace d'une partition antérieure effacée à une partition "du-dessous" (postérieure), parce que le système de fichiers de la partition du-dessous est un ancrage indéplaçable (on ne peut pas le pousser vers le haut des blocs du disque), qui gère seulement les blocs qui suivent en terme numéral et qui ne peut être "étiré" à un espace supplémentaire que s'il est situé toujours en-dessous.​

En appliquant ce laïus à ton cas de figure > tu ne peux pas ajouter l'espace de ta partition El Captian précédante à celui de ta partition macOS Sierra conséquente, car le système de fichiers de macOS Sierra est ancré à la limite supérieure de la partition macOS Sierra (dans la zone du 125è Go de blocs) > ce système de fichiers ne peut pas être poussé vers le haut du disque, pour résider en tête de la zone du 1er Go de blocs. Si tu voulais à tout prix ajouter les espaces, il faudrait que tu détruises le système de fichiers de macOS Sierra pour convertir ses blocs à de l'espace libre réallouable > ce qui permettrait au système de fichiers de la partition El Captian d'être étiré vers le bas pour capturer les blocs libres et gérer une seule partition doublée en espace.

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

Ton idée que le Système résidant sur une partition précédente "surclasse" (override) le Système résidant sur une partition conséquente n'a, par contre, pas de fondements logiques. Antécédence topique n'équivaut pas à Primauté politique. Donc tu pourrais si tu voulais laisser «Sierra» sur la partition basse et tranformer la partition haute en espace de stockage. Mais je sais : c'est techniquement correct > mais humainement incorrect => car l'imagination humaine ne peut s'empêcher d'assimiler le haut et le dominant > le bas et le subalterne (la tête et les pieds, l'État et le Peuple etc.). Donc mieux vaut éviter un malaise psychologique
361608_original.png
à se dire quotidiennement qu'on boote sur un Système d'un emplacement subalterne à celui du volume de stockage qui aurait la "dominance". Et puis, tu veux peut-être une seule partition-Système d'un seul tenant, et pas 2 partitions...

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

Alors ta perspective :
refaire une installation de sierra sur la partition el capitan, puis de remettre mes données...
Une fois ceci fait, alors j'efface mon ancienne partition de sierra...

est absolument correcte > c'est ainsi que tu dois t'y prendre.

Si tu n'as aucune donnée à sauvegarder dans le volume actuel El Captian > je te conseille :

- a) de formater ce volume dans l'utilitaire de disque de «Sierra» sans chercher à effacer la partition.

- b) d'utiliser la démo (gratuite un mois) de ☞Carbon Copy Cloner☜ pour créer une nouvelle tâche telle que : "source" = le volume macOS Sierra > "destination" = le volume El Captian (tu renommeras plus tard ce volume à ta guise) > presse le bouton "Cloner " > dis oui à la fin à la demande de clonage d'une partition Recovery HD sous le volume El Captian. Un clone = image-miroir démarrable des fichiers d'un volume-Système dans un autre volume qui devient la réplique démarrable du premier.

- c) une fois démarré sur le Système de la partition El Captian (qui est désormais une image-miroir de celui de macOS Sierra égale en dignitié à son original > et même supérieure pour l'imagination, car localisée sur emplacement "antérieur") > poste ici le résultat des 2 commandes (à passer séparément) :
Bloc de code:
diskutil list
diskutil cs list
pour qu'on te passe les commandes permettant d'effacer les 2 partitions basses (macOS Sierra et sa Recorery HD) et réallouer l'espace à la partition El Captian. Il y a un CoreStorage sur la partition macOS Sierra > ça demande une commande spéciale de déconstruction.

--------------------​
 
Dernière édition par un modérateur:
  • J’aime
Réactions: QuickPwn
Salut macomaniac !

Alors là, merci d'une telle réponse avec une partie théorique qui m'a fait comprendre pourquoi cela ne marchait pas...
D'ailleurs je viens de me rendre compte que j'avais mal taper El Capitan x)...
Du coup, je vais effectuer ce clone, mais pas tout de suite car niveau batterie ça va pas le faire, et je dois bosser encore dessus :3

Mais, je reviens ce soir pour terminer le boulot :)
 
Salut les héros:coucou:

Perso je l'aurais tenté autrement :

1) supprimer la partition El Capitan :
diskutil eraseVolume free space disk0s2

2) agrandir la partition Corestorage :
diskutil cs resizestack 76733E79-4009-45F2-894F-0E99C2B7259E 0b
 
@Jean

Le CoreStorage de «Sierra» dont l'espace-disque de support est la partition disk0s3 ne peut pas récupérer l'espace libéré par la suppression de la partition disk0s2 qui le précède > pour la même raison qu'en cas de système de fichiers JHFS+ standard :

l'étirement du système de fichier terminal jhfs+ (ancré sur un dev node exporté par le Volume Logique) > la dilatatation correspondante du Volume Logique exporté > la dilatation corrélée du Volume Physique importé > l'augmentation adaptée du container-disque brut disk0s3 enfin => ne peuvent se faire qu'en direction du "bas" (du point de vue de la localisation numérale des blocs) et pas vers le haut.

Une commande de type diskutil coreStorage resizeStack ne peut pas déplacer l'ancrage d'en-tête de la partition disk0s3 vers le départ du disque (juste sous la partition EFI) : car les headers du CoreStorage et les fichiers du système de fichiers JHFS+ terminal sont ancrés en mode fixe sur les blocs de tête de cette partition.​
 
Mais QuickPwn peut très bien tenter l'expérience > qui devrait fournir une sanction expérimentale édifiante.

[Je désirerais que la commande de Jean passe > ce qui constituerait la preuve qu'un miracle logique est possible : l'extension vers le haut d'un CoreStorage. Mais ma raison me dicte que ce miracle si désirable est forclos. Reste à vérifier comment fonctionne l'élasticité des Containers APFS qui malheureusement ne peuvent pas accueillir de Système démarrable actuellement.]

Je conjecture que diskutil va afficher un message d'erreur du type : "l'espace disponible est trop petit pour exécuter la commande" > parce qu'ayant cherché de l'espace libre "en-dessous" du CoreStorage (disk0s3) et de la partition Recovery HD indissociable (disk0s4) > il va tomber directement sur les 32 derniers blocs du disque supportant le backup de la GPT.
 
Me revoilà,

Bon j'aurai pas du tester ce que tu me proposais Jean x)

voilà le résultat :

Capture d’écran 2016-09-22 à 22.37.42.webp

là je ne sais plus quoi faire...

Le pire c'est que j'avais bien fait mon clone ect.... x)

Et oui, erreur pour resize...
 
Et oui, erreur pour resize...

Bon --> la sanction expérimentale est tombée : comme logiquement conjecturé > il est aussi impossible de re-dimensionner un format CoreStorage vers le haut (afin de lui faire récupérer des blocs libres situés avant la partition de résidence d'un point de vue numéral) qu'il est impossible de le faire avec un format JHFS+ standard.

Ne te désole pas, QuickPwn : ton expérimentation a servi à valider l'assertion « théorique » qu'une partition ne peut être re-dimensionnnée qu'en direction d'un espace libre située numéralement en-dessous d'elle, ce quel que soit le format susceptble d'extension du gestionnaire de la partition (JHFS+ ou CoreStorage). Parce que ledit gestionnaire a son ancrage logique sur l'en-tête des blocs de la partition (headers du CoreStorage > fichiers du JHFS+) > par suite, cet ancrage logique équivaut à un « point origine » pour la définition GPT de la partition. C'est comme pour toutes les « Origines » ("fons & origo") : on ne peut la reculer, puisque, en essence, elle est l'« origine » (c'est ce que déclarait Aristote dans sa «Métaphysique» : « Anankè stênaï » - il est nécessaire de s'arrêter (sous-entendu : à un point fixe constituant l'Origine).

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

Maintenant ce qui t'importe, ce ne sont certes pas les élucubrations matutinales du sieur macomaniac (qui se délecte à des abstractions de quintessence) - mais bien l'apuration pratique de la table de partition de ton disque. Pas de panique !

Il y a pour toi 2 options :

- a) simple --> quand tu dis :
Le pire c'est que j'avais bien fait mon clone ect...
si le clone en question réside sur un DDE (et n'avait pas été opéré dans le volume de la partition supprimée) > tu dois pouvoir démarrer dessus > et à partir de ce Système externe > effacer ton disque > puis rétro-cloner ton clone à rebours dans le volume monté unique désormais du disque de ton Mac.

=> à toi de dire si tu as un tel clone résidant sur un DDE. Si ce n'est pas le cas > il t'est toujours possible d'en créer un tel, si tu as un DDE disponible sous la main.

- b) complexe --> il existe un utilitaire UNIX gpt (guid_partition_table_utility) qui peut permettre de te recréer une partition avec l'espace de blocs libres actuellement situé entre la partition ESP (EFI System Partition) disk0s1 et la partition disk0s4 (index qui ne devrait pas résister à un re-démarrage, mais se recaler sur disk0s2).

=> si c'est l'option à laquelle tu te trouves conduit > passe dans le «Terminal» la commande :
Bloc de code:
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 la distribution des blocs de ton disque, aussi bien en sections relevant de la GPT (GUID Partition Table) qu'en bandes de blocs libres --> peux-tu le poster ici en copier-coller ?​

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

Glose 1: si la commande gpt est exécutable en mode informatif (show) à destination d'un disque dont les volumes sont montés > elle ne peut être exécutée en mode opératoire (add) qu'à destination d'un disque dont tous les volumes sont démontés (= systèmes de fichiers désactivés). Pour passer donc une commande opératoire de type "add" recréant une partition avec les blocs libres du disque > il te faudra démarrer en mode Recovery par la combinaison de touches ⌘R > car cette commande de démarrage crée un RAMDisk (disque virtuel) en RAM > et clone à la volée dans son volume monté le dossier de boot de la Recovery HD (disk0s5 chez toi actuellement) > pour démarrer le Mac sur ce Système purement résident en RAM > et donc totalement indépendant du disk0 de ton Mac.

=> il est donc possible à partir de là de démonter tous les volumes du disk0. Je dis démonter, car, ayant choisi un CoreStorage Chiffré > le volume MacOS Sierra chez toi est verrouillé et donc non monté si tu démarres en mode Recovery en RAM > mais étant verrouillé, je conjecture qu'il soit bloquer en l'état la capacité opératoire de la commande gpt à destination des bocs du disk0 > il doit donc falloir déverrouiller le Volume Logique (ce qui le monte), avant de le démonter formellement (sans qu'il se re-verrouille), afin de libérer la capacité d'intervention de gpt.


Glose 2: la partition ci-devant disk0s2 ayant été supprimée par l'utilitaire diskutil > recréer une partition avec les blocs libres ne permettra pas de récupérer l'index n°2 primitif de cette partition. En effet, l'ESP sera la n°1 > MacOS Sierra la n°2 > Recovery HD la n°3 et la nouvelle partition sera indexée en n°4 (en terme d'index GPT, quoique ses blocs soient numéralement antérieurs à ceux de la partition indexée en n°2).

Cette complication logique n'est pas, nonobstant, blocante. Car après clonage des fichiers de ton volume macOS Sierra dans celui de la nouvelle partition > il te sera possible de démarrer sur le Système de la nouvelle partition > supprimer la partition macOS Sierra (index n°2) et la Recovery HD (index n°3) = virer leurs blocs au statut "espace libre" > ce qui revient à libérer leurs index > re-démarrer => alors, il se produira un ré-ajustement forcé des index GPT : tu auras 3 partitions = ESP n°1 > nouveau volume n°2 > sa Recovery HD clonée n°3 (si tu utilises «CCC») > et en-dessous (numéralement) les blocs libres de macOS Sierra + sa Recovery HD originelle supprimées => une simple commande de re-dimensionnement de la nouvelle partition-Système apurera tout.

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

=> comme tu peux le voir : complexe est le procédé b) > simple le procédé a) en regard.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: QuickPwn
En effet pas de problème insurmontable.
Si tu as un clone de ta partition Sierra, tout va bien. Sinon en créer un. Rien n'est perdu, a part El Capitan, mais j'ai cru comprendre que ça n'avait pas d'importance.
Il suffit de démarrer sur le clone, d'effacer depuis l'utilitaire de disque le disque principal, cela va recréer une partition à vérifier : Type Mac os X étendu et schéma GUID et penser à modifier le nom.
Ceci fait il suffit de rétro-cloner Sierra sur cette nouvelle partition.
 
  • J’aime
Réactions: QuickPwn
Salut !

Merci pour vos réponses.

Dans un soucis de temps libre, je ne vais pas le faire tout de suite, je le ferai certainement demain, et je pense que je vais opter la solution la plus simple même si j'aurai bien voulu mettre les mains dedans...

Merci à vous deux, et je vous tiens au jus !
 
je pense que je vais opter la solution la plus simple
☝︎
361608_original.png
Inversement, mon prof de Latin ne cessait de me seriner : "quand tu as le choix entre la lectio facilior et la lectio difficilior, choisis toujours la lectio difficilior". Je crois que ça s'est gravé...
 
Cela n'a rien à voir. Ici on parle de fusion de partitions et là-bas de fusion de disques.;)
C'est vrai que le titre prête à con fusion:D
C'est justement ça le problème, avec le fusion drive, à partir du moment où on a partitionné, il est devenu impossible de revenir à une seule partition, on est obligé de détricoter pour retricoter.
 
C'est justement ça le problème, avec le fusion drive, à partir du moment où on a partitionné, il est devenu impossible de revenir à une seule partition, on est obligé de détricoter pour retricoter.
Oui mais ici je répépète qu'il n'est pas question de fusion drive.
 
Bonjour à tous !

En ce moment même j'ai démarré sur mon clone, j'ai effacé totalement le ssd, me retrouvant donc avec mes 256 petits go.
je suis entrain de lancer l'utilitaire d'installation de macOS Sierra pour qu'il fasse gentiment son installation sur le ssd interne.
Une fois ceci fait, j'utiliserai l'assistant de migration pour y copier mes données.

Si je ne clone pas mon clone sur mon ssd tout beau, c'est uniquement car j'ai peur de manquer de batterie et que je ne peux pas recharger en même temps... (Oui il s'agit du macbook 12")

Par contre, si j'ai le temps un de ses 4, je serai partant pour recréer le problème et faire la solution 2 de macomaniac :p

Merci à vous !
 
:coucou: Antoine

C'est comme si c'était fait - alors.

j'ai peur de manquer de batterie et que je ne peux pas recharger en même temps... (Oui il s'agit du macbook 12")

Ha ! Ha ! Tu n'as pas de raccord USB-C multi-prises ?

Ma solution : je l'ai vérifiée sur une clé USB multi-partitionnée pour le test, avec suppression de la partition du haut > ça marche. Recréation d'une partition vide avec les blocs libres > importation d'un système de fichiers pour remonter un volume utilisable > l'index de la partition glisse effectivement en dernière position (quoique ses blocs soient toujours juste après la partition EFI en numérotation > possibilité de restaurer le contenu du volume du bas dans le volume du haut juste créé > suppression des partitions basses devenues inutiles > au re-démarrage > la nouvelle partition récupère le bon index.