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