Upgrade from Mint 18.4 to 19 results in screen resizes being handled wrongly - No copy/paste

[Nantris]

Except this singular issue, everything works wonderfully. I already tried apt-get purge open-vm-tools open-vm-tools-desktop but it didn't help.

This is what I'm seeing after upgrading. The Y coordinates of the mouse/elements on the screen are also no longer in sync.

And shrinking the size of the VMware Window results in this:

The OS gets the proper screen resolution reported, but resizes itself incorrectly:

[Nantris]

Also looks unfortunately like copy/paste in and out of the machine doesn't work anymore.

[deepak-rawat]

@slapbox Could you please provide the output of dmesg for this issue. Thanks.

[Nantris]

Thanks very much for your reply @deepak-rawat.

Here's the full output of the dmesg command in a gist to avoid cluttering the issue page: https://gist.github.com/Slapbox/1747b882b3897d7a8f9524249684a45f

[lemke1458]

For the copy/paste, is "vmtoolsd -n vmusr" running?

[Nantris]

Running that in the VM as root returns: Segmentation fault (core dumped)

Running it again seems to hang indefinitely. Enter does nothing to move it along and there seems to be no CPU usage.

When I finally cancel the command it returns this output: free(): invalid size

[lemke1458]

So it wasn't running before?

Its a daemon, and should be started when you log in to the desktop by a login script. and by running as the desktop user.

If you log in/out of the desktop, is it running, and does drag/drop work?

[Nantris]

Oh I thought you meant to run that as a command. My mistake.

ps cax | grep vmtoolsd returns: 588 ? Ssl 0:09 vmtoolsd

Both rebooting and logging out and back in do not change the results of anything as best I can tell. Logging out and back in, the result is 588 ? Ssl 0:09 vmtoolsd, so it's starting on boot and running whether a user is logged in or not, but as far as actually providing the tools, no dice so far.

[lemke1458]

That explains a lack of drag and drop. The distros manage vmtoosld startup, so I think this is a Mint issue.

[Nantris]

I'm a bit confused. vmtoolsd is running so I'm not sure what's incorrect here, can you explain?

[lemke1458]

When using a desktop, there's usually two vmtoolsd processes.

One is the 'user' version (-n vmusr), which runs as the user logged into the desktop. It handles anything done on behalf of the user, which is mostly UI related things like interactive guestOps, drag&drop and cut&paste.

The other is the 'system' version, which runs as root, and it handles everything else (information gathering, non-interactive guestOps, power scripts, backup scripts, etc)

Ubuntu ships these as two different packages,; you've got both (sometimes its missing which is the problem). But since the user mode isn't running, that suggests the new version of Mint isn't starting it up.

[Nantris]

Great explanation! Thank you!

Is there a way I can start this manually in the meantime? Mint 19 is great and I don't want to downgrade, but no vmtools is pretty brutal.

[deepak-rawat]

Hi since vmtool is not running you can use below command to set the mode:

xrandr -d :0 --output Virtual1 --mode 800x600

and simply xrandr to check list of mode supported

For now I suspect that somehow mode-setting is failing in kernel module for modes other than advertised during driver initialization (may be failing due tools not running) so we have scaling issue because desktop environment not checking for failure. I will do more analysis. Thanks.

[lemke1458]

It should be as simple as just running it as yourself in the desktop env:

$ vmtoolsd -n vmusr &

[Nantris]

@deepak-rawat I've updated the title to reflect a second symptom I later noticed and mentioned (not prominently enough) which is no copy/paste between host and virtual machine.

Unfortunately running vmtoolsd -n vmusr & doesn't resolve the issue (screen resize and copy/paste still a no go)

After running the above, ps cax | grep vmtoolsd returns:

588 ? Ss 0:12 vmtoolsd
4560 pts/0 S 0:00 vmtoolsd