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

[Denis L. <de...@po...>]

Latest DKMS package

http://www.poolshark.org/dkms-open-vm-tools/dkms-open-vm-tools-0-1.2008.09.03.fc9.src.rpm

Note: doesn't work on Fedora 9 and newer. Fedora 8 is ok.


Adar Dembo wrote:
> 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?

Yes probably, along with the kernel modules not compiling on very recent
kernels.

> 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.

Yes this is correct.

Typically things like setuid or file ownerships are managed by the
package spec file.


>> - 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:

I'm sorry, my statement was inaccurate. The problem is the call to
'depmod', which requires root privileges. I would recommend to provide a
configure option that disables the call to depmod. Similar options are 
very common for example in gnome applications, to disable the call to 
the desktop or mime info installation script (packagers prefer to do 
this from the spec files).


>> - 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?

The ln command fails because $(DESTDIR)/sbin doesn't exist. Simply
create the directory first, that fixes it.


>> - 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.

Log attached. As you can see it's pretty short. The last entry is 
'[vmsvc]: Registering callback 'Vix_1_SyncDriver_Thaw'.

The hang occurs with both Fedora 9 and Fedora rawhide.


> 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.

Xorg 7.3. vmmouse seems to be pretty thoroughly broken for it. Even by 
specifying vmmouse in xorg.conf, the driver loads correctly but doesn't 
work correctly (x,y coordinates are incorect). I see bug reports in 
launchpad about this as well.