VMware Workstation is having problems with openSUSE or vice-versa - again.
Installed openSUSE Leap 42.2
VMware Workkstation 12.5.6 compiles with kernel 4.4.62-18.6-default
but the Workstation Servef does not start
Upgraded openSUSE to openSUSE Leap 42.3 Beta
With Kernel 4.4.68-2-default WS fails to compile since it cannot find file version.h. Version.h is nowhere to be found in any sources. This happened with some versions of openSUSE many years ago but there version.h could be found otherwise.
I have a choice. I can go back to kernel 4.4.62-18.6-default or I can use kernel-4.4.68-2-vanilla which I know will compile and has version.h. The other possibility of course is to use another distro. Unfortunately I’m finding that Debian 9 has problems with recent upgrades.
If anybody knows how I can version.h for the current Leap kernel I’d appreciate it.
Actually that should not be needed, but kernel-devel and kernel-default-devel.
I successfully compiled the VMware kernel modules (10.0.6 though) a few days ago here, I had to patch them though to get them build (like basically after every upgrade, that’s why I prefer VirtualBox since years…)
But why are you using kernel 4.4.68?
42.3 ships with 4.4.76.
I don’t know about this specific situation, but historically VMware is a 2-stage build so just because you are able to build stage 1 doesn’t mean that you’ve successfully built everything that’s needed.
Besides the kernel,
I’ve also had to install the appropriate kernel-devel, plus the usual build tools.
Although most often a Tumbleweed issue, I’ve also found that the gcc version has sometimes been an issue. If you have to downgrade your gcc, install the older gcc from your openSUSE repo, then follow the following article to configure an update-alternatives so you can temporarily make your older gcc your default while you build and install VMware
Addendum to my prior post,
If you simply execute the VMware installation binary by clicking or double-clicking it, you won’t know why it fails.
You need to open a console and execute the binary within it to be able to view any errors, and my guess is that you’ll then be able to see build errors perhaps referencing gcc which would be addressed by the procedure I described.
When you installed VMware Workstation,
You first download the install binary.
The install binary is only a minimal file, so the full install needs to be downloaded and built, then kicks off a separate build.
This was how it worked awhile ago and might be different today, as you describe kernel modules should be included in the kernel and not need to be built.
Again, the installer doesn’t build anything. Vmware is proprietary, closed-source software.
Except for the kernel modules.
Those will probably be built when running the installer (although AFAIK it includes some precompiled too for specific distributions), and vmware will offer you to build/install them on every start if they cannot be loaded (because of a kernel update e.g.).
as you describe kernel modules should be included in the kernel and not need to be built.
No, vmware itself comes with kernel modules that need to be built and installed for proper function.
vmmon and vmnet in particular, there are more but the others are indeed included in the kernel meanwhile…
But I could not test the workaround from this vmware thread. Or does someone know, where to download the file “VMware-Workstation-Full-e.x.p-6056110.x86_64.bundle” (the experimental version), mentioned there?
tmp/vmware/source/vmnet-only/netif.c:468:4: note: in expansion of macro ‘compat_netif_trans_update’
compat_netif_trans_update(dev);
^
/usr/src/linux-4.4.76-1/scripts/Makefile.build:259: recipe for target ‘/tmp/vmware/source/vmnet-only/netif.o’ failed
The fix for this is easy: just replace compat_netif_trans_update with netif_trans_update (i.e. remove the compat_) and it should compile.
@Wolfi323:
Yes, but with the current, newest non-experimental version, I’m able to download (12.5.7), I’m still stuck with errors like this:
In file included from /usr/src/linux-4.4.76-1/include/linux/highmem.h:7:0,
from /tmp/modconfig-Ha6MKm/vmnet-only/userif.c:26:
/usr/src/linux-4.4.76-1/include/linux/mm.h:1264:6: note: expected ‘long unsigned int’ but argument is of type ‘struct task_struct *’
long get_user_pages(unsigned long start, unsigned long nr_pages,
^
Right, that was another one line change (in vmnet-only/userif.c) I had to make.
I cannot look till tomorrow evening though, as I am not near that machine currently.
Well, I rejoiced too early.
The experimental version has the experimental “feature” of crashing my graphical desktop and/or locking up my computer in a way, that only a cold boot could revive it.
So I reinstalled the officially released vmware player (12.5.7) and changed all the files, affected by compilation errors, manually, as described here in previous answers.
Thanks to all.
After all this experiments and comparing the source code my personal suspicion, whats causes this lockups, is the usage of the function get_user_pages_fast() instead of get_user_pages().
But I’m no kernel hacker and have no idea, how to really prove that.
Just wonder if anyone had any luck compiling the modules from v12.5.7.
I tried the experimental build with the suggested changes from Failed to build vmnet module on Linux 4.4.76-1-default openSUSE Leap 42.3 and it is working… some minor UI issues and still figuring out how to disable gathering debugging info (apparently this one is just renaming the binaries as explained here) but I would like to avoid using the preview software at all, mainly because of stability.
