Upgrade to 15.3.2, fsck reports disk as bad (memory bug)

[bergert]

I just updated my Mini M1 from 15.3.0 to 15.3.2. When it mounts my external 60TB RAID disk, I get the message "macOS can't repair the disk <name>". Disk Utility reports error 8; and refuses to mount the volume.

I updated my MacStudio at the same time to 15.3.2, and it CAN mount the RAID volume fine (read/write), and running Disk Utility there are no issues reported or fixed.

Next, I booted the Mini into the emergency mode (hold power button) and re-installed the OS, but it is back at 15.3.2.

At this point, I can only wait for Apple to fix this. Wiping the disk and re-installing the OS will bring back 15.3.2 - but what I really want is revert to 15.3 (15.3.0). No can do!

Thank you Apple, for removing system restore from TimeMachine.

The disk is formatted HFS (journaled). It looks like DiskUtility crashes because of the larger volume and and number of files when on my 32GB-RAM MacStudio the same disk has no issues - and Disk Utilty does not find/fix any issues. Same OS version (15.3.2).

 

[JonaM]

Create a bootable installer of 15.3.0 ( https://swcdn.apple.com/content/dow...mr07vwe27n8hfvubidmxgcbk/InstallAssistant.pkg) and then put on USB stick, erase the Mini using Recovery and then boot from installer to get 15.3 back?
Annoyingly long-winded, but should do it

 

[bergert]

(macStudio 32GB RAM)
sudo fsck_hfs -df /dev/disk18s2
journal_replay(/dev/disk18s2) returned 6
** /dev/rdisk18s2
Cache size should be greater than 32M and less than 17592186044415M
Using cacheBlockSize=32K cacheTotalBlock=98304 cacheSize=3145728K.
Executing fsck_hfs (version hfs-677.81.4).
** Checking Journaled HFS Plus volume.
The volume name is xx
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume xx appears to be OK.
CheckHFS returned 0, fsmodified = 0

% sudo fsck_hfs -df -c 32m /dev/disk18s2
journal_replay(/dev/disk18s2) returned 6
** /dev/rdisk18s2
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
Executing fsck_hfs (version hfs-677.81.4).
** Checking Journaled HFS Plus volume.
The volume name is xx
** Checking extents overflow file.
Couldn't read node #8136
** The volume xx could not be verified completely.
volume check failed with error 12
volume type is pure HFS+
primary MDB is at block 0 0x00
alternate MDB is at block 0 0x00
primary VHB is at block 2 0x02
alternate VHB is at block 97655504766 0x16bcb8bf7e
sector size = 512 0x200
VolumeObject flags = 0x07
total sectors for volume = 97655504768 0x16bcb8bf80
total sectors for embedded volume = 0 0x00
CheckHFS returned 12, fsmodified = 1

% sudo fsck_hfs -df -c 3g /dev/disk18s2
journal_replay(/dev/disk18s2) returned 6
** /dev/rdisk18s2
Using cacheBlockSize=32K cacheTotalBlock=98304 cacheSize=3145728K.
Executing fsck_hfs (version hfs-677.81.4).
** Checking Journaled HFS Plus volume.
The volume name is xx
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume xx appears to be OK.
CheckHFS returned 0, fsmodified = 1

(macMini 8GB RAM)
Mac-mini ~ % sudo fsck_hfs -df /dev/disk4s2
journal_replay(/dev/disk4s2) returned 6
** /dev/rdisk4s2
Using cacheBlockSize=32K cacheTotalBlock=32768 cacheSize=1048576K.
Executing fsck_hfs (version hfs-677.81.4).
** Checking Journaled HFS Plus volume.
The volume name is xx
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
Couldn't read node #61432
** The volume C could not be verified completely.
volume check failed with error 12
volume type is pure HFS+
primary MDB is at block 0 0x00
alternate MDB is at block 0 0x00
primary VHB is at block 2 0x02
alternate VHB is at block 97655504766 0x16bcb8bf7e
sector size = 512 0x200
VolumeObject flags = 0x07
total sectors for volume = 97655504768 0x16bcb8bf80
total sectors for embedded volume = 0 0x00
CheckHFS returned 12, fsmodified = 1

Mac-mini ~ % sudo fsck_hfs -df -c 3g /dev/disk4s2
journal_replay(/dev/disk4s2) returned 6
** /dev/rdisk4s2
Using cacheBlockSize=32K cacheTotalBlock=98304 cacheSize=3145728K.
Executing fsck_hfs (version hfs-677.81.4).
** Checking Journaled HFS Plus volume.
The volume name is C
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume C appears to be OK.
CheckHFS returned 0, fsmodified = 1
%

The solution in my case (not a hardware problem!) is to manually run fsck using a larger cache size (-c option). This resolves the disk bad issue, and Disk Utility can mount it normally (read/write). The volume good state will persist over a restart, after restart the volume is mounted normally.

However, running First Aid from disk utility will report the volume as "bad", and leave it unmounted. Restarting will bring up the error message (backup your data...) and the volume is mounted read-only. To fix, unmount (using Disk Utility) and then manually run fsck using a larger memory allocation. Another option is to run Disk Utility from a computer with more RAM (macStudio in my case).

NOTE: if your disk actually has a hardware problem, backup yor data - and buy a new disk. Re-creating a volume will not fix a hardware problem. In my case, my external RAID enclosure deos report on the state of controller and disks, so I know for sure that my hardware is OK.

 

[Johnny Jackhammer]

I can confirm that this behavior appears to be fixed in macOS Tahoe 26.6. I don't know what happened during the interim... v15.3 — v26.5.2. If there was a regression or it was consistently broken the entire time. I was unable to mount my volume after Finder determined it as "damaged" and when removing and re-adding the volume it was in read only mode!

I tested the same 18 TB Mac OS Extended (Journaled) volume on the same 8 GB Apple-silicon Mac mini, using the same read-only command:

sudo /sbin/fsck_hfs -fn -d /dev/rdisk14s2

Before updating

macOS Tahoe 26.5.2 (build 25F84)
fsck_hfs version: hfs-715.120.4

Using cacheBlockSize=32K cacheTotalBlock=32768 cacheSize=1048576K.
Executing fsck_hfs (version hfs-715.120.4).
** Checking extended attributes file.
Couldn't read node #61432
** The volume could not be verified completely.
    volume check failed with error 12
    CheckHFS returned 12, fsmodified = 0

After updating the same Mac mini

macOS Tahoe 26.6 (build 25G72)
fsck_hfs version: hfs-715.160.9

Using cacheBlockSize=32K cacheTotalBlock=32768 cacheSize=1048576K.
Executing fsck_hfs (version hfs-715.160.9).
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume appears to be OK.
    CheckHFS returned 0, fsmodified = 0

The Mac, its 8 GB of RAM, the HFS+ volume, the command, and the 1 GiB cache allocation were unchanged. The meaningful change was the fsck_hfs build supplied by macOS 26.6.

This indicates that the successful result was not caused by allocating a larger cache. Version 715.160.9 completes the same check with the same 32,768 × 32 KiB cache that version 715.120.4 exhausted or mishandled.

In my case, Disk Utility's earlier “cannot repair” result was therefore a false failure from the older checker, not evidence of actual filesystem or drive damage. Both tests were read-only and reported fsmodified = 0.