Probleme démarrage impossible MBP 15 Yosemite

Tu as un SSD de 180 Go ??? et un DD de 500 Go.
Pourquoi conserver un Fusion Drive alors que tu peux mettre le système sur le SSD et tes données sur le DD?
C'est un choix, mais il s'avère plutôt dangereux dans le cas précis.
Enfin c'est à toi de voir.
Que te renvoie :
Bloc de code:
diskutil list

Cette commande me renvoi ça :

J'avais fais le choix du fusion drive justement pour ne pas me prendre la tête avec plusieurs back up séparés mais 1 seul back up.

Non Rémy le problème n'est pas résolu car je n'ai pas encore les outils nécessaires sous la main.
Est-il possible de récupérer mes données en bootant sur un DDE avec Linux ? Et si oui est-il possible de sauver les données sur un autre DDE ?
 
Tente de démarrer sur le DDE Linux, tu verras bien si ton disque est reconnu et monté. A partir de là oui tu peux sauver les données si elles sont présentes.
L'idéal serait de booter sur un système apple, car là tu n'aurais pas de questions à te poser sur la compatibilité des formats.
Donc ton SSD fait bien 180 Go (taille inhabituelle, mais enfin...)

Dans tous les cas si tu arrives à sauver tes données, il faudra "casser" le Fusion puis le recréer. Ça tu dois savoir faire, sinon tu vas trouver les réponses sur le net en recherchant par exemple : "diskutil cs delete"

@+
 
La commande diskutil list renvoie l'affichage du tableau de partitionnement de tous les disques attachés actuellement au Mac -->

Bloc de code:
/dev/disk0
#:             TYPE NAME                    SIZE       IDENTIFIER
0:             GUID_partition_scheme       *180.0 GB   disk0
1:             EFI EFI                      209.7 MB   disk0s1
2:             Apple_CoreStorage            179.7 GB   disk0s2
3:             Apple_Boot Boot OS X         134.2 MB   disk0s3

/dev/disk1
#:             TYPE NAME                    SIZE       IDENTIFIER
0:             GUID_partition_scheme       *500.1 GB   disk1
1:             EFI EFI                      209.7 MB   disk1s1
2:             Apple_CoreStorage            499.2 GB   disk1s2
3:             Apple_Boot Recovery HD       650.1 MB   disk1s3

/dev/disk2
#:             TYPE NAME                    SIZE       IDENTIFIER
0:             Apple_partition_scheme      *1.3GB      disk2
1:             Apple_partition_map          30.7 KB    disk2s1
2:             Apple_HFS OS X Base System   1.3 GB     disk2s2

/dev/disk3
#:             TYPE NAME                    SIZE       IDENTIFIER
0:             Apple_HFS Macintosh HD      *672.8 GB   disk3
                         Logical Volume on disk0s2, disk1s2
                         EBFD4CDB-2F2C-4DE8-878D-FEA2FD55E7F2
                         Unencrypted Fusion Drive

/dev/disk4
#:             TYPE NAME                    SIZE       IDENTIFIER
0:             Untitled                    *5.2 MB     disk4

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

/dev/disk16
#:              TYPE NAME                    SIZE      IDENTIFIER
0:              Untitled                   *X.0 MB     disk16

☞ je ne trouve rien à noter que de très attendu dans ta configuration :



/dev/disk0 désigne ton SSD, avec une tripartition : la petite partition-EFI qui est l'en-tête du Tableau de Partition GUID ; un Apple_CoreStorage de 179 GB qui identifie le 1er Disque Physique Virtuel en /dev/disk0s2 ; et une petite partition Apple_Boot Boot OS X qui est le Volume de Famille Logique servant d'instance de pilotage du Groupe de Volumes Logiques.

/dev/disk1 désigne ton HDD, avec une tripartition encore : la petite partition-EFI qui est l'en-tête du Tableau de Partition GUID ; un Apple_CoreStorage de 499 GB qui identifie le 2è Disque Physique Virtuel en /dev/disk1s2 ; et une petite partition Apple_Boot Recovery HD de 650 Mo qui est le volume de la partition de récupération »Recovery HD» connexe de OS X.

/dev/disk2 désigne le volume monté du disque virtuel : BaseSystem.dmg recelé sur le volume précédent de la «Recovery HD» (le /dev/disk1s3), avec une bipartition : la petite Carte d'Amorçage qui constitue l'en-tête du montage en volume du disque virtuel BaseSystem.dmg ; et le volume proprement dit : OS X Base System qui monte à partir du disque virtuel BaseSystem.dmg de 455 Mo compressés en donnant par décompression une taille de 1,3 GB.

/dev/disk3 désigne le Volume Logique unique de 672 GB, intitulé Macintosh HD, rejeté par le Groupe de Volumes Logiques du Fusion Drive à partir des 2 Disques Physiques Virtuels : Apple_CoreStorage sis en /dev/disk0s2 & /dev/disk1s2 respectivement. Son UUID est renseigné ainsi que son statut de volume non chiffré par «FileVault-2».


