Comment 2 for bug 1921116

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
Paride is right, but didn't know about the background.
There are mulitple discussions upstream like:
https://github.com/vmware/open-vm-tools/issues/240
https://github.com/vmware/open-vm-tools/issues/350
https://github.com/vmware/open-vm-tools/issues/356

And the reason is isn't fixed there is that the "new way" that is supported and coded on isn't affected at all anyway.

That might seem odd, but we've considered adding After=dbus.service in the Ubuntu packages when it came up the first time.
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1793715
But it turned out that this will break more cases/setups than it will fix.
Therefore eventually even VMWare did ask to NOT set After=dbus.service by default and only published it for the affected as KB article.

This is a fairly complex case and I tried to summarize a bit here:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1793715/comments/18

Essentially the one way out not breaking other setups is what I outlined therein as (B) which is upstream VMware to split the customization code/service into two and then one can be early and one can be later. But I guess since their new style of customization code doesn't have the issue they never started on that and with every passing month the benefit of doing so gets smaller.

Never the less - AFAIU the case - if we want to get this resolved we need to ring bells and whistles at upstream.

... This is one of the cases that makes me sad, I want to help but I cant :-/ ...

Marking as a duplicate to 1793715