Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#69649 - [open-vm-tools] Resolution fails to resize after updates

Attached to Project: Community Packages
Opened by M.Reynolds (TheChickenMan) - Monday, 15 February 2021, 19:26 GMT
Last edited by Christian Hesse (eworm) - Tuesday, 16 February 2021, 08:32 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
When starting a VM, vmware-tools will "sometimes" fail to resize the screen resolution of the VM. The service appears to be running correctly though restarting the service with systemd will "fix" the issue.

Additional info:
* package version(s) 6:11.2.5-1

Steps to reproduce:
The issue appears somewhat randomly for me though if starting from a working condition, a kernel update will generally produce this issue. I believe this issue is being caused by the vmware tools service loading too early, before something to do with the graphics. I have included a systemd timer file which when used instead of the service file introduces a slight delay. This inclusion has fixed the issue for me on all of my vmware hosts and guests. Perhaps there is a more elegant solution by asking the service file to start "after" a particular service or state?
   vmtoolsd.timer (0.1 KiB)
This task depends upon

Closed by  Christian Hesse (eworm)
Tuesday, 16 February 2021, 08:32 GMT
Reason for closing:  Fixed
Additional comments about closing:  open-vm-tools 6:11.2.5-2
Comment by Christian Hesse (eworm) - Monday, 15 February 2021, 21:36 GMT
Using a timer for this is not really elegant... :-p

Currently I have only headless VMs running on VMware, thus I can not test this myself.

Wondering if adding "After=display-manager.service" to the service fixes the issue...
This adds an ordering, but should not pull in a dependency.
Comment by M.Reynolds (TheChickenMan) - Monday, 15 February 2021, 23:20 GMT
Yeah it's a total hack and I would not suggest actually using a timer. I just included my duck tape patch to illustrate what I was thinking (and couldn't think of "what" to put it After).
I tested adding "After=display-manager.service" like you said and it works perfectly for me!! :)))

Loading...