workstation 17.5.1 make failed when using RHEL with kernel version: 5.14.0-427.13.1.el9_4.x86_64

[Paperside]

Briefly speaking, you may do following things to fix the problem:

Find the following part in ./vmmon-only/include/pgtbl.h and ./vmnet-only/bridge.c then modify them as follows:

• pgtbl.h

...
 91#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,5,0)
 92             pte_t *pte = pte_offset_kernel(pmd, addr);
 93 #else
 94             pte_t *pte = pte_offset_map(pmd, addr);
 95 #endif
...

line 94: replace pte_offset_map with pte_offset_kernel to make kernel version check invalid

 94             pte_t *pte = pte_offset_kernel(pmd, addr);

• bridge.c

...
  28
  29 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10)
  30 #include <net/gso.h>
  31 #endif
...

line 28: add #include <net/gso.h> so that net/gso.h will be included anyway

  28 #include <net/gso.h>

Hopefully 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:

2024-05-02T04:02:14.437Z In(05) host-6681 ERROR: modpost: "__pte_offset_map" [/tmp/modconfig-HY9acv/vmmon-only/vmmon.ko] undefined!
2024-05-02T04:02:14.437Z In(05) host-6681 make[2]: *** [scripts/Makefile.modpost:134: /tmp/modconfig-HY9acv/vmmon-only/Module.symvers] Error 1
2024-05-02T04:02:14.437Z In(05) host-6681 make[2]: *** Deleting file '/tmp/modconfig-HY9acv/vmmon-only/Module.symvers'
2024-05-02T04:02:14.437Z In(05) host-6681 make[1]: *** [Makefile:1848: modules] Error 2
2024-05-02T04:02:14.437Z In(05) host-6681 make: *** [Makefile:117: vmmon.ko] Error 2
2024-05-02T04:02:14.437Z In(05) host-6681 Using kernel build system.
2024-05-02T04:02:14.437Z In(05) host-6681 /tmp/modconfig-HY9acv/vmnet-only/bridge.c: In function ‘VNetBridgeSendLargePacket’:
2024-05-02T04:02:14.437Z In(05) host-6681 /tmp/modconfig-HY9acv/vmnet-only/bridge.c:1416:11: error: implicit declaration of function ‘skb_gso_segment’; did you mean ‘tcp_gso_segment’? [-Werror=implicit-function-declaration]
2024-05-02T04:02:14.437Z In(05) host-6681  1416 |    segs = skb_gso_segment(skb, 0);
2024-05-02T04:02:14.437Z In(05) host-6681       |           ^~~~~~~~~~~~~~~
2024-05-02T04:02:14.437Z In(05) host-6681       |           tcp_gso_segment
2024-05-02T04:02:14.437Z In(05) host-6681 /tmp/modconfig-HY9acv/vmnet-only/bridge.c:1416:9: warning: assignment to ‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
2024-05-02T04:02:14.437Z In(05) host-6681  1416 |    segs = skb_gso_segment(skb, 0);
2024-05-02T04:02:14.437Z In(05) host-6681       |         ^
2024-05-02T04:02:14.437Z In(05) host-6681 cc1: some warnings being treated as errors
2024-05-02T04:02:14.437Z In(05) host-6681 make[2]: *** [scripts/Makefile.build:299: /tmp/modconfig-HY9acv/vmnet-only/bridge.o] Error 1
2024-05-02T04:02:14.437Z In(05) host-6681 make[2]: *** Waiting for unfinished jobs....
2024-05-02T04:02:14.437Z In(05) host-6681 make[1]: *** [Makefile:1934: /tmp/modconfig-HY9acv/vmnet-only] Error 2

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:

ERROR: modpost: "__pte_offset_map" [/root/Downloads/vmware-host-modules/vmmon-only/vmmon.ko] undefined!
make[3]: *** [scripts/Makefile.modpost:134: /root/Downloads/vmware-host-modules/vmmon-only/Module.symvers] Error 1
make[3]: *** Deleting file '/root/Downloads/vmware-host-modules/vmmon-only/Module.symvers'
make[2]: *** [Makefile:1848: modules] Error 2
make[2]: Leaving directory '/usr/src/kernels/5.14.0-427.13.1.el9_4.x86_64'
make[1]: *** [Makefile:117: vmmon.ko] Error 2
make[1]: Leaving directory '/root/Downloads/vmware-host-modules/vmmon-only'
make: *** [Makefile:21: vmmon-only] Error 2

