** 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.
+  * 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
+  * 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
-  
+  * 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.
+  * 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.
+  * 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.
+ 
+  * For a somewhat faked test you could drop a file that prevents the 
+    module from loading e.g.
+      $ echo "blacklist vmwgfx" | sudo tee 
/etc/modprobe.d/blacklist-vmware.conf
+      $ echo "install vmwgfx /bin/false" | sudo tee -a 
/etc/modprobe.d/blacklist-vmware.conf
+      $ sudo update-initramfs -u -k all
+    Then reboot which will make it start without the module and trigger the 
+    error condition as if it would have raced (service up but the module 
+    not loaded).
+    On a service restart you'll see the error:
+      [2019-03-04T08:17:34.112Z] [ message] [resolutionCommon] 
+      resolutionCheckForKMS: dlopen succeeded.
+      [2019-03-04T08:17:34.268Z] [ warning] [resolutionCommon] 
+      resolutionCheckForKMS: No system support for resolutionKMS.
+    Even if you now remove the blacklist it will still fail that way.
+    If you modprobe vmwgfx it will switch to
+      [2019-03-04T08:18:42.983Z] [ message] [resolutionCommon] 
+      resolutionCheckForKMS: dlopen succeeded.
+      [2019-03-04T08:18:42.986Z] [ message] [resolutionCommon] 
+      resolutionCheckForKMS: System support available for resolutionKMS.
+    The latter should work without manual modprobe and with the fix it 
+    does.
+ 
  
  [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.
+  * 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].
- 
+  * 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
+  * 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

-- 
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to