open-vm-tools-devel — List for open-vm-tools developer discussions.

Re: Open vm tools for Ubuntu 8.0.4

[Praki P. <pra...@gm...>]

Adar,

Thanks for your response. The version of ESX I am running doesn't support
Ubuntu 8.0.4 but I have been running it for a few months now and the only
problem I have run into is the display resolution.

I will look into ESX update release. Thank you.

Praki

On Sun, Dec 14, 2008 at 12:42 AM, Adar Dembo <ad...@vm...> wrote:

> > I have a Ubuntu 8.0.4 guest running on ESX 3.5. Unfortunately, I have
> > not been able to install vmware tools in this guest vm. I have
> > downloaded the latest open vm tools. When I run vmware-config-tools.pl,
> > it is unable to properly detect X server version. It prints the
> > following message.
> >
> >
> > Detected X.org version 0.0.0.
> >
> >
> >
> > No drivers for X.org version: 0.0.0.
> >
> >
> > I am unable to configure my display resolution correctly and this
> > proving to be a major issue. I really need to get this done.
> >
> > Any suggestions or work around for this problem?
>
> The VMware Tools configurator (vmware-config-tools.pl) isn't part of the
> open-vm-tools. What you're trying to do is install the regular VMware Tools,
> most likely the ones that shipped with ESX 3.5. We can try to help you with
> them too, but you'll probably have more luck filing a support request or
> posting in the VMware forums.
>
> >From what I recall, the release of ESX 3.5 didn't include support for
> Ubuntu 8.04. That came later, in an ESX 3.5 update release or patch. Could
> you make sure that the version of ESX 3.5 you're using supports Ubuntu 8.04,
> and that the Tools you're trying to install are from that version?
>
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>

RE: Open vm tools for Ubuntu 8.0.4

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

> I have a Ubuntu 8.0.4 guest running on ESX 3.5. Unfortunately, I have
> not been able to install vmware tools in this guest vm. I have
> downloaded the latest open vm tools. When I run vmware-config-tools.pl,
> it is unable to properly detect X server version. It prints the
> following message.
> 
> 
> Detected X.org version 0.0.0.
> 
> 
> 
> No drivers for X.org version: 0.0.0.
> 
> 
> I am unable to configure my display resolution correctly and this
> proving to be a major issue. I really need to get this done.
> 
> Any suggestions or work around for this problem?

The VMware Tools configurator (vmware-config-tools.pl) isn't part of the open-vm-tools. What you're trying to do is install the regular VMware Tools, most likely the ones that shipped with ESX 3.5. We can try to help you with them too, but you'll probably have more luck filing a support request or posting in the VMware forums. 

>From what I recall, the release of ESX 3.5 didn't include support for Ubuntu 8.04. That came later, in an ESX 3.5 update release or patch. Could you make sure that the version of ESX 3.5 you're using supports Ubuntu 8.04, and that the Tools you're trying to install are from that version?

Open vm tools for Ubuntu 8.0.4

[Praki P. <pra...@gm...>]

Hi,

I have a Ubuntu 8.0.4 guest running on ESX 3.5. Unfortunately, I have not
been able to install vmware tools in this guest vm. I have downloaded the
latest open vm tools. When I run vmware-config-tools.pl, it is unable to
properly detect X server version. It prints the following message.


Detected X.org version 0.0.0.



No drivers for X.org version: 0.0.0.


I am unable to configure my display resolution correctly and this proving to
be a major issue. I really need to get this done.

Any suggestions or work around for this problem?

Thanks,
P

We wish you a merry Christmaas!

[Gab M. <dis...@pr...>]

Help yourself on Chrisstmas!
   http://cid-e34289da7953ec7b.spaces.live.com/blog/cns!E34289DA7953EC7B!106.entry
 



Not that. It's something else. She paused, then twisted her
hands in a dramatic gesture. She looked he had filled with
water to heat for the benefit it. Malcolm rose with it,
hastened to his boat, him. He looked at kirsten lindstrom.
tou blamed.

Santa Claus and Christmaas night!

[Fairy S. <div...@we...>]

WOW! Santa Claus try our meds and fuck houssewife and her daughter!

http://cid-9efe37c9f5f5ddb3.spaces.live.com/blog/cns!9EFE37C9F5F5DDB3!106.entry
	


Of halfpitying, halfamused toleration was vaguely his ten
pigs took the fattest one for tithes, where is it? Down
in ever such a hole, under the do get down, poirot. Dr.
carelli will be here us consider another point. In the case
of pondicherry,.

Re: Using VMCI in the kernel

[Min Xu (Hsu) <mi...@vm...>]

On Fri, 05 Dec 2008 Cam Macdonell wrote :
> That is interesting.  Linux has a new feature in 2.6.27 called kernel 
> shared memory that merges identical pages and marks them COW.  If a 
> write occurs, then those pages are no longer shared and the writing VM 
> gets their own copy.

At high level, this is what we do as well. We may have different ways to
detect identical pages. But I am not an expert on this.

> If you can tell me, how does VMware handle it?  If VM1 changes one of 
> these shared pages then does that VM get its own copy of it?  What I 
> want is if one VM writes to a page, I want the other VM to see the 
> changes.  If your product can do that, then I would be interested.

No, VM1 write to the page, VM1 gets its own copy. Other VMs don't see
the update. Again, IMHO, if an update is visible to other VMs, the isolation
property of a VM is no more. If you want to a writeable cache for files,
you start to deal with consistency issues between writes. Things seem to
get complicated quickly. Why do you need other VMs to see an update? Can
you use socket/datagram for that if the updates are rare?

Re: Using VMCI in the kernel

[Cam M. <ca...@cs...>]

Min Xu (Hsu) wrote:
> On Fri, 05 Dec 2008 Cam Macdonell wrote :
>> Min Xu (Hsu) wrote:
>>> On Fri, 05 Dec 2008 Cam Macdonell wrote :
>>>> I can certainly see how a datagram model has some advantages.  But, I'm 
>>>> trying to do caching and for this purpose using shared memory requires 
>>>> less concurrent programming (threads, etc) and it reduces unnecessary 
>>>> copying of the data.  I'm looking at VMs in the context of distributed 
>>>> high-performance computing.  Our VMs are disposable sandboxes in this 
>>>> use, so suspension and replay are not features we need.
>>> I see. This use case does make sense to me. Thanks a lot for sharing it.
>>> I wonder does the shared memory punch a hole in your sandboxes in that a
>>> incorrect program in one VM can change the shared memory in a way to
>>> crash other VMs? Perhaps the shared memory is readonly from the VMs?
>>>
>> The idea, whether it will work or not, is that the cache will only be 
>> used as an optimization.  The VMs will always have the regular file 
>> system API to access the files, but if the file is in the cache it will 
>> use that.  As for inconsistent data causing problems, it will require 
>> checks that prevent that from happening and synchronization to prevent 
>> multiple writers.
>>
>>> If you are caching a readonly FS, maybe there is a better way?
>> Not just readonly, but mostly reading.  I'm always interested in hearing 
>> of better ways!
> 
> Hi Cam,
> 
> I am certainly no expert on the problem you are dealing. But personally,
> I would imagine having shared memory between VMs may cause the sandboxing
> become ineffective. Deadlocks, rare conditions, etc. may happen if
> synchronization are done incorrectly. I am not saying datagram does not
> have these synchronization problems. The problem of distributed file
> system is inherently hard.