/root/Downloads/vmware-host-modules/vmnet-only/bridge.c: In function ‘VNetBridgeSendLargePacket’:
/root/Downloads/vmware-host-modules/vmnet-only/bridge.c:1418:11: error: implicit declaration of function ‘skb_gso_segment’; did you mean ‘tcp_gso_segment’? [-Werror=implicit-function-declaration]
 1418 |    segs = skb_gso_segment(skb, 0);
      |           ^~~~~~~~~~~~~~~
      |           tcp_gso_segment
/root/Downloads/vmware-host-modules/vmnet-only/bridge.c:1418:9: warning: assignment to ‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
 1418 |    segs = skb_gso_segment(skb, 0);
      |         ^
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:299: /root/Downloads/vmware-host-modules/vmnet-only/bridge.o] Error 1
make[2]: *** [Makefile:1934: /root/Downloads/vmware-host-modules/vmnet-only] Error 2
make[2]: Leaving directory '/usr/src/kernels/5.14.0-427.13.1.el9_4.x86_64'
make[1]: *** [Makefile:117: vmnet.ko] Error 2
make[1]: Leaving directory '/root/Downloads/vmware-host-modules/vmnet-only'
make: *** [Makefile:21: vmnet-only] Error 2

Eventually I checked ./vmmon-only/include/pgtbl.h and ./vmnet-only/bridge.c then 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 -r to get kernel version in ubuntu 22.04, you are likely to get this :

6.5.0-28-generic

But when you run that in RHEL9 or CentOS 9 Stream...You will get this:

5.14.0-427.13.1.el9_4.x86_64

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.h and ./vmnet-only/bridge.c :

• pgtbl.h

...
 91#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,5,0)
 92             pte_t *pte = pte_offset_kernel(pmd, addr);
 93 #else
 94             pte_t *pte = pte_offset_map(pmd, addr);
 95 #endif
...

• bridge.c

...
  29 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10)
  30 #include <net/gso.h>
  31 #endif
...

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:

• pgtbl.h

...
 91#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,5,0)
 92             pte_t *pte = pte_offset_kernel(pmd, addr);
 93 #else
 94             pte_t *pte = pte_offset_kernel(pmd, addr);//replace "pte_offset_map" with "pte_offset_kernel" to make kernel version check invalid
 95 #endif
...

• bridge.c

...
  28 #include <net/gso.h> //add this line so that net/gso.h will be included anyway
  29 #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10)
  30 #include <net/gso.h>
  31 #endif
...

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.

[mkubecek]

Please don't suggest the pte_offset_kernel() hack that has been known to be broken for quite some time.

[Paperside]

One more thing

Since 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 Secure Boot option is enabled in your computer.

More specific, the two modules will be installed into /lib/modules/<dir_named_with_your_current_kernel_version>/misc/ as vmmon.ko and vmnet.ko .

You can use following command to get the current Secure Boot status of your computer:

mokutil --sb-state

And the output is like:

SecureBoot enabled

If you try to load them mannually:

insmod vmmon.so
insmod vmnet.so
dmesg

Then 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 service

which means the module have a key but that is invalid.

The most convenient way to avoid this problem is just disabling Secure Boot in your computer’s UEFI Setup(BIOS).

Or, you can also look for other ways to get rid of this side effect, such as sign them mannually.

[Paperside]

Please don't suggest the pte_offset_kernel() hack that has been known to be broken for quite some time.

Sorry, I have no idea about this before and I didn't find out any related infomation. Hacking pte_offset_kernel() should not be recommended indeed if it will get broken from time to time. I would appreciate it if you can offer me some ways to learn more about the bug.

[GlacierFox]

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,

[Legends0]

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:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10) || RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4)

In vmnet-only/bridge.c:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0) || RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4)

[MeatBunny]

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: #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10) || RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4)

In vmnet-only/bridge.c: #if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0) || RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4)

For those of us without experience in C, where exactly do we put this? Thanks!

[Legends0]

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 91 in vmmon-only/include/pgtbl.h:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10) || RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4)
                 pte_t *pte = pte_offset_kernel(pmd, addr);
#else
                 pte_t *pte = pte_offset_map(pmd, addr);
#endif

Line 29 in vmnet-only/bridge.c:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0) || RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4)
#include <net/gso.h>
#endif

[alanbaugher]

Positive feedback on this process in this ticket with RHEL 9.4 OS

