workstation 17.5.1 make failed when using RHEL with kernel version: 5.14.0-427.13.1.el9_4.x86_64 #244
Comments
|
Please don't suggest the |
One more thingSince the vmmon and vmnet are embbed in the kernel as kernel modules, and the solution above actually hacked original code of both modules, their secure signature will be be invalid and they will be prevented if the More specific, the two modules will be installed into You can use following command to get the current mokutil --sb-stateAnd the output is like: If you try to load them mannually: insmod vmmon.so
insmod vmnet.so
dmesgThen you are likely to see something like this: insmod: ERROR: could not insert module vmmon.ko: Key was rejected by service
insmod: ERROR: could not insert module vmnet.ko: Key was rejected by service
...
ERROR: could not insert module: Key was rejected by servicewhich means the module have a key but that is invalid. The most convenient way to avoid this problem is just disabling Or, you can also look for other ways to get rid of this side effect, such as sign them mannually. |
Sorry, I have no idea about this before and I didn't find out any related infomation. Hacking |
|
Same problem here. Updated to RHEL 9.4 and can't get the bundle to install either of the modules. I'll hold off on trying your hack incase some other more robust solution comes up... |
|
@mkubecek tried the solution recommended at top of rebuilding vmmon and vmnet, no joy, with or without Secure Boot enabled. I'm available to test with some guidance to make Workstation 17.5.2 or 17.5.1. Tried to reached out to Broadcom / VMware support and the answer was, reach out to RHEL / or any EL9 distro to resolve this. Thanks in advance, |
|
Simply adjusting the preprocessor definitions to include RHEL 9.4+ as part of the list of kernels to accept for the newer kernel definitions resolved it for me. In vmmon-only/include/pgtbl.h: In vmnet-only/bridge.c: |
For those of us without experience in C, where exactly do we put this? Thanks! |
It's in the same locations that @Paperside is referencing: Line 29 in vmnet-only/bridge.c: |
|
Positive feedback on this process in this ticket with RHEL 9.4 OS Two (2) challenges:
$ rpm -qa kernel*
[AppLoader] GLib does not have GSettings support. Resolution: Used the steps mentioned above by @Legends0 and others, with @mkubecek git repo for 7.5.1. I can confirm this process worked for both VMware Workstation Pro 7.5.1 (with license) and 7.5.2 (personal edition from Broadcom) on RHEL 9.4 5.14.0-427.13.1.el9_4.x86_64 Supporting details below for validation$ systemctl status vmware.service $ vmware --version $ uname -a $ sudo /usr/bin/vmware-networks --stop ; sudo /usr/bin/vmware-networks --verbose --start Follow upRelated to RHEL 9.4 glibc library. The 'ovftool' CLI and VMware Workstation UI OVA import require a deprecated library, libnsl. The UI did not report an error message, but the 'ovftool' CLI did. Used 'strace -e openat ovftool' to confirm. Per RHEL, this is known issue with glibc: https://access.redhat.com/solutions/4975641 Added libnsl to the OS: dnf install -y libnsl and can report no import issue. |
|
Related, I think. alma linux 9.4, but with Workstation 16.2.5: LD [M] /localhome/habig/vmware/vmware-host-modules/vmmon-only/vmmon.o Tried jamming the RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4) cpp directives in there as suggested above, no luck. Also just discovered that Broadcom's vmware support is currently totally fubar at the moment so I can't get into vmware to re-download their tarballs. Not that I have any optimism that it's fixed upstream, but thought it was worth a try. |
|
If you can't access the Broadcom site, another option is to follow the help/update link provided in the VMware Workstation UI. Broadcom has the "core" release of VMware Workstation available as a public download. These included the newer public license versions. If you use wget or curl, you can access these directly to your Linux box instead of using your Broadcom account to access the "full" release with the "vmware tools" built-in. You can also use a browser to the links to get the "vmware-tools" tar files as well. Example(s): Broadcom/Vmware software update URLs for "core" workstation of VMworkstation 17.5.2 for both Linux/Win. Side note: One minor gotcha that I found was within the VMware UI logs (/tmp/vmware-USERNAME): older VMware images built with earlier releases need to be updated to version 17 to access the "heartbeat" checks. Otherwise, the VMware-UI logs will grow quite a bit. |
|
Hi everyone, So found this post while trying to fix the vmmon vmnet module compile issue. The solution from Legends0 worked fine until this evening when I was trying to install the CORE network emulator and had to install updates for RHEL 9.4 and now VMWare 17.5.1 workstation is broken again, and the previous solution doesn't work anymore. So how do I fix the compile error this time, or should I just give up on running VMWare workstation on RHEL? If I have to give up vmware what is solid stable replacement. If vmware is the best game in town, how do I learn to troubleshoot and fix this issue. This really irritating because every time I make progress setting up my vm lab this happens and it's three weeks before I getting it working again TNX |
|
@alanbaugher , thanks! I'd avoided upgraded to v17 because VMWare support was almost actively hostile when I had some problems with my v16, the features I was asking about (headless workstation instances) were depreciated and being removed anyway so they wouldn't help me make them work in the version that had them. So, didn't want to send them money for the upgrade to just get functionality removed :) However, in the interest of seeing what I could make work, I grabbed that 17.5.2 bundle as suggested. This repo knows about 17.5.1 and not .2 yet, but OK, let's see where can I get. The answer is even with the latest 17.5.1 branch from here, the same build problem with
Like @kidkaos32, I might be better served finding a vmware alternative at this point. A shame, been using vmware more or less since they became a thing, but there have to be open source alternatives that do the job these days. |
|
I am on Rocky linux 9.4 and I had workstation 16.2.4 woking.. AS per kernel version 17 is not supported. No with update of kernel |
|
A workaround that meets my use case, which is primarily having a windows VM around for things like Acrobat: I installed VirtualBox from the repos with dnf. Installed a fresh copy of windows (there are apparently ways to import a VMWare image, but I didn't have anything on there that needed saving anyway). And tried it out. It works way better these days than it first did way back when. So far, only thing so far that I like VMWare better for is a better selection of screen resolutions. But there's one setting in VirtualBox that's OK enough to use, so good enough. VirtualBox also seems snappier performancewise, although the "shiny new windows install hasn't unravelled yet" effect could be in play. VMWare Workstation had gotten awful after upgrading from SL7 to Alma9 though, even with a fresh windows install. Eventually found that having the virtual disk not think it needed to go into powersaving mode made a huge difference, but it was still pretty laggy compared to what it used to be. I don't think VirtualBox supports headless VMs, but neither does VMWare Workstation anymore anyway. So, my immediate need for a Windows VM is satisfied. I'll keep the VMWare images around in case debugging is needed to see if it can eventually be made to work again, but will eventually free up their GB. Won't need to send anymore money VMWare^h^h^h^h^h^hBroadcomm's way, which is nice. Will feel sad that software I'd used for decades doesn't work anymore. |
|
Hope you have better luck or Broadcom updates their embedded features for RHEL type OSes. I saw your comment about headless features with VMware workstation and wanted to share my experience. When my primary host restarts, I start the VMware images with several automation processes. To expand on the default host-only networking with vmware workstation, I used a vyos software router, and have built a systemd process to autostart it. cat vyosauto.service I have used VMware workstation for both Kubernetes and OpenShift deployments, using the headless features. I haven't seen a change in release 17 yet to prevent me from still using these features. Examples of some additional useful commands:
|
|
I am enclosing all the steps to resolve this issue for a fresh install of the RHEL 9.4 OS. Observations:
Linux hostname.here 5.14.0-427.13.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 10 10:29:16 EDT 2024 x86_64 x86_64 x86_64 GNU/Linu
3a) Attempted to update VMware mods with post-step but had a first minor issue. [AppLoader] Use shipped PC/SC Lite smart card framework. 3b) Install requested components on RHEL 9.4 OS
[AppLoader] GLib does not have GSettings support.
kernel-tools-libs-5.14.0-427.13.1.el9_4.x86_64
8a) Download the git repo and checkout git that matches the current VMware workstation release. 8b) STOP and edit two (2) files: and change this line from: and change this line from: 8c) Continue with the "make" process for the two modules
Able to enter license into the VMware Workstation UI and continue with access. (used the RHEL GUI to access this UI)
This is related to the RHEL 9.4 glibc library. The 'ovftool' CLI and VMware Workstation UI OVA import require the deprecated library libnsl. The VMware UI did not report an error message during import of a OVA file, but the 'ovftool' CLI did. I used 'strace -e openat ovftool' to confirm the missing library file. Per RHEL, this is a known issue with glibc: https://access.redhat.com/solutions/4975641 Added libnsl to the OS: and can report no import issue with VMware-Workstation-Full-17. Hopefully, these steps will help others. If we look at RHEL tech note: https://access.redhat.com/solutions/37608 We can see information supporting the OR statement's use in the above workaround with RHEL_RELEASE_VERSION string why it is needed, as the KERNEL_VERSION string would not match the IF statement. |
|
Thank you @alanbaugher for the headless suggestions. I was going on my experiences with filing a support ticket with problems doing headless with Workstation. The VMWare support people refused to help me with it on the excuse that it was depreciated anyway, I shouldn't be using it, and should go buy the expensive datacenter version instead of the Workstation which was still allegedly under support. I'll try backporting your current version fixes to see if I can get 16.2.5 to compile on alma9, but won't be sending good money after bad to upgrade to v17 first :( |
|
@habig Just so you know I have VMware Enterprise support 24/7 support contract and I've been in a fight with them regarding this for months now. They just agreed on the ticket that this is an issue and that it should be corrected to be installed and working correctly with either 17.5.1 or 17.5.2 under 9.4. I'll update once I have a final answer with fix. |
|
Hi everyone, Can You help me guys? ERROR: modpost: "__pte_offset_map" [/home/marcos/drives_compilados_kernel/vmware-host-modules-workstation-17.5.2-k6.9-/vmmon-only/vmmon.ko] undefined! make[1]: *** [Makefile:117: vmmon.ko] Erro 2 make: *** [Makefile:21: vmmon-only] Erro 2 ... When I try the second method I got the error message after the command "sudo vmware-modconfig --console --install-all": ... -declaration] make: *** [Makefile:117: vmnet.ko] Erro 2 Unable to install all modules. See log for details. .... Any solution? Thanks! |
Briefly speaking, you may do following things to fix the problem:
Find the following part in
./vmmon-only/include/pgtbl.hand./vmnet-only/bridge.cthen modify them as follows:line 94: replace
pte_offset_mapwithpte_offset_kernelto make kernel version check invalidline 28: add
#include <net/gso.h>so that net/gso.h will be included anywayHopefully that may solve the problems!
The Following part is my analysing experience:
VMWare workstation cannot automatically install vmmon and vmnet modules with error logs like this:
Thus I cloned this git repo to mannually compile and install vmmon and vmnet. But when I switched to the correct branch and began to make, the same error occurs:
Eventually I checked
./vmmon-only/include/pgtbl.hand./vmnet-only/bridge.cthen found out why:Linux branches like RHEL CentOS and Fedora have different linux kernel version name definition compare to other branches like Ubuntu, who uses standard linux kernel version name instead. If you execute
uname -rto get kernel version in ubuntu 22.04, you are likely to get this :But when you run that in RHEL9 or CentOS 9 Stream...You will get this:
RHEL 9 actually have a newer kernel but its version is even lower!
Now let's check out what is in
./vmmon-only/include/pgtbl.hand./vmnet-only/bridge.c:Have you figured out where the problem lies in? That's exactly: Your linux kernel version(5.14.0) is probably misjudjed as "OUT OF DATE(>=6.5.0|>=6.4.10)" in the two files. But that's not true.
Now that we have known the possible reason, it's comparatively easy to fix them up though the way may not be very elegant, just edit the two files like this:
I have no idea about whether there are still other files have similar problems, but I installed vmmon and vmnet successfully after fixed up only both of the two files.
The text was updated successfully, but these errors were encountered: