J'ai eu à faire face à de nombreux problèmes de disque au cours des années en administrant de nombreux systèmes d'exploitation différents, mais celui-ci est nouveau pour moi... aide/idées appréciées avant que je n'abandonne et ne restaure !
Je me suis réveillé ce matin et mon iMac (5K, 27", Late 2014, SSD + 3TB Fusion, OS X 10.11.3) s'est éteint pendant la nuit (pas de problèmes d'alimentation ailleurs dans la maison, ou sur cette prise...). Le redémarrage d'un démarrage normal provoque un arrêt avant que l'interface graphique ne se déclenche. Le démarrage sécurisé fait la même chose. Au cours d'un démarrage détaillé, j'ai vu que le lecteur de démarrage ne pouvait pas être monté et le système a abandonné, passant à un arrêt complet.
Donc, j'ai démarré en mode récupération et j'ai lancé l'utilitaire de disque. Le disque Fusion était grisé mais l'exécution de First Aid n'a trouvé aucun problème avec le CoreStorage ou le volume HFS. Il a refusé de se monter manuellement dans une fenêtre Terminal (même avec l'option readOnly).
J'ai ensuite démarré en mode mono-utilisateur où j'ai pu capturer ces messages inhabituels :
La clé ici semble être la 3ème ligne Too few free segments, mark MLV as readonly . Je suppose que cela provient de la structure CoreStorage, mais Google a trouvé très peu de références à des phrases de ce type. Il m'est venu à l'esprit que cela pouvait également faire référence au SSD, mais honnêtement, je ne suis pas trop familier avec les détails de leur stockage. Après cela, vous pouvez voir que la relecture du journal échoue en raison d'une "violation de privilège" (vraisemblablement le statut de lecture seule). Sur les démarrages normaux ou sûrs, cela pousse le système dans un arrêt propre car il ne peut pas monter le volume Root en lecture-écriture avec le problème de permissions et un journal sale (voir plus bas).
Il est intéressant de noter que, dans le cadre d'un démarrage en mode mono-utilisateur, le disque est monté en lecture seule à l'emplacement suivant / très bien. J'ai parcouru les répertoires et rien ne semble bizarre. L'exécution de fsck_cs et fsck_hfs à la main ne rapporte aucune erreur. Mais le disque ne parvient pas à monter en lecture-écriture à n'importe quel moment. En mode mono-utilisateur, j'ai également pu consulter le fichier system.log, mais aucun indice réel là non plus. Les derniers bits du journal ressemblent à des messages typiques du cycle de sommeil.
Quoi qu'il en soit, le volume HFS n'est rempli qu'à ~60-70%, comme le confirme le mode mono-utilisateur. Curieusement, DU indique que le volume est plein lorsqu'il est démarré en mode Recovery, mais je ne suis pas sûr de faire confiance à cela puisqu'il ne démarre clairement pas le volume à cet endroit (par exemple, il n'y a pas de répartition de l'espace disque en types de fichiers... c'est tout "Other").
Le démarrage à partir d'un disque externe n'a pas donné de résultats très différents de ceux de Recovery - le disque ne peut pas être monté, même en lecture seule. Voici la sortie de fsck_cs :
Executing fsck_cs (version 517.20.1)
** Checking volume
** disk0s2: Scan for Volume Headers
** disk1s2: Scan for Volume Headers
** disk1s5: Scan for Volume Headers
** disk0s2: Scan for Disk Labels
** disk1s2: Scan for Disk Labels
** disk1s5: Scan for Disk Labels
** Logical Volume Group 56BA393B-9EF3-4BE6-8CA0-240920F97724 spans 3 devices
** disk0s2+disk1s2+disk1s5: Scan for Metadata Volume
** Logical Volume Group has a 210 MB Metadata Volume with double redundancy
** Start scanning metadata for a valid checkpoint
** Load and verify Segment Headers
** Load and verify Checkpoint Payload
** Load and verify Transaction Segment
** Incorporate 0 newer non-checkpoint transactions
** Load and verify Virtual Address Table
** Load and verify Segment Usage Table
** Load and verify Metadata Superblock
** Load and verify Logical Volumes B-Trees
** Logical Volume Group contains 1 Logical Volume
** Load and verify DF9F3BA2-1863-4EEF-AA29-EEA46DE5151E
** Load and verify 13503CA3-FAC4-4CB1-ACF4-6930800B12E8
** Load and verify Freespace Summary
** Load and verify Block Accounting
** Load and verify Live Virtual Addresses
** Newest transaction commit checkpoint is valid
** Load and verify Segment Cleaning
** The volume 56BA393B-9EF3-4BE6-8CA0-240920F97724 appears to be OKEt voici ce que la console indique lorsque le système tente de monter le disque à la fin de fsck_cs - ces messages sont presque identiques aux messages d'erreur de démarrage :
com.apple.kextd[24]: LVG changed
kernel[0]: CoreStorage: fsck_cs has finished for group "56BA393B-9EF3-4BE6-8CA0-240920F97724" with status 0x00
com.apple.kextd[24]: LVG changed
kernel[0]: thr <ptr> Upgrading read-only MLV to at least read-only LV because LVG is sparse
kernel[0]: thr <ptr> Too few free segments, mark MLV as readonly
com.apple.kextd[24]: LVG changed
kernel[0]: hfs: early journal init: volume on disk2 is read-only and journal is dirty. Can not mount volume.
kernel[0]: hfs_mountfs: hfs_early_journal_init failed, erroring out
kernel[0]: hfs_mount: hfs_mountfs returned error=22 for device disk2
diskarbitrationd[46]: unable to mount /dev/disk2 (status code 0x00000001).C'est assez frustrant car le démarrage en mode mono-utilisateur (et le DU) semble indiquer que le volume HFS est parfait. Il fonctionne bien depuis environ un an. Rien de spécial n'a été modifié la veille du jour où cela s'est produit, non plus. Si cela est important, une partition BootCamp sur le disque dur démarre toujours très bien. Et je ne vois aucune erreur d'entrée/sortie dans les journaux qui sont souvent le prélude à une défaillance du disque.
A ce stade, je n'ai plus d'autres idées que de détruire et recréer le volume CS/Fusion avec une sauvegarde TM, mais je cherche d'autres fils de discussion à suivre avant de perdre une journée à faire ce processus.