/dev/disk4 à /dev/disk16 désignent de petits disques temporaires dont la commande diskutil list retourne toujours la présence dès lors qu'elle est passée à partir du «Terminal» de la «Recovery HD» démarrée, càd. à partir du volume monté : OS X Base System --> ces petits "copains" de la «Recovery HD» doivent être toujours comptés comme quantité négligeable.





Si "touffu" en apparence qu'apparaisse ce tableau de partitionnement, il n'offre aucune anomalie logique par rapport à ce qu'on peut attendre dans le contexte d'un Fusion Drive solidarisant un SSD + un HDD et d'un démarrage sur le volume de la «Recovery HD» impliquant le montage du disque virtuel BaseSystem.dmg en un volume décompressé OS X Base System accompagné d'une pléïade de micro-disques temporaires.

Je n'ai qu'un point à signaler : comme manifestement la partition de la «Recovery HD» s'est trouvée installée sur le HDD (en /dev/disk1s3) ([ce qui laisse supposer que OSX tout entier est lui bien installé sur la partition /dev/disk0s2 du SSD] ; si l'on intègre le fait que ta 1ère tentative de démarrage sur la «Recovery HD» par la commande directe : ⌘R (tel qu'attesté par ton message #4) n'était pas parvenue à monter en volume démarrable OS X Base System le disque virtuel BaseSystem.dmg mais que, de façon inattendue, c'était la «Recovery On-line» qui s'était lancée comme lorsqu'aucune «Recovery HD» n'existe sur le disque interne du Mac --> il ne faut pas être un grand logicien pour en inférer que les I/O errors (erreurs d'input/output, càd. échecs de lecture_disque / montage_données) attestées dans le «Terminal» de root lors du démarrage en Single User doivent concerner le HDD (et pas le SSD) en ayant, dans cette occurrence, proscrit dans un 1er temps le démarrage sur la «Recovery HD» suite à des erreurs de lecture du disque. La défaillance d'un disque étant susceptible de "hauts et de bas" (si je puis dire), le HDD qui semble avoir du "plomb dans l'aile" (et qui donc par sa défaillance solitaire menace de ruine l'ensemble de l'édifice du Fusion Drive, càd. le caractère montable du Volume Logique unique qui en est rejeté et qui déploie l'espace d'exploitation des données) semble néanmoins capable (aléatoirement) de jouer sa partie de support d'un montage "simple" du Volume Logique en qualité de volume de stockage. Un démarrage "miraculeux" sur l'OS de ce Volume Logique n'est pas absolument à exclure par ailleurs, mais on touche là au «Pari» de Pascal carrément.

Sauvegarder si possible, détruire le Fusion Drive, examiner les 2 disques isolément (à partir d'un démarrage en externe), changer le disque défaillant (si avéré), ré-installer un Système : ça paraît la séquence logique désormais.

Pour détruire le CoreStorage lorsqu'il y aura lieu, à partir de l'OS démarré d'un DDE connecté au Mac, passer dans son «Terminal» la commande :

Bloc de code:
sudo diskutil coreStorage deleteLVG 028D807B-094D-4314-8BE9-11B9C38C3057
et ↩︎ (touche 'Entrée') --> demande de
password (commande sudo) --> saisir le mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎. Si la commande de destruction se passe à partir du «Terminal» de la «Recovery HD» du HDD (ou de la «Recovery On-line» si la 1ère n'est plus démarrable suite à la défaillance du HDD), comme il s'agit du -bash-3.2# de root, ne pas invoquer sudo qui ne serait pas reconnu comme valide, mais saisir simplement :
Bloc de code:
diskutil coreStorage deleteLVG 028D807B-094D-4314-8BE9-11B9C38C3057
.


Dans les 2 cas de figure, passer avant la commande de destruction la commande informative :
Bloc de code:
diskutil cs list
qui retourne l'affichage du
Groupe de Volume Logique : CoreStorage existant du Fusion Drive et permet un copier-coller de l'UUID de 32 carcactères alpha-numériques du Groupe de Volumes Logiques (IDentifiant Unique Universel de la structure holistique, affiché en instance tête de tableau, le seul requis pour la commande de destruction).


 
Dernière édition par un modérateur:
Suite à vos avis et l'avis d'autres informaticiens, j'ai abandonné l'idée de récupérer mes données car ça semblait trop complexe et avec peu de chances de réussite.

Tu as un SSD de 180 Go ??? et un DD de 500 Go.
Pourquoi conserver un Fusion Drive alors que tu peux mettre le système sur le SSD et tes données sur le DD?
C'est un choix, mais il s'avère plutôt dangereux dans le cas précis.

Ayant tenu compte de ce commentaire, j'ai donc réinstallé le système sur le SSD, migré les applications sur le SSD et migré le reste des fichiers sur le DD à plateaux. L'opération a bien fonctionné malgré quelques détails à régler à la main.

Il me reste cependant un problème à résoudre (peut-être devrais-je créer un nouveau fichier ?).
Avant que l'ordinateur arrête de fonctionnait, j'avais sauvegardé des e-mails en local sur l'ordinateur avec l'application mail. Je n'arrive pas à réimporter les fichiers .mbox de l'ancienne sauvegarde TimeMachine à mon nouveau système.

Merci à tous pour m'avoir aidé !