Ho affrontato un sacco di problemi con il disco nel corso degli anni, amministra molti sistemi operativi diversi, ma questo è nuovo per me ... aiuto / idee apprezzate prima di arrendermi e ripristinarle!
Mi sono svegliato stamattina con il mio iMac (5K, 27 ", Fine 2014, SSD + 3TB Fusion, OS X 10.11.3) che si è spento da un giorno all'altro (nessun problema di alimentazione altrove in casa o in quella presa ... Il riavvio di un avvio normale causa uno spegnimento prima che l'interfaccia grafica si accenda. L'avvio sicuro fa la stessa cosa Durante un avvio prolisso, ho visto che l'unità di avvio non era in grado di essere montata e il sistema si arresta, entrando in un clean shutdown.
Quindi, ho avviato il ripristino e ho eseguito Utility Disco. L'unità Fusion è stata disattivata, ma l'esecuzione di First Aid non ha rilevato alcun problema con il CoreStorage o il volume effettivo di HFS. Si è rifiutato di montare a mano in una finestra di Terminale (anche con l'opzione readOnly).
Successivamente ho avviato la modalità utente singolo in cui sono riuscito a catturare questi messaggi insoliti:
LachiavequisembraesserelaterzarigaToofewfreesegments,markMLVasreadonly.PresumochequestosiadallastrutturaCoreStoragemasuGoogletrovipochiriferimentiafrasicomequesta.MièvenutoinmentechepotrebberiferirsianchealSSD,maonestamentenonsonomoltofamiliareconilorodettaglidiarchiviazione.Dopodiché,èpossibilevederelariproduzionedeljournalfallitaacausadi"violazione dei privilegi" (presumibilmente lo stato di sola lettura). In caso di avvio normale o sicuro, questo sistema spinge il sistema in un arresto pulito poiché non può montare il volume root in lettura-scrittura con il problema delle autorizzazioni e un diario sporco (vedere più sotto).
È interessante notare che, in avvio da utente singolo, l'unità è montata in sola lettura a / bene. Ho sfogliato le directory e non sembra niente di strano. L'esecuzione di fsck_cs e fsck_hfs a mano non riporta alcun errore. Ma l'unità non riesce a montare la lettura-scrittura in qualsiasi punto. Da single-user, sono stato anche in grado di guardare il system.log, ma non ci sono nemmeno veri indizi. Gli ultimi bit nel registro sembrano i tipici messaggi del ciclo di sonno.
In ogni caso, il volume HFS è solo ~ 60-70% pieno, come confermato nella modalità utente singolo. Curiosamente, il DU mostra il volume come pieno quando avviato in Recovery, ma non sono sicuro che mi fido di questo dato che chiaramente non sta avviando il volume lì (ad esempio, non c'è interruzione dello spazio su disco in tipi di file ... è tutto "Altro").
L'avvio da un'unità esterna non ha dato risultati molto diversi da Recovery: l'unità non può essere montata, nemmeno in sola lettura. Ecco l'output di 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
Ed ecco cosa segnala la Console quando il sistema prova a montare l'unità quando termina fsck_cs - questi sono quasi identici ai messaggi di errore di avvio:
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).
Questo è piuttosto frustrante dal momento che l'avvio da utente singolo (e DU) sembra indicare che il volume HFS è perfetto. Sta funzionando bene per l'anno scorso o così. Niente di speciale è stato ottimizzato il giorno prima che ciò accadesse. Se è importante, una partizione BootCamp sull'HDD si avvia ancora correttamente. E non vedo errori di I / O nei log che spesso preludono all'errore del disco.
A questo punto non ho più idee che distruggere e ricreare il volume CS / Fusion con un backup TM, ma sto cercando altri thread da seguire prima di sprecare un giorno a fare quel processo.