hdiutil failed with non-zero exit code: 16 about macinbox HOT 13 CLOSED

The command being run in this case is /usr/bin/hdiutil detach /dev/disk17:

You could try changing the max_attempts in that function, or making the sleep longer, as a workaround. The reason why the function does multiple attempts is that it seems to take a while for APFS volumes to "quiesce" after having lots of data written to them. On my machine, 60 seconds is always long enough, but on a different machine, under different load, it could conceivably take longer.

from macinbox.

I worry that doing a detach! immediately after the install would result in a corrupted filesystem. For some reason the device usually stays busy for about 20 seconds after the install completes.

from macinbox.

I've pushed up 4888511 which replaces hditutil detach with diskutil eject. Hopefully that helps!

from macinbox.

I've also pushed up 5f78830 which adds a --verbose flag which prints out the commands that are run, but unlike --debug doesn't leave behind the temporary directories.

from macinbox.

Yeah, that's the around the part where I'm digging into : why is the resource still busy, or what (if anything) is still going on ... had to take a break, but couple hours later and trying manually:

$ sudo /usr/bin/hdiutil detach /dev/disk17
Password:
"disk17" unmounted.
hdiutil: couldn't eject "disk17" - Resource busy

So back to digging in "what the what" is causing the hang, pretty sure this is something on my system, but would still be handy if, in a situation like this, macinbox would spit out the command that failed (rather than having to dig through code to find it).

from macinbox.

That's surprising that the disk would still be busy after a few hours. The lsof tool might reveal if something is holding a file open on the disk. From the logs you posted, you'd be looking for something open under the scratch_mountpoint directory, e.g. :

sudo lsof | grep scratch_mountpoint

from macinbox.

Surprisingly :

# rm -rf /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ii08lvPL/scratch_mountpoint
rm: /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ii08lvPL/scratch_mountpoint: Resource busy

Hence

# lsof | grep scratch_mountpoint
mds          80               root   20r      DIR               1,41          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.vUrgBZxP/scratch_mountpoint
mds          80               root   23r      DIR               1,17          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ii08lvPL/scratch_mountpoint
mds          80               root   30r      DIR               1,17          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ii08lvPL/scratch_mountpoint
mds          80               root   36r      DIR               1,17          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.ii08lvPL/scratch_mountpoint
mds          80               root   38r      DIR               1,29          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.3778RisT/scratch_mountpoint
mds          80               root   39r      DIR               1,29          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.3778RisT/scratch_mountpoint
mds          80               root   42r      DIR               1,29          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.3778RisT/scratch_mountpoint
mds          80               root   43r      DIR               1,41          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.vUrgBZxP/scratch_mountpoint
mds          80               root   48r      DIR               1,41          64          2 /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.vUrgBZxP/scratch_mountpoint

And this is even with having /private/var/folders in the "Privacy" tab in System Preferences > Spotlight.
No idea why mds is deciding to start searching it.

Can do eject even though detach errors out ... wondering of drawbacks to bypassing detach and going straight to eject.

from macinbox.

Thanks, @Brantone. The man page for hdiutil says:

eject is a synonym for detach. In common operation, detach is very similar to diskutil(8)'s eject.

Which eject did you use? I'm willing to test out changing away from hdiutil detach if there's something else that works better for you and equally as well for me.

from macinbox.

Currently still debating if eject is best option.
Also wondering detach was preferred in the first place? Ex: why not just use the detach! method all the time since it has detach -quiet -force and doesn't care for exit status?

from macinbox.

Later on tonight I can submit a PR the experiment I tested and can go from there.
I did get it to successfully create a Vagrant box, but it still failed on clean up:

• Installing box...
  + Copying box to /Users/USER/.vagrant.d/boxes...
    - Installed box: macos-10.14.3-1 (vmware_fusion, 10.14.3)
• Cleaning up...
• WARNING: Temporary files were not removed. Run this command to remove them:
• sudo rm -rf /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_box_from_vmdk.TrSqD5ZE \
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_vmdk_from_image.zXmCd4WQ \
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/create_image_from_installer.8F6RO5qG \
/var/folders/nx/q112c5wx7vn_0bmv9vdhgp7hqpw449/T/macinbox_user_temp.oJ4rjFRv \
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/macinbox_root_temp.MU3FAEJd

Doing lsof showed all the files in those subdirs are still open, so something is holding onto them. If no one else has run into it, will just chalk it up to something unique in my dev environment.

from macinbox.

My own experiments with eject seem successful, the first diskutil eject after the install fails, but then the second attempt after waiting 15 seconds succeeds. I'm working on getting that merged, hopefully it helps with your situation.

The temporary files are intentionally not removed when you pass the --debug option, but all of the mounted disk images are supposed to be properly unmounted when the script ends. Does the rm -rf command not work for you even after the box is installed correctly?

from macinbox.

Fwiw, this was the minor tweak I made just to get the ball rolling again:
master...Brantone:master
Still no idea why those folders are open / in use, thus the rm -rf fails with error as expected. The box still does get created, so not as concerned about it.

$ pwd
/Users/USER/.vagrant.d/boxes/macos-10.14.3-1/10.14.3/vmware_fusion
HOST:vmware_fusion USER$ ls
Vagrantfile		macinbox-Snapshot1.vmsn	macinbox.vmsd		macinbox.vmxf
macinbox-000001.vmdk	macinbox.vmdk		macinbox.vmx		metadata.json

from macinbox.

Tagged and released: https://github.com/bacongravy/macinbox/tree/v3.3.0

from macinbox.