Certainly, problems may arise from lack of synchronization, but from 
there we'll have to figure out if they can be addressed as well.

> 
> For caching, I feel a better way is to let the virtual machine monitor
> deal with it transparently. On our product, we have transparent memory
> sharing between VMs. It means if two VMs are using two "virtual
> physical" memory pages that have identical contents, the monitor will
> make the two VMs use the same physical memory page. This is done without
> breaking isolation between VMs. So for caching, perhaps you can make sure
> each VM cache same data in same page offset so the monitor can back them
> using the same host physical memory? I don't know if we provide an API
> for the VM to "hint" the virtual machine monitor what pages maybe
> shared. But hinting is a possibility too.

Hi Min,

That is interesting.  Linux has a new feature in 2.6.27 called kernel 
shared memory that merges identical pages and marks them COW.  If a 
write occurs, then those pages are no longer shared and the writing VM 
gets their own copy.

If you can tell me, how does VMware handle it?  If VM1 changes one of 
these shared pages then does that VM get its own copy of it?  What I 
want is if one VM writes to a page, I want the other VM to see the 
changes.  If your product can do that, then I would be interested.

Thanks,
Cam

Re: Using VMCI in the kernel

[Min Xu (Hsu) <mi...@vm...>]

On Fri, 05 Dec 2008 Cam Macdonell wrote :
> Min Xu (Hsu) wrote:
> > On Fri, 05 Dec 2008 Cam Macdonell wrote :
> >> I can certainly see how a datagram model has some advantages.  But, I'm 
> >> trying to do caching and for this purpose using shared memory requires 
> >> less concurrent programming (threads, etc) and it reduces unnecessary 
> >> copying of the data.  I'm looking at VMs in the context of distributed 
> >> high-performance computing.  Our VMs are disposable sandboxes in this 
> >> use, so suspension and replay are not features we need.
> > 
> > I see. This use case does make sense to me. Thanks a lot for sharing it.
> > I wonder does the shared memory punch a hole in your sandboxes in that a
> > incorrect program in one VM can change the shared memory in a way to
> > crash other VMs? Perhaps the shared memory is readonly from the VMs?
> > 
> 
> The idea, whether it will work or not, is that the cache will only be 
> used as an optimization.  The VMs will always have the regular file 
> system API to access the files, but if the file is in the cache it will 
> use that.  As for inconsistent data causing problems, it will require 
> checks that prevent that from happening and synchronization to prevent 
> multiple writers.
> 
> > If you are caching a readonly FS, maybe there is a better way?
> 
> Not just readonly, but mostly reading.  I'm always interested in hearing 
> of better ways!

Hi Cam,

I am certainly no expert on the problem you are dealing. But personally,
I would imagine having shared memory between VMs may cause the sandboxing
become ineffective. Deadlocks, rare conditions, etc. may happen if
synchronization are done incorrectly. I am not saying datagram does not
have these synchronization problems. The problem of distributed file
system is inherently hard.

For caching, I feel a better way is to let the virtual machine monitor
deal with it transparently. On our product, we have transparent memory
sharing between VMs. It means if two VMs are using two "virtual
physical" memory pages that have identical contents, the monitor will
make the two VMs use the same physical memory page. This is done without
breaking isolation between VMs. So for caching, perhaps you can make sure
each VM cache same data in same page offset so the monitor can back them
using the same host physical memory? I don't know if we provide an API
for the VM to "hint" the virtual machine monitor what pages maybe
shared. But hinting is a possibility too.

thanks,
min

Re: Using VMCI in the kernel

[Cam M. <ca...@cs...>]

Min Xu (Hsu) wrote:
> On Fri, 05 Dec 2008 Cam Macdonell wrote :
>> I can certainly see how a datagram model has some advantages.  But, I'm 
>> trying to do caching and for this purpose using shared memory requires 
>> less concurrent programming (threads, etc) and it reduces unnecessary 
>> copying of the data.  I'm looking at VMs in the context of distributed 
>> high-performance computing.  Our VMs are disposable sandboxes in this 
>> use, so suspension and replay are not features we need.
> 
> I see. This use case does make sense to me. Thanks a lot for sharing it.
> I wonder does the shared memory punch a hole in your sandboxes in that a
> incorrect program in one VM can change the shared memory in a way to
> crash other VMs? Perhaps the shared memory is readonly from the VMs?
> 

The idea, whether it will work or not, is that the cache will only be 
used as an optimization.  The VMs will always have the regular file 
system API to access the files, but if the file is in the cache it will 
use that.  As for inconsistent data causing problems, it will require 
checks that prevent that from happening and synchronization to prevent 
multiple writers.

> If you are caching a readonly FS, maybe there is a better way?

Not just readonly, but mostly reading.  I'm always interested in hearing 
of better ways!

Cam

Re: Using VMCI in the kernel

[Min Xu (Hsu) <mi...@vm...>]

On Fri, 05 Dec 2008 Cam Macdonell wrote :
> I can certainly see how a datagram model has some advantages.  But, I'm 
> trying to do caching and for this purpose using shared memory requires 
> less concurrent programming (threads, etc) and it reduces unnecessary 
> copying of the data.  I'm looking at VMs in the context of distributed 
> high-performance computing.  Our VMs are disposable sandboxes in this 
> use, so suspension and replay are not features we need.

I see. This use case does make sense to me. Thanks a lot for sharing it.
I wonder does the shared memory punch a hole in your sandboxes in that a
incorrect program in one VM can change the shared memory in a way to
crash other VMs? Perhaps the shared memory is readonly from the VMs?

If you are caching a readonly FS, maybe there is a better way?

Re: Using VMCI in the kernel

[Cam M. <ca...@cs...>]

Min Xu (Hsu) wrote:
> On Thu, 04 Dec 2008 Cam Macdonell wrote :
>> Aaron Rolett wrote:
>>> Hi Cam,
>>>     Are you talking about the VMCI Sockets interface from within the 
>>> kernel on linux? If so ... I don't think anyone has tried this yet ... 
>>> but I *think* it should mostly work. One thing that might need a little 
>>> work is registering the dynamic address family value since that is 
>>> currently done through /dev/vsock in userspace. This is something I'd 
>>> like to try out when I have a chance.
>> Yup, within Linux.
>>
>>>         With regards to VMCI Sockets on windows in kernel mode ... we 
>>> don't currently have support for this.
>>  >
>>> Out of curiosity ... what are you trying use VMCI Sockets for?
>> I'm actually interested in the shared memory VMCI interface, not in the 
>> socket/datagram one at this point.  Because of this I am using WS 6.0.4 
>> due to shared memory's deprecation in 6.5 (and newer open-vm-tools).
>>
>> To answer your question, what I would like to do is use shared memory as 
>> a file cache between VMs on the same host that would all be accessing a 
>> remote file system.  In particular I'm working with Samba.  I was using 
>> fusesmb so I could work at user level, but fusesmb is flaky and doesn't 
>> seem to be an active project in terms of development.  So, I'm thinking 
>> of using the CIFS kernel module to work on my implementation.
> 
> Hi Cam,
> 

Hi Min,

Thanks for your thoughts,. You make good points and they made me think.

> Why use a deprecated API? 

I can only reply: Why deprecate an API people are using?

> I know shared memory maybe easier to program
> than datagram. But shared memory model "de-virtualize" your VM: make it
> hard to suspend/resume or record/replay a VM. Datagram at least force
> someone to deal with error conditions, like re-connect, timeout, etc.

