NOT SOLVED !! : Open-VM-Tools - NOT WORKING on vSphere

[jimp]

And that command runs fine for me, and the daemon continues to run once I start it by hand.

[secabeen]

@Clouseau:

@secabeen:

This package looks like it installs and runs successfully, but doesn't start properly on bootup.  I can run the scripts in /usr/local/etc/rc.d/, but if I reboot the PFSense VM, when it comes back up, the vmware daemon and kernel modules aren't loaded.

true, it installs just fine without any errors but vmtools just are not starting. I Still go this error: root: /usr/local/etc/rc.d/vmware-guestd.sh: WARNING: run_rc_command: cannot run /usr/local/bin/vmtoolsd

This is only package I use in my system.

Do you have problems on both 64-bit and 32-bit VMs?

[photonman]

@secabeen:

Do you have problems on both 64-bit and 32-bit VMs?

My 64-bit RC2 loads up fine (I think)

no error messages

[jimp]

@Clouseau:

true, it installs just fine without any errors but vmtools just are not starting. I Still go this error: root: /usr/local/etc/rc.d/vmware-guestd.sh: WARNING: run_rc_command: cannot run /usr/local/bin/vmtoolsd

This is only package I use in my system.

You appear to have an issue that nobody else seems to have. Try these commands, and show the output:

file /usr/local/bin/vmtoolsd
ldd /usr/local/bin/vmtoolsd

For comparison, I get this output on my system:

: file /usr/local/bin/vmtoolsd
/usr/local/bin/vmtoolsd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.1, stripped
: ldd /usr/local/bin/vmtoolsd
/usr/local/bin/vmtoolsd:
        libvmtools.so.0 => /usr/local/lib/libvmtools.so.0 (0x2809a000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x280f5000)
        libthr.so.3 => /lib/libthr.so.3 (0x2810e000)
        libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x28123000)
        libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28127000)
        libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x2816a000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x2816f000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28241000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2824a000)
        libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28340000)
        libicui18n.so.46 => /usr/local/lib/libicui18n.so.46 (0x2837c000)
        libicuuc.so.46 => /usr/local/lib/libicuuc.so.46 (0x2855e000)
        libicudata.so.46 => /usr/local/lib/libicudata.so.46 (0x28694000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x29513000)
        libm.so.5 => /lib/libm.so.5 (0x29607000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x29621000)
        libc.so.7 => /lib/libc.so.7 (0x2962c000)

[Clouseau]

Jimp:

