Épître dominicale sur un sujet byzantin
pickwick.
Certainement encore une des double joyeusetés inaugurées avec Fusion Drive et Yosemite.
Un gag du core storage.
Il faut peut être défaire le Fusion Drive et le refaire ensuite avant de pouvoir installer Yo ?
Peut être que MacO qui adore ces problèmes passera par là ?
Tiens ! Ça faisait longtemps qu'on n'avait plus reçu de message de détresse en provenance d'un
Fusion Drive en train de couler par le fond...
Je peux déjà régler un point de détail, qui a occasionné l'intitulé de ce fil : «
Disque dur interne passé en mode read only » --> lorsqu'on démarre le Mac en mode
Single User (avec les touches ⌘S pressées), on n'ouvre pas
in fine une session d'utilisateur
admin graphique, mais une session d'utilisateur
root dans un
shell en mode texte. Les lignes qui défilent au début décrivent en mode
verbose les phases du
pré-boot :
kernel +
extensions (en gros le lancement du pilotage de la bécane physique). Lorsque l'invite de commande :
-bash-3.2# s'affiche à la fin de ce défilement, eh bien ! le système de fichiers de l'OS n'est pas encore chargé, à proprement parler : aucun des
daemons n'est activé notamment. L'utilisateur
root n'a devant lui qu'un système de fichiers monté en volume en mode "
read_only" (lecture seule) justement, et s'il veut intervenir sur ce système de fichiers "en plan", il lui faut d'abord passer une commande de "re-montage" du système de fichiers en mode
writable (éditable en écriture), qui est le classique :
mount -uw / --> l'information que tu as obtenue dans la session du
Single User en fin de chargement des pilotes de la bécane par le
kernel : système de fichiers en mode
read_only ne signale donc aucune anomalie - c'est l'état absolument normal des choses dans ce
shell de
root = système de fichiers de l'OS monté en volume simple, sans activations des
daemons, en mode "
read_only" par défaut. Donc RAS.
☞ Je crois, par suite, que le vrai titre de ton fil serait plutôt un de ce genre :
« Problème avec le Volume Logique d'un Fusion Drive : OS X s'installe mais ne démarre pas »
--------------------
Ce qui nous ramène à la question du
Fusion Drive qui, comme l'a bien vu
Invité , me paraît le
point nodal dans le cas que tu as soumis.
Ton ami a donc un
iMac, avec un
Fusion Drive de 1 To : qu'est-ce que ça signifie concrètement ? Qu'il y a 2 disques attachés dans sa bécane : un SSD en connexion SATA, que je supposerai d'une taille de 128 Go ; et un HDD (disque à plateaux) à la place du Super-Drive, que je supposerai d'une taille de 1 To, ce qui donnerait un espace global de 1,13 To.
Qu'est-ce alors que le
Fusion Drive ? Un procédé de solidarisation logique de ces 2 disques physiques séparés, qui fait ce que faisait déjà l'
Apple RAID mais par des procédés plus modernes et en offrant des services plus diversifiés que ce procédé plus ancien. Ce nouveau procédé, contemporain à sa création de l'OS «
Lion 10.7» et introduit d'abord afin de permettre le chiffrement «
FileVault-2» du volume de l'OS, s'intitule le :
CoreStorage. Ce dernier utilise (dans le cas d'un
CoreStorage simple tel qu'il a été "popularisé" par l'installateur de «
Yosemite») comme base la partition n°2 (
/dev/disk0s2) au format
jhfs+ d'un disque tablé en
Table de Partition GUID et commence par "asseoir" sur la partition en question une couche logique
émulant un disque dur qui s'intitule un : "
Physical Volume". Ce "
Physical Volume" (qui est donc un "disque émulé") sert de support à l'exportation d'un volume tout à fait spécial, qui est un "
Logical Volume", pilotable par une instance médiatrice entre le
Volume Physique et le
Volume Logique dite : "
Logical Volume Family" (capable de gérer le chiffrement de ce volume, par exemple, ou une distribution préférentielle des écritures). C'est uniquement tout en "haut" de cet édifice logique (qui est un "bassin d'instances" dénommé un :
Groupe de Volumes Logiques), "
on top of the pool", que se trouve contenu le système de fichiers
jhfs+ standard d'un OS. On a donc :
Table de Partition GUID -->
partition jhfs+ -->
Physical Volume -->
Logical Volume Family -->
Logical Volume -->
filesystem jhfs+ de l'OS.
Dans le cas d'un
Fusion Drive, il y a 2
Physical Volumes : un "assis" sur la partition
GUID :
/dev/disk0s2 du SSD-SATA et un "assis" sur la partition
GUID :
/dev/disk1s2 du HDD --> les 2 supervisés par une
Famille de Volumes Logiques unique (capable de gérer une allocation préférentielle des écritures aux blocs des disques assimilés au
Physical Volume n°1 = SSD vs au
Physical Volume n°2 = HDD), qui exporte à partir de ces 2
Physical Volumes un
Volume Logique unique.
Le principe d'écriture imposé par le format
CoreStorage en cas de
Fusion Drive (2 disques hétérogènes associés logiquement) est le suivant : toutes les écritures à l'installation de l'OS et après vont au SSD exclusivement jusqu'à saturation de l'espace-disque correspondant aux 90% de ce disque (il y a toujours 10% d'espace réservé à une mémoire-tampon) ;
sauf l'installation de la «
Recovery HD» qui se fait toujours sur une partition terminale de 650 Mo du HDD
hors CoreStorage ; à partir du dépassement des 90% d'espace-disque disponible du SSD --> toutes les écritures excédentaires se font dans un 1er temps au HDD --> puis, dans les phases de veille "inactive" du Mac, il y a redistribution fonctionnelle des écritures : les écritures des blocs du HDD correspondant au
Physical Volume n° 2 les plus fréquemment atteints en lecture sont transférées aux blocs du SSD corrrespondant au
Physical Volume n° 1 les moins fréquemment atteints en lecture et vice-versa (dans certains limites : ensembles de moins de 4 Go).
--------------------
Cet indigeste topo concernant le
Fusion Drive (que je ne peux jamais m'empêcher d'imaginer comme l'attelage improbable du
lièvre & de la
tortue - si les
tortues n'étaient pas réputées pour leur longévité à la différence des HDD) permet pourtant de tirer des
conjectures expérimentales.
La fragilité du
Fusion Drive, c'est clairement
la tortue le HDD (disque à plateaux en rotation). Si le HDD tombe carrément en rade, le
Volume Logique de synthèse exporté par le
CoreStorage est fichu : impossible de le monter, parce qu'un des 2
Physical Volumes (le n° 2) est planté. Donc le système de fichiers
jhfs+ terminal : celui de l'OS avec les données, contenu dans ce
Logical Volume, est fichu lui aussi.
Ce n'est pas le cas avec l'
iMac de ton ami. Mais (il y a un mais) si le HDD, au lieu d'être absolument HS, est seulement en train de "fatiguer" - eh bien ! là, on entre dans une zone de flottement. J'en veux pour preuve ce fil épique : ☞
Installer 2 OS différents sur le même disque☜ où j'ai essayé par toutes les combinaisons logiques possibles (jusqu'à 2 Fusion Drives parallèles ou 1 Fusion Drive & 1 AppleRAID concomitants) de tirer d'affaire Guyllaume sans remettre en question les prémisses : l'association logique de 2 disques d'un iMac (SSD + HDD). Les OS parvenaient à s'installer, mais soit l'un des 2 ne démarrait pas, soit après démarrage les processus ralentissaient jusqu'au plantage. Ce qui en est ressorti à la fin de l'histoire : le HDD était en train de lâcher.
A priori, c'est ce que je suspecterais dans le cas de l'iMac de ton pote. Il démarre sans problème sur un système externe. L'installation se fait sans problème sur le Volume Logique de synthèse du CoreStorage. Mais le re-démarrage plante. Car ce que tu as reformaté, ce n'est pas le "disque" (impossible avec un CoreStorage de type Fusion Drive : les disques physiques réels sont inaccessibles ; les Physical Volumes émulés sont également intouchables ; le Logical Volume de synthèse est lui-même inaccessible dans son format CoreStorage, via l'«Utilitaire de Disque») ; tu n'as pu que supprimer le filesystem sommital jhfs+ et en re-créer un autre dans le "container" intouchable Groupe de Volumes Logiques : CoreStorage). Lors de l'installation des 12 Go décompressés environ de l'OS, tout s'est écrit aux blocs relevant du SSD (no problem) ; mais lors du re-démarrage, c'est l'ensemble de l'attelage : lièvre + tortue qui doit être opérationnel, car le Volume Logique unique dépend d'une Famille de Volumes Logiques qui doit prendre en charge les 2 Physical Volumes émulés (celui du HDD y compris, puisqu'elle a en charge l'optimisation des écritures entre les 2). Là, si ton HDD a du plomb dans l'aile : ça ne démarre pas...
Il y a un test critique : la «Recovery HD» s'installe toujours exclusivement, en cas de Fusion Drive, sur une partition caudale de 650 Mo du HDD hors CoreStorage (/dev/disk1s3). Or tu dis qu'elle est introuvable après installation régulière à partir d'un installateur Apple résidant sur un disque externe démarrable. Il faut savoir qu'en cas de CoreStorage (aussi bien simple, que double = Fusion Drive, sans ou avec chiffrement par «FileVault-2»), jamais le volume de la «Recovery HD» n'est affiché à l'écran de choix du disque de démarrage obtenu avec la touche "alt". On n'y accède qu'avec la combinaison directe ⌘R au départ. Test : si tu démarres avec ⌘R, est-ce que tu atteins le Bureau simplifié de la partition de récupération ? Super-test : si tu passes la commande dans le «Terminal» :
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> est-ce que tu vois listée une : Apple_Boot Recovery HD 650.0 MB disk1s3 ou rien ? Si rien, c'est qu'à l'installation, les blocs du HDD ne sont pas "scriptibles" (seul les blocs du SSD affectés au
Physical Volume n° 1 le sont, tandis qu'au re-démarrage, la défaillance du HDD "plombe" l'ensemble).
[NB. Je pense que «
DiskWarrior» est incapable de gérer une structure logique de type :
CoreStorage. Je ne me fierais pas aux réactions de ce logiciel en cas de
Fusion Drive. Il doit vérifier seulement le niveau de la
Table de Partition GUID élémentaire.]
--------------------
Si tu passes la commande dans le «
Terminal» (de ton système externe démarré) :
tu vas obtenir en retour l'affichage du tableau complet du
Groupe de Volumes Logiques : CoreStorage de ton
Fusion Drive. Tu noteras, tout en haut de tableau, à la rubrique :
Logical Volume Group, un
UUID (
Universal
Unique
IDentifier :
IDentifiant
Unique
Universel) de 32 caractères alphanumériques sur la droite de ce titre, de type :
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Si tu le sélectionnes et fais un ⌘C (copier dans le presse-papier) de cet
UUID, tu peux passer une commande :
Bloc de code:
sudo diskutil coreStorage deleteLVG xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
(où tu colles par ⌘V l'
UUID du presse-papier à sa place) et ↩︎ --> demande de
password (commande
sudo) --> tape ton mot-de-passe
admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> attends le réaffichage de l'invite de commande : le format
CoreStorage va être détruit (avec toutes les écritures du
Volume Logique) et les 2 disques désolidarisés.
Re-démarre impérativement pour que le
kernel charge le nouvel état des disques. Tu peux faire dans l'«
Utilitaire de Disque» un "
Effacer" sur le disque physique global du SSD et itou sur le HDD --> tu obtiens 2 disques distincts, chacun supportant une
Table de Partition GUID et exportant un volume
jhfs+ principal.
Si tu tentes 2 installations parallèles de l'OS, l'une sur le volume du SSD, l'autre sur celui du HDD, est-ce que ça démarre sur le volume SSD et est-ce que ça plante sur celui du HDD ?
À supposer que le volume du HDD n'accepte plus de fonctionner que comme volume de
stockage et pas comme volume de
boot, tu pourrais laisser l'OS installé uniquement sur le SSD, et déporter le dossier de compte de ton pote sur le volume du HDD (recopié de ta sauvegarde) puis lier son identité d'utilisateur au dossier de compte déporté sur le volume du HDD comme dossier de départ (panneau des
Utilisateurs et groupes --> sélectionner le Nom d'Utilisateur avec la touche
ctrl pressée -->
Options avancées... --> rubrique :
Répertoire de départ : naviguer au dossier de compte déporté sur le volume du HDD et presser le bouton "
Ouvrir" qui le sélectionne).
Voir si ça marche - mais honnêtement, s'il y a des doutes quant à l'état de santé du HDD, avoir un dossier de compte déporté sur un volume qui en dépend, c'est comme d'avoir placé ses économies dans les emprunts russes à l'époque...
[NB. En cas de doutes sur l'état de santé du HDD, comme l'
iMac bénéficie toujours de l'
AppleCare : c'est au SAV de prendre en charge le remplacement du HDD. Et je ne pense pas que la suppression expérimentale du
Fusion Drive - opération purement logique sur les disques - entame en quoi que ce soit cette garantie. S'il y avait lieu, demande quelles commandes permettent d'en re-créer un, plantable au re-démarrage & donc indistinguable du premier ©Apple...]
--------------------
