Menu
▾
▴
#56 kernel-modules not longer building on fedora
Since april 2009 the open-vm-tools are not longer building on fedora 9 / fedora 10
Since a long time i use the following script to build the kernel-modules for distributing after that to all other machines and it would be fine to get this working again because kernel 2.6.29 landed in updates-testing today
[root@buildserver:/scripts]$ cat /scripts/open-vm-tools/build.sh
#!/bin/bash
tar -xzf open-vm-tools-*.gz
cd open-vm-tools-*/modules/linux
modsrc="/usr/lib/vmware-tools/modules/source"
for x in `ls -d v*`
do
mv $x ${x}-only
tar -cf $x.tar ${x}-only
mv ${x}-only $x
mv $modsrc/$x.tar $modsrc/$x.tar.orig
mv $x.tar $modsrc
done
vmware-config-tools.pl
That won't work. The module directories don't contain all needed files anymore - the shared files are reused from other locations. If you want the tar packages you should probably get them from VMware's Tools distribution that goes with the products, or try to adapt the instructions on the following thread to create them from the open-vm-tools code:
https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel
> The module directories don't contain all needed files anymore
WHY?
You make unuseable this for non c-programmers in many cases or hurt them
Since many months this works very well on round 20 guest-machines and
On the referenced mailing-list i find no clear solution to get this working as it did
before april 2009.
> you should probably get them from VMware's Tools distribution that goes with the products
If this would be so easy there would be NO NEED for open-vm-tools because you need them
for distributions with really new kernels as not official supported fedora-guests
Now i try to get compiled the kernel-modules and i would like to copy them directly without install the other stuff
But it is not building - So give me please a working way to get the kernel-modules built on recent fedora-versions or make the old way working again
cc1: warnings being treated as errors
wiperPosix.c: In function 'Wiper_Init':
wiperPosix.c:1016: error: ignoring return value of 'fgets', declared with attribute warn_unused_result
make[2]: *** [wiperPosix.lo] Fehler 1
make[2]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib/wiper'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/usr/local/scripts/open-vm-tools/open-vm-tools-2009.05.22-167859/lib'
make: *** [all-recursive] Fehler 1
#!/bin/bash
cd /scripts/open-vm-tools/open-vm-tools*/
export CFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2"
export CXXFLAGS="-O6 -march=native -mtune=native -fopenmp -pipe -fno-strict-aliasing -D_FORTIFY_SOURCE=2"
./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --without-procps \ --without-gtkmm \ --without-gtk2 \ --disable-unity \ --disable-docs && make
You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream.
For the record, I have an RPM of the latest open-vm-tools, but I'm seeing massive regression (drag-n-drop not working, etc...). But i'm short on time, patches are always welcome.
> You need to file a bug against the Fedora rpmfusion packager (i.e. myself), not upstream.
> For the record, I have an RPM of the latest open-vm-tools, but I'm seeing
> massive regression (drag-n-drop not working, etc...). But i'm short on
> time, patches are always welcome.
Where does rpmfusion matter in my context?
I try to build the whole time by myself the same way i did before april and i need only the newest kernel-modules
We are speaking from hi-performance web- and databaseservers living on an vmware-esxi
drag-n-drop does not matter, i need vmxnet etc. on the buildmachine/internel cacherepo and distribute them with rsync to the other machines before distribute the kernel-updates to avoid downtime and problems maybe not solveable without networking on the live-servers.
If i would have a rock-stable src.rpm which builds the newest versions for vmci, vmemctl and vmxnet against the last kernel-updates i can distribute this as optimiized httpd, php... from the buildmachine.
However - It's crazy to modify the open-vm-tools in a way that they makes such problems
On VMware-Supported distributions they nobody needs and on guests where you need them you can not use them any longer - WTF?
your tone is rude at best, and yet you expect help. Amazing.
Your issue is less with the open-vm-tools (you break them apart and try to do something with them what they are not meant for).
Why don't you just take the original vmware-tools ones and apply the existing patches???
It's not as they would not exist!
http://communities.vmware.com/thread/208963
OR:
Use the following script to build all the modules (we use this script on openSUSE since first versions of open-vm-tools hit the download mirrors, with only minor modifications long ago):
###
TOPDIR=$PWD
cd ..
mkdir -p obj
for flavor in %{flavors_to_build}; do
rm -rf obj/$flavor
cp -r %{name}-%{version}-%{svn_rev} obj/$flavor
pushd obj/$flavor
for module in %{vm_modules}; do
pushd modules/linux/$module
make -C /usr/src/linux-obj/%{_target_cpu}/$flavor modules M=$PWD VM_CCVER=$(gcc -dumpversion) HEADER_DIR="/usr/src/linux-obj/$(uname -i)/default/include" SRCROOT=$PWD OVT_SOURCE_DIR=$TOPDIR
popd
done
popd
done
###
(this is part of the spec file posted recently on the open-vm-tools maiinglist).
the 'for' with the flavors you can skip for your usecase. It will most likely be 'default'
Reindl, not to get too held up in semantics, but you weren't building the modules, you were re-packaging them. Once you re-package them, if you can't build them it's probably an issue in *your* packaging steps, since we make sure that if you build things using the open-vm-tools makefiles it will build (and it does).
You're seeing issues because in the past two months I cleaned up all the duplicate files in the open-vm-tools package. This means that a bunch of headers and sources that used to be duplicated in all kernel modules' directories are not there anymore and are instead re-used from other places. This is a good thing because it helps us internally at VMware with some projects we have in the mid-term. It also makes things better organized.
So again, you're doing something that is not "standard building procedure" as far as the package goes; so if things don't build for you now, you need to fix your procedure and not the way around. Other people had problems building the module too after these changes - and they fixed their packages and now things work.
About the fgets() problem, we fixed it internally already, it's a simple fix (just enclose it in an if () so that the compiler thinks you're using the return value).
> Reindl, not to get too held up in semantics, but you weren't building the
> modules, you were re-packaging them.
Bullshit - I would package them if i would make a rpm
If i compile them i BUILD them
> since we make
> sure that if you build things using the open-vm-tools makefiles it will
> build (and it does).
It does NOT damned
> About the fgets() problem, we fixed it internally already, it's a simple
> fix (just enclose it in an if () so that the compiler thinks you're using
> the return value).
See above, internally fixed does not matter the released package DOES NOT build
I am no C++ programmer, i am enduser
Does not matter any longer
I made many months ago on livna a feature-request for the kernel-modules and it was declined
Sorry that i could not smell that after switch to "rpmfusion" the modules been included and nobody said a word in the bugreport
So the current F-9 and F-10 RpmFusion open-vm-tools packages don't work for you ?
They do but i did not know that they exist before your posting and what me made angry was the link to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel in the first answer because there is no real solution for a aneduser and "you should probably get them from VMware's Tools distribution that goes with the products" is not useful if you want to run fedora on a esx-host
You don't seem to really be willing to realize that the makefiles have changed and that whatever custom steps you were doing before may not work anymore, but I'll try to address your comments anyway.
> Bullshit - I would package them if i would make a rpm
> If i compile them i BUILD them
If you do the "configure / make / make install" dance and the modules do not compile, then it's a problem in the package. If you go into the module's directory (e.g., modules/linux/vmhgfs) and type "make", it's not an open-vm-tools problem since that's not the way these modules are expected to be built. Just "make" is not enough to satisfy the makefiles anymore. That's why there is a Makefile.am in the "modules" dir that builds the modules in the correct way.
> See above, internally fixed does not matter the released package DOES NOT
> build I am no C++ programmer, i am enduser
Then you need to understand that the open-vm-tools package (e.g., the .tar.gz distributes through the sourceforge project page) is not targeted at end users, and is also to be considered "experimental" and unsupported by VMware. It contains bleeding edge code that hasn't been fully tested, and may not compile in the latest and greatest distros (a good example is this exact fgets() issue, which older distros don't complain about).
If you're an end user, you should be using either the RPMs provided by your distro (as others have pointed out), with the caveat about VMware support, or the official Tools shipped with the VMware product you own. When you install those, you get the source code for the modules in /usr/lib/vmware-tools/modules/source, and you can build and distribute those any way you want (since IIRC they're also GPL).
> You don't seem to really be willing to realize that the makefiles have
> changed and that whatever custom steps you were doing before may not work
> anymore
You don't realize that the problem is solved by using rpms and the only thing that made me angry was your reference to https://sourceforge.net/mailarchive/forum.php?thread_name=200905181606.57759.olivier.lahaye%40cea.fr&forum_name=open-vm-tools-devel - what the hell should a non c-programmer do with this?
> the official Tools shipped with the VMware product you own.
> When you install those, you get the source code for the modules in
> /usr/lib/vmware-tools/modules/source, and you can build and distribute
> those any way you want
*lol* in your world must exist other vmware-release-cycles, in the real world they ship a update fpr vmware-server where the SERVER-kernel-modules are not compiling on 2.6.29 and the update was released long after 2.6.29, so what should i do with the "shipped with the VMware product"? And no - debian instead of fedora ist no solution, i need php 5.3 this year and not in the next century
> You don't realize that the problem is solved by using rpms
I do and I mentioned it.
> the only thing that made me angry was your reference to [url stripped]
> what the hell should a non c-programmer do with this?
There's nothing related to C programming in that thread. It's all about packaging. End users may not be able to make much sense of that, but as I said, open-vm-tools (the package distributed on sourceforge.net) is *not* targeted at end users. It's targeted at developers and packagers.
> in your world must exist other vmware-release-cycles, in the real
> world they ship a update fpr vmware-server where the SERVER-kernel-modules
> are not compiling on 2.6.29
I understand very well the VMware release cycles. Your problem is fixed by getting VMware updates (we do update kernel modules on patch releases of ESX, Workstation and Fusion). If you're using VMware *Server*, your problem is that this product isn't being updated - you can probably find patches in the VMware forums if you're so inclined. But open-vm-tools is *not* the solution for that problem, since that is not what it's meant to be.
I'm closing this bug for comments because this discussion is obviously not going anywhere.