Can't compile vmmon after Ubuntu 20.04 LTS and restart of Workstation Pro 16.2.3-19376536.x86_64 -

[rfreytag]

Updates of Ubuntu 20.04 LTS sometimes require recompilation of vmmon when I run ‘vmware’. This time the log file shows a problem starting a little after “Using kernel build system.” See the beginning of where things go wrong below….

Using kernel build system.
/tmp/modconfig-kuxShM/vmmon-only/common/phystrack.o: warning: objtool: PhysTrack_Free() falls through to next function PhysTrack_Add()
/tmp/modconfig-kuxShM/vmmon-only/common/phystrack.o: warning: objtool: PhysTrack_Add() falls through to next function PhysTrack_Remove()
/tmp/modconfig-kuxShM/vmmon-only/common/phystrack.o: warning: objtool: PhysTrack_Remove() falls through to next function PhysTrack_Test()
In file included from /tmp/modconfig-kuxShM/vmmon-only/./include/x86desc.h:33,
from /tmp/modconfig-kuxShM/vmmon-only/./include/modulecall.h:34,
from /tmp/modconfig-kuxShM/vmmon-only/common/task.c:60:
/tmp/modconfig-kuxShM/vmmon-only/common/task.c: In function ‘TaskRestoreHostGDTTRLDT’:
/tmp/modconfig-kuxShM/vmmon-only/./include/vm_asm_x86.h:67:44: error: expression in static assertion is not constant
67 | ASSERT_ON_COMPILE(sizeof(Selector) == 2 && \
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68 | ((__builtin_constant_p(expr) && ((expr) >> 16) == 0) || \
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
69 | sizeof(expr) <= 2))
| ~~~~~~~~~~~~~~~~~~

...it goes on for maybe another hundred lines of one error after another.  Is there a fix coming from VMware for this compilation problem?

[rfreytag]

Full log is available on request. 

[continuum]

This is the top one issue at the moment - did you read https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-3-not-working-on-Ubuntu-22-04-L...

[rfreytag]

I did find that solution for Ubuntu 22 LTS and tried it.  The solution posted by Contributor liberattgustavo  reads ...

cd /usr/lib/vmware/modules/source
git clone https://github.com/mkubecek/vmware-host-modules
cd vmware-host-modules
git checkout workstation-16.2.3
make
tar -cf vmnet.tar vmnet-only
tar -cf vmmon.tar vmmon-only
mv vmnet.tar /usr/lib/vmware/modules/source/
mv vmmon.tar /usr/lib/vmware/modules/source/
vmware-modconfig --console --install-all

 
...following those instructions worked.  I rebooted my Ubuntu host but probably could have just run 'vmware' from the command line. 

On restarting 'vmware', I was prompted to acknowledge the license agreement again like it was a new install (but that might have been because I had uninstalled Workstation Pro 16.2.3-1... while trying things to that might fix the original problem.  You might not see this prompt if you didn't uninstall-reinstall Workstation Pro.

Thanks!

Are we going to have to do this often or will a better fix be provided?

[continuum]

> Are we going to have to do this often or will a better fix be provided?

Let me give you an answer based on 20 years Workstation and VMTN experience ...
From VMware developers point of view there are 3 categories of Linux - distributions.
A: Serious Distribution: RedHat and Centos from last year and Debian Stable 2 or 3 years old
B: Bleeding edge Distribution: all recent Fedoras, all new Ubuntu-derivats - most current Linux distributions
C: Gentoo, Slackware, Linux from Scratch

Category A Linux usually installs flawless and is updated only rarely
Category B Linux usually fails to install - but the user-scene typically will provide Howtos or patches within weeks
Category C Linux require a stubborn root-user with lots of experience

So if you want to avoid the need to apply thirdparty or obscure patches use RedHat, Centos or older Debian.

You may have noticed that the free VirtualBox usually installs flawlessly.
Yep - thats correct. VMware developers are immune to this argument.
Do not request that the expensive Workstation should install as easy as VirtualBox if you value your mental health.
This request is 20 years old and VMware is very experienced in ignoring it.

So how to deal with it ?
Thats easy - if you need a working, reliable Workstation installation use a category A Linux.
What ever you do - do NOT install updates and upgrades for your host Linux as soon as they are released.
Watch the forum for at least 2 or 3 weeks and check if new patches are posted.

Ulli

By the way - since Windows 10 the same applies to Windows hosts.
At the moment using Win10 / 11 and latest Ubuntu may break your Workstation-setup with the next update.
Be careful and read the forum first.

Ulli

[louyo]

A pretty good compromise is LMDE5, Linux MInt Debian Edition, now at version 5. Similar to Mint but not based on Ubuntu. Does not update to bleeding edge kernels. I switched to it from Centos. 

YMMV

Lou 

The A, B, C analysis is right on target. 

edit: it is Mint, just based on Debian.

[mkubecek]

---

@continuum wrote:

You may have noticed that the free VirtualBox usually installs flawlessly.

VirtualBox is prone to the same kind of problems but it's usually (not always) faster to catch up.

By the way - since Windows 10 the same applies to Windows hosts.
At the moment using Win10 / 11 and latest Ubuntu may break your Workstation-setup with the next update.

---

There is one big difference, though: with "Category B Linux", the source is public for both the kernel and the VMware host modules. So either you can adapt the modules to recent changes yourself or someone else can. With Windows, all you can do is to wait for VMware.

My understanding of the core problem is that VMware does not actually understand linux worlds and their mindset is based on the old notion of "supported OS systems" (there is an actual list for both guest and host side). This list consists of some versions of best known (to them) linux distributions, mostly the enterprise flavor: RHEL, SLES, Ubuntu and few selected others. Even for these, recent releases and service packs are often missing. Rolling type distributions (Fedora, openSUSE Tumbleweed etc.) or less known distributions are our of their sight and thinking in terms of kernel versions rather than "supported host systems" is completely out of question. Well, perhaps not for developers (or at least not completely) but certainly for managers who make decisions about what will be released and when. And with Workstation (or even Player) itself being far from company focus, it would be naive to expect a significant change of the approach.

[continuum]

@mkubecek 
RHEL - lol - I still refer to it as RedHat
anyway - would you mind and edit my categories - A,B and C
I completely forgot about Suse for example ...

Thanks Ulli

[davidkariuki]

I build an automated shell- script to help download, extract and build the VMWARE `vmnet` and `vmmon` files.

Running the script should fix the issue. The link also contains the instructions to do this.

Try it here -> vmware-host-modules-builder-cli  and create an issue if you encounter any problems.

[uupr1]

Hi. When I ran

git clone https://github.com/mkubecek/vmware-host-modules

I got the following error message:

"fatal: could not create work tree dir 'vmware-host-modules': Permission denied"

I believe it is a permission issue, but I'm not sure how to resolve it.

Would you be able to provide any insight?