open-vm-tools-desktop: resolutionKMS plugins sometimes fails to load at boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
VMWare tools |
New
|
Unknown
|
|||
open-vm-tools (Debian) |
Fix Released
|
Unknown
|
|||
open-vm-tools (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[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-
(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-
* 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/
It will have:
[ warning] [resolutionCommon] resolutionCheck
support for resolutionKMS.
While with the fix it should always work which looks like:
[ message] [resolutionCommon] resolutionCheck
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.
$ echo "install vmwgfx /bin/false" | sudo tee -a /etc/modprobe.
$ 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-
resolution
[2019-
resolution
Even if you now remove the blacklist it will still fail that way.
If you modprobe vmwgfx it will switch to
[2019-
resolution
[2019-
resolution
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.
* 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:/
[2]: https:/
---
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:/
https:/
https:/
description: | updated |
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 |
Changed in open-vm-tools (Debian): | |
status: | Unknown → Fix Released |
description: | updated |
Changed in open-vm-tools: | |
status: | Unknown → New |
Added remote bugs as bug tasks