He lidiado con muchos problemas de disco a lo largo de los años administrando muchos sistemas operativos diferentes, pero este es nuevo para mí... ¡se agradece la ayuda/ideas antes de que me rinda y restaure!
Me he despertado esta mañana y mi iMac (5K, 27", finales de 2014, SSD + 3TB Fusion, OS X 10.11.3) se ha apagado durante la noche (no hay problemas de alimentación en ninguna otra parte de la casa, ni en ese enchufe...). Reiniciar un arranque normal provoca un apagado antes de que se dispare la IU gráfica. El arranque seguro hace lo mismo. Durante un arranque verboso, vi que la unidad de arranque no podía ser montada y el sistema se rinde, entrando en un apagado limpio.
Así que, arranqué en Recovery y ejecuté Disk Utility. La unidad Fusion estaba en gris, pero al ejecutar First Aid en ella no se encontraron problemas con el CoreStorage o el volumen HFS real. Se negó a montar a mano en una ventana de Terminal (incluso con la opción readOnly).
A continuación, arranqué en modo monopuesto, donde pude capturar estos inusuales mensajes:
La clave aquí parece ser la tercera línea Too few free segments, mark MLV as readonly . Supongo que esto es de la estructura de CoreStorage pero buscando en Google encuentro muy pocas referencias a frases como esta. Se me pasó por la cabeza que podría referirse al SSD también, pero honestamente no estoy muy familiarizado con sus detalles de almacenamiento. Después de esto, se puede ver que la repetición del diario falla debido a la "violación de privilegios" (presumiblemente el estado de sólo lectura). En los arranques normales o seguros, esto empuja al sistema a un apagado limpio ya que no puede montar el volumen Root de lectura-escritura con el problema de los permisos y un diario sucio (ver más abajo).
Curiosamente, en el arranque de un solo usuario la unidad se monta de sólo lectura en / muy bien. He revisado los directorios y nada parece extraño. Ejecutando fsck_cs y fsck_hfs a mano no reporta ningún error. Pero la unidad falla en el montaje de lectura-escritura en cualquier punto. Desde un solo usuario, también pude mirar el system.log, pero tampoco hay pistas reales allí. Los últimos bits del registro parecen los típicos mensajes del ciclo de sueño.
En cualquier caso, el volumen HFS sólo está lleno en un 60-70%, como se confirma en el modo de usuario único. Curiosamente, DU muestra el volumen como lleno cuando se arranca en Recovery, pero no estoy seguro de confiar en eso ya que claramente no está arrancando el volumen allí (por ejemplo, no hay un desglose en el espacio de la unidad en tipos de archivo... es todo "Otros").
El arranque desde una unidad externa no dio resultados muy diferentes a los del Recovery: la unidad no se puede montar, ni siquiera de sólo lectura. Aquí está la salida 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 OKY esto es lo que informa la consola cuando el sistema trata de montar la unidad cuando fsck_cs termina-estos son casi idénticos a los mensajes de error de arranque:
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).Esto es bastante frustrante ya que el arranque monopuesto (y la DU) parece indicar que el volumen HFS está bien. Ha estado funcionando bien durante el último año o así. Tampoco se ajustó nada especial el día antes de que ocurriera esto. Si importa, una partición BootCamp en el disco duro sigue arrancando bien. Y no veo errores de entrada/salida en los registros que suelen ser preludios de fallos de disco.
En este punto se me acaban las ideas que no sean destruir y volver a crear el volumen de CS/Fusion con una copia de seguridad de TM, pero estoy buscando otros hilos para seguir antes de perder un día haciendo ese proceso.