I can certainly see how a datagram model has some advantages.  But, I'm 
trying to do caching and for this purpose using shared memory requires 
less concurrent programming (threads, etc) and it reduces unnecessary 
copying of the data.  I'm looking at VMs in the context of distributed 
high-performance computing.  Our VMs are disposable sandboxes in this 
use, so suspension and replay are not features we need.

Thanks again for your 2 cents :)
Cam

Re: Using VMCI in the kernel

[Min Xu (Hsu) <mi...@vm...>]

On Thu, 04 Dec 2008 Cam Macdonell wrote :
> Aaron Rolett wrote:
> > Hi Cam,
> >     Are you talking about the VMCI Sockets interface from within the 
> > kernel on linux? If so ... I don't think anyone has tried this yet ... 
> > but I *think* it should mostly work. One thing that might need a little 
> > work is registering the dynamic address family value since that is 
> > currently done through /dev/vsock in userspace. This is something I'd 
> > like to try out when I have a chance.
> 
> Yup, within Linux.
> 
> >         With regards to VMCI Sockets on windows in kernel mode ... we 
> > don't currently have support for this.
>  >
> > Out of curiosity ... what are you trying use VMCI Sockets for?
> 
> I'm actually interested in the shared memory VMCI interface, not in the 
> socket/datagram one at this point.  Because of this I am using WS 6.0.4 
> due to shared memory's deprecation in 6.5 (and newer open-vm-tools).
> 
> To answer your question, what I would like to do is use shared memory as 
> a file cache between VMs on the same host that would all be accessing a 
> remote file system.  In particular I'm working with Samba.  I was using 
> fusesmb so I could work at user level, but fusesmb is flaky and doesn't 
> seem to be an active project in terms of development.  So, I'm thinking 
> of using the CIFS kernel module to work on my implementation.

Hi Cam,

Why use a deprecated API? I know shared memory maybe easier to program
than datagram. But shared memory model "de-virtualize" your VM: make it
hard to suspend/resume or record/replay a VM. Datagram at least force
someone to deal with error conditions, like re-connect, timeout, etc.

Just my two cents.

thanks,
min

Re: Using VMCI in the kernel

[Cam M. <ca...@cs...>]

Aaron Rolett wrote:
> Hi Cam,
>     Are you talking about the VMCI Sockets interface from within the 
> kernel on linux? If so ... I don't think anyone has tried this yet ... 
> but I *think* it should mostly work. One thing that might need a little 
> work is registering the dynamic address family value since that is 
> currently done through /dev/vsock in userspace. This is something I'd 
> like to try out when I have a chance.

Yup, within Linux.

>         With regards to VMCI Sockets on windows in kernel mode ... we 
> don't currently have support for this.
 >
> Out of curiosity ... what are you trying use VMCI Sockets for?

I'm actually interested in the shared memory VMCI interface, not in the 
socket/datagram one at this point.  Because of this I am using WS 6.0.4 
due to shared memory's deprecation in 6.5 (and newer open-vm-tools).

To answer your question, what I would like to do is use shared memory as 
a file cache between VMs on the same host that would all be accessing a 
remote file system.  In particular I'm working with Samba.  I was using 
fusesmb so I could work at user level, but fusesmb is flaky and doesn't 
seem to be an active project in terms of development.  So, I'm thinking 
of using the CIFS kernel module to work on my implementation.

Cam

> 
> Aaron
> On Dec 3, 2008, at 10:54 AM, Cam Macdonell wrote:
> 
>>
>> Hi,
>>
>> I was curious if it is possible to use VMCI from the kernel?  I have a
>> kernel module that I would like to have communicate with another VM.
>> While some may brand this as insane.  I was curious if it is possible.
>>
>> Thanks,
>> Cam
>>
>> -------------------------------------------------------------------------
>> 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-devel mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

[ open-vm-tools-Tracker-2205584 ] unable to initialize blocking driver

[SourceForge.net <no...@so...>]

Tracker item #2205584, was opened at 2008-10-28 22:12
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: vmware-user
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Adam (aer0)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to initialize blocking driver

Initial Comment:
Ubuntu 8.1
After installing, tried to invoke vmware-user.  For the unable to initialize error message.  Mouse is locked in vm session, but resolution resizing seems to work.  

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2008-12-04 02:21

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-19 02:25

Message:
I'll set this to pending while I wait for an update, since I wasn't able to
reproduce the problem.

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-01 01:10

Message:
Hi Adam, I have a few questions:

. what is the distro / kernel you're using?
. is the vmblock kernel module loaded?
. are you running as root? If you're not, you should be running
"vmware-user-suid-wrapper" instead, and that binary should be suid root
(owned by root with mode 4755).

. for the crash issue, do you have gdb installed? If you do, could you run
vmware-user inside gdb and get a better stack trace (once it crashes,
running "bt" should give you better information)? Otherwise, could you
attach your vmware-user binary to the bug so I can try to reproduce it?

I just built the latest open-vm-tools code from git on an Ubuntu 8.04 VM
and vmware-user seems to be working fine (although I don't have the Unity
code compiled in).


----------------------------------------------------------------------

Comment By: Adam (aer0)
Date: 2008-10-28 22:54

Message:
Here is a stack trace from the invocation as root.  It works for about 1s
before crashing:

adam@cdl2:~$ vmware-user failed to initialize blocking driver.  
Error in the RPC recieve loop: RpcIn: Unable to send            
Another instance of VMwareUser may be running.                 //its
not... 

*** glibc detected *** vmware-user: free(): invalid pointer: 0x0966f3a0
***
======= Backtrace: =========                                              

/lib/tls/i686/cmov/libc.so.6[0xb74573f4]                                  

/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7459456]                      

/usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb770bc06]                        

vmware-user[0x804e26b]                                                    

vmware-user[0x804e368]                                                    

vmware-user[0x805641d]                                                    

vmware-user[0x8058ef6]                                                    

vmware-user[0x80575e9]                                                    

/usr/lib/libglib-2.0.so.0[0xb7703e26]                                     

/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb77036f8]      

/usr/lib/libglib-2.0.so.0[0xb7706da3]                                     

/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1d2)[0xb77072c2]              

/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0xb7c573a9]                   

vmware-user[0x8057375]                                                    

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb73fe685]          

vmware-user[0x804d211]                                                    

======= Memory map: ========                                              

08048000-080a6000 r-xp 00000000 08:01 820888    
/usr/local/bin/vmware-user
080a6000-080a7000 r--p 0005d000 08:01 820888    
/usr/local/bin/vmware-user
080a7000-080a8000 rw-p 0005e000 08:01 820888    
/usr/local/bin/vmware-user
080a8000-08136000 rw-p 080a8000 00:00 0                                   

09661000-096a4000 rw-p 09661000 00:00 0          [heap]                   

b70f1000-b70fe000 r-xp 00000000 08:01 33050      /lib/libgcc_s.so.1       

b70fe000-b70ff000 r--p 0000c000 08:01 33050      /lib/libgcc_s.so.1       

b70ff000-b7100000 rw-p 0000d000 08:01 33050      /lib/libgcc_s.so.1       

b7100000-b7121000 rw-p b7100000 00:00 0                                   

b7121000-b7200000 ---p b7121000 00:00 0                                   

