Up to Release -2405 the problem still persists.

A solution without recompiling any kernel is to manually add the symbol lockdep_init_map to the vmnet module by (i.e. for release 2.6.17-1.2405.fc6):

SYMBOL=`grep "\<lockdep_init_map$" /boot/System.map-2.6.17-1.2405.fc6 | colrm 9`
ld -m elf_i386 --defsym lockdep_init_map=0x$SYMBOL -r -o vmnet.ko vmnet.o vmnet.mod.o
cp vmnet.ko /lib/modules/2.6.17-1.2405.fc6/misc/vmnet.o
cd /lib/modules/2.6.17-1.2405.fc6/misc
ln -s vmnet.o vmnet.ko

This should be done after the vmware-config.pl script fails. The build directory for the vmnet module is the vmnet-only subdirectory in the newest vmware-config* directory in /tmp (i.e. /tmp/vmware-config0/vmnet-only).

After copying the vmnet module into the kernel modules directory, the rest of the vmware-config.pl script should be executed. For this I suggest starting the script with option prebuilt and returning 'yes' in the following code segment of the script instead of 'no':

if ($gOption{'prebuilt'} == 1) {
db_add_answer('BUILDR_' . $name, 'no');
print wrap('None of the pre-built ' . $name . ' modules for '
. vmware_product_name() . ' is suitable for your '
. 'running kernel.' . "\n\n", 0);
return 'yes';
}

The manual linking of the lockdep_init_map symbol to a module should work for any third-party module. That's probably the way it is done with the nvidia driver. But it is not GPL-like.

Dirk

I tried the above "work around" on an x86_64 box. I changed the script to use elf_x86_64 object and changed the kernel version to 2432. All seems to go OK until I run the "vmware-config.pl prebuilt" script. Bridged networking on /dev/vmnet0 fails and NAT service on /dev/vmnet8 fails. After that, vmnet cannot be removed with a "module busy" error. Only a reboot removes the module. Has anyone got this "work around" to work on an AMD-64 with FC6T1 kernel 2432?

Jim

For those running 64 bit machines, here is the revised script.

Jim

VERSION=`uname -r`
SYMBOL=`grep "\<lockdep_init_map$" /boot/System.map-$VERSION | colrm 17`
ld -m elf_x86_64 --defsym lockdep_init_map=0x$SYMBOL -r -o vmnet.ko vmnet.o vmnet.mod.o
cp vmnet.ko /lib/modules/$VERSION/misc/vmnet.o
cd /lib/modules/$VERSION/misc
ln -fs vmnet.o vmnet.ko

http://platan.vc.cvut.cz/ftp/pub/vmware/

This seems to have been solved by kernel 2517.
With any-any-update102, no need of 'make prepare' and patches.

But any-any-update103 has someting wrong.

Sorry, I forgot to change (2, 6, 18) to (2, 6. 17) same as update102.
I thought 103 solved this.
It works fine.

Message was edited by:
hydetech

You can upgrade from WS5.0.0 to WS5.5.2 for free. You should...