macOS 27 Golden Gate does not actually support CoreStorage volumes – Wade Tregaskis

macOS 15 Sequoia had a hard time with CoreStorage – and thus encrypted 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 APFS1, 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 / encrypted 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 & encrypted HFS+ support is going away, and typoed the version number as 28 rather than 27? Details macOS 27 cannot mount CoreStorage 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-855B3011D89DBC304645-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/disk27hmount: /dev/disk27: not a Macintosh HFS volume (Invalid argument)$ sudo hmount /dev/disk10s2hmount: /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/SmashDocuments 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-on-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-C1BBEBDAFCEBStarted CoreStorage operationUnmounting Logical VolumesDestroying Logical Volume GroupErasing disk10s2newfs_hfs: cannot create filesystem on /dev/rdisk10s2: Resource busyMounting diskCould not mount disk10s2 after eraseError: -69832: File system formatter failed1 💣 $ 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-C1BBEBDAFCEBStarted CoreStorage operationDestroying Logical Volume GroupError: -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. The problem remains the same in macOS 27 – so three major macOS versions, at a minimum, where essential system update functionality has not worked. Sigh.$ diskutil apfs convert disk27Converting the volume on disk27 to an APFS Volume on an APFS ContainerStarted APFS operation on disk27 (Smash)Converting HFS Volume to an APFS Container which will export one APFS VolumeThe target is the Journaled HFS+ volume "Smash" on disk27 backed via CoreStorage on disk10s2Checking booter partition disk10s3The target is a data disk; it is not a macOS system diskNo APFS EFI driver found to installSaving encryption contextThe target is encryptedUnmounting disk27Starting conversion from HFS to APFSPerforming apfs_hfs_convert -x --verbose=0x400 /dev/disk10s2Reporting post-conversion statisticsA problem occurred during conversion from HFS to APFSAPFS Converter exit code is 1Aborted conversion in commit mode so will restore typeSetting type of disk10s2 to CSChanging the physical disk partition type in shared modePartition modification attempt count was 1Not mounting APFS VolumeExiting conversion operations with error code -69860Error: -69860: The underlying task reported failure on exitUnderlying error: 1 ↩