b7203000-b720d000 r-xp 00000000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720d000-b720e000 r--p 00009000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720e000-b720f000 rw-p 0000a000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720f000-b7218000 r-xp 00000000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7218000-b7219000 r--p 00008000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7219000-b721a000 rw-p 00009000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b721a000-b7221000 r-xp 00000000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7221000-b7222000 r--p 00006000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7222000-b7223000 rw-p 00007000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7234000-b7315000 r--p 00000000 08:01 771203    
/usr/lib/locale/en_US.utf8/LC_COLLATE
b7315000-b7354000 r--p 00000000 08:01 771204    
/usr/lib/locale/en_US.utf8/LC_CTYPE
b7354000-b7357000 rw-p b7354000 00:00 0
b7357000-b7358000 r-xp 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7358000-b7359000 r--p 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7359000-b735a000 rw-p 00001000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b735a000-b7382000 r-xp 00000000 08:01 32880      /lib/libpcre.so.3.12.1
b7382000-b7383000 r--p 00027000 08:01 32880      /lib/libpcre.so.3.12.1
b7383000-b7384000 rw-p 00028000 08:01 32880      /lib/libpcre.so.3.12.1
b7384000-b7399000 r-xp 00000000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b7399000-b739a000 r--p 00014000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739a000-b739b000 rw-p 00015000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739b000-b739d000 rw-p b739b000 00:00 0
b739d000-b73c1000 r-xp 00000000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c1000-b73c3000 r--p 00023000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c3000-b73c4000 rw-p 00025000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c4000-b73c5000 rw-p b73c4000 00:00 0
b73c5000-b73c9000 r-xp 00000000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73c9000-b73ca000 rw-p 00003000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73ca000-b73cc000 r-xp 00000000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cc000-b73cd000 rw-p 00001000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cd000-b73e5000 r-xp 00000000 08:01 32892      /lib/libselinux.so.1
b73e5000-b73e6000 r--p 00017000 08:01 32892      /lib/libselinux.so.1
b73e6000-b73e7000 rw-p 00018000 08:01 32892      /lib/libselinux.so.1
b73e7000-b73e8000 rw-p b73e7000 00:00 0
b73e8000-b7540000 r-xp 00000000 08:01 50380      /lib/tl
[1]+  Aborted                 sudo vmware-user


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

Re: Using VMCI in the kernel

[Aaron R. <ar...@vm...>]

Hi Cam,
	Are you talking about the VMCI Sockets interface from within the  
kernel on linux? If so ... I don't think anyone has tried this yet ...  
but I *think* it should mostly work. One thing that might need a  
little work is registering the dynamic address family value since that  
is currently done through /dev/vsock in userspace. This is something  
I'd like to try out when I have a chance.

         With regards to VMCI Sockets on windows in kernel mode ... we  
don't currently have support for this.


Out of curiosity ... what are you trying use VMCI Sockets for?

Aaron
On Dec 3, 2008, at 10:54 AM, Cam Macdonell wrote:

>
> Hi,
>
> I was curious if it is possible to use VMCI from the kernel?  I have a
> kernel module that I would like to have communicate with another VM.
> While some may brand this as insane.  I was curious if it is possible.
>
> Thanks,
> Cam
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

Using VMCI in the kernel

[Cam M. <ca...@cs...>]

Hi,

I was curious if it is possible to use VMCI from the kernel?  I have a 
kernel module that I would like to have communicate with another VM. 
While some may brand this as insane.  I was curious if it is possible.

Thanks,
Cam

Re: [open-vm-tools-devel] VMWare Workstatiosn / 2.6.27 kernels

[Aaron R. <ar...@vm...>]

Ahh .... I misunderstood the problem ... I thought you were trying to  
install vsock in
a guest.
You are right that the problem does still
exist for the host and open-vm-tools cannot be installed there.

In this particular case ... the vmci module is different on the host  
and the guest.
The vsock module is the same code compiled with different defines. In  
particular the
vsock module on the host is compiled without SOCK_STREAM support because
the vmci module on the host does not have exactly the same support as  
the vmci module
in the guest.*

The change to get module versions is actually the same makefile change  
for both the
VMCI module on the host and the guest as well as the vsock module.

You can look at the patch Adar posted awhile back:
http://launchpadlibrarian.net/19950928/modversions.ubuntu.patch to see  
the open-vm-tools
version which should the same for the host and the guest (adding the  
postbuild makefile target  for vmci and a prebuild target
for vsock).

Really that just automates the copy of Module.symvers between the two  
directories like you do
in the shellscript you posted at:
https://bugzilla.novell.com/show_bug.cgi?id=447430

Hopefully that change will make it into a future WS patch release ...  
but until then it is probably
easiest to just manually copy the Module.symvers file.

*The VMCI module on the guest supports datagrams and queuepair  
primitives
while the host vmci module only supports datagram primitives.

Hope that helps clarify things a bit,
Aaron

On Dec 2, 2008, at 12:31 AM, Dominique Leuenberger wrote:

> Aaron,
>
> No problem for some delays. I hope you enjoyed your holiday.
>
>>>> On 12/1/2008 at 8:11 PM, Aaron Rolett <ar...@vm...> wrote:
>> Dominique,
>>    Apologies for the delay in my response ... I was on vacation last
>
>> week.
>>
>> Unfortunately my change did not make it into the workstation 6.5.1
>> release but
>> is in the latest open-vm-tools release (11-18)
>>
>> The changes are only makefile related. In particular the changes are
> in:
>> open-vm-tools-2008.11.18-130226/modules/linux/vsock/Makefile.kernel
>> open-vm-tools-2008.11.18-130226/modules/linux/vsock/Makefile
>> open-vm-tools-2008.11.18-130226/modules/linux/vmci/Makefile.kernel
>> open-vm-tools-2008.11.18-130226/modules/linux/vmci/Makefile
>>
>> Hopefully the change will make it into the next patch release for
> WS.
>>
>> Let me know if there are more issues,
>> Aaron
>>
>
> Well, to 'my' understanding the open-vm-tools are to be installed on a
> virtual machine (inside a guest) whereas the report I pointed out in  
> the
> mail is more about the host system not having the capabilities it  
> should
> provide for installation.
>
> Would you generally advise to install open-vm-tools on the host and  
> the
> guest?
>
> Dominique

Re: [open-vm-tools-devel] VMWare Workstatiosn / 2.6.27 kernels

[Dominique L. <Dom...@TM...>]

Aaron,

No problem for some delays. I hope you enjoyed your holiday.

>>> On 12/1/2008 at 8:11 PM, Aaron Rolett <ar...@vm...> wrote:
> Dominique,
>     Apologies for the delay in my response ... I was on vacation last
 
> week.
> 
> Unfortunately my change did not make it into the workstation 6.5.1  
> release but
> is in the latest open-vm-tools release (11-18)
> 
> The changes are only makefile related. In particular the changes are
in:
> open-vm-tools-2008.11.18-130226/modules/linux/vsock/Makefile.kernel
> open-vm-tools-2008.11.18-130226/modules/linux/vsock/Makefile
> open-vm-tools-2008.11.18-130226/modules/linux/vmci/Makefile.kernel
> open-vm-tools-2008.11.18-130226/modules/linux/vmci/Makefile
> 
> Hopefully the change will make it into the next patch release for
WS.
> 
> Let me know if there are more issues,
> Aaron
> 

Well, to 'my' understanding the open-vm-tools are to be installed on a
virtual machine (inside a guest) whereas the report I pointed out in the
mail is more about the host system not having the capabilities it should
provide for installation.

Would you generally advise to install open-vm-tools on the host and the
guest?

Dominique

Re: [open-vm-tools-devel] VMWare Workstatiosn / 2.6.27 kernels

