macOS: uninstaller should unmount Nix Store before deleting it

[niklaskorz]

When running /nix/nix-installer uninstall on macOS 14 (possibly also on 13, did not check), the uninstall process fails because it's unable to unmount the Nix Store volume. I tested this two times, with fresh installations using nix-install 0.12.0. The same error did not occur in the version I was previously using (0.5.0, also on macOS 14). Removing the partition by hand in the macOS disk manager works, and I can then reinstall using nix-installer without issues.

Error

Error: 
   0: Error reverting
   0: Action `create_apfs_volume` errored
      Failed to execute command with status 1 `"/usr/sbin/diskutil" "apfs" "deleteVolume" "Nix Store"`, stdout: Started APFS operation
      Deleting APFS Volume from its APFS Container
      Unmounting disk3s7
      The volume "Nix Store" on disk3s7 couldn't be unmounted because it is in use by process 0 (kernel)

      stderr: Error: -69888: Couldn't unmount disk

Metadata

key	value
version	0.12.0
os	macos
arch	aarch64

[niklaskorz]

Unfortunately we didn't get very far with getting to the cause of this on Discord, but I might have an idea for preventing this scenario. Currently, the volume is just getting unmounted as part of the APFS delete volume operation. When unmounting a volume directly with diskutil unmountDisk, an additional force parameter can be provided, e.g. diskutil unmountDisk force disk3s7.

So the options would be

a. always force-unmount the volume before deleting it
b. trying to delete the volume, and if it fails with the "Couldn't unmount disk" error, offer the user to force-unmount it (and hint that they will have to remove the volume manually if they don't), then run the delete volume operation again.

[Hoverbear]

Great digging!

In this case a is our only option, as the installer has no concept of interacting with the user to ask those things.

[Hoverbear]

@niklaskorz I've prepared #662 which should fix the issue. Since I haven't managed to reproduce the issue it's a bit hard to test. I tested my normal happy path and it seems fine.

If you happen to be able to reproduce could you try:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix/pr/662 | sh -s -- install