iMac Disque fusion invisible depuis réinstallation forcée... :(

[Membre supprimé 1060554]

« Unable to delete the Logical Volume Group » (impossible de supprimer le Groupe de Volumes Logiques) -->

La raison doit en être que le Physical Volume (disque dur émulé) qui résidait auparavant sur la partition disk0s2 du SSD > se trouve toujours logiquement inscrit dans l'architecture globale du CoreStorage Fusion Drive > mais ne peut pas être actuellement trouvé en vue d'une destruction (puisque la partition disk0s2 du SSD a été reformatée).

Ecraser les 2 disques et recréer un Fusion Drive?

Pas exactement > car il y a une partition de données intitulée Data macOS en 4è position sur le HDD. On ne peut donc ré-initialiser le HDD entier pour faire sauter le CoreStorage récalcitrant qui y réside. Et un reformatage simple de la partition est impossible à cause du CoreStorage qui y est inscrit.

Mais j'ai trouvé une méthode, Zeduke.

Pour cela > poste le tableau résultant d'une commande :

diskutil list

dans le «Terminal» de «Sierra» > que je vérifie le n° de disque du HDD.

 

[ZeDuke]

« Unable to delete the Logical Volume Group » (impossible de supprimer le Groupe de Volumes Logiques) -->

La raison doit en être que le Physical Volume (disque dur émulé) qui résidait auparavant sur la partition disk0s2 du SSD > se trouve toujours logiquement inscrit dans l'architecture globale du CoreStorage Fusion Drive > mais ne peut pas être actuellement trouvé en vue d'une destruction (puisque la partition disk0s2 du SSD a été reformatée).



Pas exactement > car il y a une partition de données intitulée Data macOS en 4è position sur le HDD. On ne peut donc ré-initialiser le HDD entier pour faire sauter le CoreStorage récalcitrant qui y réside. Et un reformatage simple de la partition est impossible à cause du CoreStorage qui y est inscrit.

Mais j'ai trouvé une méthode, Zeduke.

Pour cela > poste le tableau résultant d'une commande :

diskutil list

dans le «Terminal» de «Sierra» > que je vérifie le n° de disque du HDD.

Et hop!

iMac-de-Fabien:~ fabienleduc$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 120.5 GB disk0s2
3: Apple_Boot Boot OS X 650.0 MB disk0s3

/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage Macintosh HD 1.1 TB disk1s2
3: Apple_Boot 650.1 MB disk1s3
4: Apple_HFS Data MacOS 1.9 TB disk1s4

/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Macintosh HD +120.2 GB disk2
Logical Volume on disk0s2
07B34B0B-1415-4BD9-BE7A-77199E7BA808
Unencrypted

/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *256.1 GB disk3
1: DOS_FAT_32 NO NAME 367.0 MB disk3s1
2: Windows_NTFS WINDOWS7 255.7 GB disk3s2

 

[Membre supprimé 1060554]

Il est donc bien toujours disk1.

Alors tu passes la commande (informative encore) :

sudo gpt show disk1

et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin (mot de passe de session) à l'aveugle - aucun caractère ne se montrant à la frappe - et à nouveau ↩︎

En retour > va s'afficher le tableau de la distribution des blocs du HDD (en partitions et en espaces libres) => tu n'as qu'à poster encore ce tableau ici : ses informations sont décisives pour la manœuvre à venir.

 

[ZeDuke]

Il est donc bien toujours disk1.

Alors tu passes la commande (informative encore) :

sudo gpt show disk1

et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin (mot de passe de session) à l'aveugle - aucun caractère ne se montrant à la frappe - et à nouveau ↩︎

En retour > va s'afficher le tableau de la distribution des blocs du HDD (en partitions et en espaces libres) => tu n'as qu'à poster encore ce tableau ici : ses informations sont décisives pour la manœuvre à venir.

OK, merci beaucoup.
Et re-hop!

 

[Membre supprimé 1060554]

Ah ! rien n'est simple en ce monde sub-lunaire...

[Mode: monologue]
Ne voilà-t-il pas que l'utilitaire gpt lit les distributions de blocs du HDD selon une carte MBR et pas selon la carte GPT escomptée ? En attestant d'une MBR sur le bloc 0 comme s'il s'agissait de la seule table de partition réglant le disque, puisqu'aucune table de partition GPT ne se trouve désignée comme il se devrait sur les blocs suivants : 1 > 32...

Et pourtant la commande diskutil list précédente > retourne bien un : GUID_partition_scheme *3.0 TB disk1 ! Il va être temps de remettre tout ça sur le droit chemin...

Et en plus notre ami a posté une photo au lieu d'un copier-coller en mode texte. Il me faut donc retaper les chiffres des blocs à la main (pfuiiii !)...
[/Mode]

Bref : je ne peux pas prédire de manière déterministe si les commandes régulières vont ou non être validées dans ce cadre logique.

Voici le topo d'ensemble de la manœuvre :

- par la commande :

diskutil umount force disk1s4

tu démontes le volume monté Data macOS (des commandes gpt opératoires ne peuvent pas être honorées si un volume du disque-cible se trouve monté).

- par la commande :

sudo gpt remove -i 2 disk1

tu supprimes normalement la partition n°2 (2: Apple_CoreStorage Macintosh HD 1.1 TB disk1s2) en la désignant par son index --> tu vas bien voir si la commande passe > car elle m'a tout l'air de devoir être adressée à la carte de partition MBR au lieu de la carte de partition GPT comme il se devrait. Si tu vois s'afficher un message affirmatif du type :

partition n°2 removed

> alors tu peux enchaîner.

- par la commande :

diskutil umount force disk1s4

tu re-démontes le volume Data macOS qui a été remonté en sortie de la commande précédente (toujours pour la même raison : nécessité que tous les volumes du disque-cible soient démontés pour passer une commande gpt opératoire).

- par la commande :

sudo gpt add -i 2 -t hfs -b 530145 -s 1060290 disk1

(si tu passes cette commande dans les 5' suivant la précédente commande sudo > alors pas besoin de ressaisir de mot-de-passe pour ce nouveau sudo) > tu ajoutes normalement une partition sur les blocs exacts de résidence de l'ancienne partition CoreStorage Fusion Drive > indexée comme n°2 > avec Apple_HFS comme type de système de fichiers. Si tu vois s'afficher un message affirmatif du type :

partition n°2 added

> alors on peut espérer que tout se soit bien passé.​

=> si le jeu des 4 commandes s'est déroulé sans anicroche > tu devrais aviser sur ton Bureau de session > en plus du volume Data macOS remonté > un nouveau volume intitulé Untitled correspondant exactement (au bloc près) à l'alignement de blocs de l'ancienne partition CoreStorage. Mais cette fois-ci un volume standard de type Apple_HFS.

Tu n'as qu'à passer une ultime commande informative :

diskutil list

et poster (en copier-coller !) le tableau retourné.

 

[ZeDuke]

Ah ! rien n'est simple en ce monde sub-lunaire...

[Mode: monologue]
Ne voilà-t-il pas que l'utilitaire gpt lit les distributions de blocs du HDD selon une carte MBR et pas selon la carte GPT escomptée ? En attestant d'une MBR sur le bloc 0 comme s'il s'agissait de la seule table de partition réglant le disque, puisqu'aucune table de partition GPT ne se trouve désignée comme il se devrait sur les blocs suivants : 1 > 32...

Et pourtant la commande diskutil list précédente > retourne bien un : GUID_partition_scheme *3.0 TB disk1 ! Il va être temps de remettre tout ça sur le droit chemin...

Et en plus notre ami a posté une photo au lieu d'un copier-coller en mode texte. Il me faut donc retaper les chiffres des blocs à la main (pfuiiii !)...
[/Mode]

Bref : je ne peux pas prédire de manière déterministe si les commandes régulières vont ou non être validées dans ce cadre logique.

Voici le topo d'ensemble de la manœuvre :

- par la commande :

diskutil umount force disk1s4

tu démontes le volume monté Data macOS (des commandes gpt opératoires ne peuvent pas être honorées si un volume du disque-cible se trouve monté).

- par la commande :

sudo gpt remove -i 2 disk1

tu supprimes normalement la partition n°2 (2: Apple_CoreStorage Macintosh HD 1.1 TB disk1s2) en la désignant par son index --> tu vas bien voir si la commande passe > car elle m'a tout l'air de devoir être adressée à la carte de partition MBR au lieu de la carte de partition GPT comme il se devrait. Si tu vois s'afficher un message affirmatif du type :

partition n°2 removed

> alors tu peux enchaîner.

- par la commande :

diskutil umount force disk1s4

tu re-démontes le volume Data macOS qui a été remonté en sortie de la commande précédente (toujours pour la même raison : nécessité que tous les volumes du disque-cible soient démontés pour passer une commande gpt opératoire).

- par la commande :

sudo gpt add -i 2 -t hfs -b 530145 -s 1060290 disk1

(si tu passes cette commande dans les 5' suivant la précédente commande sudo > alors pas besoin de ressaisir de mot-de-passe pour ce nouveau sudo) > tu ajoutes normalement une partition sur les blocs exacts de résidence de l'ancienne partition CoreStorage Fusion Drive > indexée comme n°2 > avec Apple_HFS comme type de système de fichiers. Si tu vois s'afficher un message affirmatif du type :

partition n°2 added

> alors on peut espérer que tout se soit bien passé.​

=> si le jeu des 4 commandes s'est déroulé sans anicroche > tu devrais aviser sur ton Bureau de session > en plus du volume Data macOS remonté > un nouveau volume intitulé Untitled correspondant exactement (au bloc près) à l'alignement de blocs de l'ancienne partition CoreStorage. Mais cette fois-ci un volume standard de type Apple_HFS.

Tu n'as qu'à passer une ultime commande informative :

diskutil list

et poster (en copier-coller !) le tableau retourné.

Oups! Vraiment désolé pour le copier / coller en mode graphique...

Bon, j'ai tenté, et le moins que l'on puisse dire, c'est que cela ne se passe pas comme prévu:

Last login: Mon Jan 30 09:59:40 on console
iMac-de-Fabien:~ fabienleduc$ diskutil umount force disk1s4
disk1s4 was already unmounted
iMac-de-Fabien:~ fabienleduc$ sudo gpt remove -i 2 disk1
Password:
gpt remove: unable to open device 'disk1': Input/output error
iMac-de-Fabien:~ fabienleduc$

 

[Deleted member 1099514]

Tu devrais tenter un sos sur le disque 1 et ses volumes.
Sinon faire un
diskutil eraseVolume jhfs+ disk1_fusion disk1s2

 

[ZeDuke]

Tu devrais tenter un sos sur le disque 1 et ses volumes.
Sinon faire un
diskutil eraseVolume jhfs+ disk1_fusion disk1s2

Merci pour le conseil, mais en quoi consiste un SOS?

 

[Deleted member 1099514]

Utilitaire de disque, puis sélectionner le disque et ensuite cliquer sur SOS. Faire la même chose pour chaque partition du disque.

 

[Membre supprimé 1060554]

Jean

Tu devrais tenter un sos sur le disque 1 et ses volumes.

Bonne idée > ça peut peut-être réparer la table de partition GUID qui a l'air d'avoir pris un sérieux coup de vent.

Sinon faire un
diskutil eraseVolume jhfs+ disk1_fusion disk1s2

Impossible : un format CoreStorage (même en miettes) sur la partition-cible (disk1s2) interdit un reformatage standard. C'est pourquoi j'avais concocté le procédé gpt (qui, expérimentalement effectué sur une clé USB porteuse d'un CoreStorage, opère parfaitement).

----------

@ZeDuke

Il semble y avoir un problème de table de partition générale du disque 1 (HDD). Le tableau retourné par la commande sudo gpt show disk1 > affichant une seule table MBR (et pas de GPT) est totalement anormal. C'est la première fois que je vois ça.

L'idéal serait : si tu pouvais sauvegarder les données du volume Data macOS sur un DDE > ainsi il serait possible de ré-initialiser complètement le HDD (ce qui ferait inmanquablement sauter le CoreStorage du Fusion Drive).

Ensuite : tu pourrais toujours voir si le logiciel de récupération avise quoi que ce soit d'intéressant des anciens fichiers en lui donnant pour cible le nouveau volume vide. Chance minime.

Enfin : reconstruction radicale du Fusion Drive depuis l'Internet Recovery > ré-installation de «Mountain Lion» > re-mise-à-niveau à «Sierra».

 

[ZeDuke]

Jean



Bonne idée > ça peut peut-être réparer la table de partition GUID qui a l'air d'avoir pris un sérieux coup de vent.



Impossible : un format CoreStorage (même en miettes) sur la partition-cible (disk1s2) interdit un reformatage standard. C'est pourquoi j'avais concocté le procédé gpt (qui, expérimentalement effectué sur une clé USB porteuse d'un CoreStorage, opère parfaitement).

----------

@ZeDuke

Il semble y avoir un problème de table de partition générale du disque 1 (HDD). Le tableau retourné par la commande sudo gpt show disk1 > affichant une seule table MBR (et pas de GPT) est totalement anormal. C'est la première fois que je vois ça.

L'idéal serait : si tu pouvais sauvegarder les données du volume Data macOS sur un DDE > ainsi il serait possible de ré-initialiser complètement le HDD (ce qui ferait inmanquablement sauter le CoreStorage du Fusion Drive).

Ensuite : tu pourrais toujours voir si le logiciel de récupération avise quoi que ce soit d'intéressant des anciens fichiers en lui donnant pour cible le nouveau volume vide. Chance minime.

Enfin : reconstruction radicale du Fusion Drive depuis l'Internet Recovery > ré-installation de «Mountain Lion» > re-mise-à-niveau à «Sierra».

Bon, ça se gâte encore un peu plus. Mon disque Data macOS n'est même plus visible...

 

[Membre supprimé 1060554]

Si tu fais un :

diskutil list

dans le «Terminal» > qu'est-ce qui est retourné ? - poste le tableau en copier-coller.

 

[ZeDuke]

Si tu fais un :

diskutil list

dans le «Terminal» > qu'est-ce qui est retourné ? - poste le tableau en copier-coller.

Je colle en mode texte... Je progresse, je progresse!

Last login: Mon Jan 30 11:30:40 on ttys000
iMac-de-Fabien:~ fabienleduc$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 120.5 GB disk0s2
3: Apple_Boot Boot OS X 650.0 MB disk0s3

/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Macintosh HD +120.2 GB disk2
Logical Volume on disk0s2
07B34B0B-1415-4BD9-BE7A-77199E7BA808
Unencrypted

/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *256.1 GB disk3
1: DOS_FAT_32 NO NAME 367.0 MB disk3s1
2: Windows_NTFS WINDOWS7 255.7 GB disk3s2

/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *2.0 TB disk4
1: Linux 271.4 MB disk4s1
2: Linux 542.9 MB disk4s2
3: Linux 1.1 GB disk4s3
4: DOS_FAT_32 UNTITLED 5 128.9 GB disk4s5
5: Linux 10.7 GB disk4s6
6: Apple_HFS Untitled 7 1.9 TB disk4s7

Visiblement, plus de trace du Fusion Drive...

 

[Membre supprimé 1060554]

Je progresse, je progresse!

Le diagnostic aussi. Ton HDD n'est plus identifié comme disque.

Il y a manifestement une panne matérielle : défaillance du disque ou de la nappe (câble connecteur reliant le disque à la Carte-Mère). Je pense que c'est cette défaillance matérielle, partielle au départ, qui a planté initialement ton Fusion Drive. Et qui a été responsable du rendu surréaliste des cartes de partition du disque par la commande gpt.

=> en résumé : tu es bon pour porter ton iMac en AppleStore ou dans un magasin agréé Apple > pour diagnostic et devis (concernant un AppleStore : prise de rendez-vous téléphonique ou par internet pour fixer un jour et une heure - il faut que tu relèves le n° de série de la machine pour pouvoir le communiquer).

 

[ZeDuke]

Le diagnostic aussi. Ton HDD n'est plus identifié comme disque.

Il y a manifestement une panne matérielle : défaillance du disque ou de la nappe (câble connecteur reliant le disque à la Carte-Mère). Je pense que c'est cette défaillance matérielle, partielle au départ, qui a planté initialement ton Fusion Drive. Et qui a été responsable du rendu surréaliste des cartes de partition du disque par la commande gpt.

=> en résumé : tu es bon pour porter ton iMac en AppleStore ou dans un magasin agréé Apple > pour diagnostic et devis (concernant un AppleStore : prise de rendez-vous téléphonique ou par internet pour fixer un jour et une heure - il faut que tu relèves le n° de série de la machine pour pouvoir le communiquer).

Aaaaarrrrfggghhhhh.

Bon, c'est une très mauvaise nouvelle car je réside à Majorque. Pas d'Apple Store à proprement parler, mais il y a une boutique qui a la licence pour la distribution.

Je vais y passer.

Encore merci pour ton aide!

 

[ZeDuke]

Si tu fais un :

diskutil list

dans le «Terminal» > qu'est-ce qui est retourné ? - poste le tableau en copier-coller.

Bonsoir @macomaniac, Je me permets de rouvrir ce sujet car, après 5 jours de déplacement, je viens de rallumer mon mac, et constate que la commande Diskutil list refait apparaître à présent le HDD manquant...

Last login: Sun Feb 5 20:50:10 on console
iMac-de-Fabien:~ fabienleduc$ diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 120.5 GB disk0s2
3: Apple_Boot Boot OS X 650.0 MB disk0s3

/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage Macintosh HD 1.1 TB disk1s2
3: Apple_Boot 650.1 MB disk1s3
4: Apple_HFS Data MacOS 1.9 TB disk1s4

/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Macintosh HD +120.2 GB disk2
Logical Volume on disk0s2
07B34B0B-1415-4BD9-BE7A-77199E7BA808
Unencrypted

/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *256.1 GB disk3
1: DOS_FAT_32 NO NAME 367.0 MB disk3s1
2: Windows_NTFS WINDOWS7 255.7 GB disk3s2

/dev/disk4 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *2.0 TB disk4
1: Linux 271.4 MB disk4s1
2: Linux 542.9 MB disk4s2
3: Linux 1.1 GB disk4s3
4: DOS_FAT_32 UNTITLED 5 128.9 GB disk4s5
5: Linux 10.7 GB disk4s6
6: Apple_HFS Untitled 7 1.9 TB disk4s7

Du coup, penses tu que l'on puisse tenter quelque chose?

Merci par avance pour ton retour.

 

[Deleted member 1099514]

Salut

Regarde si tu n'es pas concerné par cela :

https://www.apple.com/fr/support/imac-harddrive-3tb/

 

[Membre supprimé 1060554]

Salut ZeDuke

Tu peux toujours (re)passer la commande :

sudo gpt show /dev/disk1

et poster le retour > pour voir si les tables de partition sont identifiées correctement ce coup-ci.

 

[ZeDuke]

Salut ZeDuke

Tu peux toujours (re)passer la commande :

sudo gpt show /dev/disk1

et poster le retour > pour voir si les tables de partition sont identifiées correctement ce coup-ci.

Bon, la commande a l'air de ne rien retourner, pas de message d'erreur, rien, nada...



Et quand je souhaite fermer le terminal, j'ai un message me demandant si je veux vraiment arrêter les processus gpt et sudo en cours d'exécution...

 

[Deleted member 1099514]

Tu as regardé ça : #37 ?