Problème réinstallation d'iMac

[Membre supprimé 1060554]

kasimodem ayant eu l'amabilité de citer un de mes messages portant sur le format CoreStorage (quoique pas sur le Fusion Drive qui recourt également à ce format), j'en viens à m'immiscer dans ce fil en position d'épigone - ce qui me ravit toujours en raison de la gratuité (pour ne pas dire la superfluité) caractéristique de ce type d'intervention au vu de laquelle on n'aurait pas tort de me ranger au nombre des Carabiniers d'Offenbach

...

... parce que joan louis (que je salue

) a très bien pris la mesure du problème qui se posait à Michael (

) et sa commande :

diskutil cs deleteLVG [UUID]

(passée depuis le -bash-3.2# de la «Recovery HD») a pu supprimer le Groupe de Volumes Logiques qui solidarisait les 2 disques du Mac : SSD + HDD.​

♤​

Je me contente donc ici de gloses (que j'aime toujours apposer en rallonge de page - faute de marges disponibles)...

Ce que révélaient les captures de Michael, c'est que le Groupe de Volumes Logiques de son Fusion Drive, suite à son intervention première, s'était vu réduit à l'association brute de 2 Disques Physiques Virtuels (dits : "Physical Volume") sans rien de plus. Or, un Groupe de Volumes Logiques : CoreStorage de type FusionDrive, lorsqu'il est au complet, non seulement consiste dans la greffe d'un Disque Physique Virtuel sur la partition majeure de chacun des disques concernés (la /dev/disk0s2 du SSD et la /dev/disk1s2 du HDD), mais dans leur solidarisation dans une instance de pilotage intermédiaire dite : Famille de Volumes Logiques, à partir des paramètres de laquelle se trouve rejeté en 3è et dernière instance un Volume Logique unique dans lequel l'OS est installé. L'intervention de Michael avait donc supprimé à la fois le Volume Logique et la Famille de Volumes Logiques de son FusionDrive --> rien d'étonnant si aucun volume ne montait plus, puisque l'instance : Volume Logique avait été supprimée.

Les 2 instances manquantes auraient très bien pu être recréées par la commande dans le «Terminal» de la «Recovery HD» :

diskutil coreStorage createVolume C2CCB3F4-793E-4758-B53B-A350CC32C9D2 jhfs+ Macintosh\ HD 100%

--> un Volume Logique neuf aurait été rejeté (avec recréation d'une Famille de Volumes Logiques ad hoc en instance médiane) sur lequel l'OS «Yosemite» aurait pu être ré-installé en Clean Install (en utilisant la fonctionnalité : Réinstaller OS X de la «Recovery HD»).

Par ailleurs, le volume de la «Recovery HD» (qui se crée régulièrement sur le HDD dans le cadre d'un FusionDrive) étant situé en /dev/disk1s3 ; la partition normalement créée par «BootCamp» (également sur le HDD dans le cadre d'un FusionDrive) se trouvait à la suite de la «Recovery HD» en /dev/disk1s4 --> il n'était nul besoin de la "supprimer" - opération qui vire l'espace d'une partition-disque au format espace libre ("free space"), càd. le place provisoirement hors partitionnement actuel en lui soustrayant la forme d'un filesystem (en conséquence de quoi, aucun volume correspondant à cet espace-disque ne monte plus). Le free space en question pourrait être reconverti en volume montable (par recréation d'un format de filesystem) et alors l'«Assistant BootCamp» pourrait être re-sollicité pour ré-installer Windows sur ce volume ad hoc - une fois l'OS réinstallé (il est impossible que le HDD ait pu être ré-partitionné, aussi longtemps que les opérations de l'«Utilitaire de Disque» ont été effectuées à partir d'un démarrage sur la «Recovery HD» occupant la position /dev/disk1s3 de ce même HDD).

Il est clair qu'actuellement Michael doit se retrouver avec 2 disques séparés, son FusionDrive ayant été supprimé. Dans l'optique de re-créer alors un FusionDrive (si telle était sa volonté), j'ai à faire remarquer qu'une commande :

diskutil mergePartitions HFS+ "Apple_HFS Macintosh HD" disk0s2 disk1s2

telle qu'elle a été proposée est invalide, car le verbe mergePartitions du programme UNIX diskutil ici invoqué requiert comme condition sine qua non pour être honoré que les partitions citées résident sur le même disque et pas sur 2 disques distincts, comme c'est le cas ici avec un /dev/disk0 et un /dev/disk1. Non. Pour recréer un FusionDrive, il faut procéder en 2 temps : d'abord passer une commande qui recrée un Groupe de Volumes Logiques incluant en 1ère instance seulement le greffon de 2 Disques Physiques Virtuels sur les 2 partition majeures : /dev/disk0s2 du SSD et /dev/disk1s2 du HDD --> commande à passer dans le «Terminal» de la «Recovery HD» :

diskutil coreStorage createLVG Macintosh\ HD /dev/disk0s2 /dev/disk1s2

(attendre la fin de l'opération marquée par le réaffichage de l'invite de commande -bash-3.2#). Passer alors la 2è commande, recréatrice d'une Famille de Volumes Logiques et à partir d'elle rejetant un Volume Logique ad hoc -->

diskutil coreStorage createVolume [lvgUUID] jhfs+ Macintosh\ HD 100%

(NB: l'UUID du Groupe de Volumes Logiques est affiché par défaut en terminaison de l'opération de création d'un Logical Volume Group par la commande précédente).​

♧​

 

[joan louis]

kasimodem ayant eu l'amabilité de citer un de mes messages portant sur le format CoreStorage (quoique pas sur le Fusion Drive qui recourt également à ce format), j'en viens à m'immiscer dans ce fil en position d'épigone - ce qui me ravit toujours en raison de la gratuité (pour ne pas dire la superfluité) caractéristique de ce type d'intervention au vu de laquelle on n'aurait pas tort de me ranger au nombre des Carabiniers d'Offenbach

...

... parce que joan louis (que je salue

) a très bien pris la mesure du problème qui se posait à Michael (

) et sa commande :

diskutil cs deleteLVG [UUID]

(passée depuis le -bash-3.2# de la «Recovery HD») a pu supprimer le Groupe de Volumes Logiques qui solidarisait les 2 disques du Mac : SSD + HDD.​

♤​

Je me contente donc ici de gloses (que j'aime toujours apposer en rallonge de page - faute de marges disponibles)...

Ce que révélaient les captures de Michael, c'est que le Groupe de Volumes Logiques de son Fusion Drive, suite à son intervention première, s'était vu réduit à l'association brute de 2 Disques Physiques Virtuels (dits : "Physical Volume") sans rien de plus. Or, un Groupe de Volumes Logiques : CoreStorage de type FusionDrive, lorsqu'il est au complet, non seulement consiste dans la greffe d'un Disque Physique Virtuel sur la partition majeure de chacun des disques concernés (la /dev/disk0s2 du SSD et la /dev/disk1s2 du HDD), mais dans leur solidarisation dans une instance de pilotage intermédiaire dite : Famille de Volumes Logiques, à partir des paramètres de laquelle se trouve rejeté en 3è et dernière instance un Volume Logique unique dans lequel l'OS est installé. L'intervention de Michael avait donc supprimé à la fois le Volume Logique et la Famille de Volumes Logiques de son FusionDrive --> rien d'étonnant si aucun volume ne montait plus, puisque l'instance : Volume Logique avait été supprimée.

Les 2 instances manquantes auraient très bien pu être recréées par la commande dans le «Terminal» de la «Recovery HD» :

diskutil coreStorage createVolume C2CCB3F4-793E-4758-B53B-A350CC32C9D2 jhfs+ Macintosh\ HD 100%

--> un Volume Logique neuf aurait été rejeté (avec recréation d'une Famille de Volumes Logiques ad hoc en instance médiane) sur lequel l'OS «Yosemite» aurait pu être ré-installé en Clean Install (en utilisant la fonctionnalité : Réinstaller OS X de la «Recovery HD»).

Par ailleurs, le volume de la «Recovery HD» (qui se crée régulièrement sur le HDD dans le cadre d'un FusionDrive) étant situé en /dev/disk1s3 ; la partition normalement créée par «BootCamp» (également sur le HDD dans le cadre d'un FusionDrive) se trouvait à la suite de la «Recovery HD» en /dev/disk1s4 --> il n'était nul besoin de la "supprimer" - opération qui vire l'espace d'une partition-disque au format espace libre ("free space"), càd. le place provisoirement hors partitionnement actuel en lui soustrayant la forme d'un filesystem (en conséquence de quoi, aucun volume correspondant à cet espace-disque ne monte plus). Le free space en question pourrait être reconverti en volume montable (par recréation d'un format de filesystem) et alors l'«Assistant BootCamp» pourrait être re-sollicité pour ré-installer Windows sur ce volume ad hoc - une fois l'OS réinstallé (il est impossible que le HDD ait pu être ré-partitionné, aussi longtemps que les opérations de l'«Utilitaire de Disque» ont été effectuées à partir d'un démarrage sur la «Recovery HD» occupant la position /dev/disk1s3 de ce même HDD).

Il est clair qu'actuellement Michael doit se retrouver avec 2 disques séparés, son FusionDrive ayant été supprimé. Dans l'optique de re-créer alors un FusionDrive (si telle était sa volonté), j'ai à faire remarquer qu'une commande :

diskutil mergePartitions HFS+ "Apple_HFS Macintosh HD" disk0s2 disk1s2

telle qu'elle a été proposée est invalide, car le verbe mergePartitions du programme UNIX diskutil ici invoqué requiert comme condition sine qua non pour être honoré que les partitions citées résident sur le même disque et pas sur 2 disques distincts, comme c'est le cas ici avec un /dev/disk0 et un /dev/disk1. Non. Pour recréer un FusionDrive, il faut procéder en 2 temps : d'abord passer une commande qui recrée un Groupe de Volumes Logiques incluant en 1ère instance seulement le greffon de 2 Disques Physiques Virtuels sur les 2 partition majeures : /dev/disk0s2 du SSD et /dev/disk1s2 du HDD --> commande à passer dans le «Terminal» de la «Recovery HD» :

diskutil coreStorage createLVG Macintosh\ HD /dev/disk0s2 /dev/disk1s2

(attendre la fin de l'opération marquée par le réaffichage de l'invite de commande -bash-3.2#). Passer alors la 2è commande, recréatrice d'une Famille de Volumes Logiques et à partir d'elle rejetant un Volume Logique ad hoc -->

diskutil coreStorage createVolume [lvgUUID] jhfs+ Macintosh\ HD 100%

(NB: l'UUID du Groupe de Volumes Logiques est affiché par défaut en terminaison de l'opération de création d'un Logical Volume Group par la commande précédente).​

♧​

ce genre de post détaillé, précis et bien écrit n'est jamais superflu ça sert aux prochains!