0

Ventura's disk utility has found unrepairable APFS errors (invalid checksums, bit flips, fsroot tree is invalid) while running First Aid on my Mojave volume. Without knowing more specifically what files or data structures are actually affected by the reported problems I find it difficult to gague the extent of current damage and risk of future damage. More specifically, what I can't determine from the First Aid output is:

  1. Which files are affected?
  2. Is the entire existing tree untrustworthy?
  3. Is the damage local to preexisting objects, or of a nature that could potentially affect newly created files and structures?
  4. ...and whether I should put less trust in backups made after the problem arose.

Why do I want to know these things? Without knowing...

  • ...#1 I don't know how to replace damaged files even after I reformat, do a clean install, and restore from a backup (if that backup happens to have been made after the corruption).
  • ...#2 I don't know whether I can "fix" (work around) the problem by replacing individual files, or whether I need to reformat the whole volume. Though I'm leaning toward a reformat since I just discovered some "non-empty" empty directories that are impossible to remove, which does not bode well. That said, so far I can still run and use Mojave normally from that volume, so damage might be localized (?)
  • ...#3 I don't know if I should avoid writes to the file system in the meantime, while working on a solution.
  • ...#1 or #2 I can't determine #4; whether my backups have been affected and whether I should compensate for that.

man fsck_apfs does not explain the output. In the output below I'm guessing that oid, btn and xid are object id, b-tree node and extent id respectively, but even if so that doesn't help me much.

The question in one sentence: Is it possible to identify the damaged objects in a way that's more relatable to me as a user? In essence, can I use the following information to conclude anything other than "reformat and restore everything"?

First Aid output (Ventura 13.4.1)

Running First Aid on “Mojave” (disk1s1)

Verifying the startup volume will cause this computer to stop responding.

Verifying file system.
Volume could not be unmounted.
Using live mode.
Performing fsck_apfs -n -l -x /dev/rdisk1s1
Checking the container superblock.
Checking the checkpoint with transaction ID 5195073.
Checking the EFI jumpstart record.
Checking the space manager.
Checking the space manager free queue trees.
Checking the object map.
Checking the encryption key structures.
Checking volume /dev/rdisk1s1.
Checking the APFS volume superblock.
The volume Mojave was formatted by diskmanagementd (945.250.134) and last modified by apfs_kext (945.275.10).
Checking the object map.
Checking the snapshot metadata tree.
Checking the snapshot metadata.
Checking snapshot 1 of 7 (com.apple.TimeMachine.2023-08-21-224452)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking snapshot 2 of 7 (com.apple.TimeMachine.2023-08-21-234501)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking snapshot 3 of 7 (com.apple.TimeMachine.2023-08-22-010420)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking snapshot 4 of 7 (com.apple.TimeMachine.2023-08-22-020426)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking snapshot 5 of 7 (com.apple.TimeMachine.2023-08-22-030433)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking snapshot 6 of 7 (com.apple.TimeMachine.2023-08-22-150009)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking snapshot 7 of 7 (com.apple.TimeMachine.2023-08-22-160051)
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
Checking the document ID tree.
Checking the fsroot tree.
warning: (oid 0x77c55) apfs_root: btn: invalid o_cksum (0x97a332a0c0f82f0f)
warning: aborting jobj validations for current fsck pass - trying to repair fsroot tree with invalid nodes
warning: (oid 0xc19a3) apfs_root: btn: invalid o_cksum (0x4b9ff977efadac3f)
error: (oid 0xc19a3) apfs_root: btn: found a bit flip at index 0x2e0c
warning: (oid 0xc1bd4) apfs_root: btn: invalid o_cksum (0x3543b8b7c0db6d66)
error: (oid 0xc1bd4) apfs_root: btn: found a bit flip at index 0x5d6f
warning: (oid 0xca9b8) apfs_root: btn: invalid o_cksum (0xc42a5017cd0fefbc)
error: (oid 0xca9b8) apfs_root: btn: found a bit flip at index 0x12c
warning: (oid 0xe5dab) apfs_root: btn: invalid o_cksum (0xf95d016805396644)
error: (oid 0xe5dab) apfs_root: btn: found a bit flip at index 0x2604
warning: (oid 0xe9e98) apfs_root: btn: invalid o_cksum (0xbe64f3bb3dae3b25)
warning: (oid 0x1d4352) apfs_root: btn: invalid o_cksum (0xd4eabeb7839d1400)
error: (oid 0x1d4352) apfs_root: btn: found a bit flip at index 0x420c
warning: (oid 0x1d7884) apfs_root: btn: invalid o_cksum (0xbe2eef72f85b5d84)
warning: (oid 0x2f6cf4) apfs_root: btn: invalid o_cksum (0x3732b1710e70951d)
warning: (oid 0x384ae7) apfs_root: btn: invalid o_cksum (0xe946e4cbedd29ee9)
error: btn: oid (285044), xid (5195072), type (0x2), subtype (0xe), flags (0x1) level (3)
error: btn: invalid btn_btree.bt_key_count (expected 7724707, actual 7725062)
fsroot tree is invalid.
The volume /dev/rdisk1s1 was found to be corrupt and cannot be repaired.
Verifying allocated space.
The volume /dev/rdisk1s1 could not be verified completely.
File system check exit code is 8.
Restoring the original state found as mounted.
File system verify or repair failed. : (-69845)

Operation successful.

Rest assured that the inconsistencies in all likelihood arose due to a bad physical SATA connection — not a failing drive — which has since been corrected (as well as the situation allows). This is determined by using an hourly log of S.M.A.R.T data and comparing CRC error counts, and has happened before. I have no reason at present to suspect faulty physical media.

3
  • 1
    It may be worse than you realise. APFS only checksums its own file system structure which you are being told can't be repaired. It does not checksum file data, so you may (or may not) also have corrupt file data. Try "First Aid" in recovery mode.
    – Gilby
    Commented Aug 24, 2023 at 23:49
  • @Gilby That's true. It's in the back of my head but for some reason I can never shake the thought "maybe they've started checksumming file contents". I've tried First Aid in recovery mode, but those results are even less verbose, probably since it's Mojave's Recovery (?) and not my OpenCore install of Ventura's. Thanks all the same. Also I did run hashdeep on all data at the time of the corruption and compared against a good backup, so critical files have been replaced already. Most concerning is if the entire tree or future writes are untrustworthy...
    – Andreas
    Commented Aug 25, 2023 at 13:11
  • * "future writes" = past writes at this point, since corruption happened months ago but I didn't have the time to clean it up. Didn't think of the possibility of endangering future writes at that point.
    – Andreas
    Commented Aug 25, 2023 at 13:16

0

You must log in to answer this question.

Browse other questions tagged .