mkubecek's Accepted Solutions

@kamiller42 wrote: No errors there, but they do appear incomplete, i.e. exited before completed. They don't look incomplete to me, AFAICS they look exactly the way they are supposed to, except for ... See more...
@kamiller42 wrote: No errors there, but they do appear incomplete, i.e. exited before completed. They don't look incomplete to me, AFAICS they look exactly the way they are supposed to, except for the warning about gcc version mismatch (which is almost certainly innocuous as it's in fact the same version). When I launch a VM, I get the vmmon not found error. Did you reload the modules after installing them? (The easiest way is to run "/etc/init.d/vmware restart".) Also, vmware fails to rebuild. The vmware build log is the same as the log in the original post. There is no need to let VMware rebuild the modules. Actually, as I explained, it would be wrong as it would use the original unpatched tarballs (which is why the rebuild fails).
Unfortunately, VMware seems to only care about NVidia GPUs (and even those only with proprietary driver) and does not officially support "3D Acceleration" on linux hosts with AMD GPUs, see e.g. this ... See more...
Unfortunately, VMware seems to only care about NVidia GPUs (and even those only with proprietary driver) and does not officially support "3D Acceleration" on linux hosts with AMD GPUs, see e.g. this document It should be possible to enable it on Radeon GPU with mks.gl.allowBlacklistedDrivers = "TRUE" But then you are on your own.
You have modules from an older version of VMware loaded and tried to run a newer version of Workstation. Version 401 is from Workstation 16.1.0, 398 from Workstation 16.0.0. You need to rebuild the m... See more...
You have modules from an older version of VMware loaded and tried to run a newer version of Workstation. Version 401 is from Workstation 16.1.0, 398 from Workstation 16.0.0. You need to rebuild the modules after Workstation upgrade and make sure the new modules are loaded (/etc/init.d/vmware restart).
This has been discussed here multiple times already. It's a known problem of Workstation 15.5.x when running on kernel 5.8 or newer which, sadly, VMware is unlikely to fix. See e.g. https://communit... See more...
This has been discussed here multiple times already. It's a known problem of Workstation 15.5.x when running on kernel 5.8 or newer which, sadly, VMware is unlikely to fix. See e.g. https://communities.vmware.com/t5/VMware-Workstation-Pro/Linux-5-8-host-support-like-VirtualBox-this-year-or-next/m-p/2296583
This sounds as if the init script were not run on boot. Does running "/etc/init.d/vmware start" help?
I meant this one: https://my.vmware.com/en/web/vmware/downloads/details?downloadGroup=WKST-1600-WIN&productId=1038&rPId=51974 You should get there from yours by clicking on "GO TO DOWNLOADS".
I checked the conditions recently and while there is only one type of license for Workstation Pro, there actually seems to be a difference between personal and commercial use: with one license, you a... See more...
I checked the conditions recently and while there is only one type of license for Workstation Pro, there actually seems to be a difference between personal and commercial use: with one license, you are allowed to run Workstation on up to three hosts for personal use but only on one for commercial (in the sense of VMware's definition of "commercial").
The vmware-modconfig segfault is a known problem; fortunately it can be worked around easily by building (patched) modules manually and then bypassing the execution of vmware-modconfig. You can e... See more...
The vmware-modconfig segfault is a known problem; fortunately it can be worked around easily by building (patched) modules manually and then bypassing the execution of vmware-modconfig. You can e.g. replace /usr/bin/vmware-modconfig by a link to /bin/true edit /usr/bin/vmware (or /usr/bin/vmplayer) so that it does not run vmware-modconfig run /usr/lib/vmware/bin/vmware directly without the wrapper script
Quoted part of the build log does not show the error but most likely it's the issue discussed in https://bugzilla.suse.com/show_bug.cgi?id=1173591 and fixed by https://github.com/mkubecek/vmware-... See more...
Quoted part of the build log does not show the error but most likely it's the issue discussed in https://bugzilla.suse.com/show_bug.cgi?id=1173591 and fixed by https://github.com/mkubecek/vmware-host-modules/commit/64ec3716346e
This is because Leap 15.2 has 5.3 kernel but has backport of skb_frag_t conversion from upstream 5.4. As the module source only checks kernel version, it uses old code while it should use new one... See more...
This is because Leap 15.2 has 5.3 kernel but has backport of skb_frag_t conversion from upstream 5.4. As the module source only checks kernel version, it uses old code while it should use new one. This patch fixes the issue: https://github.com/mkubecek/vmware-host-modules/commit/64ec3716346e
Looks like the issue addressed by this patch: https://github.com/mkubecek/vmware-host-modules/commit/992ae1d5a16e Some people reported that these objtool warnings may result in failed build on... See more...
Looks like the issue addressed by this patch: https://github.com/mkubecek/vmware-host-modules/commit/992ae1d5a16e Some people reported that these objtool warnings may result in failed build on some systems.
You need patched version of the host modules (only two latest patches are strictly necessary but I would recommend building from branch head anyway).