[Aaron R. <ar...@vm...>]

Dominique,
    Apologies for the delay in my response ... I was on vacation last  
week.

Unfortunately my change did not make it into the workstation 6.5.1  
release but
is in the latest open-vm-tools release (11-18)

The changes are only makefile related. In particular the changes are in:
open-vm-tools-2008.11.18-130226/modules/linux/vsock/Makefile.kernel
open-vm-tools-2008.11.18-130226/modules/linux/vsock/Makefile
open-vm-tools-2008.11.18-130226/modules/linux/vmci/Makefile.kernel
open-vm-tools-2008.11.18-130226/modules/linux/vmci/Makefile

Hopefully the change will make it into the next patch release for WS.

Let me know if there are more issues,
Aaron

On Nov 26, 2008, at 7:06 AM, Dominique Leuenberger wrote:

>>>> On 10/21/2008 at 6:51 PM, Aaron Rolett <ar...@vm...> wrote:
>> Dominique,
>>      The vsock module warning messages have always been there (its
>
>> been on our list of things to cleanup for awhile). They appear
> because
>> the vsock build has no knowledge of the vmci module build even though
>
>> vsock depends on vmci symbols. I believe that the kernel module
> loader
>> changed sometime before 2.6.27 to prevent modules with unknown
> symbols
>> from loading if the kernel was built with CONFIG_MODVERSIONS. This is
>
>> something I was going to look into internally but haven't had a
> chance
>> to test out yet.
>> The reporters have seen the following from dmesg:
>> home/user/vmxnet3h/hosted08/bora# insmod build/obj-x64/ws/modules/
>> local/2.6.27-4-generic/vsock/vsock.ko
>> insmod: error inserting 'build/obj-x64/ws/modules/local/2.6.27-4-
>> generic/vsock/vsock.ko': -1 Unknown symbol in module
>>
>> A quick test to see if this is the problem would be to:
>> 1. Build the vmci module
>> 2. Copy Module.symvers from vmci => vsock
>> 3. Build vsock
>> 4. Try loading the module.
>>
>> All of that being said, ws shouldn't be segfaulting on startup (it
>> should be able to load and run fine without the vsock module ... you
>
>> just will not be able to use vmci sockets).
>>
>> A couple of questions:
>> 1. Which process specifically is dying? vmware / vmware-vmx something
>
>> else?
>> 2. Can you get us a core dump from the segfault?
>> 3. Can you upload the relevant logs. On my machine they live in /tmp/
>
>> vmware-${USER} and <VM Directory>/vmware.log
>> 4. Any other relevant debugging information you can think of.
>>
>
> Aaron,
>
> In reference to the mail from Oct 21 on the open-vm-tools mailing  
> list,
> I wanted to ask if you know about anything that is going to change in
> the next days / weeks / months?
>
> As openSUSE 11.1 is due to be released, I hear more and more requests
> from users with failing module compilations, due to this error (last  
> one
> was at https://bugzilla.novell.com/show_bug.cgi?id=447430 )
>
> I hoped at least that the new VM WS 6.5.1 would solve something in  
> this
> respect, but it did not :(
>
> Thanks for your thoughts,
> Dominique
>
>

[ open-vm-tools-Tracker-1813024 ] checkvm compile fails

[SourceForge.net <no...@so...>]

Tracker item #1813024, was opened at 2007-10-13 15:05
Message generated for change (Settings changed) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1813024&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: checkvm
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: checkvm compile fails

Initial Comment:
Checkvm fails to compile (see error message below).

./configure --prefix=/usr --disable-multimon --without-x
make LDFLAGS=-liconv all

Unfortunately upgrading to a newer gcc is at the moment not possible.

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----------------------------------
gcc -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/usr --localstatedir=/var
--enable-shared --enable-CONFIG_SHELL=/bin/bash --enable-threads=posix
--with-slibdir=/lib --enable-__cxa_atexit --enable-clocale=gnu
--enable-languages=c,c++,objc --disable-nls i586-pc-linux-gnu
Thread model: posix
gcc version 3.3.2
-----------------------------------
ld -v
GNU ld version 2.16.1
-----------------------------------
glibc 2.3.2
-----------------------------------
[ cut the stuff with worked ]
make[1]: Entering directory
`/data/build/tmp/open-vm-tools-2007.10.08-SNAPSHOT/checkvm'
gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\"
-DPACKAGE_VERSION=\"2007.10.08-SNAPSHOT\"
-DPACKAGE_STRING=\"open-vm-tools\ 2007.10.08-SNAPSHOT\"
-DPACKAGE_BUGREPORT=\"ope...@li...\"
-DPACKAGE=\"open-vm-tools\" -DVERSION=\"2007.10.08-SNAPSHOT\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DX_DISPLAY_MISSING=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_WCHAR_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_CRYPT_H=1 -DHAVE_SYS_IO_H=1
-DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE__BOOL=1
-DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1
-DHAVE_LSEEK=1 -DNO_MULTIMON=1 -I.    -Wall -Werror -Wno-unknown-pragmas
-Wno-uninitialized -fno-strict-aliasing -Wno-unused-value -DVMX86_TOOLS
-I/data/build/tmp/open-vm-tools-2007.10.08-SNAPSHOT/lib/include
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -D_SVID_SOURCE -DUSING_AUTOCONF=1 -MT checkvm.o -MD -MP -MF
.deps/checkvm.Tpo -c -o checkvm.o checkvm.c
checkvm.c: In function `getVersion':
checkvm.c:80: error: can't find a register in class `BREG' while reloading
`asm'
make[1]: *** [checkvm.o] Error 1
make[1]: Leaving directory
`/data/build/tmp/open-vm-tools-2007.10.08-SNAPSHOT/checkvm'
make: *** [all-recursive] Error 1

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-11-24 02:32

Message:
Mike, we haven't added -nopie upstream, but enough people have complained
about this (here and in the Gentoo bug report) that we should look into
doing just that, or look at changing the affected checkvm.c code. I'll
reopen this bug.

For those seeing this bug report for the first time, there's a lot more
information available at the associated Gentoo bug report, which can be
found here: http://bugs.gentoo.org/show_bug.cgi?id=200376


----------------------------------------------------------------------

Comment By: Mike Auty (ikelos)
Date: 2007-11-26 11:04

Message:
Logged In: YES 
user_id=230582
Originator: NO

Sorry to check on this, but does that mean that -nopie has been added to
the CFLAGS in the Makefile, or could other users still run into this
problem?  If it has been added, is it enabled at all times, or just when
being built against a hardened config?  Certainly for the Gentoo
distribution we can add in a Makefile patch, I just would have thought it
more beneficial to have a solid fix upstream...

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2007-11-26 10:38

Message:
Logged In: YES 
user_id=18318
Originator: NO

Closing as "WORKSFORME"...

----------------------------------------------------------------------

Comment By: Heiko Zuerker (smiley73)
Date: 2007-11-26 09:23

Message:
Logged In: YES 
user_id=112133
Originator: YES

Hey,

I ended up using this to get the compile running:
CC="gcc -U_FORTIFY_SOURCE -fno-PIE" LDFLAGS=-liconv ./configure
--prefix=/usr --without-x
make all modules

-U_FORTIFY_SOURCE was necessary because there are a lot of compiler
warnings and we treat warnings as errors.
-fno-PIE was necessary because of the error in the original support
request.

It may be required on hardened systems in general.
Devil-Linux uses the hardened settings from "Hardened Linux from Scratch",
which may be the base or similar to other hardened distros.

Heiko


----------------------------------------------------------------------

Comment By: Mike Auty (ikelos)
Date: 2007-11-26 04:24

Message:
Logged In: YES 
user_id=230582
Originator: NO

Hiya, we've had a report of one of our users patching the Makefile in
checkvm to include I tried to CFLAGS+="-nopie" and this appears to solve
the problem.  It would be nice to find a way of only enabling this if
required...

----------------------------------------------------------------------

Comment By: Heiko Zuerker (smiley73)
Date: 2007-10-16 14:06

Message:
Logged In: YES 
user_id=112133
Originator: YES

I hate to admit it, but the problem seems to be Devil-Linux specific.
I disabled all security features and now it compiles fine.
I'm not sure where the problem is, this may take quite some time to figure
it out. It may be SSP or PIE related.

If you want you can close this tracker.

Heiko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1813024&group_id=204462

[ open-vm-tools-Tracker-1813024 ] checkvm compile fails

[SourceForge.net <no...@so...>]

Tracker item #1813024, was opened at 2007-10-13 15:05
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1813024&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: checkvm
Group: None
Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Heiko Zuerker (smiley73)
Assigned to: Nobody/Anonymous (nobody)
Summary: checkvm compile fails

Initial Comment:
Checkvm fails to compile (see error message below).

./configure --prefix=/usr --disable-multimon --without-x
make LDFLAGS=-liconv all

Unfortunately upgrading to a newer gcc is at the moment not possible.

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----------------------------------
gcc -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/usr --localstatedir=/var
--enable-shared --enable-CONFIG_SHELL=/bin/bash --enable-threads=posix
--with-slibdir=/lib --enable-__cxa_atexit --enable-clocale=gnu
--enable-languages=c,c++,objc --disable-nls i586-pc-linux-gnu
Thread model: posix
gcc version 3.3.2
-----------------------------------
ld -v
GNU ld version 2.16.1
-----------------------------------
glibc 2.3.2
-----------------------------------
[ cut the stuff with worked ]
make[1]: Entering directory
`/data/build/tmp/open-vm-tools-2007.10.08-SNAPSHOT/checkvm'
gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\"
-DPACKAGE_VERSION=\"2007.10.08-SNAPSHOT\"
-DPACKAGE_STRING=\"open-vm-tools\ 2007.10.08-SNAPSHOT\"
-DPACKAGE_BUGREPORT=\"ope...@li...\"
-DPACKAGE=\"open-vm-tools\" -DVERSION=\"2007.10.08-SNAPSHOT\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DX_DISPLAY_MISSING=1 -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DHAVE_WCHAR_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_CRYPT_H=1 -DHAVE_SYS_IO_H=1
-DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE__BOOL=1
-DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1
-DHAVE_LSEEK=1 -DNO_MULTIMON=1 -I.    -Wall -Werror -Wno-unknown-pragmas
-Wno-uninitialized -fno-strict-aliasing -Wno-unused-value -DVMX86_TOOLS
-I/data/build/tmp/open-vm-tools-2007.10.08-SNAPSHOT/lib/include
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -D_SVID_SOURCE -DUSING_AUTOCONF=1 -MT checkvm.o -MD -MP -MF
.deps/checkvm.Tpo -c -o checkvm.o checkvm.c
checkvm.c: In function `getVersion':
checkvm.c:80: error: can't find a register in class `BREG' while reloading
`asm'
make[1]: *** [checkvm.o] Error 1
make[1]: Leaving directory
`/data/build/tmp/open-vm-tools-2007.10.08-SNAPSHOT/checkvm'
make: *** [all-recursive] Error 1

----------------------------------------------------------------------

Comment By: Adar Dembo (adembo)
Date: 2008-11-24 02:32

Message:
Mike, we haven't added -nopie upstream, but enough people have complained
about this (here and in the Gentoo bug report) that we should look into
doing just that, or look at changing the affected checkvm.c code. I'll
reopen this bug.

For those seeing this bug report for the first time, there's a lot more
information available at the associated Gentoo bug report, which can be
found here: http://bugs.gentoo.org/show_bug.cgi?id=200376


----------------------------------------------------------------------

Comment By: Mike Auty (ikelos)
Date: 2007-11-26 11:04

Message:
Logged In: YES 
user_id=230582
Originator: NO

Sorry to check on this, but does that mean that -nopie has been added to
the CFLAGS in the Makefile, or could other users still run into this
problem?  If it has been added, is it enabled at all times, or just when
being built against a hardened config?  Certainly for the Gentoo
distribution we can add in a Makefile patch, I just would have thought it
more beneficial to have a solid fix upstream...

----------------------------------------------------------------------

Comment By: ECL (sopwith)
Date: 2007-11-26 10:38

Message:
Logged In: YES 
user_id=18318
Originator: NO

Closing as "WORKSFORME"...

----------------------------------------------------------------------

Comment By: Heiko Zuerker (smiley73)
Date: 2007-11-26 09:23

Message:
Logged In: YES 
user_id=112133
Originator: YES

Hey,

I ended up using this to get the compile running:
CC="gcc -U_FORTIFY_SOURCE -fno-PIE" LDFLAGS=-liconv ./configure
--prefix=/usr --without-x
make all modules

-U_FORTIFY_SOURCE was necessary because there are a lot of compiler
warnings and we treat warnings as errors.
-fno-PIE was necessary because of the error in the original support
request.

It may be required on hardened systems in general.
Devil-Linux uses the hardened settings from "Hardened Linux from Scratch",
which may be the base or similar to other hardened distros.

Heiko


----------------------------------------------------------------------

Comment By: Mike Auty (ikelos)
Date: 2007-11-26 04:24

Message:
Logged In: YES 
user_id=230582
Originator: NO

Hiya, we've had a report of one of our users patching the Makefile in
checkvm to include I tried to CFLAGS+="-nopie" and this appears to solve
the problem.  It would be nice to find a way of only enabling this if
required...

----------------------------------------------------------------------

Comment By: Heiko Zuerker (smiley73)
Date: 2007-10-16 14:06

Message:
Logged In: YES 
user_id=112133
Originator: YES

I hate to admit it, but the problem seems to be Devil-Linux specific.
I disabled all security features and now it compiles fine.
I'm not sure where the problem is, this may take quite some time to figure
it out. It may be SSP or PIE related.

If you want you can close this tracker.

Heiko

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1813024&group_id=204462

[ open-vm-tools-Tracker-2301228 ] Build fails with --disable-multimon in unity

[SourceForge.net <no...@so...>]

Tracker item #2301228, was opened at 2008-11-16 15:15
Message generated for change (Comment added) made by aspecial
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Brooks (aspecial)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails with --disable-multimon in unity

Initial Comment:
The build of version 2008.10.10 with --disable-multimon (no xinerama support) and with Unity enabled fails in lib/unity/unityPlatformX11.c due to extensive use of the header, functions, and structures from xinerama not contained within #ifndef NO_MULTIMON - making a build with unity and without xinerama impossible. Due to use of structures from xinerama, it's too much for me to resolve myself.

If this isn't something that is intended to be fixed (i.e. a dependency will be made on xinerama), let me know and i'll get the gentoo ebuild updated accordingly - currently it tries to use --disable-multimon whenever xinerama isn't available/enabled.

----------------------------------------------------------------------

>Comment By: John Brooks (aspecial)
Date: 2008-11-19 04:24

Message:
Sounds good. I've filed a gentoo bug to this effect, to have a dependency
added for xinerama when unity is enabled. Thanks.

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-17 20:56

Message:
Hi John,

To the best of my knowledge, Unity depends on the multimon functionality,
so I guess you'll need to update the ebuild. I'll keep this bug open to add
a similar check in the configure script itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2301228&group_id=204462

[ open-vm-tools-Tracker-2205584 ] unable to initialize blocking driver

[SourceForge.net <no...@so...>]

Tracker item #2205584, was opened at 2008-10-28 15:12
Message generated for change (Settings changed) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: vmware-user
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Adam (aer0)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to initialize blocking driver

Initial Comment:
Ubuntu 8.1
After installing, tried to invoke vmware-user.  For the unable to initialize error message.  Mouse is locked in vm session, but resolution resizing seems to work.  

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-18 18:25

Message:
I'll set this to pending while I wait for an update, since I wasn't able to
reproduce the problem.

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-10-31 18:10

Message:
Hi Adam, I have a few questions:

. what is the distro / kernel you're using?
. is the vmblock kernel module loaded?
. are you running as root? If you're not, you should be running
"vmware-user-suid-wrapper" instead, and that binary should be suid root
(owned by root with mode 4755).

. for the crash issue, do you have gdb installed? If you do, could you run
vmware-user inside gdb and get a better stack trace (once it crashes,
running "bt" should give you better information)? Otherwise, could you
attach your vmware-user binary to the bug so I can try to reproduce it?

I just built the latest open-vm-tools code from git on an Ubuntu 8.04 VM
and vmware-user seems to be working fine (although I don't have the Unity
code compiled in).


----------------------------------------------------------------------

Comment By: Adam (aer0)
Date: 2008-10-28 15:54

Message:
Here is a stack trace from the invocation as root.  It works for about 1s
before crashing:

adam@cdl2:~$ vmware-user failed to initialize blocking driver.  
Error in the RPC recieve loop: RpcIn: Unable to send            
Another instance of VMwareUser may be running.                 //its
not... 

*** glibc detected *** vmware-user: free(): invalid pointer: 0x0966f3a0
***
======= Backtrace: =========                                              

/lib/tls/i686/cmov/libc.so.6[0xb74573f4]                                  

/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7459456]                      

/usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb770bc06]                        

