My Problem:
After updating Fedora 29, VMware Workstation Pro 15 needed to have some kernel modules compiled. However, attempting to install them earned me warning signs on the “Virtual Machine Monitor” and “Virtual Network Device” compilation process, and of course starting the services failed. Logs stated “Failed to build vmmon” and “Failed to build vmnet.”
My Solution:
Digest this SuperUser thread: https://superuser.com/questions/1328401/vmware-workstation-vmmon-broken-on-ubuntu-18-04/1330890
Ultimately, you need to clone this github repo: https://github.com/mkubecek/vmware-host-modules.git. Checkout the proper branch that corresponds to your product and version (for example, I used the Workstation 15.0.3 branch). make
then make install
within that repo, and finally you’ll want to create a symlink for libz.so.1.
Using two separate answers in the above SuperUser thread, then modifying it for my own purposes, I came up with this:
#!/bin/bash
VMWARE_VERSION=workstation-15.0.3 #This needs to be the actual name of the appropriate branch in mkubecek's GitHub repo for your purposes
TMP_FOLDER=/tmp/patch-vmware
rm -fdr $TMP_FOLDER
mkdir -p $TMP_FOLDER
cd $TMP_FOLDER
git clone https://github.com/mkubecek/vmware-host-modules.git #Use `git branch -a` to find all available branches and find the one that's appropriate for you
cd $TMP_FOLDER/vmware-host-modules
git checkout $VMWARE_VERSION
git fetch
make
sudo make install
sudo rm /usr/lib/vmware/lib/libz.so.1/libz.so.1
sudo ln -s /lib/x86_64-linux-gnu/libz.so.1 /usr/lib/vmware/lib/libz.so.1/libz.so.1
systemctl restart vmware && vmware &
The Long Story:
After a massive cascade of updates on my Fedora 29 workstation that I had been delaying, VMware Workstation Pro 15.0.3 (build-12422535, and Kernal 5.0.3-200.fc29.x86_64 for whatever it’s worth) was unable to launch, instead requiring some kmods to be compiled and loaded:

Dutifully clicking install earned me these lovely caution signs:

The services were unable to start, so I checked out the logs:

