I have the drive ejected. I'm used to ejecting a drive, then unplugging it. The first time I tried this, DiskUtility complained that all sorts of processes were using it still, after I ejected the drive (Bash, simctl, Code Helper, Word, kernel 0). So I closed all the processes one by one, until only kernel proc 0 was remaining. Apparently, it is not safe to simply eject a drive and then unplug it, as Eject "succeeds" but many processes still have the drive open.
So, clarifying some details here, the system uses "Eject" as a somewhat loosely defined shorthand. Historically, the commands here were:
-
"Unmount” -> Close out the logical file system and flush all writes to disk.
-
"Eject” -> Unmount the volume, then send an "Eject" command to the removable media device. Note that you couldn't "Eject" a hard drive, you'd just unmount it and unplug.
However, the system eventually ended up repurposing the "Eject" command as something like:
- "Eject” -> Unmount all logical volumes that you know to be associated with the same physical volume as the logical volume being targeted.
The key here is that "Eject" and "Unmount" don't really do anything different unless you happen to be dealing with a removable media device.
Shifting to the error here:
The volume on disk6 couldn't be unmounted because it is in use by process 0 (kernel)
Anytime a volume is mounted, the disk is actually "opened" by the kernel, since that's how the file system driver performs I/O. However, unmounting should close that open, which makes the error above a little bit strange. A few possibilities off the top of my head:
-
If any kind of Endpoint Security client is installed, they can cause weird errors like this. The ES API works by allowing the client to fail a variety of low-level syscalls, but that dynamic also means that it can create failures that higher-level clients don't really expect and/or describe.
-
You're targeting the whole disk ("disk6") but, assuming the volume is partitioned, the actual volumes would be mounted on slices ("disk6sX") of the whole disk. Disk Utility generally handles that fine, but I have seen cases where it couldn't unmount the slice and the configuration of the volume meant it couldn't "explain" that to the user.
-
As a special case of that, I think you'll get a failure very similar to this if you send eject to a whole disk ("disk6") while some other process has directly opened a child device node ("/dev/disk6sX", NOT a mounted volume). Disk Arb is what's responsible for identifying what processes are preventing unmount, but that only works on mounted volumes, NOT dev nodes.
Note that those are just three examples off the top of my head. Unfortunately, determining a specific cause for an issue like this often requires a fairly in-depth look at the system, which isn't something I can easily explain how to do.
How do I format the drive?
In terms of just getting something to work, the first things I would try are:
- Unplug the drive, then replug the drive, and then reformat the drive.
Then:
- Unplug the drive, restart the machine, plug the drive in, and then reformat the drive.
Note that while we warn against unplugging live volumes and the system will complain about you doing so, that doesn't matter here. The warning is there because doing so can/will cause data loss on the device you've unplugged, but you don't care about that if you're going to format the volume anyway.
If the problem is still happening after those two steps, then something is actively preventing the devices from closing out properly. An ES client (#1) is one example, but it's also possible some other 3rd party app is doing it by manipulating the volumes. Figuring that means digging into exactly what's running on your system and disabling things until you find the problem.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
