Wade Tregaskis
Wade Tregaskis订阅

macOS 27 Golden Gate does not actually support CoreStorage or HFS+ volumes

macOS 15 Sequoia had a hard time with CoreStorage and HFS+ volumes, since it deprecated both technologies and callously crippled some important tools for working with them, but nonetheless it mostly still worked. While I’d often – but not always – have to manually unlock one of my HFS+ volumes – but not the others – at boot, and it also refused to convert some – but not all – volumes from HFS+ to APFS, keeping me trapped in the situation – it ultimately still worked. I could get at my data and use the volumes more or less normally.

Unfortunately, in macOS 27 that’s no longer the case. Not only does Golden Gate just not support CoreStorage or HFS+ volumes, out of the box you can’t do anything with them – can’t mount them, can’t convert them to APFS, can’t even erase them. It renders your expensive storage hardware completely useless.

Worse, macOS 27 puts up a misleading dialog, upon boot, saying that macOS 28 (the next version) won’t support these volumes. I have no idea what Apple’s doing or thinking. Maybe it’s all just an embarrassing misunderstanding – the file system team told the notifications team that CoreStorage & HFS support is gone, and typoed the version number as 28 rather than 27?

Details

macOS 27 cannot mount CoreStorage or HFS+ volumes automatically or through any normal means. Worse, Disk Utility can’t mount them even when manually told to – it just fails with the cryptic error:

com.apple.DiskManagement.disenter error 49,153

diskutil mount also fails, this time with an error message that is a blatant lie:

disk27 is a CoreStorage Logical Volume which is locked; use "diskutil coreStorage unlockVolume" 
$ diskutil cs unlockVolume BC304645-7D99-481E-931F-855B3011D89D
BC304645-7D99-481E-931F-855B3011D89D is already unlocked and is attached as disk27
$ diskutil cs list 
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
 =========================================================
 Name: Smash
 Status: Online
 Size: 2000054960128 B (2.0 TB)
 Free Space: 0 B (0 B)
 |
 +-< Physical Volume 1B5A1754-184B-4F17-A797-BF69B4BB627F
 | ----------------------------------------------------
 | Index: 0
 | Disk: disk10s2
 | Status: Online
 | Size: 2000054960128 B (2.0 TB)
 |
 +-> Logical Volume Family 376204CD-8048-4962-B05C-72F4FC16B77B
 ----------------------------------------------------------
 Encryption Type: AES-XTS
 Encryption Status: Unlocked
 Conversion Status: Complete
 High Level Queries: Fully Secure
 | Passphrase Required
 | Accepts New Users
 | Has Visible Users
 | Has Volume Key
 |
 +-> Logical Volume BC304645-7D99-481E-931F-855B3011D89D
 ---------------------------------------------------
 Disk: disk27
 Status: Online
 Size (Total): 1999702634496 B (2.0 TB)
 Revertible: No
 LV Name: Smash
 Volume Name: Smash
 Content Hint: Apple_HFS

Tangentially: surprisingly, hfsutils (installed via brew) don’t work at all:

$ sudo hmount /dev/disk27
hmount: /dev/disk27: not a Macintosh HFS volume (Invalid argument)
$ sudo hmount /dev/disk10s2
hmount: /dev/disk10s2: not a Macintosh HFS volume (Invalid argument)

But what’s even worse about this dumpster fire is that macOS 27 can mount these volumes just fine – it’s just that all the normal ways to do it are completely broken. If you go down to a lower level and run mount_hfs directly, it does work:

$ sudo mkdir -p /Volumes/Smash
$ sudo mount_hfs -o rdonly /dev/disk27 /Volumes/Smash
$ ls /Volumes/Smash
Documents Pictures Scratch space

That said… that -o rdonly parameter… in principle it shouldn’t be required, but I could not get macOS 27 to let me mount any HFS+ or CoreStorage volume as read-write – no matter what I did, it always fails with error “Resource busy” (EBUSY). I spent a lot of time trying to debug this, and could find no evidence of anything having the volume in question open (nothing in lsof etc).

But wait, it gets worse.

macOS 27 can’t even erase the volume. All the normal tools – diskutil, Disk Utility, etc – fail with that same “Resource busy” error.

Workaround

Thankfully, with the help of Gemini 4 Argon, I did find a workaround. It’s convoluted, but takes only a few steps, thankfully.

First, while if you try to delete the logical volume group it ostensibly fails, it doesn’t completely fail – it does actually delete the logical volume(s) within:

$ diskutil cs delete 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
Started CoreStorage operation
Unmounting Logical Volumes
Destroying Logical Volume Group
Erasing disk10s2
newfs_hfs: cannot create filesystem on /dev/rdisk10s2: Resource busy
Mounting disk
Could not mount disk10s2 after erase
Error: -69832: File system formatter failed
1 💣 Max [2047] /Volumes/Macintosh HD/System/Volumes/Data/Users/robot/Documents/TUIkit 👾 diskutil cs list 
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
 =========================================================
 Name: Smash
 Status: Offline
 Size: 2000054960128 B (2.0 TB)
 Free Space: -none-
 |
 +-< Physical Volume 1B5A1754-184B-4F17-A797-BF69B4BB627F
 ----------------------------------------------------
 (No properties)
$ diskutil cs delete 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
Started CoreStorage operation
Destroying Logical Volume Group
Error: -69783: Unable to delete the CoreStorage Logical Volume Group

You still can’t destroy it completely, nor can you erase the physical volume yet – the “Resource busy” errors persist. But, the trick is to restart – after that, you can then erase the volume.

So it seems that whatever broken thing is holding the physical volume (or logical volume group) in a ‘busy’ state is tied to the existence of the logical volume(s) therein, and once they’re deleted (and the machine rebooted) the bug stops being triggered.

Call for better workarounds

I’ve glossed over a lot of debugging and attempts I made to save the volume in-place, by either making it work as-is (even if only with e.g. hfsutils) or by converting it to APFS, but neither I nor Gemini 4 Argon could find anything that worked. It’s too late for me – I was forced to just delete all my HFS+ & CoreStorage volumes and rebuild them painstakingly from backups – but if anyone finds a way, I’d love to amend this post, for the benefit of future readers.

  1. The problem remains the same in macOS 27 – so three major macOS versions, at a minimum, where essential system update functionality has flat-out not worked. Sigh.

    $ diskutil apfs convert disk27
    Converting the volume on disk27 to an APFS Volume on an APFS Container
    Started APFS operation on disk27 (Smash)
    Converting HFS Volume to an APFS Container which will export one APFS Volume
    The target is the Journaled HFS+ volume "Smash" on disk27 backed via CoreStorage on disk10s2
    Checking booter partition disk10s3
    The target is a data disk; it is not a macOS system disk
    No APFS EFI driver found to install
    Saving encryption context
    The target is encrypted
    Unmounting disk27
    Starting conversion from HFS to APFS
    Performing apfs_hfs_convert -x --verbose=0x400 /dev/disk10s2
    Reporting post-conversion statistics
    A problem occurred during conversion from HFS to APFS
    APFS Converter exit code is 1
    Aborted conversion in commit mode so will restore type
    Setting type of disk10s2 to CS
    Changing the physical disk partition type in shared mode
    Partition modification attempt count was 1
    Not mounting APFS Volume
    Exiting conversion operations with error code -69860
    Error: -69860: The underlying task reported failure on exit
    Underlying error: 1
参与讨论