vmware-user[0x804e26b]                                                    

vmware-user[0x804e368]                                                    

vmware-user[0x805641d]                                                    

vmware-user[0x8058ef6]                                                    

vmware-user[0x80575e9]                                                    

/usr/lib/libglib-2.0.so.0[0xb7703e26]                                     

/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb77036f8]      

/usr/lib/libglib-2.0.so.0[0xb7706da3]                                     

/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1d2)[0xb77072c2]              

/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0xb7c573a9]                   

vmware-user[0x8057375]                                                    

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb73fe685]          

vmware-user[0x804d211]                                                    

======= Memory map: ========                                              

08048000-080a6000 r-xp 00000000 08:01 820888    
/usr/local/bin/vmware-user
080a6000-080a7000 r--p 0005d000 08:01 820888    
/usr/local/bin/vmware-user
080a7000-080a8000 rw-p 0005e000 08:01 820888    
/usr/local/bin/vmware-user
080a8000-08136000 rw-p 080a8000 00:00 0                                   

09661000-096a4000 rw-p 09661000 00:00 0          [heap]                   

b70f1000-b70fe000 r-xp 00000000 08:01 33050      /lib/libgcc_s.so.1       

b70fe000-b70ff000 r--p 0000c000 08:01 33050      /lib/libgcc_s.so.1       

