A lo largo de los años, he lidiado con muchos problemas de disco al administrar muchos sistemas operativos diferentes, pero este es nuevo para mí ... ¡se agradecen las ideas / ayuda antes de que me rinda y restaure!
Esta mañana me desperté con mi iMac (5K, 27 ", finales de 2014, SSD + 3TB Fusion, OS X 10.11.3) que se apagó durante la noche (no hay problemas de alimentación en ninguna otra parte de la casa, ni en esa salida ... ). El reinicio de un arranque normal provoca un apagado antes de que se inicie la IU gráfica. El arranque seguro hace lo mismo. Durante un arranque detallado, vi que la unidad de arranque no se pudo montar y el sistema se rindió, entrando en un cierre limpio.
Entonces, inicié la recuperación y ejecuté la Utilidad de Discos. La unidad Fusion estaba en gris, pero al ejecutar First Aid en ella no se encontraron problemas con el CoreStorage o el volumen real de HFS. Se negó a montar a mano en una ventana de Terminal (incluso con la opción readOnly).
A continuación, inicié el modo de usuario único en el que pude capturar estos mensajes inusuales:
LaclaveaquípareceserlaterceralíneaToofewfreesegments,markMLVasreadonly.SupongoqueestoesdelaestructuraCoreStorageperoGooglebuscamuypocasreferenciasafrasescomoesta.SemeocurrióquepodríaestarrefiriéndosetambiénalaSSD,pero,sinceramente,noestoymuyfamiliarizadoconsusdetallesdealmacenamiento.Despuésdeeso,puedeverquelareproduccióndeldiariofalladebidoauna"violación de privilegios" (presumiblemente el estado de solo lectura). En los arranques normales o seguros, esto empuja al sistema a un cierre limpio, ya que no puede montar el volumen raíz de lectura-escritura con el problema de los permisos y un diario sucio (vea más a continuación).
Curiosamente, en el arranque de un solo usuario, la unidad se monta de solo lectura en / muy bien. He hojeado los directorios y nada se ve raro. La ejecución manual de fsck_cs y fsck_hfs no produce errores. Pero la unidad no puede montar lectura-escritura en ningún punto. Desde un solo usuario, también pude ver el system.log, pero tampoco hay pistas reales. Los últimos bits del registro se parecen a los mensajes típicos del ciclo de suspensión.
En cualquier caso, el volumen HFS tiene solo un 60% -70%, como se confirmó en el modo de usuario único. Curiosamente, DU muestra que el volumen está completo cuando se inicia en la recuperación, pero no estoy seguro de que confíe en eso ya que claramente no está iniciando el volumen allí (por ejemplo, no hay un desglose del espacio de la unidad en los tipos de archivos ... es todo "Otro").
El arranque desde una unidad externa no dio resultados muy diferentes a la recuperación: la unidad no se puede montar, ni siquiera en modo de solo 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 OK
Y esto es lo que la Consola informa cuando el sistema intenta montar la unidad cuando finaliza fsck_cs; 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 inicio de un solo usuario (y DU) parece indicar que el volumen HFS está bien. Ha estado funcionando bien durante el último año más o menos. Nada especial fue ajustado el día antes de que esto sucediera, tampoco. Si es importante, una partición BootCamp en el HDD aún arranca muy bien. Y no veo errores de E / S en los registros que a menudo son preludios de la falla del disco.
En este momento no tengo más ideas que destruir y volver a crear el volumen CS / Fusion con una copia de seguridad TM, pero estoy buscando otros hilos antes de desperdiciar un día haciendo ese proceso.