`diskutil` child process stuck on "Shrinking APFS data structures"

[eoyoa]

Machine details

  Product name: MacBook Air (M2, 2022)
  SoC: Apple M2
  Device class: j413ap
  Product type: Mac14,2
  Board ID: 0x28
  Chip ID: 0x8112
  System firmware: iBoot-11881.140.96
  Boot UUID: 652B99A2-135C-494F-9F28-83B553F2BF16
  Boot VGID: 652B99A2-135C-494F-9F28-83B553F2BF16
  Default boot VGID: 8C0EE6E5-AF69-48BE-B91D-ACE90C48C4D5
  Boot mode: macOS
  OS version: 15.6.1 (24G90)
  OS restore version: 24.7.90.0.0,0
  Main firmware version: 15.6.1 (24G90)
  No Fallback System Firmware / rOS
  SFR version: 24.7.90.0.0,0
  SystemRecovery version: 24.4.70.0.0,0 (15.3.1 24D70)
  Login user: ***

Context

Here are the installer logs leading up to the stuck state:

Resizing will free up 80.00 GB of space.
Note: your system may appear to freeze during the resize.
This is normal, just wait until the process completes.
» Continue? (y/N): y
Started APFS operation
Aligning shrink delta to 80,004,337,664 bytes and targeting a new container size of 414,380,457,984 bytes
Determined the minimum size for the APFS Container to be 337,138,155,520 bytes
Resizing APFS Container designated by APFS Container Reference disk3
The specific APFS Physical Store being resized is disk0s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the checkpoint with transaction ID 16804592
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking the encryption key structures
Checking volume /dev/rdisk3s1
Checking the APFS volume superblock
The volume Macintosh HD was formatted by newfs_apfs (1677.41.3.100.4) and last modified by apfs_kext (2332.140.13)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 1 (com.apple.os.update-9E3B7EFBB732B00D98BF266D7444FDC8348CC3B2CCEF551FF262CA73E4E23BAE, transaction ID 16537127)
Checking the fsroot tree
Checking the file extent tree
Checking the extent ref tree
Verifying volume object map space
The volume /dev/rdisk3s1 with UUID 1EDE9DFE-593B-473F-BCEE-E24FB623C6C1 appears to be OK
Checking volume /dev/rdisk3s2
Checking the APFS volume superblock
The volume Preboot was formatted by newfs_apfs (1934.121.2) and last modified by apfs_kext (2332.140.13)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the fsroot tree
Checking the extent ref tree
Verifying volume object map space
The volume /dev/rdisk3s2 with UUID EB28F32F-CA2A-4EF4-A299-DF1E36A89AC2 appears to be OK
Checking volume /dev/rdisk3s3
Checking the APFS volume superblock
The volume Recovery was formatted by newfs_apfs (1934.121.2) and last modified by apfs_kext (2332.140.13)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the fsroot tree
Checking the extent ref tree
Verifying volume object map space
The volume /dev/rdisk3s3 with UUID 68F1CE3F-F492-4258-93CB-911A483DB483 appears to be OK
Checking volume /dev/rdisk3s4
Checking the APFS volume superblock
The volume Update was formatted by newfs_apfs (1934.121.2) and last modified by apfs_kext (2332.140.13)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the fsroot tree
Checking the extent ref tree
Verifying volume object map space
The volume /dev/rdisk3s4 with UUID 3E83538F-85E2-4E57-9F4D-131EF0D6AFE3 appears to be OK
Checking volume /dev/rdisk3s5
Checking the APFS volume superblock
The volume Data was formatted by newfs_apfs (1934.121.2) and last modified by apfs_kext (2332.140.13)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the document ID tree
Checking the fsroot tree
Checking the extent ref tree
Checking the file key rolling tree
Verifying volume object map space
The volume /dev/rdisk3s5 with UUID 652B99A2-135C-494F-9F28-83B553F2BF16 appears to be OK
Checking volume /dev/rdisk3s6
Checking the APFS volume superblock
The volume VM was formatted by apfs_boot_util (1934.121.2) and last modified by apfs_kext (2332.120.31.0.2)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the fsroot tree
Checking the extent ref tree
Verifying volume object map space
The volume /dev/rdisk3s6 with UUID 869D9093-AB35-4F7E-9FF1-F448B51598CF appears to be OK
Verifying allocated space
The container /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Shrinking APFS Physical Store disk0s2 from 494,384,795,648 to 414,380,457,984 bytes
Shrinking APFS data structures
[ / 0%..10%..20%..30%..40%............................... ] 49.5%

It then hangs on this, with very low CPU utilization and iostat numbers.

However, diskutil list returns:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         494.4 GB   disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3
/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +414.4 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            11.3 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 11.3 GB    disk3s1s1
   3:                APFS Volume Preboot                 7.1 GB     disk3s2
   4:                APFS Volume Recovery                1.0 GB     disk3s3
   5:                APFS Volume Data                    306.4 GB   disk3s5
   6:                APFS Volume VM                      3.2 GB     disk3s6

So, the container is resized, but the partitioning did not complete.

Workaround

Killing the installer, then running sudo diskutil apfs resizeContainer disk0s2 <DISK SIZE> separately worked. After successfully partitioning, I continued with the Asahi installation process.

Warning: do not do this if you do not know what you are doing!

Possible causes

I'm not going to try to reproduce this bug: I only have one Mac machine and it's my daily driver.

But, just thinking about why this bug might have occured:

1. I might have just gotten impatient and didn't wait long enough. It's entirely possible diskutil could have been doing something, but given the evidence (stuck at 49.5%, low CPU utilization, low disk usage), I don't think so.
2. Maybe diskutil isn't behaving properly since it is running non-interactively/as a child process? Not sure.

Hope this issue could at least guide anyone else with a similar issue (i.e. this, or this, or even this), or perhaps take a step towards fixing this issue.