b70ff000-b7100000 rw-p 0000d000 08:01 33050      /lib/libgcc_s.so.1       

b7100000-b7121000 rw-p b7100000 00:00 0                                   

b7121000-b7200000 ---p b7121000 00:00 0                                   

b7203000-b720d000 r-xp 00000000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720d000-b720e000 r--p 00009000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720e000-b720f000 rw-p 0000a000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720f000-b7218000 r-xp 00000000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7218000-b7219000 r--p 00008000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7219000-b721a000 rw-p 00009000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b721a000-b7221000 r-xp 00000000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7221000-b7222000 r--p 00006000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7222000-b7223000 rw-p 00007000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7234000-b7315000 r--p 00000000 08:01 771203    
/usr/lib/locale/en_US.utf8/LC_COLLATE
b7315000-b7354000 r--p 00000000 08:01 771204    
/usr/lib/locale/en_US.utf8/LC_CTYPE
b7354000-b7357000 rw-p b7354000 00:00 0
b7357000-b7358000 r-xp 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7358000-b7359000 r--p 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7359000-b735a000 rw-p 00001000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b735a000-b7382000 r-xp 00000000 08:01 32880      /lib/libpcre.so.3.12.1
b7382000-b7383000 r--p 00027000 08:01 32880      /lib/libpcre.so.3.12.1
b7383000-b7384000 rw-p 00028000 08:01 32880      /lib/libpcre.so.3.12.1
b7384000-b7399000 r-xp 00000000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b7399000-b739a000 r--p 00014000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739a000-b739b000 rw-p 00015000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739b000-b739d000 rw-p b739b000 00:00 0
b739d000-b73c1000 r-xp 00000000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c1000-b73c3000 r--p 00023000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c3000-b73c4000 rw-p 00025000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c4000-b73c5000 rw-p b73c4000 00:00 0
b73c5000-b73c9000 r-xp 00000000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73c9000-b73ca000 rw-p 00003000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73ca000-b73cc000 r-xp 00000000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cc000-b73cd000 rw-p 00001000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cd000-b73e5000 r-xp 00000000 08:01 32892      /lib/libselinux.so.1
b73e5000-b73e6000 r--p 00017000 08:01 32892      /lib/libselinux.so.1
b73e6000-b73e7000 rw-p 00018000 08:01 32892      /lib/libselinux.so.1
b73e7000-b73e8000 rw-p b73e7000 00:00 0
b73e8000-b7540000 r-xp 00000000 08:01 50380      /lib/tl
[1]+  Aborted                 sudo vmware-user


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

[ open-vm-tools-Tracker-2205584 ] unable to initialize blocking driver

[SourceForge.net <no...@so...>]

Tracker item #2205584, was opened at 2008-10-28 15:12
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam (aer0)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to initialize blocking driver

Initial Comment:
Ubuntu 8.1
After installing, tried to invoke vmware-user.  For the unable to initialize error message.  Mouse is locked in vm session, but resolution resizing seems to work.  

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-18 18:25

Message:
I'll set this to pending while I wait for an update, since I wasn't able to
reproduce the problem.

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-10-31 18:10

Message:
Hi Adam, I have a few questions:

. what is the distro / kernel you're using?
. is the vmblock kernel module loaded?
. are you running as root? If you're not, you should be running
"vmware-user-suid-wrapper" instead, and that binary should be suid root
(owned by root with mode 4755).

. for the crash issue, do you have gdb installed? If you do, could you run
vmware-user inside gdb and get a better stack trace (once it crashes,
running "bt" should give you better information)? Otherwise, could you
attach your vmware-user binary to the bug so I can try to reproduce it?

I just built the latest open-vm-tools code from git on an Ubuntu 8.04 VM
and vmware-user seems to be working fine (although I don't have the Unity
code compiled in).


----------------------------------------------------------------------

Comment By: Adam (aer0)
Date: 2008-10-28 15:54

