** Description changed:
+ [Impact]
+
+ * The service for vmware base kernel mode setting fails sometimes (racy)
+ to work after boot, but suceeds when restarted. The reason is that
+ loading the required module is not always done in time.
+
+ * This is fixed by a drop-in snippet extending open-vm-tools.service.
+ (Not modifying the base .service file as the service and the
+ drop in are owned by different packages).
+ This drop in makes the service ensuring the load of the module in the
+ ExecStartPre phase
+
+ * Backport the change [1] as part of the regular backport we do
+ for the latest Ubuntu LTS
+
+ [Test Case]
+
+ * Due to the racy nature of this issue there isn't a great 100%
+ reliable test. But we can do something to at least try based on
+ retries.
+
+ * install a VMware guest with e.g. Ubuntu Desktop and install
+ open-vm-tools-desktop
+ * Put that guest into a reboot loop for a while, but wait until Desktop
+ is fully up before that
+ * Checking resulution sucks (manual on each reboot) but without the fix
+ chances are (due to the race only chances) that the log contains the
+ error triggering, see /var/log/vmware-vmsvc.log
+ It will have:
+ [ warning] [resolutionCommon] resolutionCheckForKMS: No system
+ support for resolutionKMS.
+ While with the fix it should always work which looks like:
+ [ message] [resolutionCommon] resolutionCheckForKMS: System
+ support available for resolutionKMS.
+ [ message] [vmtoolsd] Plugin 'resolutionKMS' initialized.
+
+ [Regression Potential]
+
+ * I wondered first if a regression could be that for some users
+ this always failed and due to that now after the change they get
+ e.g. different guest resolution. But the race seems unable to be
+ reliable either way, so those users would today be flaky with/without
+ KMS working and the fix would make that reliable. Therefore that is
+ no regression but an actual fix for those users.
+
+ * Also failing to load the module is not a (regressing) problem.
+ In our kernel packaging that module is only part of the -oem,
+ -lowlatency and all modules-extra-... packages. That said there
+ can be cases where e.g. running the virt kernels the modules isn't
+ available. But that will not make the service fail as it is using
+ the prefix "-" which means that if failing it still goes on to
+ start the service itself [2].
+
+
+ [Other Info]
+
+ * n/a
+
+ [1]: https://github.com/bzed/pkg-open-vm-tools/commit/db2a3642d45
+ [2]: https://www.freedesktop.org/software/systemd/man/systemd.service.html
+
+
+ ---
+
This is about the tracking of a bug that was reported and fixed in
Debian (and thereby also Ubuntu 19.04 already) to also SRU that back as
part of our open-vm-tools backports to latest LTS.
+ Related:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915031
https://github.com/vmware/open-vm-tools/issues/214
https://github.com/bzed/pkg-open-vm-tools/pull/13
** Also affects: open-vm-tools (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: open-vm-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: open-vm-tools (Ubuntu)
Status: Triaged => Fix Released
** Changed in: open-vm-tools (Ubuntu Bionic)
Status: New => Triaged
** Changed in: open-vm-tools (Ubuntu Cosmic)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1818473
Title:
open-vm-tools-desktop: resolutionKMS plugins sometimes fails to load
at boot
To manage notifications about this bug go to:
https://bugs.launchpad.net/open-vm-tools/+bug/1818473/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