Two (2) challenges:

1. Minor - Fresh install of RHEL 9.4 had missing kernel-headers and kernel-devel via official RHEL repos. These had to be downloaded & applied via a RHEL security advisory. https://access.redhat.com/errata/RHSA-2024:2394

$ rpm -qa kernel*
kernel-tools-libs-5.14.0-427.13.1.el9_4.x86_64
kernel-modules-core-5.14.0-427.13.1.el9_4.x86_64
kernel-core-5.14.0-427.13.1.el9_4.x86_64
kernel-modules-5.14.0-427.13.1.el9_4.x86_64
kernel-tools-5.14.0-427.13.1.el9_4.x86_64
kernel-5.14.0-427.13.1.el9_4.x86_64
kernel-srpm-macros-1.0-13.el9.noarch

2. Typical error from sudo vmware-modconfig --console --install-all

[AppLoader] GLib does not have GSettings support.
(process:95861): GLib-CRITICAL **: 12:43:01.941: g_file_test: assertion 'filename != NULL' failed

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.service - VMware host virtualization and network services for Workstation
Loaded: loaded (/usr/lib/systemd/system/vmware.service; enabled; preset: disabled)
Active: active (running) since Thu 2024-06-13 17:40:34 CDT; 16min ago
Process: 151074 ExecStart=/usr/lib/vmware/scripts/init/vmware start (code=exited, status=0/SUCCESS)
Tasks: 6 (limit: 3296082)
Memory: 3.4M
CPU: 152ms
CGroup: /system.slice/vmware.service
├─151134 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet1.pid /dev/vmnet1 vmnet1
├─151140 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet1/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhcpd-vmnet1.pid vm>
├─151144 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vmnet8/nat/nat.conf
├─151146 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet8.pid /dev/vmnet8 vmnet8
├─151149 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet8/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhcpd-vmnet8.pid vm>
└─151166 /usr/sbin/vmware-authdlauncher

$ vmware --version
VMware Workstation 17.5.2 build-23775571

$ uname -a
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/Linux

$ sudo /usr/bin/vmware-networks --stop ; sudo /usr/bin/vmware-networks --verbose --start
Stopped Bridged networking on vmnet0
Stopped DHCP service on vmnet1
Disabled hostonly virtual adapter on vmnet1
Stopped DHCP service on vmnet8
Stopped NAT service on vmnet8
Disabled hostonly virtual adapter on vmnet8
Stopped all configured services on all networks
Commands specified: start
Features configured on vmnet0 are: Bridge
Started Bridge networking on vmnet0
Features configured on vmnet1 are: subnet DHCP HostOnlyAdapter
Creating thread #: 0 to ping subnet on vmnet1
Checking availability of subnet configured for vmnet1
Features configured on vmnet8 are: subnet DHCP NAT HostOnlyAdapter
Creating thread #: 1 to ping subnet on vmnet8
Checking availability of subnet configured for vmnet8
Subnet configured for vmnet1 is available
Subnet configured for vmnet8 is available
Checking if services on vmnet1 can be started, thread #0
Enabled hostonly virtual adapter on vmnet1
Started DHCP service on vmnet1
Finished processing thread #0 on vmnet1
Checking if services on vmnet8 can be started, thread #1
Started NAT service on vmnet8
Enabled hostonly virtual adapter on vmnet8
Started DHCP service on vmnet8
Finished processing thread #1 on vmnet8
Started all configured services on all networks

Follow up

Related 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.

[habig]

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
MODPOST /localhome/habig/vmware/vmware-host-modules/vmmon-only/Module.symvers
ERROR: modpost: "__pte_offset_map" [/localhome/habig/vmware/vmware-host-modules/vmmon-only/vmmon.ko] undefined!

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.

[alanbaugher]

@habig

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.

wget https://softwareupdate.vmware.com/cds/vmw-desktop/ws/17.5.2/23775571/linux/core/VMware-Workstation-17.5.2-23775571.x86_64.bundle.tar

wget https://softwareupdate.vmware.com/cds/vmw-desktop/ws/17.5.2/23775571/windows/core/VMware-workstation-17.5.2-23775571.exe.tar

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.

[kidkaos32]

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
Folks

[habig]

@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

ERROR: modpost: "__pte_offset_map" [/localhome/habig/vmware/new/vmware-host-modules-workstation-17.5.1/vmmon-only/vmmon.ko] undefined!

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.