Message:
Here is a stack trace from the invocation as root.  It works for about 1s
before crashing:

adam@cdl2:~$ vmware-user failed to initialize blocking driver.  
Error in the RPC recieve loop: RpcIn: Unable to send            
Another instance of VMwareUser may be running.                 //its
not... 

*** glibc detected *** vmware-user: free(): invalid pointer: 0x0966f3a0
***
======= Backtrace: =========                                              

/lib/tls/i686/cmov/libc.so.6[0xb74573f4]                                  

/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7459456]                      

/usr/lib/libglib-2.0.so.0(g_free+0x36)[0xb770bc06]                        

vmware-user[0x804e26b]                                                    

vmware-user[0x804e368]                                                    

vmware-user[0x805641d]                                                    

vmware-user[0x8058ef6]                                                    

vmware-user[0x80575e9]                                                    

/usr/lib/libglib-2.0.so.0[0xb7703e26]                                     

/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb77036f8]      

/usr/lib/libglib-2.0.so.0[0xb7706da3]                                     

/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1d2)[0xb77072c2]              

/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0xb7c573a9]                   

vmware-user[0x8057375]                                                    

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb73fe685]          

vmware-user[0x804d211]                                                    

======= Memory map: ========                                              

08048000-080a6000 r-xp 00000000 08:01 820888    
/usr/local/bin/vmware-user
080a6000-080a7000 r--p 0005d000 08:01 820888    
/usr/local/bin/vmware-user
080a7000-080a8000 rw-p 0005e000 08:01 820888    
/usr/local/bin/vmware-user
080a8000-08136000 rw-p 080a8000 00:00 0                                   

09661000-096a4000 rw-p 09661000 00:00 0          [heap]                   

b70f1000-b70fe000 r-xp 00000000 08:01 33050      /lib/libgcc_s.so.1       

b70fe000-b70ff000 r--p 0000c000 08:01 33050      /lib/libgcc_s.so.1       

b70ff000-b7100000 rw-p 0000d000 08:01 33050      /lib/libgcc_s.so.1       

b7100000-b7121000 rw-p b7100000 00:00 0                                   

b7121000-b7200000 ---p b7121000 00:00 0                                   

b7203000-b720d000 r-xp 00000000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720d000-b720e000 r--p 00009000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720e000-b720f000 rw-p 0000a000 08:01 50397     
/lib/tls/i686/cmov/libnss_files-2.8.90.so
b720f000-b7218000 r-xp 00000000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7218000-b7219000 r--p 00008000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b7219000-b721a000 rw-p 00009000 08:01 50401     
/lib/tls/i686/cmov/libnss_nis-2.8.90.so  
b721a000-b7221000 r-xp 00000000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7221000-b7222000 r--p 00006000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7222000-b7223000 rw-p 00007000 08:01 50393     
/lib/tls/i686/cmov/libnss_compat-2.8.90.so
b7234000-b7315000 r--p 00000000 08:01 771203    
/usr/lib/locale/en_US.utf8/LC_COLLATE
b7315000-b7354000 r--p 00000000 08:01 771204    
/usr/lib/locale/en_US.utf8/LC_CTYPE
b7354000-b7357000 rw-p b7354000 00:00 0
b7357000-b7358000 r-xp 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7358000-b7359000 r--p 00000000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b7359000-b735a000 rw-p 00001000 08:01 748141    
/usr/lib/libxcb-xlib.so.0.0.0
b735a000-b7382000 r-xp 00000000 08:01 32880      /lib/libpcre.so.3.12.1
b7382000-b7383000 r--p 00027000 08:01 32880      /lib/libpcre.so.3.12.1
b7383000-b7384000 rw-p 00028000 08:01 32880      /lib/libpcre.so.3.12.1
b7384000-b7399000 r-xp 00000000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b7399000-b739a000 r--p 00014000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739a000-b739b000 rw-p 00015000 08:01 50391     
/lib/tls/i686/cmov/libnsl-2.8.90.so
b739b000-b739d000 rw-p b739b000 00:00 0
b739d000-b73c1000 r-xp 00000000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c1000-b73c3000 r--p 00023000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c3000-b73c4000 rw-p 00025000 08:01 747214    
/usr/lib/libexpat.so.1.5.2
b73c4000-b73c5000 rw-p b73c4000 00:00 0
b73c5000-b73c9000 r-xp 00000000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73c9000-b73ca000 rw-p 00003000 08:01 746986    
/usr/lib/libXdmcp.so.6.0.0
b73ca000-b73cc000 r-xp 00000000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cc000-b73cd000 rw-p 00001000 08:01 746975     /usr/lib/libXau.so.6.0.0
b73cd000-b73e5000 r-xp 00000000 08:01 32892      /lib/libselinux.so.1
b73e5000-b73e6000 r--p 00017000 08:01 32892      /lib/libselinux.so.1
b73e6000-b73e7000 rw-p 00018000 08:01 32892      /lib/libselinux.so.1
b73e7000-b73e8000 rw-p b73e7000 00:00 0
b73e8000-b7540000 r-xp 00000000 08:01 50380      /lib/tl
[1]+  Aborted                 sudo vmware-user


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2205584&group_id=204462

[ open-vm-tools-Tracker-2298353 ] vmware-user does not autostart

[SourceForge.net <no...@so...>]

Tracker item #2298353, was opened at 2008-11-16 04:46
Message generated for change (Settings changed) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: vmware-user
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: lucatrv (lucatrv)
Assigned to: Nobody/Anonymous (nobody)
Summary: vmware-user does not autostart

Initial Comment:
Ubuntu Intrepid 8.10
Although the vmware-user.desktop link is present in /etc/xdg/autostart , vmware-user does not start automatically at boot. So copy/past doesn't work.

This has a very quick fix: add the line line "Type=Application" in the file  vmware-user.desktop

$ cat vmware-user.desktop 
[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=vmware-user-suid-wrapper
Name=VMware User Agent
X-KDE-autostart-phase=1
NoDisplay=true

Now vmware-user starts at boot so copy/paste works.

Please add this very quick fix to the next release...

Thanks

PS. to improve your documentation page (http://open-vm-tools.wiki.sourceforge.net/Packaging) I think you should add under the vmhgfs paragraph (after the fstab description) a phrase telling that if one doesn't want that updatedb indexes all the shared folder it is necessary to add "vmhgfs" in the file /etc/updatedb.conf after "PRUNEFS=". In fact, this was automatically done by the old perl installer.


----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2008-11-18 18:24

Message:
This is fixed in the latest code refresh (2008.11.18).

----------------------------------------------------------------------

Comment By: Syd Logan (slogan621)
Date: 2008-11-17 00:07

Message:
Thanks, we ran into that fix a week or so ago and the fix you described
should be in an upcoming release.

----------------------------------------------------------------------

Comment By: lucatrv (lucatrv)
Date: 2008-11-16 13:50

Message:
Ops, sorry, I didn't notice it was mentioned already. So you can ignore the
last "PS" part of my post.

----------------------------------------------------------------------

Comment By: Ragavan S (ragavan_s)
Date: 2008-11-16 13:20

Message:
Thanks for submitting this. With regards to the documentation suggestion, I
think we already mention this in the vmhgfs section:

"We typically exclude vmhgfs from the locate database as crawling the
Shared Folders is time consuming. To do this, add "vmhgfs" to PRUNEFS
within updatedb's configuration file, typically found in
/etc/updatedb.conf"

Is this what you were suggesting or something else?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2298353&group_id=204462