open-vm-tools-discuss

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

[Joshua D. F. <jdf...@gm...>]

Hello, I'm running VMWare Fusion 2 beta and trying to get
open-vm-tools installed in a Fedora 9 VM.

I first tried the download on the main page but ran into the
procps header problem, so I rebuilt the Fedora 8 RPM at
http://www.poolshark.org/dkms-open-vm-tools/
dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm	

It seemed to work fine and shows up in "dkms status"...
but I still get "VMware Tools is not installed."  and
copy/paste does not work. Should it?

By the way, Fedora 10 is nearing beta so it would be
great to get this working there too. It's pretty easy for
me to build a livecd iso from the devel tree so if anyone
wants to play with it let me know and I'll put up a
download of a livecd that includes dev tools.

Or, if you're running Fedora, you can build a custom devel
livecd easily by following these instructions:
http://spevack.livejournal.com/31634.html

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

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

> I first tried the download on the main page but ran into the
> procps header problem, so I rebuilt the Fedora 8 RPM at
> http://www.poolshark.org/dkms-open-vm-tools/
> dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm

You could also use the Sourceforge download and pass --without-procps to configure. Doing that will cause some code in vmware-guestd to be skipped, but that doesn't matter at all to Fusion.

> It seemed to work fine and shows up in "dkms status"...
> but I still get "VMware Tools is not installed."  and
> copy/paste does not work. Should it?

Can you verify that vmware-guestd is running? The UI's Tools status notification comes from messages sent by vmware-guestd.

Are you using a console or are you within an X11 session? Can you verify that vmware-user is running?

> By the way, Fedora 10 is nearing beta so it would be
> great to get this working there too. It's pretty easy for
> me to build a livecd iso from the devel tree so if anyone
> wants to play with it let me know and I'll put up a
> download of a livecd that includes dev tools.
>
> Or, if you're running Fedora, you can build a custom devel
> livecd easily by following these instructions:
> http://spevack.livejournal.com/31634.html

I don't have the bandwidth to do that right now, but I just thought I'd add that I too would appreciate seeing a Fedora 10 package.

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

[Joshua D. F. <jdf...@gm...>]

On Fri, Sep 5, 2008 at 4:57 PM, Adar Dembo wrote:
>> I first tried the download on the main page but ran into the
>> procps header problem, so I rebuilt the Fedora 8 RPM at
>> http://www.poolshark.org/dkms-open-vm-tools/
>> dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm
>
> You could also use the Sourceforge download and pass --without-procps to configure. Doing that will cause some code in vmware-guestd to be skipped, but that doesn't matter at all to Fusion.

I may try that after getting this first VM working.

>> It seemed to work fine and shows up in "dkms status"...
>> but I still get "VMware Tools is not installed."  and
>> copy/paste does not work. Should it?
>
> Can you verify that vmware-guestd is running? The UI's Tools status notification comes from messages sent by vmware-guestd.
>
> Are you using a console or are you within an X11 session? Can you verify that vmware-user is running?

X11. Yep, "ps x" shows both are running.


>> By the way, Fedora 10 is nearing beta so it would be
>> great to get this working there too. It's pretty easy for
>> me to build a livecd iso from the devel tree so if anyone
>> wants to play with it let me know and I'll put up a
>> download of a livecd that includes dev tools.
>>
>> Or, if you're running Fedora, you can build a custom devel
>> livecd easily by following these instructions:
>> http://spevack.livejournal.com/31634.html
>
> I don't have the bandwidth to do that right now, but I just thought I'd add that I too would appreciate seeing a Fedora 10 package.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> open-vm-tools-discuss mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-discuss
>

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

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

> >> It seemed to work fine and shows up in "dkms status"...
> >> but I still get "VMware Tools is not installed."  and
> >> copy/paste does not work. Should it?
> >
> > Can you verify that vmware-guestd is running? The UI's Tools status
> notification comes from messages sent by vmware-guestd.
> >
> > Are you using a console or are you within an X11 session? Can you
> verify that vmware-user is running?
>
> X11. Yep, "ps x" shows both are running.

