Thanks for the confirmations! The service can only have one set of dependencies, since it is the same package no matter if some component on your deployment chain chooses between: A) For Set cloud-init as the customization engine: B) For Set perl script as the customization engine:
IMHO all paths should use (A) through cloud-init, but I'm sure you had reasons to also have (B). Therefore since you likely want/need to keep (B) still I'd think that the right solution for that is (as suggested before) to split the functionality of vmtoolsd/open-vm-tools.service. Split it into: - one providing services e.g. rpc used by other components that runs early (essentially as we have it today) - one executing the (B) customization scripts late as you'd need it to make the guarantees for (B) As I have mentioned before a lessons learned from cloud-init that you might use is that some changes have to be early (unable to change later) and some late (need some components up). Therefore an even better split is to break (B) into early and late stages. E.g. considering all your legacy (B) late but one might want to add early script in the future. Or to re-iterate just use the already existing path through cloud-init if you can. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1793715 Title: VMWare Guest OS Customization will fail for Ubuntu 18.04 Server LiveCD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1793715/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
