Re: [open-vm-tools-discuss] open-vm-tools on Fedora 9

[Adar D. <ad...@vm...>]

> I've been working on a more recent version of my dkms packages. The
> 09-03 release is the first in a long time that actually compiles on
> rawhide (after working around an icu bug, bug 461348, will be pushed to
> rawhide in a few days), although it's still far from working. Some of
> the issues i ran into:

Thanks for taking the time to describe each of these issues. I'm guessing the compilation problems you were seeing got fixed in bug 2048423?

> - 'make install' tries to 'chown' some files (in the hgfsmounter
> install-exec-hook). This will fail on most packaging system, since
> packages are rarely built as root. I don't think the chown is necessary
> anyway.

Hmm, the intent of this install-exec-hook is, among other things, to ensure that hgfsmounter is setuid root, which is why the chown is there.

But I guess you're saying that it's not necessary because of the following logic:
1) The user can run 'make install' as is, or under sudo/su.
2) If sudo/su isn't used, there's no way to establish setuid root on the binary anyway.
3) If sudo/su is used, 'make install' will guarantee that the owner/group is root by virtue of the fact that the default actions for bin_PROGRAMS or sbin_PROGRAMS is to install the file as the current user.

Is that correct? If so, I'll remove the chown.

> - The module installation ignores DESTDIR, and so will also fail as
> part
> of an non-root RPM build.

Are you sure about that? I see this code in modules/Makefile.am:

        for MOD in $(MODULES); do \
                $(INSTALL) -d $(DESTDIR)`eval echo '$$'$${MOD}dir`; \
                $(INSTALL) -m644 $(MODULES_OS)/$$MOD/$$MOD.ko $(DESTDIR)`eval echo '$$'$${MOD}dir`; \
        done

I see $(DESTDIR) prefixes, what's missing? I mean, there's no path separator between $(DESTDIR) and the rest, but I think that shouldn't matter because every module directory (vmblockdir, vmcidir, etc.) begins with $(MODULES_DIR) which is an absolute path, thus already prefixed with a path separator.

> - mount.vmhgfs gets installed in /usr/sbin instead of /sbin

Does this matter if there's also a symlink from /sbin/mount.vmhgfs to /usr/sbin/mount.vmhgfs? Looking at the code, the very last action in install-exec-hook is:

        -$(LN_S) $(DESTDIR)$(sbindir)/mount.vmhgfs \
                $(DESTDIR)/sbin/mount.vmhgfs &> /dev/null

That should guarantee a symlink from /sbin/mount.vmhgfs, right?

> - after I got everything built and prepared, guestd seems to hang on
> startup, using up 100% cpu. Vmware workstation reports 'Your VM tools
> is
> out of date' (i'm using workstation 6.5 on linux host). Is there a way
> to compile in more debug information that I could report ?

Yes, see my reply to Joshua Franklin to see how guestd/vmware-user logging can be enabled. Let's start from there and add more serious instrumentation if logging doesn't help.

> - can't move the mouse out of the VM window. Somehow Xorg is not using
> the vmmouse driver ? The system runs without an xorg.conf file (as is
> the norm nowadays), but it should have selected the right drivers by
> default.

What Xorg version is in Fedora 9? I noticed this same issue with Ubuntu Intrepid; turns out new versions of Xorg use input-hotplug which cannot detect vmmouse. I think we're trying to address this by switching over to the VMware USB mouse (different from vmmouse) and improving evdev's support for this mouse, but I don't know the specifics or the status.

> - running vmware-user yields the same hang problem as guestd.

Let's go for the logs. I'm trying to think of shared components between guestd and vmware-user; libicu definitely fits the bill, though there may be others.