Help with PKGBUILD (vmware-workstation)

[yum13241]

Hello everyone, I’m trying to install version 17.0.2, rather than the latest version offered (don’t ask why). You would think to go back in the PKGBUILD history, but the version that installs 17.0.2 there has dead links. Therefore, I am trying to modify the PKGBUILD.

Here’s where I’ve gotten: https://privatebin.net/?c0db6f2750ddf0be#7BHMCXdxtoxXmgxduVuti6Xnq2mwxdJE5x2LWJezaJPF

The issue is that with my modified PKGBUILD, the VMWare kernel modules do not work. vmmon for example, does not install.

(4/9) Install DKMS modules
==> dkms install --no-depmod vmware-workstation-noxsave/17.0.2_21581411 -k 6.10.10-arch1-1
Error! Bad return status for module build on kernel: 6.10.10-arch1-1 (x86_64)
Consult /var/lib/dkms/vmware-workstation-noxsave/17.0.2_21581411/build/make.log for more information.
==> WARNING: `dkms install --no-depmod vmware-workstation-noxsave/17.0.2_21581411 -k 6.10.10-arch1-1' exited 10

Here’s the /var/lib/dkms/vmware-workstation-noxsave/17.0.2_21581411/build/make.log that was mentioned in the above codeblock.

How would I fix this? If I install with the regular PKGBUILD, the kernel modules do work (but you can guess from the modified package name why I don’t just use that). So clearly, there has to be a way to somehow get the kernel modules working.

Hopefully I’ve provided everything needed to get help.

[dalto]

You can’t use an older version of vmware against a newer kernel. The host modules need patches applied to make them compatible. Of course, nobody maintains patches for old versions of vmware against new kernels.

If you apply the patches you find here you can probably run 17.0.2 against LTS. However, this isn’t really sustainable unless you are going to lock your kernel in time permanently or you are willing to develop and maintain your own patches to the modules.

[yum13241]

I see this in the sources() array in the PKGBUILD:

  'dkms.conf.in'
  'Makefile'
  'vmmon.patch'
  'vmnet.patch'

How would I make the PKGBUILD get the right versions of these files from where you linked?

or you are willing to develop and maintain your own patches to the modules.

This sounds like one of those “if you have to ask, you shouldn’t” things. (Why do I feel I would have to reverse engineer VMWare?)

lock your kernel in time permanently

I can just lock the LTS kernel in time instead.

[yum13241]

So before I made this thread I emailed the maintainer (lol, don’t try this at home), and got a response. Here’s what he said (snipped as I see fit):

You will find enclosed the vmmon.patch and vmnet.patch I just created to allow VMware Workstation 17.0.2 running on Linux 6.11 (and previous). You can rebuild your package with them and that should work.

But the modules will be broken again sooner or later (maybe after Linux 6.12 upgrade) and I don't plan to maintain these patches for this intermediate version of VMware Workstation. So, for the long term, you will have 3 solutions:

- Maintaining these patches yourself. To do that, after each broken kernel upgrade, you can track the changes made on the package vmware-workstation16 and try to apply them on your package, that should work most of the time (but it's not 100% guaranteed).

- Switch on vmware-workstation16 (I guess this version doesn't use the XSAVE instruction) and let the package maintainer doing the work for you.

- Stay as long as possible on a Linux LTS version which doesn't break the kernel modules.

Right now I downgraded to VMware Workstation 16, since I did that before getting the reply (thanks, Jean-Marc!), but I guess I can upgrade to 17.0.2 (for a while, anyway).

Instructions:

1. yay -G vmware-workstation in a directory of your choice.
2. Replace Jean-Marc’s PKGBUILD with mine.
3. makepkg -s and have it download its prerequisites - Press CTRL + C when it tries to download a file starting with VMware.
4. Replace vmnet.patch and vmmon.patch with the maintainer’s edited versions.
5. Go to the directory in which you set everything up and type makepkg -si.
6. Enjoy! I would recommend creating your VMs with 16.2.X compatibility selected just in case you have to downgrade again.

EDIT 2024-10-21:
In case you are having issues (mksSandbox crash with 3D acceleration on, sepia firmware screen), try adding these options to /etc/vmware/config:

mks.enableDX12Renderer = "FALSE"
mks.enableDX11Renderer = "FALSE"
mks.enableVulkanRenderer = "FALSE"
mks.enableGLRenderer = "TRUE"
mks.gl.allowBlacklistedDrivers = "TRUE"
mks.vk.allowUnsupportedDevices = "FALSE"
mks.forceDiscreteGPU = "TRUE"
mks.sandbox.socketTimeoutMS = "200000"
svga.allowAsyncReadback = "FALSE"

These options will make VMware prefer OpenGL, since some GPUs (integrated ones in particular) have shoddy Vulkan support. If you have 3D acceleration (and VMware tools if applicable) enabled and you are not having issues, DO NOT USE THESE OPTIONS, they will HURT performance.

Or add the options to the VMs .vmx file if you’re only having issues with one VM.