vmware 6.0 vmware-config fails with kernel 2.6.22.1

[CuZnDragon]

This is the error I am getting...

Using 2.6.x kernel build system.

make: Entering directory `/tmp/vmware-config3/vmnet-only'

make -C /lib/modules/2.6.22.1/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules

make[1]: Entering directory `/usr/src/linux-2.6.22.1'

CC /tmp/vmware-config3/vmnet-only/driver.o

CC /tmp/vmware-config3/vmnet-only/hub.o

CC /tmp/vmware-config3/vmnet-only/userif.o

/tmp/vmware-config3/vmnet-only/userif.c: In function ‘VNetCopyDatagramToUser’:

/tmp/vmware-config3/vmnet-only/userif.c:630: error: ‘const struct sk_buff’ has no member named ‘h’

/tmp/vmware-config3/vmnet-only/userif.c:630: error: ‘const struct sk_buff’ has no member named ‘nh’

/tmp/vmware-config3/vmnet-only/userif.c:636: error: ‘const struct sk_buff’ has no member named ‘h’

make[2]: *** Error 1

make[1]: *** \[_module_/tmp/vmware-config3/vmnet-only] Error 2

make[1]: Leaving directory `/usr/src/linux-2.6.22.1'

make: *** \[vmnet.ko] Error 2

make: Leaving directory `/tmp/vmware-config3/vmnet-only'

Unable to build the vmnet module.

[demorecorder]

Hi,

I just stumbled over the same problem but I was able to fix it by patching source of the vmnet module.

The reason of the problem was some renaming and restructuring in the struct sk_buff which happened for Kernel version 2.6.22.