OK, could you upload your VMX log (vmware.log) as well as the vmware-user and vmware-guestd logs? You can obtain the latter by editing the tools.conf file (it's probably in /etc/vmware-tools) and adding the following two lines:

log = "true"
log.file = "/path/to/file"

After that, the processes should start logging themselves to /path/to/file and /path/to/file.<pid> (vmware-user typically can't write to the same log as vmware-guestd). I'd especially like to see the logging done at startup for both processes, so after you've enabled logging, restart them.

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

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

Joshua Daniel Franklin wrote:
> Hello, I'm running VMWare Fusion 2 beta and trying to get
> open-vm-tools installed in a Fedora 9 VM.
> 
> I first tried the download on the main page but ran into the
> procps header problem, so I rebuilt the Fedora 8 RPM at
> http://www.poolshark.org/dkms-open-vm-tools/
> dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm	

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:

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

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

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

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

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

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

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.

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

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

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

Nice catch.

I confirm this is a libicu problem. Reverting back from libicu 3.8.1 to 
3.8 makes vmware-guestd and vmware-user happy.

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

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

> > 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.
>
> Nice catch.
>
> I confirm this is a libicu problem. Reverting back from libicu 3.8.1 to
> 3.8 makes vmware-guestd and vmware-user happy.

Cool. What's the next step? Should we do some debugging on our end, or would it be best to file a bug against libicu?

If you do file a libicu bug, please cc me on it.

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

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

Adar Dembo wrote:
>>> 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.
>> Nice catch.
>>
>> I confirm this is a libicu problem. Reverting back from libicu 3.8.1 to
>> 3.8 makes vmware-guestd and vmware-user happy.
> 
> Cool. What's the next step? Should we do some debugging on our end, or would it be best to file a bug against libicu?
> 
> If you do file a libicu bug, please cc me on it.

Was trying to get a trace from the hang, but now I'm having problems 
reproducing the bug. I might have misdiagnosed the libicu cause. Sorry 
for the confusion, things are working better now both with F-9 and 
rawhide. dkms on poolshark.org is updated with some packaging fixes. Not 
sure what happened, still looking into it.

-denis

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

[Joshua D. F. <jdf...@gm...>]

On Mon, Sep 8, 2008 at 6:45 AM, Denis Leroy wrote:
> Was trying to get a trace from the hang, but now I'm having problems
> reproducing the bug. I might have misdiagnosed the libicu cause. Sorry
> for the confusion, things are working better now both with F-9 and
> rawhide. dkms on poolshark.org is updated with some packaging fixes. Not
> sure what happened, still looking into it.

Denis,

Thanks very much. I rebuilt the latest dkms rpm on my Fedora 9 VM. It installed
fine and in GNOME I was able to drag over a PNG file without any trouble, and
the "tools are not installed" message is gone. However, I still have
to click inside
the window to get a mouse (using either X11 or gpm) which it sounds like
you're working on. I'd be happy to test again on Fedora 9 running in
Fusion 2 beta when needed. Adar: I turned on logging, but I'm guessing you
don't need it anymore.

Joshua

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

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

Joshua Daniel Franklin wrote:
> On Mon, Sep 8, 2008 at 6:45 AM, Denis Leroy wrote:
>> Was trying to get a trace from the hang, but now I'm having problems
>> reproducing the bug. I might have misdiagnosed the libicu cause. Sorry
>> for the confusion, things are working better now both with F-9 and
>> rawhide. dkms on poolshark.org is updated with some packaging fixes. Not
>> sure what happened, still looking into it.
> 
> Denis,
> 
> Thanks very much. I rebuilt the latest dkms rpm on my Fedora 9 VM. It installed
> fine and in GNOME I was able to drag over a PNG file without any trouble, and
> the "tools are not installed" message is gone. However, I still have
> to click inside
> the window to get a mouse (using either X11 or gpm) which it sounds like
> you're working on. I'd be happy to test again on Fedora 9 running in
> Fusion 2 beta when needed. Adar: I turned on logging, but I'm guessing you
> don't need it anymore.
> 

Joshua,

the mouse problem is not an open-vm-tools issue. It's the xorg vmmouse 
driver that's broken in XOrg 7.3. See

https://bugzilla.redhat.com/show_bug.cgi?id=434807

There is a workaround however. You'll have to create a 
/etc/X11/xorg.conf file manually (or with the system-config-display 
tool), and add a mouse section to force the vmmouse driver to load:

Section "InputDevice"
         Identifier  "Mouse0"
         Driver      "vmmouse"
         Option      "Device"      "/dev/input/mice"
EndSection

And add the following lines inside the "ServerLayout" section:
      Option "AutoAddDevices" "off"
      InputDevice    "Mouse0" "CorePointer

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.

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

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

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

Here's a patch to address the three make install issues. Let me know if it works for you and I'll apply it to the git repo.