Checking out the logs, I see a build command that failed:
2019-03-28T13:51:03.779-07:00| host-17464| I125: Invoking modinfo on "vmnet".
2019-03-28T13:51:03.781-07:00| host-17464| I125: "/sbin/modinfo" exited with status 256.
2019-03-28T13:51:03.833-07:00| host-17464| I125: Setting destination path for vmmon to "/lib/modules/5.0.3-200.fc29.x86_64/misc/vmmon.ko".
2019-03-28T13:51:03.833-07:00| host-17464| I125: Extracting the vmmon source from "/usr/lib/vmware/modules/source/vmmon.tar".
2019-03-28T13:51:03.839-07:00| host-17464| I125: Successfully extracted the vmmon source.
2019-03-28T13:51:03.839-07:00| host-17464| I125: Building module with command "/usr/bin/make -j12 -C /tmp/modconfig-PG76zy/vmmon-only auto-build HEADER_DIR=/lib/modules/5.0.3-200.fc29.x86_64/build/include CC=/usr/bin/gcc IS_GCC_3=no"
2019-03-28T13:51:05.179-07:00| host-17464| W115: Failed to build vmmon. Failed to execute the build command.
2019-03-28T13:51:05.181-07:00| host-17464| I125: Setting destination path for vmnet to "/lib/modules/5.0.3-200.fc29.x86_64/misc/vmnet.ko".
2019-03-28T13:51:05.181-07:00| host-17464| I125: Extracting the vmnet source from "/usr/lib/vmware/modules/source/vmnet.tar".
2019-03-28T13:51:05.185-07:00| host-17464| I125: Successfully extracted the vmnet source.
2019-03-28T13:51:05.185-07:00| host-17464| I125: Building module with command "/usr/bin/make -j12 -C /tmp/modconfig-PG76zy/vmnet-only auto-build HEADER_DIR=/lib/modules/5.0.3-200.fc29.x86_64/build/include CC=/usr/bin/gcc IS_GCC_3=no"
2019-03-28T13:51:06.597-07:00| host-17464| W115: Failed to build vmnet. Failed to execute the build command.
I see two other log files:
total 44
-rw-------. 1 root root 16669 Mar 28 13:51 vmware-17464.log
-rw-------. 1 root root 16555 Mar 28 13:50 vmware-apploader-17464.log
-rw-r-----. 1 root root 2792 Mar 28 13:51 vmware-authdlauncher-20116.log
The apploader log file didn’t appear to have anything of note in it. The authdlauncher… I wasn’t so sure:
2019-03-28T13:51:10.246-07:00| authdlauncher| I125: SOCKET 1 (12) creating new listening socket on port 902
2019-03-28T13:51:10.246-07:00| authdlauncher| W115: SOCKET Could not bind socket, error 98: Address already in use
2019-03-28T13:51:10.246-07:00| authdlauncher| I125: SOCKET Could not create IPv6 listener socket, error 11: Socket bind address already in use
2019-03-28T13:51:10.246-07:00| authdlauncher| I125: SOCKET 2 (12) creating new listening socket on port 902
2019-03-28T13:51:10.246-07:00| authdlauncher| W115: SOCKET Could not bind socket, error 98: Address already in use
2019-03-28T13:51:10.246-07:00| authdlauncher| I125: SOCKET Could not create IPv4 listener socket, error 11: Socket bind address already in use
2019-03-28T13:51:10.246-07:00| authdlauncher| I125: failed to listen on port 902, error 11: Resource temporarily unavailable... Exiting.
Hmm, indeed something is listening on port 902 that looks like VMware:
# sudo lsof -i -P -n | grep 902
vmware-au 1556 root 12u IPv6 28200 0t0 TCP *:902 (LISTEN)
vmware-au 1556 root 13u IPv4 28201 0t0 TCP *:902 (LISTEN)
I have my doubts that this is the ultimate problem, but I figured I’d HUP
those suckers and see what happens. Of course, that didn’t do anything worthwhile. The processes listening on port 902 are left up and running after the failed installation, not idling there as the cause of the failure.
After tooling around with untaring the kmod and making it by hand, I saw enough errors that made me think there was a serious lack of… something on my install. This just didn’t seem right. As a result, I gave up and Googled, which brought me to this: https://kb.vmware.com/s/article/58533?lang=en_US
The short story to that long thread is that you should uninstall VMware Workstation, make sure that you have the proper prerequisite packages installed, then re-install VMware Workstation. In my case, that did absolutely nothing and I still had the same issue.
A bit more searching and I found this thread from 2017 that seems to have about a year of activity on it: https://communities.vmware.com/thread/568089. Apparently this is a fairly common issue that doesn’t have a very elegant solution. Basically, VMware Workstation’s latest version doesn’t support the kernel that I updated to, and I had to patch it. I blindly followed repomon‘s Apr 4, 2018 7:16 PM post, even though it was for VMware Workstation 12. Of course, that didn’t work well because it ended up compiling for an older version of vmmon and vmnet than what I had previously.
Some more Googling brought me to this SuperUser post: https://superuser.com/questions/1328401/vmware-workstation-vmmon-broken-on-ubuntu-18-04/1330890. Using that as inspiration, I realized that GitHub user mkubecek appears to be keeping up to date with the latest versions of VMware Workstation and Player products and creating appropriate patches to help work through this issue.
The specific script / solution I came to is described in the “My Solution” section above.
You are a lifesaver. Thank you.
hello friend , thank you very much, I use fedora 29 with gnome and your script worked for me too, thank you
super gracias
Thanks
running back to WINDOWS
Thank you very much!!It solved my problem quickly.
thank you man for your post really appreciate it keep it UP
thank u kind sir, your a saint and a lifesaver.
Worked for me. Thank you very much! Huge time saver.
Worked for me.
Ubuntu 18.04.3 LTS
VMware Workstation 14.1.7 build-12989993
Thanks a lot.
thnaks a lot from mexico
Worked perfectly. Thanks a lot.
Awesome!!!!
Works on Debian 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux
and VMware Workstation 15.5.1 build-15018445
Thank you so much, I had VMWare 15.1.0 running happily on Ubuntu 18 for about 1/2 year, when one day, the host machine was off. Turned it back on, to have the above problem. Still have no idea why. Your solution was a Godsend.
YOU RE THE REAL MVP YOU MADE IT WORK !!!
Thank you for this post. I was at the end of my wits.
Thanks so much from A Coruña (Spain)!
Works on Ubuntu 16.04 (AMD64) and VMware Workstation 15.5.2 build-15785246
Thanks so much from Colombia!
Works fine on Ubuntu 20.04 , Vmware v15.1.0 Build 13591040
Hi!
Thank you very much for that profound article and good solution!
It worked for my vmware 15.5.6 on Opensuse 15.1, I only had to change the path of /lib/x86_64-linux-gnu/libz.so.1 to /lib64/libz.so.1 (I think a small discrepancy between distros).
Keep up that good work!
This worked great!
Thank you so much for creating and maintaining it!
Works fine for OpenSUSe15.2 and VMware-workstation 15.5.6 like described in part of the file .
THX for your effort!
This is great.
Thanks a lot. It’s helped me. My version VMware is 15.5.1.
What a life saver!
Running VMware Workstation Pro 14.1.3.
Upgraded my workstation from Ubuntu 18.04 LTS to:
user@linux:~/GITrepos$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
user@linux:~/GITrepos$ uname -r
5.4.0-52-generic
user@linux:~/GITrepos$
Got the same error when starting the VMware Workstation after OS upgrade, as author and numerous other source on Internet mention. Tried reinstalling with no avail. Had to stick with this VMware version, as this is the version I have the license for.
Ended up using author’s script with “w14.1.7-k5.4” tag name for https://github.com/mkubecek/vmware-host-modules/releases?after=w14.1.7-k5.4, as there were no “w14.1.3-k5.4” in Michal’s github repo.
Thank you, Wesley David and Michal Kubecek!
I wonder why VMware does not handle such an obvious use case / OS upgrade scenario.