The following patch fixes that for me ( use at your own risk or have the patch verified by vmware support 😞

http://www.DemoRecorder.com/download/Vmware-patch-for-2.6.22.1/patch-vmnet-for-linux-2.6.22.1.gz

(provided as a link because the forum-software may garble the patch)

You can apply the patch as follows: ( as root, please replace yourdownloaddir[/i] with the directory where you have stored the patch )

cd /usr/local/lib/vmware/modules/source

cp vmnet.tar vmnet.tar.orig

tar xvpf vmnet.tar

zcat yourdownloaddir[/i]/patch-vmnet-for-linux-2.6.22.1.gz | patch -p4

tar cvf vmnet.tar vmnet-only

Then please rerun /usr/local/bin/vmware-config.pl

I hope this helps,

Chris

P.S. Please note that the patch is against the newest Vmware-Workstation version, i.e. VMware-workstation-6.0.0-45731.i386.tar.gz .

P.P.S. I have tested that only a few minutes which I needed to get my real work done in a Windows2000 emulation under Vmware.

But there it worked very well. I use the "host-only" network mode, so other modes ( bridged etc ) are not tested.

[Grogan]

I'm looking for a proper[/i] fix for this problem. Yes, the above patch compiles and it works, however, I use bridged networking and I'm unable to communicate with the (Linux) host computer. I can ping the host, but no high level networking functions. It just sits there and hangs. Linux guests, Windows guests the same. I've tried three different patches that have been floating around here. That's not good, because it's how I transfer files between host and guests. The damned vmware-tools shared folders driver doesn't compile if the Linux guests have a modern kernel either. I have to transfer files to another box as a buffer, and then transfer them to the host. That's a waste of my time.

A virtual machine should act just like another PC on the LAN when bridged networking is used. It acquires IP settings from my router and normally would be able to connect to the host.

In the old days, Petr would have a viable (though unofficial) fix cooked up during the first release candidate of a new kernel release cycle. But I don't see him around here anymore. This is what made vmware viable for me.

This problem does not occur with the original vmnet.tar, on Linux 2.6.21 and below.

Going back to 2.6.21 is not an option, for I need fixes and drivers in 2.6.22.

Yes, I do realize I'm not using a "supported" Linux distribution on the host.

Has anyone else noticed this problem with bridged networking on a Linux 2.6.22 host, using the vmnet patches floating around this forum?

[chguernsey]

I'm a bit irked that the devs changed the network code, but your patch works! Thank you, sir!

[grisutheguru]

Same problem here.

Patch makes it compile, but cause network problems.

Any idea, when VMWare will fix it?

Best regards

\--

Grisu

Message was edited by:

grisutheguru

[noyb]

vmware-mount.pl people!

or diskmount if you're using Windows!

[jasn]

Has anyone else noticed this problem with bridged networking on a Linux 2.6.22 host, using the vmnet patches floating around this forum?

Yes. I've been running VMWare Workstation 6.0 successfully on my Gentoo Linux laptop since 44426 without issues. I upgraded my kernel to 2.6.22, and now the bridged network config of my XPSP2 guest OS, can't get an IP address from the dhcp server here.

It's more than just fixing a module build problem. Something else is wrong here.

[AbsintheSyringe]

Yes, Slackware here. Just moved to 2.6.22.1 today.

Same problem, tried vmware any-to-any patch (cuz it used to solve this kind of problem) which actually said:

root@havoc:/home/absinthe/Download/src/vmware-any-any-update109# ./runme.pl

"Unknown VMware version 4 is installed. This installer supports only version 2

and 3.

Execution aborted.

root@havoc:/home/absinthe/Download/src/vmware-any-any-update109#

Even tried reinstalling, it wont even install on 2.6.22.x. VMware team, these are constant, persistent, old bugs, and they keep happening, you seriously might consider to fix them already ...

Message was edited by:

AbsintheSyringe

[nick_couchman]

Well, right now the only "proper" fix is to use a kernel that's SUPPORTED by VMware. Since you're using a BLEEDING EDGE kernel, it isn't supported, yet - you will just have to be patient and wait for VMware to catch up a little bit. Companies can't always stay on top of the latest developments, especially for something as fluid as the Linux kernel, so you have to be patient and let them catch up. Petr does still create patches every now and then, but these patches still DO NOT represent official VMware support. He is a VMware employee, but he is creating these patches on his own, not in his role as a VMware employee. If he were, they would be posted on the VMware site and not on Petr's own homepage.

[AbsintheSyringe]

I think VMware already has a team of lawyers to represent them. Patching, any-to-any patch has been around for awhile. This has already been an issue, ok, I don't mind using any-to-any patch, but please patch it so works on latest Vmware Workstation version.

At this point, I'll try to fix bug myself, (patch any-to-any patch) it's better then just waiting for mercy bug fix. If successful I'll post it here.

[Grogan]

Well right now, THAT OBVIOUSLY ISN'T GOOD ENOUGH FOR ME. I'm just not going to take that crap. I did say that I realize that I'm not using a supported system in hopes of avoiding the all too typical replies from some of the resident forum mouthpieces. Don't think I haven't noticed that things have gone down hill around here either.

It's evidently not just me having the problem, which is another thing I needed to find out. Thanks for responding, folks.

I don't consider it a bleeding edge kernel. It's the latest stable release and it's been final for a few weeks now after a long release cycle. I refrained from making further inquiries until this time. If purchased software can't support the latest kernel releases then I have no use for it. Note that Nvidia does a better job of maintaining their proprietary drivers than this.

Patience... How long are we supposed to wait? Until next year when Vmware 6.5 is released and what then? Proprietary software models on systems like Linux do not work. Yes, that's right, things are "fluid" and this is like concrete shoes weighing me down. I think I'll just cut my losses and move on. Lesson learned and it won't happen again.

This is nothing against the helpful people who have provided unofficial vmware patches. I very much appreciate their efforts. I don't expect them to get everything right, because they have no knowledge of some of the vmware internals. (Which is why I mentioned Petr, because he's one that does and has been most helpful over the last few years. It's nothing against him either of course. After I was absent for a while, I was alarmed to see that he wasn't posting here anymore.)

Well, right now the only "proper" fix is to use a

kernel that's SUPPORTED by VMware. Since you're

using a BLEEDING EDGE kernel, it isn't supported, yet