$ file /usr/local/bin/vmtoolsd
/usr/local/bin/vmtoolsd: cannot open `/usr/local/bin/vmtoolsd' (No such file or directory)

and

$ ldd /usr/local/bin/vmtoolsd

Something is totally wrong here, but what can you really do wrong? Bad mouse click on install package ;D

I got version:
2.0-RC2 (i386)
built on Sun May 15 20:43:07 EDT 2011

Problems are now only on 32bit pfSense.

[jimp]

Either the package isn't getting fully installed somehow, or it thinks it is installed but really isn't.

Uninstall the vmware tools package, and then run:

pkg_info

And then report the results back here. Odds are there is something in the list that, once you pkg_delete -f it, things will start to work properly.

Sure, all you did was click the mouse, but odds are that something in the underlying OS is the real issue, especially since it seems unique to just you.

[Clouseau]

I run your command: pkg_info:

$ pkg_info
grub-0.97_3         GRand Unified Bootloader
packages            BSD Installer mega-package
python26-2.6.5      An interpreted object-oriented programming language

I run commands:

pkg_delete -f grub-0.97_3
pkg_delete -f packages
pkg_delete -f python26-2.6.5

Now everything seems to be clear.

After this I installed Open-VM-Tools again.

And logs says that vmware tools are not running!

Jun 13 14:06:24 	kernel: VMware memory control driver initialized
Jun 13 14:06:24 	root: /usr/local/etc/rc.d/vmware-guestd.sh: WARNING: failed to start vmware_guestd

Now I run pkg_info again:

fusefs-kmod-0.3.9.p1.20080208_7 Kernel module for fuse
fusefs-libs-2.7.4   FUSE allows filesystem implementation in userspace
libdnet-1.11_3      A simple interface to low level networking routines
libiconv-1.13.1_1   A character set conversion library
open-vm-tools-nox11-313025_2 Open VMware tools for FreeBSD VMware guests
pcre-8.12           Perl Compatible Regular Expressions library
pkg-config-0.25_1   A utility to retrieve information about installed libraries

So, this issue is not solved! Should I pkg_delete all these packages now?

[jimp]

Don't pkg_delete those, try to find out more about why it can't start vmware-guestd.

What does this output?

ldd /usr/local/bin/vmtoolsd

[Clouseau]

$ ldd /usr/local/bin/vmtoolsd
/usr/local/bin/vmtoolsd:
	libvmtools.so.0 => /usr/local/lib/libvmtools.so.0 (0x2809a000)
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x280f5000)
	libthr.so.3 => /lib/libthr.so.3 (0x2810e000)
	libgmodule-2.0.so.0 => not found (0x0)
	libgobject-2.0.so.0 => not found (0x0)
	libgthread-2.0.so.0 => not found (0x0)
	libglib-2.0.so.0 => not found (0x0)
	libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28123000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2812c000)
	libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28222000)
	libicui18n.so.46 => not found (0x0)
	libicuuc.so.46 => not found (0x0)
	libicudata.so.46 => not found (0x0)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2825e000)
	libm.so.5 => /lib/libm.so.5 (0x28352000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2836c000)
	libc.so.7 => /lib/libc.so.7 (0x28377000)
	libglib-2.0.so.0 => not found (0x0)
	libicui18n.so.46 => not found (0x0)
	libicuuc.so.46 => not found (0x0)
	libicudata.so.46 => not found (0x0)

[jimp]

So for some reason on your system it's not pulling in all of the dependencies that it needs. All of the ones that say "not found" should exist.

[Clouseau]

yep - no wonder I have some problems  :D

Now must figure out how to fix it.

[jimp]

It works fine from a fresh install. I just wiped a VM, installed from the latest ISO, and only installed the vmware tools package.

[2.0-RC2][root@pfSense.localdomain]/root(1): ps uxawww | grep vm
root      19  0.0  0.0     0     8  ??  DL   12:17PM   0:00.00 [vmdaemon]
root   34122  0.0  1.1 26188  5320  ??  S    12:31PM   0:00.33 /usr/local/bin/vmtoolsd -c /usr/local/share/vmware-tools/tools.conf -p /usr/local/lib/open-vm-tools/plugins/vmsvc
root   33235  0.0  0.2  1848  1164   0  R+   12:35PM   0:00.00 grep vm

[2.0-RC2][root@pfSense.localdomain]/root(2): pkg_info
bsdinstaller-2.0.2011.0612 BSD Installer mega-package
fusefs-kmod-0.3.9.p1.20080208_7 Kernel module for fuse
fusefs-libs-2.7.4   FUSE allows filesystem implementation in userspace
gettext-0.18.1.1    GNU gettext package
glib-2.26.1_1       Some useful routines of C programming (current stable versi
grub-0.97_4         GRand Unified Bootloader
icu-4.6.1           International Components for Unicode (from IBM)
libdnet-1.11_3      A simple interface to low level networking routines
libiconv-1.13.1_1   A character set conversion library
open-vm-tools-nox11-313025_2 Open VMware tools for FreeBSD VMware guests
pcre-8.12           Perl Compatible Regular Expressions library
perl-5.10.1_3       Practical Extraction and Report Language
perl-5.12.3         Practical Extraction and Report Language
pkg-config-0.25_1   A utility to retrieve information about installed libraries
python27-2.7.1_1    An interpreted object-oriented programming language

[2.0-RC2][root@pfSense.localdomain]/root(3): ldd `which vmtoolsd`
/usr/local/bin/vmtoolsd:
        libvmtools.so.0 => /usr/local/lib/libvmtools.so.0 (0x2809a000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x280f5000)
        libthr.so.3 => /lib/libthr.so.3 (0x2810e000)
        libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x28123000)
        libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28127000)
        libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x2816a000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x2816f000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x28241000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2824a000)
        libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28340000)
        libicui18n.so.46 => /usr/local/lib/libicui18n.so.46 (0x2837c000)
        libicuuc.so.46 => /usr/local/lib/libicuuc.so.46 (0x2855e000)
        libicudata.so.46 => /usr/local/lib/libicudata.so.46 (0x28694000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x29513000)
        libm.so.5 => /lib/libm.so.5 (0x29607000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x29621000)
        libc.so.7 => /lib/libc.so.7 (0x2962c000)

[Clouseau]

ok - but I need to get this fixed (not possible make a fresh install)  ???

[jimp]

If that isn't working, there is no telling what else isn't working.

It's a VM. Make a new VM. Restore the config. Power off the old one, power on the new one, install the package.

It's a lot easier to make a fresh install into a VM than real hardware. There is very little compelling reason to fight something that is obviously corrupt or not proper about a VM.

[photonman]

@jimp:

There is very little compelling reason to fight something that is obviously corrupt or not proper about a VM.

…amen

cut the losses and move on...

that is what is so wonderful about VM's as they are so easy to provision with new pf builds...

[Clouseau]

@jimp:

If that isn't working, there is no telling what else isn't working.

It's a VM. Make a new VM. Restore the config. Power off the old one, power on the new one, install the package.

It's a lot easier to make a fresh install into a VM than real hardware. There is very little compelling reason to fight something that is obviously corrupt or not proper about a VM.

Yes, easy fix !

• but I'm still interested to find what went and is wrong and how to avoid it next time! This same problem or bug might popup again and then you should have the knowledge fix it easily or even avoid it totally. That's why we use RC/BETA's to find these kind of bugs and unwanted features. The beta testing it's not always to find the easy fix but solid solution :-)

[jimp]

That is only useful if you spend less time tracking it down than reinstalling. If you want to figure it out, have at it, but when there are workable alternatives that get you a working system in less time then I don't see how spending more developer resources on tracking down what happened in one specific odd case would be worth the time.