Vmware tools in a debian guest with custom kernel

Here you can discuss every aspect of Debian. Note: not for support requests!

Vmware tools in a debian guest with custom kernel

Postby jspilon » 2006-10-25 21:02

Hi all,

I am running debian guests in vmware server on a debian host. I had to compile new 2.6 kernels for my virtual machines and i have a hard time re-building the vmware tools LKMs..

I have found a very similar post on the board, but it did not help me

http://forums.debian.net/viewtopic.php?t=6412&highlight=vmware

The kernel was built using make-kpkg, I packaged the source and headers as well.

Installed image, source and headers on the target system. untar'ed the sources

Then when running /usr/local/bin/vmware-config-tools.pl

I get the following error:

What is the location of the directory of C header files that match your running
kernel? [/usr/src/linux/include] /usr/src/kernel-headers-2.6.8-vmware-1/include

Extracting the sources of the vmhgfs module.

Building the vmhgfs module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config7/vmhgfs-only'
make -C /usr/src/kernel-headers-2.6.8-vmware-1/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
/usr/src/kernel-headers-2.6.8-vmware-1/scripts/gcc-version.sh: /usr/src/kernel-headers-2.6.8-vmware-1/scripts/gcc-version.sh: No such file or directory
make[1]: Entering directory `/usr/src/kernel-headers-2.6.8-vmware-1'
make[2]: scripts/Makefile.build: No such file or directory
make[2]: *** No rule to make target `scripts/Makefile.build'. Stop.
make[1]: *** [_module_/tmp/vmware-config7/vmhgfs-only] Error 2
make[1]: Leaving directory `/usr/src/kernel-headers-2.6.8-vmware-1'
make: *** [vmhgfs.ko] Error 2
make: Leaving directory `/tmp/vmware-config7/vmhgfs-only'
Unable to build the vmhgfs module.

The filesystem driver (vmhgfs module) is used only for the shared folder
feature. The rest of the software provided by VMware Tools is designed to work
independently of this feature.
If you wish to have the shared folders feature, you can install the driver by
running vmware-config-tools.pl again after making sure that gcc, binutils, make
and the kernel sources for your running kernel are installed on your machine.
These packages are available on your distribution's installation CD.
[ Press Enter key to continue ]
jspilon
 
Posts: 71
Joined: 2006-08-29 15:33
Location: Canada

Postby jspilon » 2006-10-26 20:39

i notice that the box on which i compiled the kernel, if I install the packages, then i will have no problem as above, looks like the kernel packages are broken... it does not do this when i install a stock kernel with kernel header package... weird.

someone?
jspilon
 
Posts: 71
Joined: 2006-08-29 15:33
Location: Canada

Postby jjmac » 2006-10-31 02:07

So if you install the packages then there isn't a problem ...

Sounds very contradictory to me :)

But i may just be following you incorrectly.


Bugs in packages aren't uncommon. The cloop package doesn't install everything needed to build the module either. Quite a large chunk needs to be copied over manually.

Why the gcc-version.sh wasn't copied over , a scrutiny of the perl script might reveal that.

If it is dependant on 'version.h' existing in .../include/linux though ..

Then if you did a make mrproper on your existing kernel before packing up the headers, that file would have been wiped.

I never use debs auto kernel building facility. imo it it much simpler to do it manually. It provides greater flexibility/control as there isn't a lot to it really.

It is one package(s) that represent just over-kill to me :)


jm
jjmac
 
Posts: 387
Joined: 2005-12-28 23:34
Location: Australia

Postby jspilon » 2006-10-31 14:52

It works with the debian distributed kernels, not with the ones I built

jjmac wrote:So if you install the packages then there isn't a problem ...

Sounds very contradictory to me :)

But i may just be following you incorrectly.



I use packages since we are moving toward 30 servers soon, I want to build a local apt repo for all our custom packages. We have a few different kernel packages and non-stock applications.

jjmac wrote:Bugs in packages aren't uncommon. The cloop package doesn't install everything needed to build the module either. Quite a large chunk needs to be copied over manually.

Why the gcc-version.sh wasn't copied over , a scrutiny of the perl script might reveal that.

If it is dependant on 'version.h' existing in .../include/linux though ..

Then if you did a make mrproper on your existing kernel before packing up the headers, that file would have been wiped.

I never use debs auto kernel building facility. imo it it much simpler to do it manually. It provides greater flexibility/control as there isn't a lot to it really.

It is one package(s) that represent just over-kill to me :)


jm
jspilon
 
Posts: 71
Joined: 2006-08-29 15:33
Location: Canada

Postby jjmac » 2006-11-14 07:37

A bit late in the thread but :)

>>
It works with the debian distributed kernels, not with the ones I built
>>

Sounds like it is probably just those files/headers being removed after a make mrproper

The particular files that will need to exist ... those that are generated as part of a kernel build but also wiped on a complete clean up are ...


These are removed on a make mrproper from the kernel srs
But are required for the building of any module i've built so far

Code: Select all
 .../scripts/mod/modpost
 .../include/linux/autoconf.h
 .../include/linux/version.h
 .../Module.symvers


As you mention that it works with the 'debian distributed kernels' but not custom ... that could also just be a 'path' issue concerning the two packages ...

Checking out how the stock package arranges it's path layout and then just supplieing that layout via symlinks to your own custom builds should take care of that.

And the 'equiv' package can also be used to make any dependancy/provides requirements visible in the management system.


>>
I use packages since we are moving toward 30 servers soon, I want to build a local apt repo for all our custom packages. We have a few different kernel packages and non-stock applications.
>>

Sounds like debs 'dpkg-repack' package would be useful in that respect. It will rebuild an installed package, including any configuration modifications that may have been made. And place the package in the directory that the script is run from.


jm
jjmac
 
Posts: 387
Joined: 2005-12-28 23:34
Location: Australia

Postby jspilon » 2006-12-06 14:39

jspilon
 
Posts: 71
Joined: 2006-08-29 15:33
Location: Canada


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 12 guests

fashionable