HellenButterlip
Contributor
Contributor

"Resource Deadlock Avoided" - A cautionary tale...

For years I've been running my Boot Camp VM from a bootable external Hard Drive on my MacBook. This allows me to quickly jump into windows for small things, but retains the ability to boot into Windows directly for work that requires dedicated HW resources. I recently decided to upgrade from a 500GB SSD to a 1TB SSD. After cloning the drive and verifying that I was able to boot from it directly, VMware was unable to create a new Boot Camp VM. I tried to recreate the VMDK using the rawdiskcreator command in Terminal, but it failed repeatedly with the dreaded "Resource Deadlock Avoided" error. I spent days working with VMware support through email but stumbled upon the root cause and pseudo-solution after hours of troubleshooting myself - Fusion relies on the Vendor and Model names to identify the disk target in the VMDK. Since I have two Samsung T5 SSDs connected (one for Bootcamp; one for Time Machine), it can't discern between them. I've suggested to tech support that they move to something a bit more unique (like the serial number) and hope that message makes its way to the dev team. For now, the workaround is to just unplug my TimeMachine drive when I need to boot up the VM. Hopefully this helps anyone else with a soft spot for brand loyalty (I love the T5 drives) and a heterogenous-OS lifestyle.

28 Replies
Technogeezer
Champion
Champion

I understand the frustration. I agree that the current method that Fusion uses to identify raw disk partitions in macOS is not usable due to macOS's non-persistent device naming. At least Linux can sort of override this with udev rules and read LVM volumes, but then again macOS is not Linux. It's not just limited to ZFS - there are plenty of raw disk volumes that would be very useful to be able to mount to both Linux and Windows VMs without having to resort to putting them behind a USB bridge. 

But using terms such as "punks", "nincompoop" and "imbecilic" isn't going to help your case, although it does allow you to vent..

0 Kudos
RDPetruska
Leadership
Leadership

"due to macOS's non-persistent device naming"

And here we are with yet ANOTHER stupid thing Apple does - assuming all of its users are ignorant of how a computer works.  Time and time again they keep showing that they don't want to make things compatible with the rest of the computing universe - but instead lock users into their own ecosystem.  Guys - if this stuff is important to you (and some of it SHOULD be) - then you need to make your voices heard to APPLE!

0 Kudos

One of my long-standing complaints.  They dumb down things to a level where they become useless.  Disk utility comes directly to mind.

0 Kudos
Technogeezer
Champion
Champion


@RDPetruska wrote:

"due to macOS's non-persistent device naming"

And here we are with yet ANOTHER stupid thing Apple does 


Then I guess Windows and Linux are stupid too, as they both do non-persistent device naming. They name devices in the order that they are discovered, and if you change something in the hardware connection or do hot adds and removes of devices, you get similar behavior. Perhaps that's why file systems on Linux have UUIDs and LVM (and likely ZFS) configurations are self describing. 

To Linux's credit it does provide a way to persist device names. However, you'd better be good at writing udev rules to do so.

Apple doesn't seem to provide a mechanism to persist a device name across boots (at least I've scoured resources and have been unable to come up with anything). Perhaps this is at the root of why Fusion has trouble with it. Yes there are use cases (like Fusion) that needs this but for the vast majority of users of macOS, persistent device naming isn't needed. macOS seems to find its supported file systems and mount them just fine without persistent device naming. It's just when there's a macOS unsupported file system type on a disk that we run into these issues.

That's not to say I'm an apologist for Apple. As @ColoradoMarmot states, there are areas where you'd like to have more fine tuned control, but it's either buried/hidden in the GUI, you have to resort to CLI utilities, or it doesn't exist at all. 

Over the years I've gotten used to (or resigned myself to the fact, pick one) that macOS, Linux, Windows, Solaris, AIX, whatever are all different and have their own "peculiarities". I used to work for a vendor that had a Linux port of their storage product, and there were big differences even between SLES and RHEL - SLES would need a tweak to modules for every one of their releases because they'd break the kernel ABI, but RHEL would keep theirs stable.

On this one, the root cause is that there's no 'Mac address' equivalent in the USB spec.  That'd solve the problem.

0 Kudos
Technogeezer
Champion
Champion

There are some things in the GPT specs that have UUIDs for partitions (not just partition types). It appears that Apple has either not implemented them or ignores them.  😞 

RDPetruska
Leadership
Leadership


@Technogeezer wrote:

It appears that Apple has either not implemented them or ignores them.  😞 


As I said above... Apple time and time again proves they do not want to play nice with the rest of the computing world, but instead lock users into their ecosystem (oh, yeah, and charge them higher prices all along the way as well).

wila
Immortal
Immortal


@RDPetruska wrote:

As I said above... Apple time and time again proves they do not want to play nice with the rest of the computing world, but instead lock users into their ecosystem (oh, yeah, and charge them higher prices all along the way as well).

The horse is dead Jim.

Maybe it has some teeth from wood that we can burn in the stove. There might even be a walking stick in one of its legs. If all else fails grab a rock and hit it.

A.k.a. can we please stay on topic?

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
kjdfhaueiase
Enthusiast
Enthusiast

The UUID is accessible.
Apple's API is unstable
VMware wants to work on apple, and didn't use the UUID instead of the drive manufacturer, then they completely screwed up on a support case related to this.

No one is without fault. Including us.

Fool me once...

0 Kudos