- you will just have to be patient and wait for

VMware to catch up a little bit. Companies can't

always stay on top of the latest developments,

especially for something as fluid as the Linux

kernel, so you have to be patient and let them catch

up. Petr does still create patches every now and

then, but these patches still DO NOT represent

official VMware support. He is a VMware employee,

but he is creating these patches on his own, not in

his role as a VMware employee. If he were, they

would be posted on the VMware site and not on Petr's

own homepage.

[muius]

Well right now, THAT OBVIOUSLY ISN'T GOOD ENOUGH FOR

ME.

+1 here. finally this is a good time for me to move on.

PS: thanks demorecorder, your patch works, but that does not means that the product that I payed for it worth the money!

[CuZnDragon]

Seems to be working okay so far.

[lid01]

Using WS6 x86_64. It doesn't work for me. I'm getting invalid operand for binary - errors

the any-any vmnet update compiles, but cpu usage is at 100% all the time, which heats up my system like a fireburner.

[mjs]

This patch doesn't apply to VMware Workstation 5.5.4. Is there an easy fix?

\# patch -p4 < /home/mjs/fedora7/vmware/patch-vmnet-for-linux-2.6.22.1

missing header for unified diff at line 4 of patch

patching file vmnet-only/bridge.c

Hunk #1 succeeded at 1072 (offset -11 lines).

Hunk #2 succeeded at 1174 (offset -196 lines).

Hunk #3 FAILED at 1196.

1 out of 3 hunks FAILED -- saving rejects to file vmnet-only/bridge.c.rej

missing header for unified diff at line 40 of patch

patching file vmnet-only/compat_sock.h

missing header for unified diff at line 51 of patch

can't find file to patch at input line 51

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

\----

---

\|diff -ru /home/chris/Temp/vmnet-only/filter.c vmnet-only/filter.c

\|--- /home/chris/Temp/vmnet-only/filter.c 2007-05-02 06:08:22.000000000 +0200

\|+++ vmnet-only/filter.c 2007-07-14 11:11:39.000000000 +0200

\----

---

File to patch: vmnet-only/filter.c

vmnet-only/filter.c: No such file or directory

Skip this patch? y

Skipping patch.

2 out of 2 hunks ignored

missing header for unified diff at line 82 of patch

patching file vmnet-only/userif.c

Hunk #1 succeeded at 630 (offset 3 lines).

missing header for unified diff at line 101 of patch

patching file vmnet-only/vnetInt.h

[AbsintheSyringe]

I believe easy fix is to just start using qemu/kqemu at this point. Freedom to the fullest.

[Pavlinux]

Worked vmnet.tar (tested on Linux 2.6.22.1 + Vmware WS6 w. WindowsXP + network in bridged mode).

http://linux.nextmail.ru/vmnet.tar

[ml664]

This patch compiles with warnings, but freezes my machine, when the module is loaded.

(Fedora7, Kernel 2.6.22.1-27.fc7, x86_64)

[cf]

Well, right now the only "proper" fix is to use a kernel that's SUPPORTED by VMware. Since you're using a BLEEDING EDGE kernel

git kernels may be bleeding edge, but 2.6.22 is a stable.

Companies can't always stay on top of the latest developments, especially for something as fluid as the Linux kernel, so you have to be patient and let them catch up.

I have to agree that keeping up in the merge burst is hard, if not unnecessary (because things may just change in the next hour). But when -rc1 is released, you can assume that things like network infrastructure do not change anymore until the final release, so this is the point where developers should get going to get it ready until -rc6 (= 5+ weeks time).

That said, Petr does an awesome job, especially \_since_ it is inofficial and it can be assumed that vmware is not devoting a full-time position to keep up with the kernel du jour.

[Pavlinux]

Ooops, sorry

Today fixed.

Here again vmnet.tar and my patch:

TAR: http://linux.nextmail.ru/vmnet.tar

PATCH: http://linux.nextmail.ru/vmnet_for_2.6.22.1.patch.bz2

.