Bugzilla Bug 122500

Hi, this will hopefully become a little tracker bug for people to test out
vmware-server and vmware-server-console ebuilds until they're happy that they
all work and can eventually be committed into portage.

Attachments to follow.

Created an attachment (id=79527) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.0.5

This should pretty much work for most systems, although obviously any testing
people can do would be most appreciated.

Notes:

It does not alter /etc/xinetd.conf, which currently only allows access from
localhost.

It does have security warnings about some precompiled perl binaries that are
installed, if anyone knows how to fixed these some advice would be deeply
appreciated.

It is based on the vmware-workstation ebuild, so the internal logic may not be
the best and some seemingly pointless things may be done by the ebuild.  Don't
be fooled, they probably really are pointless, please let me know and I'll try
and fix them.

I still haven't managed to get permissions sorted properly, so any user of the
linux box that can authenticate through pam will be accepted to connect to the
server.  They will not be able to run a virtual server (and in fact will
probably hang the server) unless they are in the vmware group.

Also this ebuild requires several auxiliary files, which I'll try and attach
next...

Created an attachment (id=79529) [details]
vmware-server auxiliary file - 90vmware-server

Created an attachment (id=79530) [details]
vmware-server auxiliary file - vmware.rc

Created an attachment (id=79531) [details]
vmware-server auxiliary file - vmware.xml

Created an attachment (id=79532) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config.patch

Created an attachment (id=79533) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config2.patch

Created an attachment (id=79534) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config3.patch

Created an attachment (id=79535) [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.0.3

Ok, this is the vmware-server-console.  It's completely rewritten from my
earlier attempt, and is based heavily on vmware-workstation-5.5.1's ebuild. 
Again, if it does anything stupid or unusual, it's probably because I forgot to
remove it or was just sleepy whilst making it (sorry).

This will create icons, it may install documentation in the wrong place (under
/opt rather than the standard /usr/share).  It does create symlinks and it's
probably ready for people to test out and get back to me about any problems it
has, thanks!

It also requires some auxiliary files (to be attached next).

Created an attachment (id=79537) [details]
vmware-server-console auxiliary file - 99vmware-console

Please note the vmware-server auxiliary file vmware.xml, is also used by the
vmware-server-console ebuild, and should be present in the /files directory of
both.  I won't bother re-attaching it.  Sorry for the spam, that's the last of
it until I either tweak the ebuilds or somebody reports a bug...

Hi Mike,

Thanks for the time/effort you put in this. Is there any reason to start a new
duplicate bug instead of continuing on bug 56881?

I've just posted there explaining my reasoning for openning a new bug.  These
technically aren't for gsx server, and rather than updating the summary (which
I probably can't do, not being the bug owner) and then moving the gsx-console
ebuild in there (since the gsx-console bug was closed).  I figured I'd start a
whole new bug to keep them both in...

It may work out to be a bad move putting them both in the same bug, but for the
time being they're kind of mutually necessary and I'd like to keep all my stuff
in one easy to get to place.  I may split the console ebuild out later if it
becomes necessary.

If you want to allow only users in vmware group to authenticate,  you need a
line as

auth   requisite   pam_wheel.so group=vmware

as first auth line.

Thanks Diego, that's very handy!  Is that for the vmware-authd program, so I'd
make a file called vmware-authd in /etc/pam.d/ with that in?  At the moment
nothing gets put in the pam.d directory.  I read on the vmware site that it
does all it's allow/deny stuff based on read access to the /etc/vmware/config
file, but that wasn't working very well, so I'll give this way a try as soon as
I can.  Thanks!

No that is not enough, you should also add th include-lines for auth account
pasword and session, look at /etc/pam.d/sshd for an example.

I just discovered that.  It turns out vmware has an
/etc/vmware/pam.d/vmware-authd file, but that seems to use pam_unix2.so which I
can't find on any of my systems.  I've been playing about with that and found
that it should get copied over to /etc/pam.d when the vmware-config.pl file
runs.  Unfortunately once that file's in place even with the requisite line, it
seems to either reject all my connection attempts, or let them all through. 
I'm reading up on pam authentication and hopefully will have something in place
in the next couple of days (I'm very busy these next few days, so I appologize
for the lack of updates)...

Well I used your ebuild from the other bug on my dual core Athlon64 SMP system
and it seems to be working well here. I managed to make a few virtual machines
although I am just using it locally right now. Thanks for all the work you have
put into these ebuilds, once I get chance I will try the updated ebuilds and
the console build for my laptop.

Just want to announce successful installation on an x86 (AMD Athlon 2500+)
system, just using local.  Windows XP installation progresses.

Right, I've been having real difficulty getting pam_wheel.so to work.  It
appears that vmware-authd (running as root) asks whether it can change to the
user provided (in this example vmuser).  The authentication determines whether
the credentials for this vmuser are correct, and the account lines determine
whether vmuser is a user or not.  Unfortunately, pam_wheel.so, doesn't check to
see whether the user you're try to get to (vmuser) is in the correct group, but
instead checks whether the user that's asking to get there (root) is in the
correct group.  There I've been a bit unsuccessful.  5:(

I did manage to find this thing called pam_require, which does exactly what I'm
after.  It checks whether the account requested (vmuser) is in one of a series
of groups (in our case just vmware).  I've tested it and it all works great. 
The problem is, it'd mean pulling in an extra dependency and it's marked ~x86,
so if vmware-server relied on it, they'd both need to be marked stable (if that
were ever to happen, eventually)...

Why is nothing ever easy?  If anyone's got any ideas/solutions for the problem
let me know.  For the time being I'm going to keep on looking for something
that'll work (I checked out pam_listfile.so, but that's not even close to what
I need), once I get this pam issue sorted I'll be posting a new version of
vmware-server that also has some mild dependecy changes that should help
modular X users, courtesy of johnm@gentoo...

*** Bug 56881 has been marked as a duplicate of this bug. ***

bug #56881 contains a few compatibility/clean-up comments. JFYI

In order to make the server beta work on my x86_64 machine I had to change
/etc/pam.d/vmware-authd to this:

#%PAM-1.0
auth       sufficient       /emul/linux/x86/lib/security/pam_unix.so shadow
nullok
auth       required         /emul/linux/x86/lib/security/pam_unix_auth.so
shadow nullok
account    sufficient       /emul/linux/x86/lib/security/pam_unix.so
account    required         /emul/linux/x86/lib/security/pam_unix_acct.so

Thanks for that dino7.  I have already corrected the hardwired paths and the
unix2.so problems and they'll be included in the next release, but the pam file
you've specified will still allow any user on the system to login to the
vmware-console (which allows file system traversal, and possibly other
nastinesses), and it's that I'm having difficulty curing.

As I said the pam_require package works perfectly, but it seems to still be in
~x86 after half a year, and is an extra requirement not standard to the
vmware-server package.  I'm unsure whether it's best practice to inform the
user that anyone can login, or force them to install the ~x86 pam_require
module, and configure for that?  If anyone can offer any guidance or opinions
on the topic, they'd be appreciated.  Thanks again...

I didn't check the package, so this could be wrong, but what about just having
the binary be owned by the vmware group, and the read/execute other permissions
removed?

Also pam_wheel should work with the "use_uid" parameter. And it's included in
the main pam distribution.

Paul, thanks for your comments.  vmware-authd gets run as root by xinetd (this
is how vmware have set it up), it then hands the authentication information for
the user credentials supplied to pam.  Pam makes it's decision and the process
then starts vmware-serverd because everything is still running as root (I
think).  However, if the user is not in the vmware group, when they actually
try and *run* a virtual machine the vmware-serverd process hangs.  It appears
vmware take this odd approach, because the virtual machine is run as the user
who owns virtual machine (not the user who logged in), but only allows the
running the of machine based on the file permissions set on the .vmx config
file (as in, if the .vmx has read and execute privs for other, then anyone can
log in and run that virtual machine).  So whilst it does *technically* restrict
access, it doesn't quite do it at the right place.  Apparently the only way to
do it is through pam.

So now on to your second point.  You're quite right, if you try pam_wheel
without use_uid (and debug to get the error messages) it says "Who's running
me?!?".  If you add the use_uid, it either allows all users in, or blocks all
users depending on where it is in the stack, and whether it's an auth or an
account line.  If someone can get a vmware_authd with the pam_wheel.so config
definitely working (so users in one group are allowed, and all others are
blocked) I'll put it straight into the package, but all my attempts have
failed, hence my looking into alternatives.  Thanks again for your comments,
we're very nearly there, just this last hurdle to get over...  5:)

Created an attachment (id=79744) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.0.6

Ok, since I'm gonna be away for a couple of days, I'm pushing out this release
a little early (as in, without a good fix for the pam/vmware-group-login
problem).

It's now got the dependency fixes that various people have pointed out to me
(thanks!).  It's also got updated dependencies for amd64 (since I figure that
the pam stuff probably requires the emulated baselibs), and has two pam.d files
(which will be posted as auxiliary files later on) which are copied over
depending on whether amd64 is in use or not.  The non-amd64 version removes the
hardwired path to the pam libraries, and should hopefully work for most
systems.  The amd64 one can't do that, since the native 64-bit pam libraries
are in the /lib/security, but the emulated 32-bit pam libraries are elsewhere,
so that gets a special file.  I've used the files themselves rather than
patches because they're about the same size, and this gives developers the
chance to make the modification more easily.

No other real changes have gone into this, a bit of tidying, some new wordage
at the end, otherwise mostly the same.  I've also realised that for amd64 users
there would be no 32-bit pam_require module (since it's not in the emulated
baselibs), so I really can't use that idea (which is a shame since it work
flawlessly).  Back to the drawing board...

This version still features the perl environment variable security problems
because I'm not sure how to fix them, or even whether we can without vmware's
help.

Two auxiliary files to follow.

Created an attachment (id=79745) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-amd64

Created an attachment (id=79746) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-x86

No pamd file in tree should have full path, just always use the base name
without the path.

Also take a look to dopamd/newpamd functions inside pam eclass (not the ones
from eutils).

Ok, I had thought that the basename without that path would attempt to locate
the native 64-bit pam files (which would work for any native 64-bit program). 
If it does however intelligently figure it out, then that'll make the ebuild
much easier and reduce the number of files, so that'd be excellent.  5:)

The reason that I don't use dopamd and similar functions is because it turns
out that vmware-config.pl copies over the pam.d file every time it's run, from
/etc/vmware/pam.d to /etc/pam.d, which means that any work I do to install the
pam file will get undone when the user updates it.  If someone could tell me
whether the vmware-authd-x86 pam.d file works on amd64, then I'll make the
necessary changes and get that all fixed up.  Thanks!

are there any negative side-effects to patching the vmware-config to not copy
pam.d everytime, and then it can be properly managed from the ebuild?

I honestly haven't looked into it.  I'll give it a check when I get time in the
next couple of days, and should have an answer for you when I'm back (either
late Wednesday or Friday)...  5:)

I actually have another request.

Since vmware-config.pl must always be run by root anyway, is there any way that
we can break out its funtionality into two separate functions.

#1.  Building modules - preferably as a second ebuild (vmware-server-modules?)
that we can use the standard module-building eclasses with so module-rebuild
works with it (keeps us from further propogation of bug #113031 into new
ebuilds)

#2.  Configuration - by putting this into the ebuild, using both the normal
ebuild functions such as src_install and pkg_config, we remove the need for
vmware-config.pl entirely

I have been wanting to get these done on vmware-workstation for some time now
and simply have not had the time to go through and understand everything that
vmware-config.pl is doing to replace all of its functionality.  This would make
it better integrate with Gentoo, and would ease upgrades, since
vmware-config.pl doesn't respect /usr/src/linux anyway and only builds modules
against the current *running* kernel, meaning a reboot is required after
building a new kernel before you can configure the VMware modules.  This would
also allow for VMware to be configured properly on more than one kernel, which
is not possible right now.

Well, I'll add it to the todo list, and whilst it would help with things like
module-rebuild there are a few reasons why I'm retisent to make separate
ebuilds.  

Firstly maintainance, whoever ends up understanding the perl script and
splitting it up will need to do it for each release where the perl script
changes much (although from what I've seen it doesn't change much at all).

Secondly they will require one of the various packages, since the module
sources are not available on their own.  In fact, it's entirely possible that
each version of vmware requires it's own modules.  I'd like to avoid ending up
with a similar situation to the old vmware-console ebuilds (version 2 was for
esx and 3 for gsx).

Still, I've put it on the todo list and will hopefully get to it soon, but the
perl security issues, and the pam authentication problem have higher precedence
at the moment...

(In reply to comment #35)
> Firstly maintainance, whoever ends up understanding the perl script and
> splitting it up will need to do it for each release where the perl script
> changes much (although from what I've seen it doesn't change much at all).

Well, most likely either Matt or I would be the ones maintaining it, and I plan
on doing this for *all* of the VMware ebuilds, so doing it now would ease this
getting into the tree.

> Secondly they will require one of the various packages, since the module
> sources are not available on their own.  In fact, it's entirely possible that
> each version of vmware requires it's own modules.  I'd like to avoid ending up
> with a similar situation to the old vmware-console ebuilds (version 2 was for
> esx and 3 for gsx).

No.  The point is that you have vmware-server-modules which always is pulled in
by vmware-server.  The distfiles would be the same, so that isn't an issue. 
You simple would RDEPEND on ~app-emulation/vmware-server-modules-${PV} in
vmware-server.  That would make it require the same version, but allow for any
revisions.

> Still, I've put it on the todo list and will hopefully get to it soon, but the
> perl security issues, and the pam authentication problem have higher precedence
> at the moment...

Understandable.  I'm just not comfortable adding something into the tree that
propogates a known and reported bug further, so it would need to be done before
I would add it.

I am hoping there is the possibility of having a standard "vmware-modules"
ebuild at some time, since the vmware-any-any-update patches were providing the
modules for *all* of the vmware-workstation ebuilds and also worked on vmware
GSX.  I am betting that the modules are compatable across most/all of their
products, it would just need to be verified.  As for the vmware-console thing,
it never should have been added with both as a single package to begin with,
since they aren't compatible.

Anyway, keep up the good work, you're doing a wonderful job and it really does
help, since it would be sometime after forever before I would get the time to
go into this much detail on this particular program.

Created an attachment (id=80201) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.0.7

Ok, sorry for the delay, I've been away for a few days this week...

Here's the latest version of the ebuild, note this is MORE broken than the
previous one, but hopefully goes towards implementing the feature requested in
comment 34.  It features a vmware-server-modules ebuild (to be attached after
this) that builds the vmmon and vmnet modules (sadly I can't test out the
vmppuser because I don't have a kernel old enough to require the parallel port
helper module).  It does still require vmware-config.pl to be run, and is
pretty broken if your kernel src directory isn't your running kernel, simply
for the reason that once you run vmware-config.pl, it tries to start the vmware
service, which of course won't have the modules run.  As soon as the init
service fails it recreates the not_configured file, and you're (from a standard
user point of view) back to square one without a clue why it failed, with only
vmware-config.pl left to re-run.  A pretty nasty catch 22, but hopefully with
the very kind volunteer help from others who know more about this than I do
(hint, hint!) we may be able to shift this into the vmware ebuild itself.  5:)

This one also backs out the amd64 pam.d special case, so please could some
amd64 users test this for me and tell me if they can log in ok.  Also, rather
than re-attaching the vmware-authd-x86 file as vmware-authd, I'm just going to
alter the description.  If it saves under a different filename it'll need
renaming.

Finally the "vmware group only" authentication problem is still there.  If
anyone's made any progress with a working pam_wheel.so config, please get in
contact and I'll start testing it and adding it to the bug.  Also the perl
library security problems are still there too, but I'm getting more convinced
that there isn't much I can do about it...

As always, please let me know if there's anything further I can do to help make
the ebuilds better.  Thanks...

Created an attachment (id=80202) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config4.patch

Created an attachment (id=80203) [details]
vmware-server-modules-1.0.0.20925.ebuild - Version 0.0.1

Created an attachment (id=80204) [details]
vmware-server-modules auxiliary file -
vmware-server-modules-1.0.0.20925-makefile.patch

Created an attachment (id=80328) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.1.0

Ok, here we go, another few little updates.

Firstly a fix for the fact that /etc/init.d/vmware fails on loading the
modules.  The reason was because vmware hardwired their init script to use
insmod and directly addressed the files as .o files.  The patch (which will be
attached next) changes it to a modprobe call which should automatically figure
out whether it's a .o for 2.4, or a .ko for 2.6 (as the build process does when
it installs the modules).

Ok, secondly I discovered that some recent update caused portage not to install
if those rpath problems I'd been having were still there.  Well, since they're
binary files I really don't have a clue how to go about altering them (save
asking vmware to do it and their 'bug tracking' system leaves a little to be
desired, since it's also their corporate support mechanism and the replies seem
a little less than specific).  So I took the rather drastic measure and assumed
that there was no need to install all the extra perl jiggery-pokery if there
was a perfectly good perl install on the system.  So I removed it.  If it
causes anybody any problems or breaks anything please let me know and I'll try
to rework it/contact vmware/do something magical to fix it...  5:)

Ok, so one more auxiliary file, and hopefully we're pretty close to being all
hunky dory (I need to check out the dependencies again).  Fingers crossed.  As
always any feedback positive or negative would be appreciated.  Thanks!  5:)

Created an attachment (id=80329) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-samples.patch

Patch to fix the init.d file's insinstance on insmodding a .o file rather than
a .ko for newer kernels.  This was fixed by a swift move to modprobe (which the
init script even uses elsewhere).

Hi, I can't get vmware-config.pl to do its job :(

 * VMware Server is installed, but it has not been (correctly) configured
 * for the running kernel. To (re-)configure it, invoke the
 * following command: /opt/vmware/server/bin/vmware-config.pl.
 * VMware is not properly configured! See above.                               
                                                                      [ !! ]
The configuration of VMware Server e.x.p build-20925 for Linux for this running
kernel completed successfully.

The only thing I didn't do by default is the Virtual Machine location
(/home/virtual)

Running an bi-opteron 242 Portage 2.0.54 (hardened/amd64, gcc-3.4.4,
glibc-2.3.6-r2, 2.6.14-hardened-r5 x86_64)

If someone can point me in the right direction or better give me a sloution :)
thanks

(In reply to comment #43)
> Hi, I can't get vmware-config.pl to do its job :(
> 

Ok, first off please ensure you're using the version of the ebuild I just
posted (the one labelled 0.1.0), because there was a bug that meant everytime
vmware's init script ran it failed and caused the "vmware not configured"
message to return.  That should hopefully now be fixed.

Secondly please run "ps aux" to make sure there are no stray vmware processes
running, then remove the /etc/vmware/not_configured file, and try running
/etc/init.d/vmware.  Please post the output from that command and it should
help us figure out what's going wrong a little bit better...

after removing the /etc/vmware/not_configured, everything is working as it
should be (at least for the server part), thanks a lot for your prompt reply.
[quick note, it requires glibc 2.3.6 which is not stable on amd64] 

Created an attachment (id=80359) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.1.1

Ok, I'm glad that all worked.  I just noticed that Version 0.1.0 that I
released is really *very* badly broken.  I was kinda hoping it wouldn't be, but
sadly completely removing the perl libraries from vmware rather kills it
(especially since they're all hardwired into it).  So it's back to the drawing
board on that front.  In the meantime, I've issued this fix which no longer
removes the RPATH affected files, but also may not install if the installation
system's too strict.  Any workable solutions would be appreciated.  I'm afraid
I don't have the clout to get vmware to notice that this is a bad thing and
issue a recompilation...  5:\

Well seems that the pam_auth bug on amd64 is there ....

I had to edit the /etc/pam.d/vmware-authd to this :
#%PAM-1.0
auth       sufficient       /emul/linux/x86/lib/security/pam_unix.so shadow
nullok
auth       required         /emul/linux/x86/lib/security/pam_unix_auth.so
shadow nullok
account    sufficient       /emul/linux/x86/lib/security/pam_unix.so
account    required         /emul/linux/x86/lib/security/pam_unix_acct.so

using pam_unix.so instead of pam_unix2.so
after that I get the following error :
Unable to connect to the remote host: 511-The process exited with an error:
    Can't locate strict.pm in @INC (@INC contains:
/opt/vmware/server/lib/perl5/site_perl/5.005
/opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux .) at
/opt/vmware/server/lib/serverd/init.pl line 47.
    BEGIN failed--compilation aborted at /opt/vmware/server/lib/serverd/init.pl
line 47.
    Perl error 2 during parsing of files.
    eval error: Can't locate strict.pm in @INC (@INC contains:
/opt/vmware/server/lib/perl5/site_perl/5.005
/opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux .) at
/opt/vmware/server/lib/serverd/init.pl line 47.
    BEGIN failed--compilation aborted
    VMServerd Panic: Could not initialize Perl script handler.

511 End of error message.

the directory /opt/vmware/server/lib/perl5/ doesn't exist ...

so I did copy it and its sub-folders from the VMware-server package and the
here is what I get :

Unable to connect to the remote host: 511-The process exited with an error:
    VMServerd Panic: The previous instance of serverd (8149) crashed, please
file a bug. The default log file is /var/log/vmware/vmware-serverd.log. To
continue, delete the following file: '/var/run/vmware/vmware-serverd.PID'

511 End of error message.

I'll keep the search tomorrow, bed time !

Well it seems you just did it !!! good job !

I still had to remove /etc/vmware/not_configured,
and I had to edit the /etc/pam.d/vmware-authd to this :
#%PAM-1.0
auth       sufficient       /emul/linux/x86/lib/security/pam_unix.so shadow
nullok
auth       required         /emul/linux/x86/lib/security/pam_unix_auth.so
shadow nullok
account    sufficient       /emul/linux/x86/lib/security/pam_unix.so
account    required         /emul/linux/x86/lib/security/pam_unix_acct.so

hello.

First thanks for the good work. Now the problem. I can't connect with the
remote console. On the server side i get:

Feb 21 14:33:07 vmware-server vmware-authd[6445]: The
"/opt/vmware/server/sbin/v
mware-serverd" process did not start properly.  Exit 0xff00

And more interesting: /var/log/vmware/vmware-serverd.log
Feb 21 14:27:13: app| Log for VMware Server pid=6104 version=e.x.p
build=build-2
0923 option=BETA
Feb 21 14:27:13: app| Program: /opt/vmware/server/sbin/vmware-serverd
Feb 21 14:27:13: app| CWD: /var/log/vmware
Feb 21 14:27:13: app| Init script: /opt/vmware/server/lib/serverd/init.pl
Feb 21 14:27:13: app| Perl error 2 during parsing of files.
Feb 21 14:27:13: app| eval error: Can't locate strict.pm in @INC (@INC
contains:
 /opt/vmware/server/lib/perl5/site_perl/5.005
/opt/vmware/server/lib/perl5/site_
perl/5.005/i386-linux .) at /opt/vmware/server/lib/serverd/init.pl line 47.
Feb 21 14:27:13: app| BEGIN failed--compilation aborted
Feb 21 14:27:13: app| VMServerd Panic: Could not initialize Perl script
handler.
Feb 21 14:27:13: app|
Feb 21 14:27:13: app| Backtrace:
Feb 21 14:27:13: app| Backtrace[0] 0xbf8da1a8 eip 0x80ccd71
Feb 21 14:27:13: app| Backtrace[1] 0xbf8dc228 eip 0x8078d95

But i have the strict.pm module. Do i have to add a path somewhere?

regards
t.

Okay. Version 0.1.1 fixes my error. Thanks.

Ok, first off Thomas, I'm very sorry, I released a BADLY BROKEN version of
vmware-server (that's version 0.1.0) which doesn't install a large chunk of the
perl modules seemingly required by the server.  There is a new build now attach
(version 0.1.1) which if you can get it to install should work.  I've now also
raised a ticket with vmware support, so we'll await their response to see how
to proceed with the RPATH security holes that are stopping this working ok.

As to the amd64 issue, thanks for reporting back about that Bertrand, it looks
like the hardwired paths are required, so the next ebuild I'm going to revert
the pam.d stuff and install a hardwired-paths version for amd64, and a normal
one for everyone else.

I'm afraid the next ebuild won't be out until later this evening, I have to
have a play around with removing just the rpath affected binaries and see how
much of an affect that has...

Sorry again for the broken ebuild, I hadn't tested actually running a machine
on it, but I'll be doing that from now on to make sure I don't send out duff
versions...

No Problem Mike. I know i play with unstable stuff. Keep up your good work. :-)

cheers
t.

Created an attachment (id=80387) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.0

Ok, now I'm really, *really* excited!  I found this wonderful little tool
called chrpath, which quite simply lets you remove blank rpath's completely! 
So I've now added this as a dependency (temporarily until vmware get their act
together) and removed the rpath fields of all the affected shared objects. 
It's such a large fix (assuming it works) that I've bumped the version to a
whole 0.2.0!!  5:)  This is an awful lot more sensible than my previous hack
off the bad bits and whole what's left limps on properly approach, however it's
possible that these binaries relied on having their rpath unset, and
unfortunately I haven't been able to test these this evening.  Please give this
a try (as I will tomorrow morning) and let me know how it all works out...

I've also recorrected the amd64 pam file too, so that problem should go away as
well now.  I think we're getting there slowly but surely...

Created an attachment (id=80416) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.1

Ok, the ebuild is getting a little dirtier now, relying not only on find, but
also on grep (I must add dependency checks for those I guess), but it now only
removes bad rpaths from those that have them (if anyone can point me to a way
to filter out files that already have an rpath using scanelf or chrpath and
bash only, then I'll be glad to integrate it).  This one really does seem to
work as expected, and if I could only get that "login even if not in vmware
group" bug fixed I'd have not only saved myself a lot of headbanging this
morning, but also class it as ready for unstable testing (well, with a few more
tweaks)...  5:)

As always, please try this version out, let me know how it works, whether it's
a pain to get going, issues/problems, whatever, and I'll keep fixing it up as
and when I can.  I think the next few days will be spent have a long hard read
of the pam_wheel.so code to figure out how it works...

Mike  5:)

I just installed it on an x86 laptop.

1.  I edited the ebuild to require glibc-2.3.5 instead of 2.3.6 since that's
still masked.  ANyone know if 2.3.6 is a hard requirement?

2.  I had to 'rm /etc/vmware/not_configured', otherwise it still though it
wasn't configured.  (But I also didn't reboot right after the install either.)

I then launched it and connected to it locally.  GUI came up and I started
going through the wizard to create a new virtual machine but didn't complete
it.  I'll do that later when I have time to install something.

Otherwise, great work!  I'm excited to try it out!

Sadly I can't do any work on it now, but I've got a pam_listfile.so line (and
an extra little auxiliary file) that seems to do the trick!!!  The only thing
then to double check are the dependencies (yes, from the reports I've had,
unfortunately glibc-2.3.6 appears to be a hard dependency) and this deleting
not_configured.  It should be that after you run vmware-config.pl properly it
removed the not_configured file, but if that's not listed in the locations file
as installed by vmware then it won't remove it.  I'll try and take a look at
what's going on on a clean box when I get a chance.  I'll also post the fixed
pam.d files and updated ebuild tomorrow...  Nearly there!  5:)

Well, just to update you so far I'm about 1/2 through a winxp install - using
the native glibc-2.3.5.  No glitches so far.  It's taking a long time for the
install, but that's to be expected on a laptop.

Thank you so much for this ebuild. It works very well on my system (amd64,
2.6.15-r5 kernel). I wrote up a little tutorial about it that explains how to
use your ebuild. It can be found at 

http://diaryproducts.net/about/operating_systems/unix/installing_vmware_server_on_gentoo_linux

Two remarks: 

The post-installation notes in vmware-server suggest editing /etc/xinetd.conf.
I would change that to /etc/xinetd.d/vmware-authd as that doesn't affect the
entire system, only vmware.

Also, I think vmware-server-console should list unzip as a dependency as it
uses that program to unpack the distribution.

(In reply to comment #57)
> Well, just to update you so far I'm about 1/2 through a winxp install - using
> the native glibc-2.3.5.  No glitches so far.  It's taking a long time for the
> install, but that's to be expected on a laptop.
> 

I myself are running on 2.3.5, but my theory is that since vmware server can
run on Redhat ES 4
(http://www.vmware.com/support/gsx3/doc/intro_sysreqs_host_gsx.html) the
minimum glibc version is glibc-2.3.4, that is what RH ES4 currently is running
at.

Created an attachment (id=80526) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.2

Ok, here we go, as promised here is the latest version with the following
changes:

* vmware group only authentication based on pam_listfile.so!  Yay!
* Fixed find line, so that grep isn't required.
* Fixed dependencies in case find isn't installed
* Fixed blurb at the end to suggest only editing xinetd.d/vmware-authd

I'm thinking that's everything, there will be three more auxiliary files to
come after this.  Thanks to all for the recent comments.  I haven't updated to
the glibc comments based on the advice of johnm@gentoo in bug 56881 comment 30,
31 and 32.  Whoever finally puts this package into portage will have to figured
out which of the condradicting views is correct because I simply don't know
enough about this stuff to decide.  Sorry...  5:\

I think I'm about done with the server ebuild.  Please report whether the
not_configured file gets deleted after a run of vmware-config.pl or not, and
I'll look into it if it's broken, otherwise enjoy!  5:)

Created an attachment (id=80527) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-amd64 -
Version 0.0.2

Created an attachment (id=80528) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-x86 -
Version 0.0.2

Created an attachment (id=80529) [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmwaregroup

Created an attachment (id=80530) [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.0.4

Hi, this is just a small bugfix version of vmware-server-console that now
features unzip in the dependencies (as it needs it to unpack).  Thanks very
much for noticing that Hannes!  5:)

I can confrim that it works fine under gblic-2.3.5.  I've installed it, I've
installed winxp under it, I've rebooted everything several times and it all
works.

The only issues I have are:

1.  I routinely still get the '/etc/vmware/not_configured' file appearing which
I have to delete.
2.  I am unable to '/etc/init.d/vmware stop'.  I get the following output:
ERROR:  "vmware" has not yet been started.
3.  The virtual network devices aren't working, but I also haven't really paid
that much attention to configuring them so it's most likely a boo boo on my
part.

I haven't figured out what' causing the not_configured file to keep reappearing
yet.

This is all on an x86 laptop.

Hi drumz.  I'm sorry, I realise this is going to sound really stupid, but the
only thing that I can think of that would fit all of your symptoms is that
/opt/vmware/server/bin/vmware-config.pl hasn't been run and your system doesn't
think it's configured.  It would explain the virtual interfaces not working,
the not_configured file's reappearance and the /etc/init.d/vmware's failure to
start (init.d/vmware seems to be failing)...

Please rerun that and let me know the output it gives you (particularly the bit
where it runs /etc/init.d/vmware start).  Hopefully we can get it figured
out...

Sorry, should have specified:  I updated to your latest files and re-emerged it
then re-ran the config script before.

I just did it again and here's the end where the vmware init script is
executed:

This program previously created the file /etc/vmware/not_configured, and was
about to remove it.  Somebody else apparently did it already.

 * Starting VMware services:                                                   
                                                             [ ok ]
 *   Virtual machine monitor                                                   
                                                             [ ok ]
 *   Virtual ethernet                                                          
                                                             [ ok ]
 *   Bridged networking on /dev/vmnet0                                         
                                                             [ !! ]
 *   Host-only networking on /dev/vmnet1 (background)                          
                                                             [ ok ]
 *   Host-only networking on /dev/vmnet8 (background)                          
                                                             [ ok ]
 *   NAT service on /dev/vmnet8                                                
                                                             [ ok ]

The configuration of VMware Server e.x.p build-20925 for Linux for this running
kernel completed successfully.


If I do an 'ls /etc/vmware/not_configured' the file is there.

Yeah, it gets created by /etc/init.d/vmware (or more accurately
/etc/vmware/init.d/vmware) whenever it tries to start up and fails.  It appears
you're having difficulty starting the bridged interface, but I'm afraid I don't
have a clue why...

Both of the device drivers seem to have built correctly, so...

Best I can come up with is to check /opt/vmware/server/bin/vmware-bridge
permissions, and also to make sure the interface you specified is valid (like
eth0, or whatever it is you're trying to bridge to), and finally try rebooting
the machine (to make sure it's a clean start) then modprobe the required
modules (vmmon and vmnet) and then run vmnet-bridge -D /dev/vmnet0
<eth0-or-whatever> and see what that tells you.  If it doesn't give you any
clues then I'm afraid I'm stumped...

Here's the directory listing of /opt/vmware/server/bin:

ls -l /opt/vmware/server/bin/*
-r-xr-xr-x  1 root root  12292 Feb 23 17:47 /opt/vmware/server/bin/vm-support
-r-xr-xr-x  1 root root   6160 Feb 23 17:47 /opt/vmware/server/bin/vmnet-bridge
-r-xr-xr-x  1 root root 110872 Feb 23 17:47 /opt/vmware/server/bin/vmnet-dhcpd
-r-xr-xr-x  1 root root 122372 Feb 23 17:47 /opt/vmware/server/bin/vmnet-natd
-r-xr-xr-x  1 root root   5192 Feb 23 17:47
/opt/vmware/server/bin/vmnet-netifup
-r-xr-xr-x  1 root root   8140 Feb 23 17:47
/opt/vmware/server/bin/vmnet-sniffer
-r-xr-xr-x  1 root root   4570 Feb 23 17:47 /opt/vmware/server/bin/vmware
-r-xr-xr-x  1 root root  80356 Feb 23 17:47
/opt/vmware/server/bin/vmware-authtrusted
-r-xr-xr-x  1 root root  22462 Feb 23 17:47 /opt/vmware/server/bin/vmware-cmd
-r-xr-xr-x  1 root root 271306 Feb 23 17:47
/opt/vmware/server/bin/vmware-config.pl
-r-xr-xr-x  1 root root 580576 Feb 23 17:47 /opt/vmware/server/bin/vmware-loop
-r-xr-xr-x  1 root root  25488 Feb 23 17:47
/opt/vmware/server/bin/vmware-mount.pl
-r-s--x--x  1 root root  10852 Feb 23 17:47 /opt/vmware/server/bin/vmware-ping
-r-xr-xr-x  1 root root  90093 Feb 23 17:47
/opt/vmware/server/bin/vmware-uninstall.pl
-r-xr-xr-x  1 root root 829016 Feb 23 17:47
/opt/vmware/server/bin/vmware-vdiskmanager


I will have to try the other stuff tomorrow after work....

Fully tested on a dual proc Opteron that had been running workstation 5.5.

I tweaked the ebuild back to glibc-2.3.5.
All of my VM's ( 5 w2k3 servers and 3 xp workstations) came up great.

Remote access was broken until I added [user] to the vmware group.

I have not tried it against the servers that had vmware-server manually
installed.

I used the directions at

http://diaryproducts.net/about/operating_systems/unix/installing_vmware_server_on_gentoo_linux

to install the local ebuild from this bug.

I did a full install of Windows XP sp2 as a test, no issues.

Pretty damn good so far!

Ok, I no (somewhat) why it's failing on the bridge:

/opt/vmware/server/bin/vmnet-bridge -D /dev/vmnet0 ath0
Turning on bridge to ath0...
ath0: Not a valid Ethernet interface


ath0 DOES in fact exist, it's my wireless interface (atheros chipset in a
d-link dwl-g650) that I use on my laptop.  If I substitute 'eth0' (for the
hardwired, built-in interface) vmware-bridge doesn't complain.

This is the first time I've attempted to run a vmware product on a laptop, I've
only previously installed/used it on desktop systems that have been wired to
the wall.

I re-ran vmware-config and changed the bridge to eth0 and now
/etc/init.d/vmware starts/stops cleanly AND without creating that annoying
not_configured file.

Excellent, I'm glad you got it sorted drumz.  It might be worth filing a bug
report upstream to say that it didn't work with your wireless card, however I
have the unfortunate feeling that since it's on Gentoo (which is officially
unsupported) you'll have a long wait ahead of you before a human response comes
back...

Meanwhile, I was wondering what the vmware herd thought about putting this into
portage?  I think the pam_listfile.so solution is a good compromise and I don't
think the dependencies are too outlandish.  The whole glibc issue needs to be
sorted but so far I haven't had any reports of a *practical* problem with
running under glibc-2.3.6, just the assertion that it was built for that
version and so shouldn't run on lesser versions.  I'll leave that one up to
you.  Whaddya think vmware herd?  Is it ready?  5:)

I would vote that it's ready to be added to the main portage tree.

I would though like to see the glibc version dropped down to the current stable
one.  I'm running it with no problems under 2.3.5.  It may be just me, but I'm
just a tad bit nervous bumping glibc up to a version that's not tagged as
'stable'.

Oh, and maybe include a message that trying to bridge using wireless may not
work (although that issue may just be limited to my card, or the driver
(madwifi), or the config I attempted, additional testing needs to be done to
narrow it down which I'll attempt when I have more time).  That way nobody's
caught off guard.  The configure script DID recognize ath0, it just appears
that bridging doesn't like it.

(In reply to comment #72)

> Meanwhile, I was wondering what the vmware herd thought about putting this into
> portage?  I think the pam_listfile.so solution is a good compromise and I don't
> think the dependencies are too outlandish.  The whole glibc issue needs to be
> sorted but so far I haven't had any reports of a *practical* problem with
> running under glibc-2.3.6, just the assertion that it was built for that
> version and so shouldn't run on lesser versions.  I'll leave that one up to
> you.  Whaddya think vmware herd?  Is it ready?  5:)
> 
I think you are safe setting it back to glibc-2.3.5, it runs rock solid on 3 of
my servers (2 athlon-xp, 1 dual proc amd64) all with glibc-2.3.5.

Hi, and firstly : thanks a lot for this great work, Mike !

The installation worked perfectly here, based on stable version og glibc :
sys-libs/glibc-2.3.5-r2. I installed it on 2 test servers, and 1 prod. server,
without any major problem. Made a tarball of my portage overlay, since this
remains very annoying to manually fetch all files ;-)

Since it seems there is no blocking problem appearing, I think these ebuilds
are ready to be added to the portage tree (~x86).

Stuff that needs fixing in attachment #80530 [details]:

* DEPEND needs to come after RDEPEND if you're including the variable in it.

* the || ( ) ordering for x11 is backwards.

* unzip purely as an RDEPEND? Is that really right?

* Calling tar manually is a bad idea. Use unpack if at all possible.

* The variable substitution at the top would be a wholllllle lot more elegant
were it to use versionator.eclass.

Why is it necessary to install xorg-x11 for the server to work?

Thanks for your comments Ciaran, I'll make the changes as soon as I'm able to,
unfortunately my development machine is otherwise engaged until the weekend...

I do have a few questions and a couple of points:

(In reply to comment #76)
> Stuff that needs fixing in attachment #80530 [details] [edit]:
> 
> * the || ( ) ordering for x11 is backwards.
>

I wasn't aware there was a particular ordering on || ( ).  If neither are there
does portage suggest the first in the list?  If so, should that be the modular
dependencies or the xorg ones which appear to be the current ones for the
profile?  Could you provide a little more explanation, and perhaps a link to
the documentation that describes accurately how || ( ) works please? 

> * The variable substitution at the top would be a wholllllle lot more elegant
> were it to use versionator.eclass.
> 

This was simply copied from the existing vmware-workstation-5.5 ebuild, so I
don't really see it as a reason to exclude the ebuild from portage.  I will
look into versionator in what remaining free time I have, however if someone
else who knows about it could jump in and help it would be *greatly*
appreciated.

> * DEPEND needs to come after RDEPEND if you're including the variable in it.
> 
> * unzip purely as an RDEPEND? Is that really right?
> 
> * Calling tar manually is a bad idea. Use unpack if at all possible.
> 

You're absolutely right, I wasn't overly paying attention as I've never
developed an ebuild for an audience of more than about 10 before.  I'll correct
those up in all the relevant ebuilds when I get a chance.


Have you any further comments on the other ebuilds?  I'm most worried about the
vmware-server-modules since that ebuild was entirely home grown whilst the
others were mostly based on the existing vmware ebuilds.

I'd also like to say that I'm a little discouraged.  I've been developing these
ebuilds for a good month now to try and get a quick release ready for the
gentoo community, and I was hoping that perhaps one of the five currently
present vmware herd (who have developed ebuilds that are in portage before and
presumably should know what fixes are required) could have jumped in and
pointed these out, or even better provided patches to fix the issues.

So far the input I've had was being asked to split the module building from the
main ebuild (which one developer admitted the herd had needed doing for all the
ebuilds but no one had done yet) and to comprehend and alter the configure
script to accommodate this.  Having done that, produced an ebuild and responded
to further comments to ensure that the ebuild works for as many people as
possible, I would have appreciated a little more help getting it into portage,
rather than a completely different gentoo developer giving me a list of all the
things that I still need to do to be finished with this.  Discouraging to say
the least...  5:\

(In reply to comment #78)
> > Stuff that needs fixing in attachment #80530 [details] [edit] [edit]:
> > 
> > * the || ( ) ordering for x11 is backwards.
> >
> 
> I wasn't aware there was a particular ordering on || ( ).  If neither are there
> does portage suggest the first in the list?  If so, should that be the modular
> dependencies or the xorg ones which appear to be the current ones for the
> profile?  Could you provide a little more explanation, and perhaps a link to
> the documentation that describes accurately how || ( ) works please? 

Ok, say we have || ( a b ) . Then Portage first checks for a, and if it's
there, does nothing more. Then, failing that, it checks for b, and it it's
there, does nothing more. Then, failing that, it checks to see whether a can be
installed, and if it can, it installs a. Then, failing that, it checks to see
whether b can be installed, and if it can, it installs b. Then, failing that,
it gives an error saying that a can't be installed.

So, with X deps, we're listing what will become the modular choice in the
future first. For users not using modular X, it's not a problem, because the
first lot will be unavailable and so the non-modular fallback will be used. For
users who are using modular X, however, it can make a difference -- if the
non-modular X is listed first and the modular group is not fully resolved,
Portage will try to pull non-modular in.

It gets more complicated if you include use? stuff inside || ( ). You don't
want to know about that until you have to...

> This was simply copied from the existing vmware-workstation-5.5 ebuild, so I
> don't really see it as a reason to exclude the ebuild from portage.

Sure. Using versionator is never mandatory, it's just a lot easier on the eyes.

> Have you any further comments on the other ebuilds?  I'm most worried about the
> vmware-server-modules since that ebuild was entirely home grown whilst the
> others were mostly based on the existing vmware ebuilds.

Could you give me a list of attachment numbers to check? Last time I tried to
work one of these out on a bug with multiple ebuilds I screwed up and ended up
looking at an obsolete ebuild.

> Discouraging to say the least...  5:\

Heh, the way to get feedback is to pester people on IRC until they either stick
you on ignore or tell you what they think. The reason I'm on this bug is
because someone pestered me on IRC about it.

Thanks for the speedy reply...  5:)

I'll swap the modular dependencies around as soon as I can.  Again the
dependencies are my (and ldd's) best guess.  In answer to Rasmus's question, I
have the feeling that some of them may be unnecessary but the script I was
using to help me figure it out was (if I've understood it right) recursing
through the linked libraries too and may have pulled in too many dependencies
as a result.  If anyone can tell me dependencies that definitely are or aren't
needed, I'll change them around accordingly...

As I mentioned I can't do any more work on these until the weekend, and you'll
find a couple of the problems you mentioned for the vmware-server-console
(attachment 80530 [details]) in the vmware-server and vmware-server-modules packages too,
but any that you mentioned I'll fix up in the other ebuilds.

If you've got the time, it'd be really helpful if you could give the same
treatment to attachment 80526 [details] and also 80203.  Also, I realise there are
several patches for the same file that I might roll into one for the final
product, I just didn't want any more obsolete attachments around than necessary
until I was nearly done...

Thanks a lot Ciaran, I appreciate your help!  5:)

Created an attachment (id=81038) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.3

Right, here are new ebuilds for all three packages that have had all the
tar/unzip etc commands replaced with unpack.  The version jiggery-pokery is now
done with versionator.  The DEPEND variable is now separate from the RDEPEND
variable, and all the dependencies have been rejigged to make more sense (for
instance, why was some stuff only required for x86?).  Which I think deals with
all of Ciaran's previous issues.  Bring on the next set!  5:)

Created an attachment (id=81039) [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.0

Created an attachment (id=81040) [details]
vmware-server-modules-1.0.0.20925.ebuild - Version 0.1.0

Also if you haven't started yet, Ciaran, the attachment numbers should now
read: attachment 81038 [details], attachment 81039 [details] and attachment 81040 [details]...

Wheee. Ok, lessee:

attachment #81030 [details]:

* I just noticed this:

        #Note: it's a bit weird to use ${D} in a preinst script but it should
work
        #(drobbins, 1 Feb 2002)

I *thought* that ${IMAGE} was the variable to use here, but I might be going
crazy.

Attachment #81038 [details]:

* virtual/os-headers looks like it's indented using spaces, rather than tabs.

Attachment #81040 [details]:

* What's the reasoning behind the nomirror restriction? Usually we're fine
mirroring things that are GPL or BSD licenced.

* Is KEYWORDS="~amd64 ~ppc ~x86" correct? I noticed that the others were ~amd64
~x86.

The other issue with all of these, which I suspect you've inherited from the
original vmware ebuilds, is lack of $ROOT support. Inside pkg_*, ebuilds are
expected to handle the package being installed to somewhere other than / ,
which is indicated by the $ROOT variable. This is used when creating images for
another system, for example. Now... Quite a lot of ebuilds don't actually
support this. However, in the interests of completeness, I'm pointing it out
anyway.

Anyway, as far as I can see, these're looking good from an ebuild perspective.

Right, some very quick fixen just before I head home...

> attachment #81030 [details] [edit]:
> 
> * I just noticed this:
> 
>         #Note: it's a bit weird to use ${D} in a preinst script but it should
> work
>         #(drobbins, 1 Feb 2002)
> 
> I *thought* that ${IMAGE} was the variable to use here, but I might be going
> crazy.
> 

No idea, D does seem to work as Mr Drobbins suggests, and I don't really know
what I'm doing when it comes to preinst stuff.  I'm assuming this happens
before ${IMAGE} has been created?  I'll probably leave it in it's working
state, unless it's really a QA issue, but I'm happy for someone who know's
what's going on to fix it up.

> Attachment #81038 [details] [edit]:
> 
> * virtual/os-headers looks like it's indented using spaces, rather than tabs.
> 

Fixed in both -server and -server-console.

> Attachment #81040 [details] [edit]:
> 
> * What's the reasoning behind the nomirror restriction? Usually we're fine
> mirroring things that are GPL or BSD licenced.
> 

It turns out this ebuild was copied from the madwifi-driver sources and (since
I had only been developing it for myself originally) the wrong license was
present, sorry.  5:(  This has now been updated to the vmware license, I'm
under the assumption that this vmware license is the same between all
vmware-ebuilds and is the correct one for this product.

The RESTRICT="nomirror" was actually just a side effect of me developing it and
not wanted to make unnecessary calls to the gentoo servers (which definitely
didn't have a mirror of it when it was being developed).  That's all been
removed, thanks...


> * Is KEYWORDS="~amd64 ~ppc ~x86" correct? I noticed that the others were ~amd64
> ~x86.
> 

No, you're quite right, fixed also.

> The other issue with all of these, which I suspect you've inherited from the
> original vmware ebuilds, is lack of $ROOT support. Inside pkg_*, ebuilds are
> expected to handle the package being installed to somewhere other than / ,
> which is indicated by the $ROOT variable. This is used when creating images for
> another system, for example. Now... Quite a lot of ebuilds don't actually
> support this. However, in the interests of completeness, I'm pointing it out
> anyway.

I've never heard of this, and the only bits I can see with pkg_* refer to
/etc/, and sadly vmware is hardwired to check that location for its
configuration information.  It would take a lot of careful patching to fix that
up, and I'm not certain it's worth it.  Again a task I'm afraid I'll leave to
others...

Cool, thanks very much for looking through those, there's stuff in there I'd
completely forgotten.  If there are any other glaring/not-so-glaring bits,
please do point them out.  Otherwise I guess the procedure is to wait and
someone somewhere will whisk them into portage when they think they're
ready/offers to maintain them?

Three attachments to follow.

Created an attachment (id=81050) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.4

Created an attachment (id=81051) [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.1

Created an attachment (id=81052) [details]
vmware-server-modules-1.0.0.20925.ebuild - Version 0.1.1

Created an attachment (id=81055) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.5

Sorry for what must now be huge quantities of spam, almost there though.  I
just forgot the versionator stuff on the vmware-server ebuild.

Re comment #90: Just a heads up, and keep 'em coming, Mike :)
I think you're doing great stuff here. I have one of the older ebuilds running
on amd64 just fine.

I've laid in the latest ebuilds for vmware-server-*, and vmware-server and
vmware-server-modules installed with nary a hiccup on my ~x86 box. However, I'm
getting:

thomas ~ # emerge vmware-server-console

Calculating dependencies -
!!! All ebuilds that could satisfy "x11-libs/libX11" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-libs/libX11-1.0.0-r2 (masked by: package.mask)
# Donnie Berkholz <spyderous@gentoo.org> (07 Aug 2005)
# Modularized X, upstream release candidates


For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.
(dependency required by "app-emulation/vmware-server-console-1.0.0.20925"
[ebuild])

thomas ~ # equery list x11
[ Searching for package 'x11' in all categories among: ]
 * installed packages
[I--] [  ] virtual/x11-6.8 (0)
[I--] [  ] x11-base/xorg-x11-6.8.2-r6 (0)
thomas ~ # emerge --info

Portage 2.1_pre5-r1 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.6-r3,
2.6.15-gentoo-r5 i686)
=================================================================
System uname: 2.6.15-gentoo-r5 i686 Intel(R) Celeron(R) CPU 2.66GHz
Gentoo Base System version 1.6
dev-lang/python:     2.3.5-r2, 2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /etc/mail/dspam /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind
/var/qmail/control /var/run/dspam"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O3 -march=pentium2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://planetmirror.com/pub/gentoo/
ftp://mirror.pacific.net.au/linux/Gentoo ftp://mirror.isp.net.au/pub/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.au.gentoo.org/gentoo-portage"
USE="x86 X aac alsa apache2 apm arts avi berkdb bitmap-fonts blas bzip2 cairo
cdr clamav crypt cups dba dbm doc dvd eds emacs emboss encode examples expat
foomaticdb fortran ftp gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile
hal howl icq ieee1394 imagemagick imap imlib innodb ipv6 jabber java javascript
jpeg kde lapack libg++ libwww mad mbox mikmod mime mono motif mp3 mpeg mysql
ncurses nls offensive ogg oggvorbis opengl oss pam pdf pdflib perl php png
postgres ppds prelude python qt quicktime readline samba sasl sdl session slang
source spell spl sqlite3 ssl svg tcltk tcpd tetex tiff truetype truetype-fonts
type1-fonts unicode usb vhosts vorbis wxwindows xml2 xmms xv zlib elibc_glibc
kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS

thomas ~ # 

Any thoughts? 

Created an attachment (id=81147) [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.2

Yeah, sorry about that, my bad.  As I was changing around the order of the
dependencies I removed the virtual/x11 line and then assumed it was
virtual/xorg-x11 when I put it in the right place.  That's now fixed with this
version.  Keep the fix suggestions coming, thanks!  5:)

Here's an interesting observation:
   I wanted to install vmware-server on a JFS partition, which has pretty
decent speed when updating/copying large atomic files. However, vmware-server
doesn't recognize jfs as a partition type, and the server refuses to start. I
found a workaround, which is that vmware only expects /etc/vmware and
/var/log/vmware to be of a certain fs type, so I created small loopback
filesystems (ext2/3 and reiserfs both worked) and then re-ran the setup script.
It works like a charm. I know this is a bug with vmware, but you might want to
add an info line to ebuild to let people know of this limitation. =)

Great work, thanks for putting in the effort!

For those of you who don't want to manually download all stuff. I've put the
files into a subversion repository. It's available at:
http://callisto.cs.kun.nl:81/svn/trees/vmware/

One additional point on the vmware-server ebuild. In some point of the ebuild,
it allows a configurable name for the group. At other points it is hardcoded,
even in a file in the filesdir. I suggest you use the variable everywhere and
generate the vmwaregroup file instead of putting it in the filesdir (it's only
one word).

Does that mean you can give Mike & co access to the svn for dev purposes while
this bug is open? :)

I have no problem giving him access. Mike, just send me a htpasswd file/line
that I can add to the configuration. If others need access, I can give it too.

I also found two bugs with userpriv.
vmware-server-console tries to remove some files at some point, but asks for
confirmation as it is not forced.

Second, the rpath stuff doesn't work with some error saying the perl modules
can't be opened.

Are these ebuilds stable / reasonably safe to use on a production system? I'm
holding out for the finished builds to do a deployment, but my employer is in
favour of having the system up sooner rather than later. Advice?

Personally I'd say we're in the "these are quite usable, we're just looking for
problems in unusual situations" stage.  I'm currently being mentored with the
intention of becoming a gentoo developer and I think the idea is that I'd then
take responsibility for these ebuilds.  Since I tend to err on the side of
caution, I wouldn't think these will go anywhere near *stable* stable for a
very long time.  I'd personally expect them to take maybe a couple of months to
actually get in portage as ~x86 (assuming both that I become a gentoo developer
and get asked to look after these ebuilds and no one else picks them up before
me).  Ultimately it is your decision and I'd hate to feel responsible for
something going wrong on a production server, but other than that...  5:)

To everyone else, I'm sorry I've been a bit busy this week, I've not got access
to the subversion repository very kindly hosted by Paul, and will be making the
minor ammendments that people have pointed out since the last release sometime
before Monday.  So that we keep a good record of everything I will still be
posting the ebuilds here as well as to the subversion repository.  Keep the
comments coming in.  Thanks!  5:)

Created an attachment (id=81808) [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.6

Ok, so here's the latest version of the server ebuild.  This is also in the
subversion repository (I appologize, there was a slight typo in my last post
saying I did not have access to the svn repo, rather than I did *now* have
access to the repo.  Thanks, Paul, for getting me that, should make
distribution a lot easier).  It includes a warning about installation on JFS
file systems, and points them to comment 94.  It also includes a completely
customizable groupname and is a bit tidier too.  5;)

Paul, you mentioned two other problems.  Sadly I don't have a userpriv setup to
test the problems you're facing, so I'm working blind on the fixes, but...

The not forced removal of files is done in two places.  The first unpacked the
zip, then unpacked the files we wanted, then removed the excess .tar.gz and
.rpm files.  I used to build on quite a tight space budget, but I've removed
that since it may have been the culprit.  The other location is in updating the
locations file (and I truely don't understand what that bit's doing, it was in
the original vmware-workstation ebuild) and I've added a -f to this to
hopefully force it through.  I'm a little worried about running an rm -f on a
user's system, but I guess the sandbox will stop anything too catastrophic from
happening.  I'll attach that ebuild next.  If people would like to see the
space saving removals put back, let me know and I'll reinstate them...

The rpath problem I can't diagnose the problem, so I can't propose a fix, could
you provide the readout when it fails so I can get a feel for what's going
wrong?

As always, any other problems, issues, etc.  Send 'em my way.  Thanks!  5:)

Created an attachment (id=81809) [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.3

As promised.  Paul, could you also please check if you get the same problem in
the vmware-server ebuild, since I think that has the same loop at the end of it
as well?  Thanks...  5:)

@james#100
Besides these ebuilds still being under development you should also take into
account that the packages provided by the ebuilds are also still beta quality.
The current binaries will (according to an email I got from vmware) only work
until 17 march. A new version has thus been posted. While this is no problem
for testing, I don't think that this would be tollerable in a production
situation.

@mike: Userpriv is not used in pkg_postinst (or preinst etc. for that matter).
I did found an error though. When reading the filesystem, you must use the
${ROOT} prefix. (rm -f is not needed there)

So not:
for x in /etc/vmware-console/._cfg????_locations ; do

but
for x in "${ROOT}/etc/vmware-console/._cfg????_locations" ; do

Hello,

what about vmware-mui? It would be nice to have a ebuild for this?

Regards Roland

on the topic of removed .cfg??? files, thats fairly problematic.
are you able to sort out ${D} locations instead? editing to-be-handled configs
isnt the job of the ebuild. in honesty, these shouldnt exist when people run
etc-update after an install anyways.

Else, it looks good.

Will a new bug be opened re upgrading to newest beta version that is now
released so we can keep the server running after 17th March?

VMware-server-e.x.p-22088.tar.gz

Thanks

Right, a few things to cover here.  Firstly the upgrade.  Simply changing the
file versions will cause the package to bump successfully.  However, going
through and renaming everything on this bug is liable to cause a lot of spam/be
fairly unnecessary, so I think I might suggest people make use of the
subversion server mentioned in comment 95.

As to the vmware-mui, I don't really have a template to work from so that will
take me much longer.  I'll look into it when I get some free time, but I'm
afraid it isn't very high on my list of stuff to look at...

Finally the editing of .cfg??? files is I think because the vmware-configure
script makes use of the locations file to determine whether it has certain
files installed/can remove certain files (such as the not_configured flag).  As
far as I can tell (and you're better off asking the author of the
vmware-workstation-5.5 ebuild) this is to ensure that at the end of an
installation the locations file contains all the correct files as installed by
vmware.  Removing that code will simply require a large red warning saying
DON'T FILE BUGS IF YOU DON'T FIX YOUR CONFIGS FIRST!  I'd sooner either just
remove the config protection from that indidivual file (which I'm not sure how
to do), or leave the code the way it is.  I'm not certain quite why the rm is
there though it must be said.  Again, it's a time issue, I'll try and figure it
out when I have more of a chance...

So in summary, check the subversion repository for updates from now on...

I'm just a minnow in this company, but encouraged by Hannes Schmidt's Web site
I decided to have a go. I duplicated his directory structure under
/usr/local/app-emulation, and I ran the ebuild [...] digest commands, which
worked just fine. Then I ran emerge -ua vmware-server but after succeeding with
vmware-modules and chrpath the installation stopped on "serious QA concerns 
with RUNPATH/RPATH" while processing vmware-server. After checking again that I
had everything in the right place I tried again, with the following result:

>>> Emerging (2 of 2) app-emulation/vmware-server-1.0.0.20925 to /
>>> checksums files   ;-) vmware-server-1.0.0.20925.ebuild
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-config2.patch
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-config3.patch
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-config4.patch
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-config.patch
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-services.patch
>>> checksums files   ;-) files/vmware.rc
>>> checksums files   ;-) files/vmware.xml
>>> checksums files   ;-) files/90vmware-server
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-vmware-authd-amd64
>>> checksums files   ;-) files/vmware-server-1.0.0.20925-vmware-authd-x86
>>> checksums files   ;-) files/digest-vmware-server-1.0.0.20925
>>> checksums src_uri ;-) VMware-server-e.x.p-20925.tar.gz
>>> Unpacking source...
>>> Unpacking VMware-server-e.x.p-20925.tar.gz to /var/tmp/portage/vmware-server-1.0.0.20925/work
 * Applying vmware-server-1.0.0.20925-config.patch ...                         
                                  [ ok ]
 * Applying vmware-server-1.0.0.20925-config2.patch ...                        
                                  [ ok ]
 * Applying vmware-server-1.0.0.20925-config3.patch ...                        
                                  [ ok ]
 * Applying vmware-server-1.0.0.20925-config4.patch ...                        
                                  [ ok ]
 * Applying vmware-server-1.0.0.20925-services.patch ...                       
                                  [ ok ]
 * Removing empty RPATH variables from perl libraries...
`/var/tmp/portage/vmware-server-1.0.0.20925/work/vmware-server-distrib/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/VmPerl/VmPerl.so'
probably isn't a 64-bit LSB-first ELF file.
elf_open: Exec format error
`/var/tmp/portage/vmware-server-1.0.0.20925/work/vmware-server-distrib/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/VmdbPerl/VmdbPerl.so'
probably isn't a 64-bit LSB-first ELF file.
elf_open: Exec format error
`/var/tmp/portage/vmware-server-1.0.0.20925/work/vmware-server-distrib/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/HConfig/HConfig.so'
probably isn't a 64-bit LSB-first ELF file.
elf_open: Exec format error
open: Permission denied
elf_open: Invalid argument
open: Permission denied
elf_open: Invalid argument
open: Permission denied
elf_open: Invalid argument
open: Permission denied
elf_open: Invalid argument
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/vmware-server-1.0.0.20925/work/vmware-server-distrib ...
>>> Source compiled.
>>> Test phase [not enabled]: app-emulation/vmware-server-1.0.0.20925

>>> Install vmware-server-1.0.0.20925 into /var/tmp/portage/vmware-server-1.0.0.20925/image/ category app-emulation
 * Adding answers to /etc/vmware/locations
man:
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/VmPerl/VmPerl.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/VmdbPerl/VmdbPerl.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/HConfig/HConfig.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/XML/Parser/Expat/Expat.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/MIME/Base64/Base64.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/auto/IO/IO.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/auto/Socket/Socket.so

...
[minor QA notices snipped]
...

!!! ERROR: app-emulation/vmware-server-1.0.0.20925 failed.
Call stack:
  ebuild.sh, line 1933:   Called dyn_install

!!! Aborting due to serious QA concerns with RUNPATH/RPATH
!!! If you need support, post the topmost build error, and the call stack if
relevant.

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

Am I missing some PERL modules?



# emerge --info
>>> cfg-update-1.8.0-r3 : Building checksum index... (takes a few seconds)  done!

Portage 2.1_pre5-r4 (default-linux/amd64/2005.1, gcc-3.4.5, glibc-2.3.6-r3,
2.6.15-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.15-gentoo-r7 x86_64 AMD Opteron(tm) Processor 246
Gentoo Base System version 1.12.0_pre16
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5-r2, 2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=opteron -mtune=opteron -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/X11/xdm/Xservers /etc/fonts /etc/gconf /etc/rc.d
/etc/rsync /etc/terminfo /etc/wget /etc/env.d"
CXXFLAGS="-O2 -march=opteron -mtune=opteron -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildpkg ccache distlocks sandbox sfperms strict userpriv
usersandbox"
GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk                
http://ftp.easynet.nl/mirror/gentoo                
http://trumpetti.atm.tut.fi/gentoo/                
ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo                
http://ftp.uni-erlangen.de/pub/mirrors/gentoo                
http://distfiles.gentoo.org                
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_GB.ISO-8859-15"
LC_ALL="en_GB.ISO-8859-15"
LINGUAS="en_GB"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages/packages.kde"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://gaia.home/gentoo-portage"
USE="amd64 X alsa arts avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr
crypt cups directfb dri dvd eds emboss encode fbcon foomaticdb fortran gif gimp
gimpprint gphoto2 gpm gstreamer gtk gtk2 hal imlib ipv6 ithreads javascript
jpeg kde kdeenablefinal libcaca lzw lzw-tiff mp3 mpeg ncurses nls nptl nsplugin
nvidia ogg opengl pam pdflib perl png ppds python qt quicktime readline scanner
sdl sox spell ssl tcpd tiff truetype truetype-fonts type1-fonts unicode usb
userlocales vorbis wmf xpm xv zlib elibc_glibc input_devices_keyboard
input_devices_mouse kernel_linux linguas_en_GB userland_GNU video_cards_nv
video_cards_nvidia"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LDFLAGS

Hi Peter, no you're not missing any perl modules.  I'm *guessing* that chrpath
was compiled natively on a 64-bit system and then unbeknownst to me will only
work on 64-bit binaries (which of course, these aren't).  I've got absolutely
no clue how to fix it at the moment, could any other AMD64 users offer a
possible solution?  I'll see if I can look into it at some point and try and
figure you out a work around.  I was hoping that the rpath problems would have
been fixed in the 22088 build, but seemingly they're still there even though I
reported a bug direct to upstream.  So yeah, I'm a bit beat at the moment,
leave it with me, and I'll see what I can do...

(In reply to comment #111)
> Hi Peter, no you're not missing any perl modules.  I'm *guessing* that chrpath
> was compiled natively on a 64-bit system

Yes, that's true.

> and then unbeknownst to me will only
> work on 64-bit binaries (which of course, these aren't).

I should have checked first, but indeed:

# file
/var/tmp/portage/vmware-server-1.0.0.20925/work/vmware-server-distrib/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/VmPerl/VmPerl.so
/var/tmp/portage/vmware-server-1.0.0.20925/work/vmware-server-distrib/lib/perl5/site_perl/5.005/i386-linux/auto/VMware/VmPerl/VmPerl.so:
ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux
2.0.0, not stripped

> I've got absolutely
> no clue how to fix it at the moment, could any other AMD64 users offer a
> possible solution?  I'll see if I can look into it at some point and try and
> figure you out a work around.  I was hoping that the rpath problems would have
> been fixed in the 22088 build, but seemingly they're still there even though I
> reported a bug direct to upstream.  So yeah, I'm a bit beat at the moment,
> leave it with me, and I'll see what I can do...

Ok, no problem. I've been waiting some time for vmware already...  :-)

Meanwhile I'll have a look into using a 32-bit chroot jail for this stuff.
Thanks from me too for all the work you've done on this, Mike.

vmware-server fails to emerge if FEATURE="userpriv" is enabled when doing
"chrpath -d $sobj" :

open: Permission denied
elf_open: Illegal seek
open: Permission denied
elf_open: Illegal seek
open: Permission denied
elf_open: Illegal seek
open: Permission denied
elf_open: Illegal seek

And leading to :
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/auto/IO/IO.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/auto/Socket/Socket.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/XML/Parser/Expat/Expat.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/MIME/Base64/Base64.so



emerge works well if userpriv is disabled.

my emerge --info :
Portage 2.1_pre5-r4 (default-linux/x86/2006.0, gcc-3.4.5, glibc-2.4-r0,
2.6.14.6-r2d2 i686)
=================================================================
System uname: 2.6.14.6-r2d2 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz
Gentoo Base System version 1.6.14
ccache version 2.4 [enabled]
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O2 -mtune=pentium4 -fomit-frame-pointer -funroll-loops
-pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=pentium4 -O2 -mtune=pentium4 -fomit-frame-pointer
-funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildsyspkg ccache distlocks fixpackages sandbox sfperms
strict userpriv usersandbox"
GENTOO_MIRRORS="ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo/
http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/
http://trumpetti.atm.tut.fi/gentoo/ http://ftp.heanet.ie/pub/gentoo/
http://mirror.switch.ch/ftp/mirror/gentoo/
http://ftp.gentoo.skynet.be/pub/gentoo/"
LANG="fr_FR.UTF-8"
LC_ALL="fr_FR.UTF-8"
LINGUAS="fr"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/gcpan-portage /usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 S3TC X X509 a52 aac acl acpi acpi4linux alsa apache2 apm asf async
audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr codecs
commercial crypt cups dba devmap dga distribution dnd dri dv dvd dvdread editor
emboss encode esd expat extensions faad fbcon ffmpeg firefox flac foomaticdb
fortran freetype fs gdbm gif gimp glut gmp gpm gtk gtk2 hal idled idn
imagemagick imap imlib2 iproute2 ipv6 ithreads jabber java jce jpeg jpeg2k kde
kdeenablefinal kipi kqemu lcms libcaca libg++ libwww live mad maildir matroska
md5sum mikmod mmx mng monkey motif mozdevelop mozilla mozsvg mp3 mpeg
mpm-worker musepack ncurses network nls no_wxgtk1 nptl nptlonly nsplugin nvidia
ofx ogg opengl pam pam_chroot pdflib perl php pic png povray print python qt
quicktime rdesktop readline real samba sasl scanner sdl shaper slang softmmu
speex spell sse sse2 ssl stream svg sysfs syslog tcpd tetex theora threads tiff
tools truetype truetype-fonts type1 type1-fonts udev unicode usb userlocales
v4l v4l2 vcd vlm vorbis win32codecs wxwindows x264 xcomposite xml xml2 xprint
xrandr xscreensaver xv xvid zlib zvbi elibc_glibc input_devices_keyboard
input_devices_mouse kernel_linux linguas_fr userland_GNU video_cards_nv
video_cards_nvidia"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LDFLAGS

Okay, I left this lingering around for a while in my system by using the old
ebuild, but now I updated to use the svn, so a couple of notes that I can see
here :)

The dependency over virtual/x11 or the set of modular X deps should be
conditional on the architecture: on amd64 it doesn't need them, as it takes the
32-bit version from emul-linux-x86-xlibs, so it should have a !amd64? ( )
conditional.

I'd have to wait for glibc and stuff to build before checking if i have to edit
vmware-server-modules so to fix the build with GCC 4.1.. in case,
http://planet.gentoo.org/developers/flameeyes/2006/01/26/vmware_kernel_and_gcc_4_1
should do it.

vmware server v. 22088 is online. Anyone tested it?

R. Roland

(In reply to comment #114)

I went through the folders, renaming the ebuild and patch files (for a in
*20925*; do b=`echo $a | sed -e 's/20925/22088/'`; cp $a $b; done), emerged,
and it seems to be working fine.

Ok, so next update's ready and here's the rundown:

Firstly, it's now for the 22088 build rather than the 20925.  You'll notice
these are all still here, that's because I'm now working exclusively from
Paul's subversion repository.  In case you missed the address, please look back
at comment 95.

Secondly, I've hopefully fixed the userpriv problems.  It turns out there was
no write access on the files when they were unpacked, so that's added before
the chrpath command and removed aftwards.

Thirdly, I've now tried to add ${ROOT} support to both the main server and
console versions.  As far as I can tell this only affects pkg_config and
pkg_postinst routines.  The preinst uses ${D} which I don't believe requires a
${ROOT}, please somebody who knows what's going on with ${ROOT} correct me if
I'm wrong, I'm just working from random comments and the only mention of
${ROOT} I could find in the handbook (which only mentioned pkg_config not
pkg_postinst).

Fourthly I've also added !amd64? to all the x dependencies.  I had removed the
x86? requirements earlier since I couldn't figure out it's purpose.  I guess
that was it.  5:)

Right, now in answer to a final couple of points.  Peter, the only solution I
can see for your problem is to package up the binaries once the rpath has been
removed and ship them with each version.  It's a bit dirty and not something I
can easily do until the portage_mirrors are shipping the package, so I'm afraid
you're probably on your own until then.  Sorry...  5:(

And Diego, I wasn't quite sure whether you were suggesting I make the gcc-4.1
makefile modification or not, so I've left it for the time being.  I already
have a patch for the internal makefiles, so it shouldn't be difficult to add
if/when necessary...

I'm still looking into the .cfg_???? problem.  Hopefully we can just make the
locations file *not* config protected, but I'm not certain.  I'm classing it as
low priority since it's been in many previous vmware ebuilds.  Again has anyone
managed to contact any of the vmware herd to see what they have to say about
all this?  Presumably they have reasons/answers for all the legacy stuff I'm
being asked to fix up?

As always, comments/questions/suggestions etc. are welcome...  5:)

The GCC 4.1 fix is needed, or it will fail emerge as it was failing
vmware-config before.

Mike, I now find that, although the rpath and scanelf errors still occur, since
upgrading to 22088 the server seems to compile ok. Now to see if it really
works...

(In reply to comment #119)
> Mike, I now find that, although the rpath and scanelf errors still occur, since
> upgrading to 22088 the server seems to compile ok. Now to see if it really
> works...

First would like to say fantastic work.  I'm running this over a dual Xeon
EMT64 system and having problem running vmware-cmd, always complaining about
missing VMPerl lib, is this related to the rpath problem.

Thanks

Martin, off the very top of my head (and this is an immediate answer), no. 
Chances are that it's some kind of 64-bit/32-bit libraries-in-the-wrong-place
problem.  I believe the vmperl modules are compiled at the end of the configure
procedure, and as such on a 64-bit system would probably be compiled in 64-bit.
 If it isn't these it's refering to, then possibly, yes, but it doesn't feel
right to me.  I'm afraid I can't really do much more investigation, but if you
can help have a poke at the problem (for instance, run vmware-cmd using strace
and post back the output, and also include just the standard output from trying
to run the command) then I can try and help remote diagnose the problem.  Hope
this helps...

I updated my article to mention Paul's subversion repository which makes
downloading the ebuilds a lot easier. Kudos to Mike and Paul for their work.

http://diaryproducts.net/about/operating_systems/unix/installing_vmware_server_on_gentoo_linux_part_2

Hannes, thanks for sumbitting your article.  It's a good guide and very handy! 
The mdns issue is probably because you upgraded to glibc-2.3.6, and I've taken
the requirements down to 2.3.5 because I haven't had any reports of failures
from anyone yet so I'm going to assume it works until proven guilty.  5:)  

You could also tell your readers that if they'd prefer, they can install
subersion and then do the following to get a copy of the repository:

cd /usr/local/overlays/
svn co http://callisto.cs.kun.nl:81/svn/trees/vmware/

and then whenever they want to check for updates, they can simply go:

cd /usr/local/overlays/vmware
svn up

Since I'm not doing revision bumps they'll have to manually re-emerge the
vmware packages to see the updates, if they'd like to help test the
installation procedures.

Also for anyone that missed it, I am now exclusively updating the subversion
repository and the attachments to this bug are no longer being updated.  Any
updates I make to the repository however, I will post mention of here.

Things are a bit busy here at the moment so those few issues still left on my
todo list will be taken care of, but perhaps not until next week sometime,
sorry...

hi mike. thanks for your great work. if you are no longer updating attachments
to this the bug, could you please mark any old attachments as obsolete?

you might also want to take a look at the $Header: $ lines in all the files.
several of them need to be removed. thanks.

(From update of attachment 81809 [details])
Right, that's all of them.  I really, really do appologize for the vast
quantities of spam, but hopefully there will be no further attachment mails, or
obsoleting mails, so that's some good news.  If anyone knows a way to obsolete
several files at once, please let me know, I'd hate to do that again...  5:(

Anyway, all done, everything's now in subversion and I'll fix up those heders
next time I do a subversion update...

The vmware-server-console ebuild probably should depend on a portage version.
The line 'unpack ./${NP}.tar.gz' does not work under portage 2.0.51.22-r3 which
expects everything to be in distfiles, but works prefectly in 2.0.54. I'm not
sure where in between this changed.

For vmware-server, vmware-config.pl probably should probably do an xinetd
reload instead of restart to play nice with other services that may be using
xinetd while vmware-config.pl is being run.

The ebuild's post-installation note now asks the user to modify
/etc/xinetd.d/vmware-authd. But is there any way to stop vmware-config.pl from
overwriting an existing, modified /etc/xinetd.d/vmware-authd? Does that file
ever contain anything customizable besides the port number? Let me just blurt
out some ideas:

Patch vmware-config.pl not to overwrite an existing file.

Patch vmware-config.pl not to overwrite an existing file if it has been
modified manually, i.e. if there are more differences than just the port
number.

Patch vmware-config.pl not to overwrite an existing file if the port number
didn't change.

Instead of patching vmware-config.pl, a wrapper script could be used also. The
wrapper script could be called vmware-config.pl and the real script could be
renamed. The wrapper makes a backup copy of the config file, calls the real
script and cleans up the mess afterwards. I think this would be the least
intrusive solution. Any thoughts?

(In reply to comment #128)
> Patch vmware-config.pl not to overwrite an existing file.

I vote this solution. Chances are many will want to edit that file to grant
access beyond the default of localhost and it would be a very small patch, just
an if statement around the section that prompts for a port number and kicks
xinetd. So if it has been run before to install the file just don't ask about
the port. Also in that patch the script could be changed to reload xinetd
instead of restart when it does install a file.

Seems like a wrapper script might be just as much work.

Well, as it turns out, vmware may well already have a solution for this.  It
has a rudimentary installation database that keeps track of all the files
installed, so it knows which ones it can modify and which it can't.  The very
bottom of the ebuild (in fact just before the merge, and I mean *just* before
it), rebuilds this to get all the date/time stamps correct.  Removing an entry
from there about it may well get it to not overwrite it.  What I'm trying to
say is that vmware may already have the solution, and it's just we're
butchering the install so much that it isn't working quite right.  Again,
something to add to my list but it's becoming quite long, so if you fancy a
little dive into perl (something I'd not recommend at the best of times) then
take a look in the vmware-console-config.pl and see what you can find about it.
 Specifically references to /etc/vmware/locations would be a good place to
look.  If you find anything, post it back here, I'll check it over and get it
pushed into the repository...

Also remember that I am really wanting to *not* install the vmware-config.pl
file, at all.  Instead, the vmware-server-modules ebuild should take care of
building all of the modules, allowing it to be used with module-rebuild, while
the rest of "vmware-config.pl" should probably be withing a pkg_config section
in the ebuild. 

Basically, the user just runs: emerge --config vmware-server

This resolves the problem of vmware-config.pl doing *anything* that we don't
want it to do and makes things "fit" better with Gentoo.  I plan on assisting
with this  once I get some time, as I want the same thing for vmware-player and
vmware-workstation.  Unfortunately, time just isn't as abundant as I would like
and this is actually a fairly complex operation to add to the ebuilds.

Indeed it is Chris, however we're halfway there.  The vmware-server-modules
(which I'd be willing to bet money are the same for
workstation/player/whatever) seem to be ok as I haven't had any bug reports
relating directly to them.  I do have to note however that after doing a
complete rebuild recently on one of my dev boxes to try out gcc-4.1/glibc-2.4 I
can't compile the modules, but I'm going to work on that next.  As to a
complete migration to --config, is that allowed to ask questions/be
interactive?  I'm also a little concerned about recoding work that's already
been doing.  Adding lots of checks to make sure stuff doesn't get over written
will presumably add a large overhead to maintaining the ebuild for new versions
(should they change anything).  At the moment removing the module build bit is
a patch to comment out three lines...  Anyway, I'll keep my focus directed on
fixing up the little issues and possibly providing work arounds for the rather
ugly perl script vmware provide (a lot of which is designed to be
cross-platform/legacy safe etc) and try and get server committed rather than
requiring people to keep track of the subversion repos.  I think the --config
bit can wait, nice though it'd be, for everyone to have a little more time/the
next release of a vmware product...  Anyway, glad to see people taking an
interest in it, keep it up, everybody!  5:)

(In reply to comment #132)
> Indeed it is Chris, however we're halfway there.  The vmware-server-modules

I know.  I was just restating a point.  Your work has been awe-inspiring and I
truly do appreciate it.

> can't compile the modules, but I'm going to work on that next.  As to a
> complete migration to --config, is that allowed to ask questions/be
> interactive?  I'm also a little concerned about recoding work that's already

Yes.  Anything under pkg_config *can* be interactive since it is not run
automatically.

> been doing.  Adding lots of checks to make sure stuff doesn't get over written
> will presumably add a large overhead to maintaining the ebuild for new versions

Well, to be honest, I would rather do it correctly and have a little bit of
extra work on my end for newer versions than to use anything outside of
portage.  Forcing a user to run an external script over and over again for no
"real" gain in my book is a waste of time.  I would much prefer the user only
need to run "emerge --config vmware-server" after a version update and *never*
at any other time.

> (should they change anything).  At the moment removing the module build bit is
> a patch to comment out three lines...  Anyway, I'll keep my focus directed on
> fixing up the little issues and possibly providing work arounds for the rather
> ugly perl script vmware provide (a lot of which is designed to be
> cross-platform/legacy safe etc) and try and get server committed rather than
> requiring people to keep track of the subversion repos.  I think the --config
> bit can wait, nice though it'd be, for everyone to have a little more time/the
> next release of a vmware product...  Anyway, glad to see people taking an
> interest in it, keep it up, everybody!  5:)

I would have no problem waiting on the --config stuff, though I would *much*
prefer not to.  That being said, I don't want to keep this out of portage for
*only* that reason, as I know this can be very useful to people and you're
"almost there" in regards to having everything else working perfectly. 
Excellent work, by the way.

Thanks Chris, but it looks like I might've spoken too soon!  5:(  I tried
building vmware-server-modules on a dev box that I updated to using
gentoo-sources-2.6.15-r7 rather than vanilla-sources that I always used to use
(mostly because of the excellent vesafb-ng patch).  Unfortunately this is now
causing :

 * Preparing vmmon module
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
rule.
  CC [M] 
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:37:5:
warning: "VMW_HAVE_EPOLL" is not defined
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:43:5:
warning: "VMW_HAVE_EPOLL" is not defined
In file included from include/asm/mpspec.h:6,
                 from include/asm/smp.h:19,
                 from include/linux/smp.h:20,
                 from include/linux/sched.h:27,
                 from include/linux/module.h:11,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:13:
include/asm/mpspec_def.h:78: warning: 'packed' attribute ignored for field of
type 'unsigned char[5u]'
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:21,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:50:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:60:
error: conflicting types for 'poll_initwait'
include/linux/poll.h:45: error: previous declaration of 'poll_initwait' was
here
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:145:
warning: initialization from incompatible pointer type
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:149:
warning: initialization from incompatible pointer type
make[2]: ***
[/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o]
Error 1
make[1]: ***
[_module_/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only]
Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'
make: *** [vmmon.ko] Error 2

Reverting to vanilla-sources-2.6.16-r6 lets them compile fine.  The only
references to the errors I'm encountering suggest using the vmware-any-any
package.  I've tried that with update98 but suffer the same problems.  One
suggestion was that the kernel source had been in some way stripped down, but I
don't really know where to look.

So, has anyone else had any encounters with this?  Any ideas as to what might
be causing it?  Why it's different to the vanilla kernel?  I'm gonna
potentially try a binary search of the patch space to find out which patch is
causing the problem, but probably not until Sunday...

Ok, sorry, figured it.  The vm_check carried out in the makefiles has -Werror
whilst carrying out the test.  The check for epoll obviously fails because of a
warning rather than a real error, and as such the module attempts to be built
differently, redefining stuff that's already defined.  It's entirely possible
this is an issue because the dev box I was using is also running glibc-2.4 and
gcc-4.1.  However, since these will eventually become the de-facto standard,
I'm probably going to add a patch to the Makefile so that it uses -Wno-error
instead.  Is anyone with a bit more experience able to tell me whether this is
a dirty hack or something worthwhile?  I'm not fully sure of the repurcussions,
so any advice would be useful.  Thanks...  5:)

No please _don't_ remove that -Werror, it's there for a reason in the tests: if
the functions prototypes does not coincide or are implicit, it throws a
warning, that -Werror transform in an error and make sure that the test tell if
the functions exists or not.
See my post in planet about GCC 4.1, you need to use -Wno-unused to ignore the
dummy extra warning from GCC 4.1, and that should be it.

D'oh, you're completely right, and worse you already told me that just a couple
of days ago!!!  My brain is really mis-firing at the moment, I completely
appologize, I should have remembered that...  5:(  Hopefully as of Monday I'll
get myself sorted out (I'm on holiday!  YAY!) so I should have lots of time to
go through all the recent fix requests and get them sorted out...  Thanks again
Diego

-Werror in C*FLAGS for any package in the tree is incorrect. It makes the
package unusable with future and unexpected compilers.

-Werror is not used during build but during tests, and unless they start
writing their own c processor to check if kernel functions variables and stuff
are defined correctly, -Werror is a perfect solution for the tests they have.
Did you actually look at the code before deciding it was heretic?

Uh huh. -Werror can make things explode on arbitrary code depending upon what
the compiler feels like doing at any particular time. It's not a valid way of
checking for a restricted set of things.

Well if you want to find a better way and propose that to vmware is probably a
good idea, in the mean time if you remove that -Werror you're breaking the hell
out of the package more than it will do elseway, so please shut up if you don't
have better solutions...

By the way, the problem seems not to appear on amd64 (although epoll.c fails
here by default, too), so might be x86 specific.

Okay, I'll try to summarise the problem here. Basically it's easy to
misunderstand the way the tests are run because they are run two times, the
fist when you call "make", due to the sourcing of Makefile.kernel, the second
when Makefile.kernel is sources but by the Kbuild makefiles, which sets the
correct include paths and stuff so that the tests are compiled correctly.
For some reasons, there's one extra warning in the epoll check that I don't
have, that causes the epoll test to fail.

To spot it, the simplest way is to unpack the vmware-server-modules ebuild,
then replace in Makefile.kernel the vm_check_build function with

vm_check_build = $(shell echo $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_KERNEL) \
        $(EXTRA_CFLAGS) -Iinclude2/asm/mach-default
-DKBUILD_BASENAME=\"$(DRIVER)\" \
        -Wno-unused -Werror -S -o /dev/null -xc $(1) \
        &> /dev/stderr; \
        if $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_KERNEL) \
        $(EXTRA_CFLAGS) -Iinclude2/asm/mach-default
-DKBUILD_BASENAME=\"$(DRIVER)\" \
        -Wno-unused -Werror -S -o /dev/null -xc $(1) \
        &> /dev/stderr; then echo "true" > /dev/stderr; echo "$(2)"; else echo
"false" > /dev/stderr; echo "$(3)"; fi)

and look at the stderr output of "make".

if someone reproducing the GCC 4.1 problem on x86 after editing the makefile
(sed -i -e 's:-Werror:-Wno-unused-value -Werror:' ${dir}/Makefile.kernel) can
paste the output, we can look at which other warning disable to let it build.

No, using -Wno-error is not an option, the second test is supposed to fail on
modern kernels, so if nobody has better ready _practical_ solutions, we can
continue this way.

(In reply to comment #142)
> No, using -Wno-error is not an option, the second test is supposed to fail on
> modern kernels, so if nobody has better ready _practical_ solutions, we can
> continue this way.

A more appropriate test would be to check the kernel's capabilities, either by
version or directly.

Ciaran: Do you want to rewrite all of vmware's make scripts. And take the blame
if things fail. It's easier if they fail because of too restrictive tests, than
if they produce unexpected (or even insecure) results because the tests were
passed when they shouldn't.

Re: -Werror

I think both Ciaran's and Diego's points are valid and nobody should be told to
"shut up". Sorry, I had to say that. As Diego put it, -Werror is there for a
reason and just taking it out is no solution. OTOH, the problem with -Werror is
that it turns every warning into an error not just the one the test is looking
for. Future changes to either the compiler or the VMWare modules' source code
could introduce another unwanted warning that breaks the build process.
Suppressing an unwanted warning by using -Werror -Wno-xxx is only a temporary
solution until another one comes up.

Ideally, GCC should have a way of turning one individual warning into an error.
Unfortunately, that is not the case so what about omitting -Werrror and
grepping the compiler output for the particular warning instead?

(In reply to comment #144)
> Ciaran: Do you want to rewrite all of vmware's make scripts. And take the blame
> if things fail. It's easier if they fail because of too restrictive tests, than
> if they produce unexpected (or even insecure) results because the tests were
> passed when they shouldn't.

You're missing it. The way they are currently is equally prone to passing when
it shouldn't (and thus you can use the bogus "ooh, it might be insecure!"
argument there too), and even more prone to not passing when it should. 

Ok, so here's my take on the overwritten vmware-auth.conf issue. The patch
makes sure that we never overwrite an existing conf file unless it has the
exact modification date as in the database in which case we can be pretty sure
that it is the one that we wrote and it should be safe to assume that we can
overwrite it.

I ran tests for the following cases:

File does not exist (1)
File exists
  and is not in database (first run of patched vmware-config.pl) (2)
  and is in database
    and timestamp in database is the same as the mtime of file (3)
    and timestamp in database is different (4)
    and no timestamp in database (5)

I think I have pretty much covered my bases. This fix actually belongs more to
vmware than to the ebuild and it should probably be posted upstream.

Attachments are on their way ...

Created an attachment (id=82407) [details]
Fixes issue with vmware-config.pl overwriting /etc/xinetd.d/vmware-authd.

Ok, running it just unpacked (rather than within the ebuild environment) turned
up an error that's been bugging me since I moved to gcc-4.1.  Loads of things
have it, and it's the following:

gcc -m32 -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-ffreestanding -O2 -fomit-frame-pointer -pipe -msoft-float
-mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=i686 -mtune=pentium4
-Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign
-Wall -Wstrict-prototypes -DVMW_USING_KBUILD -DVMMON -DVMCORE
-I/root/tmp/orig/vmmon-only/./include -I/root/tmp/orig/vmmon-only/./common
-I/root/tmp/orig/vmmon-only/./linux -I/root/tmp/orig/vmmon-only/./vmcore
-Iinclude2/asm/mach-default -DKBUILD_BASENAME="vmmon" -Wno-unused
-Wno-attributes -Werror -S -o /dev/null -xc
/root/tmp/orig/vmmon-only/./autoconf/epoll.c
cc1: warnings being treated as errors
In file included from include/asm/mpspec.h:5,
                 from include/asm/smp.h:18,
                 from include/linux/smp.h:19,
                 from include/linux/sched.h:26,
                 from include/linux/mm.h:4,
                 from include/linux/poll.h:11,
                 from /root/tmp/orig/vmmon-only/./autoconf/epoll.c:5:
include/asm/mpspec_def.h:78: warning: 'packed' attribute ignored for field of
type 'unsigned char[5u]'false

Unfortunately I've looked through the warning options for gcc-4.1
(http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Warning-Options.html) and I can't
find the right one to turn that kind of thing off.  I've tried -Wno-packed and
-Wno-attributes to no avail.  Anybody any ideas how to turn off this specific
warning?

Hannes, thanks for the patch, I'll review it sometime this week and try and get
it (and all the other little clean ups) integrated into the subversion
repository...

I'd also like to avoid an argument, or certainly any harsh words from either
side.  I realise Ciaran has a quality assurance issue to defend, and I concur
that the ebuilds could break in new and unusual ways in the future.  I also can
see why Diego would wish to alter the ebuilds as little from their original
intent as possible, since disabling a warning could cause the tests to pass
successfully and then cause the full complation to fail.

Either way there will be some errors and they'll be reported one way or
another.  Since I'm currently developing these ebuilds I'm going to use the
following compromise: The patch to remove my warning problems could easily be
extended for any other warnings found in the future, so we'll use that for the
time being, however if it turns out to be too much work, or causing people
aggravation, then we can alter the patch to remove all warnings in the future,
and hope that the numbers of bugs stops increasing.  Hopefully this sounds fair
to both sides, if not, please let me know as gently as possible and we'll try
and come to a workable middleground.  5:)

Finally, I'd like to thank Diego again for all his help in diagnosing my
current issue, and Ciaran for offering an alternative perspective that needed
to be considered...

Scratch that last comment.  A little more checking (and discovery of a typo in
my test) shows that it is in fact -Wno-attributes, but that unfortunately turns
off all attribute warnings, not just the 'packed' attribute.  I'll work up a
patch that applies this and -Wno-unused.  I don't really know the other type of
attribute failures that occur, but apparently there was a patch for this that
went into the 2.6.15 kernel (git's 3 and 5 apparently).  Quite why it's not in
the gentoo sources I'm not sure, but that's certainly why it worked with the
2.6.16 vanilla sources...

Ok everybody, here's the latest installment.  Available now in all good
subversion repositories!  5:)  It's basically a tidy up of all the little
requests I hadn't had time to work on recently.

Here's the changelog:

Update vmware-server's config file with Hannes' patch, vmware-authd should no
longer be overwritten.
Added my own patch to fix vmware restart xinetd rather than just reloading it.
Altered /etc/init.d/vmware to ensure that xinetd is started before the vmware
service.
Fix up dependencies in vmware-server-* to ensure that portage can unpack local
files.
Fix vmware-server-* ebuild cvs headers.
Vmware-server-modules gcc4 patch.

Could people please test this out for me?  Specifically the starting/stopping
of xinetd in relation to vmware, and also during vmware configuration process,
since these are pretty new and I just knocked them up this afternoon...

Things not fixed up yet:

Chris, I'm going to look into what'd be required to move the configuration perl
script into a --config request.  Most notably would be the removal of the
not_configured flag from the init script (the vmware init script, not our
wrapper on).  At the moment, if the vmware service ever fails to start up, it
won't start again until the whole configuration's been re-run.  This is a
little bit more than daft, but hopefully we can fix this up.  It may also be
worth turning this into an eclass, since the config script seems to be shared
between their applications...

Martin, from comment 120, I haven't heard back from you about what's causing
your problems, if you need help further investigating the problem, please let
me know and I'll try and talk your through it.  If it's no longer causing you
problems, please let us know as well...

Peter, from comment 110, I still haven't worked out a good system for packing
up the various rpath-patched 32-bit binaries.  As I mentioned before, this is
only likely to happen once it gets into portage and we can deliver larger files
via the mirrors.  Sorry...

I think that's everything on the todo list.  As always any difficulties,
suggestions etc with this release, please don't hesitate to report it here, and
I'll get to it as soon as I can...

in vmware-server-module, your makefile2.patch breaks the module compilation on
my box : gcc 3.4.5 / kernel 2.6.16

Works very well removing this patch : my vms run correctly

Here is the compilation log with makefile2.patch :

>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/vmware-server-modules-1.0.0.22088/work ...
 * Preparing vmmon module
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.16'
make[1]: AVERTISSEMENT: serveur de t

in vmware-server-module, your makefile2.patch breaks the module compilation on
my box : gcc 3.4.5 / kernel 2.6.16

Works very well removing this patch : my vms run correctly

Here is the compilation log with makefile2.patch :

>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/vmware-server-modules-1.0.0.22088/work ...
 * Preparing vmmon module
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.16'
make[1]: AVERTISSEMENT: serveur de tâches n'est pas disponible: utilisation de
-j1. Ajouter « + » à la règle parent du make.
  CC [M] 
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o
Dans le fichier inclus à partir de
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
          à partir de
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:37:5:
attention : « VMW_HAVE_EPOLL » n'est pas défini
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:43:5:
attention : « VMW_HAVE_EPOLL » n'est pas défini
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:60:
erreur: types conflictuels pour « poll_initwait »
include/linux/poll.h:45: erreur: déclaration précédente de « poll_initwait
» était ici
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:60:
erreur: types conflictuels pour « poll_initwait »
include/linux/poll.h:45: erreur: déclaration précédente de « poll_initwait
» était ici
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:145:
attention : initialisation d'un type pointeur incompatible
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:149:
attention : initialisation d'un type pointeur incompatible
make[2]: ***
[/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o]
Erreur 1
make[1]: ***
[_module_/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only]
Erreur 2
make[1]: Leaving directory `/usr/src/linux-2.6.16'
make: *** [vmmon.ko] Erreur 2

Hmmm, curiouser and curiouser...  This lokos *exactly* like the errors I had
been getting *before* adding that patch, on the latest gentoo-sources (only not
in French of course).  Well, back to the drawing board I guess...

Actually, Guillaume, is there any chance you could manually unpack the modules,
and edit the makefiles as mentioned in comment 142, and post me the results
(either directly or on the bug tracker) and I'll try and figure out what's
going on this time?  Thanks...

Simpler from that, just try to use

echo "int main() {}" | gcc -Wno-unused -Wno-attributes - -o /dev/null

if that outputs warnings about -Wno-unused or -Wno-attributes being unknown,
the patch has to be applied conditionally of gcc 4.1 .

OK, I see I will not have to unpack it and compile manually :

Here is the output of your command (switched to english this time ;)) :

$ echo "int main() {}" | gcc -Wno-unused -Wno-attributes - -o /dev/null
gcc: -E or -x required when input is from standard input

So need to add "-x c" option :

$ echo "int main() {}" | gcc -Wno-unused -Wno-attributes -x c - -o /dev/null
cc1: error: unrecognized command line option "-Wno-attributes"

(In reply to comment #151)

> Peter, from comment 110, I still haven't worked out a good system for packing
> up the various rpath-patched 32-bit binaries.  As I mentioned before, this is
> only likely to happen once it gets into portage and we can deliver larger files
> via the mirrors.  Sorry...

Ok, never mind :)  I seem to be able to use your setup anyway - thanks again!

But you seem to have broken something. This is what I get now after svn up. Oh,
and I've just upgraded my kernel from 2.6.15-r7 to 2.6.16:

$ cat /var/log/portage/3691-vmware-server-modules-1.0.0.22088.log
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     2.6.16-gentoo
>>> Unpacking source...
>>> Unpacking VMware-server-e.x.p-22088.tar.gz to /var/tmp/portage/vmware-server-modules-1.0.0.22088/work
>>> Unpacking ./vmware-server-distrib/lib/modules/source/vmmon.tar to /var/tmp/portage/vmware-server-modules-1.0.0.22088/work
 * Applying vmware-server-modules-1.0.0.22088-makefile.patch ...               
                                  [ ok ]
 * Applying vmware-server-modules-1.0.0.22088-makefile2.patch ...              
                                  [ ok ]
 * Converting vmmon-only/Makefile to use M= instead of SUBDIRS= ...            
                                  [ ok ]
>>> Unpacking ./vmware-server-distrib/lib/modules/source/vmnet.tar to /var/tmp/portage/vmware-server-modules-1.0.0.22088/work
 * Applying vmware-server-modules-1.0.0.22088-makefile.patch ...               
                                  [ ok ]
 * Applying vmware-server-modules-1.0.0.22088-makefile2.patch ...              
                                  [ ok ]
 * Converting vmnet-only/Makefile to use M= instead of SUBDIRS= ...            
                                  [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/vmware-server-modules-1.0.0.22088/work ...
 * Preparing vmmon module
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.16-gentoo'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
rule.
  CC [M] 
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:37:5:
warning: "VMW_HAVE_EPOLL" is not defined
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:43:5:
warning: "VMW_HAVE_EPOLL" is not defined
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:60:
error: conflicting types for 'poll_initwait'
include/linux/poll.h:45: error: previous declaration of 'poll_initwait' was
here
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:60:
error: conflicting types for 'poll_initwait'
include/linux/poll.h:45: error: previous declaration of 'poll_initwait' was
here
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:145:
warning: initialization from incompatible pointer type
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:149:
warning: initialization from incompatible pointer type
make[2]: ***
[/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o]
Error 1
make[1]: ***
[_module_/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only]
Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.16-gentoo'
make: *** [vmmon.ko] Error 2

!!! ERROR: app-emulation/vmware-server-modules-1.0.0.22088 failed.
Call stack:
  ebuild.sh, line 1565:   Called dyn_compile
  ebuild.sh, line 974:   Called src_compile
  ebuild.sh, line 1280:   Called linux-mod_src_compile

!!! Unable to make                                   auto-build.
!!! If you need support, post the topmost build error, and the call stack if
relevant.

For the time being I've reverted to the files I'd assembled from this bug, and
recompiled against the new kernel with no apparent problems.

Sorry to be the bearer of bad tidings!   :-(

Yep, sorry both of you, in my eagerness to get a version ready for gcc-4.1
which is round the corner, I rather hastily applied it all builds assuming that
gcc-3.4.5 would have all the same options.  I'm going to go away and figure out
how to determine whether it's gcc-4+ being used to compile the system, and not
apply the makefile2.patch if it is.  That should solve those problems, and I'll
try to get that into the repository by this evening.

Thanks again for everybody's help bugtesting, it's been invaluable...  5:)

Hint: toolchain-funcs.eclass, gcc-major-version()  ;)

Hehehe, yeah, just spotted that one after a grep of gcc through the eclass
directory, but thanks for the hint.  I'll get on it right after I get back from
town...

Ok, all fixed up and checked into subversion.  Please keep the bug reports
coming, the ebuild's looking pretty good now...  5:)

OK, all compile very well now with gcc 3.4.5
Thanks for all your work !

OK, which file do I have to use?

OK, which file do I have to use?(In reply to comment #162)
> OK, which file do I have to use?
> 
Found the subversion comment. Ingnore previous comment.

A dependency to xinetd should be added.

(In reply to comment #164)
> A dependency to xinetd should be added.

There's more than one inetd. Is xinitd the only one that works?

Ok, well, firstly vmware-server does have a runtime dependency on
sys-apps/xinetd.  I've also now made the service have a dependency on the
xinetd service so that should ensure xinetd is started when vmware is.

As to using any inetd, whilst technically the configure/init scripts that
vmware provides can run with both xinetd and inetd, I haven't tested the inetd
support, and I dunno if it can run with the full compliment of programs that
provide virtual/inetd.

I realise that I was under the presumption that xinetd is the only secure inetd
available out there and so didn't really think about it.  If other people use
other inetd's please alter the ebuilds to test them out and if it all seems
positive lemme know and I'll make the changes.  I'd prefer not to do it until I
have a positive response just to save time...

Rene, perhaps I'm misreading your comment, do you mean that xinetd is missing a
dependency, or that vmware-server is missing a dependency on xinetd?  Please
let me know and I'll try and get it all cleared up as soon as I can...  5:)

(In reply to comment #166)
> Ok, well, firstly vmware-server does have a runtime dependency on
> sys-apps/xinetd.  I've also now made the service have a dependency on the
> xinetd service so that should ensure xinetd is started when vmware is.
> 
> As to using any inetd, whilst technically the configure/init scripts that
> vmware provides can run with both xinetd and inetd, I haven't tested the inetd
> support, and I dunno if it can run with the full compliment of programs that
> provide virtual/inetd.
> 
> I realise that I was under the presumption that xinetd is the only secure inetd
> available out there and so didn't really think about it.  If other people use
> other inetd's please alter the ebuilds to test them out and if it all seems
> positive lemme know and I'll make the changes.  I'd prefer not to do it until I
> have a positive response just to save time...
> 
> Rene, perhaps I'm misreading your comment, do you mean that xinetd is missing a
> dependency, or that vmware-server is missing a dependency on xinetd?  Please
> let me know and I'll try and get it all cleared up as soon as I can...  5:)
> 

I meant vmware-server is is missing a dependency on xinetd.

I had no xinetd installed on my system. I installed vmware-server. When I
started the vmware service it failed to start the xinetd service (because
xinetd was not installed) 

Rene, I'm afraid I really haven't a clue why that happened.  Even in the
ebuilds posted here there has been sys-apps/xinetd included in the RDEPEND
variable.  The only way that vmware-server might have installed itself without
installed xinetd, is if you'd used emerge --nodeps or emerge -O when installing
it.  Could you please post the output of 'emerge --info' and also the output of
the line 'emerge -pv vmware-server'.  This will hopefully let me figure out
what's going on.  Thanks very much...

(In reply to comment #168)
> Rene, I'm afraid I really haven't a clue why that happened.  Even in the
> ebuilds posted here there has been sys-apps/xinetd included in the RDEPEND
> variable.  The only way that vmware-server might have installed itself without
> installed xinetd, is if you'd used emerge --nodeps or emerge -O when installing
> it.  Could you please post the output of 'emerge --info' and also the output of
> the line 'emerge -pv vmware-server'.  This will hopefully let me figure out
> what's going on.  Thanks very much...
> 
OK, I made a little investigation on my system and I found out that it was my
misstake. I had xinetd in /etc/portage/profile/packages.provided. Sorry about
that. Everything works fine until now. Great work, I let you know if I might
find something.

Sorry, I have been working very hard lately,

> Martin, from comment 120, I haven't heard back from you about what's causing
> your problems, if you need help further investigating the problem, please let
> me know and I'll try and talk your through it.  If it's no longer causing you
> problems, please let us know as well...
> Peter, from comment 110, I still haven't worked out a good system for packing
> up the various rpath-patched 32-bit binaries.  As I mentioned before, this is
> only likely to happen once it gets into portage and we can deliver larger 



I decided to reinstall from scratch and now I have a very similar problem to
Peter.

scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/auto/IO/IO.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/auto/Socket/Socket.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/XML/Parser/Expat/Expat.so
scanelf: rpath_security_checks(): Security problem NULL DT_RPATH in
/var/tmp/portage/vmware-server-1.0.0.20925/image//opt/vmware/server/lib/perl5/site_perl/5.005/i386-linux/auto/MIME/Base64/Base64.so

I have all the same rpath trouble but at the end I have the following message:

!!! Function dyn_install, Line 1057, Exitcode 0
!!! Insecure binaries detected

All this refering to bug 81745.  

Martin

Ok Martin, no problem, I hope the heat's off a bit now...  5:)

So my first question is just to double check that you're running on a 64-bit
(such as amd64 or ia64) system, rather than with the x86 keyword?  Assuming
this is the case, chrpath will build as a 64-bit version and won't be able to
remove the blank RPATH definitions from the 32-bit binaries.  So, the best I
can do is to request that if someone has some spare disk-space I'll create a
tar-ball with the already fixed rpath libraries for this version, and then
unpack them for all systems (which will remove the need for all the rpath
jiggery pokery too).

I'd rather not put it into the subversion repository because subversion doesn't
handle binary files very well, and would put an undue load on Paul's very
generously donated server.

If you have got some webspace that you're happy to donate to this ebuild,
please either post here, or mail me directly.  Thanks very much...

Mike  5:)

I can host it.  Just shoot me the file via email and I'll put it up at
http://dev.gentoo.org/~wolf31o2/sources/dump for now.

(In reply to comment #171)

Yes, I have a EMT64 system running the AMD64 gentoo.  Instead of hosting some
binaries, wouldn't be to hard to script the installation/compilation of rpath
in 32 bits?

Martin

Martin, I'm afraid I have no idea how to force a program to compile in 32-bit
mode under a 64-bit system, and since I don't have control over the chrpath
ebuild I have the feeling there's very little I can do.  The idea is that
vmware themselves will fix this in due course, but for the time being manually
packaging up the fixed libraries can be used for everybody, adds only 1.2 Mb to
the download and ensures that everybody's consistent.  If anyone knows how to
force the removal of a blank RPATH from a 32-bit library under a 64-bit
environment I'll be happy to consider it and see if I can implement it. 
Otherwise this looks by far the easiest solution.  Chris has very kindly
offered his webspace, and I've sent him the tar-ball, so as soon as that goes
up, I'll push out the new ebuild for people to try.

Interestingly with chrpath installed, it looks like the latest copy of portage
attempts to correct the problem for you...

(In reply to comment #174)
> Martin, I'm afraid I have no idea how to force a program to compile in 32-bit
> mode under a 64-bit system.

Humm tought it was only a mater of parsing new arguments to make and ignoring
the ones in make.conf.  Anyway.  I found that installing from a vanilla Gentoo
2006.0 it complains about RPATH but does install.  If you emerge --update
world, it becomes broken. Maybe there is a chrpath update, I haven't check yet.

vmware-cmd still doesnt work since it complains about not finding VmPerl.pm in
@INC I tried the export PERL5LIB trick but now, it complains about a missing
shared object... 

Does your ebuild takes care of this in the 32bits env, or it is just me that
have missed something?

Martin

Martin, I'm afraid I'm a little inexperienced at many of the matters you
raised.  I don't know a lot about RPATH's, simply that there's a program to
remove them, but that the 64-bit version seems not to remove them from 32-bit
binaries.  I wouldn't want to make alterations to people's make files, or
require them to do so either, but hopefully the prepackaged fixed libraries
will remove all that problem...

As to the vmware-cmd problem, and vmperl not being installed, I again have no
experience.  I've never really used vmware-cmd, not the vmperl modules,
however, I do know that the vmware-config.pl is supposed to compile some perl
modules of some kind during its run, so perhaps the configure script is failing
somewhere in the middle?  I'm afraid to do any further diagnosis I'm going to
need an exact copy of the output from when you run vmware-cmd, and I'll need
the output from the vmware-config.pl (and I believe it may create logs in
either /var/log/vmware or /tmp/vmware-configX/, which would also be helpful). 
In short, any actual results or information about the installation that you can
send me will help me track down the problem much more easily.  Also, if anyone
else thinks they might be suffering similar problems, please let me know as
well, the more test cases failing the same way we have, the easier it might be
to find the commonalities...

Thanks all of you for your time, I hope to have the rpath corrected libraries
up and working soon...

Ok, another quick update.  The subversion server now features the latest
ebuilds, such that rather than requiring the installation of chrpath and manual
patching, the pre-patched libraries for this particular version are downloaded
and used to overwrite the ones provided by vmware.  The end result should be
identical, save for the fact that users of 64-bit systems should also get the
patch rpath libraries.  As a minor note, the vmware ebuilds now also feature an
Id line, so you can determine which version you're using when reporting bugs...

I'm still trying to work with Martin to determine the amd64 problems with
vmware-cmd (which seem related to the vmware-config.pl's attempts to compile
some perl libraries natively), but hopefully we'll see if this update fixes
those problems.

As always, please report any bugs or issues here and I'll try and get to them
as quickly as I can...  5:)

On a server which does not have X installed before, I tried to emerge
vmware-server. Instead of X-6.8, I unmasked 7.0 instead. I keyworded all
packages that portage asked me to (iterative attempts).

In the end, vmware-server emerges but then when I tried to run the
configuration script, it complained of libraries missing:

--------------------
>> /opt/vmware/server/bin/vmware-config.pl
The correct version of one or more libraries needed to run VMware Server may be
missing.  This is the output of ldd /opt/vmware/server/bin/vmware:
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7ed3000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ecf000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7ebd000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7dc2000)
        libXtst.so.6 => not found
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7db1000)
        libXt.so.6 => not found
        libICE.so.6 => not found
        libSM.so.6 => not found
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7da8000)
        libz.so.1 => /lib/libz.so.1 (0xb7d96000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7c81000)
        /lib/ld-linux.so.2 (0xb7efd000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7c7e000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7c79000)

This program cannot tell for sure, but you may need to upgrade libc5 to glibc
before you can run VMware Server.
-----------------

Indeed many libraries that I keyworded were not pulled by portage (including
the missing libXtst for example)

I am not sure if this is to consider a portage bug, or if vmware-server list of
dependencies should cover all the required libraries ?

The ebuild should list all of the required dependencies.

Christophe, Chris is quite right, apparently I didn't include enough libraries
for vmware-server.  I wasn't certain what the full requirements were for
vmware-server when I first added it and tried to keep the xorg-server
requirements to a minimum, I'll fix those when I make the next ebuild release. 
That might not be immediately because I'm just testing out the ebuild with the
latest vmware release (22874 or something, up from 22088) and hopefully I'll
push all that out sometime tomorrow...

Thanks for the bug report, keep them coming!  5:)

Ok. The four missing libraries were libXtst libXt libICE libSM. Once emerged,
vmware configuration script runs fine. I forgot before to mention this was on a
x86 machine. (I installed it 3 times already on amd64 without the problem). 

But - new problem is with init script. vmware was started at the end of
configuration. But I cannot stop it, or stop/restart xinetd now :

>>/etc/init.d/vmware stop
/etc/vmware/init.d/vmware: line 667: [: -: integer expression expected
/etc/vmware/init.d/vmware: line 684: [: -: integer expression expected
* Stopping VMware services:                            [ ok ]
*   Virtual machine monitor                            [ !! ]
*   Bridged networking on /dev/vmnet0                  [ ok ]
*   Virtual ethernet                                   [ !! ]

The server itself works fine.. as I was able to connect to it remotely.

Christophe, could you please provide the output of "lsmod" and also the output
to the following command:

/sbin/lsmod | driver=vmmon awk 'BEGIN {n = 0;} {if ($1 == "'"$driver"'") n =
$3;} END {print n;}'

That's the subfunction that gets called to determine whether vmmon is in use or
not, and should return an integer.  Seemingly on your system however, it isn't
doing.  Hopefully this will let me figure out why and we can try and solve the
problem from there.  Thanks...  5:)

> lsmod
Module                  Size  Used by
vmnet                  34052  -
vmmon                 105548  -

> /sbin/lsmod | driver=vmmon awk 'BEGIN {n = 0;} {if ($1 == "'"$driver"'") n = $3;} END {print n;}'
0

But this line always always 0, even when run on my machines where server is
running (amd64)... could this depend of network options chosen during
configuration script ?

I rebooted server. I had to re-run configure script. vmware started fine. VMs
worked. But that awk command return 0 before I started vmware and after I
started it, even during using a VM. So this does not seem to be a reliable test
to know if vmware is started or not...

Hi, 

Big thanx to all for the good work!! 

I have installed the the vmware server on my host. The emerge seems to work
without errors so does the emerge of the modules package. I am also able to
load the modules vmmon & vmnet in to the kernel.

The problem/bug is after running vmware-conf.pl which seems run OK I get the
following message at the end:

* VMware Server is installed, but it has not been (correctly) configured
 * for the running kernel. To (re-)configure it, invoke the
 * following command: /opt/vmware/server/bin/vmware-config.pl.
 * VMware is not properly configured! See above.                               
                                                                               
 [ !! ]

The configuration of VMware Server e.x.p build-22088 for Linux for this running
kernel completed successfully.

How do I do about debuging this?

Cheers
Heinzg

(In reply to comment #184)
> The problem/bug is after running vmware-conf.pl which seems run OK I get the
> following message at the end:
> 
> * VMware Server is installed, but it has not been (correctly) configured
>  * for the running kernel. To (re-)configure it, invoke the
>  * following command: /opt/vmware/server/bin/vmware-config.pl.
>  * VMware is not properly configured! See above.                               
>                                                                                
>  [ !! ]
> 
> The configuration of VMware Server e.x.p build-22088 for Linux for this running
> kernel completed successfully.

For somereason vmware-config.pl did not remove /etc/vmware/not_configured. I've
seen this before but never figgured out why that file was not automaticly
removed.

(In reply to comment #185)
> (In reply to comment #184)
> > The problem/bug is after running vmware-conf.pl which seems run OK I get the
> > following message at the end:
> > 
> > * VMware Server is installed, but it has not been (correctly) configured
> >  * for the running kernel. To (re-)configure it, invoke the
> >  * following command: /opt/vmware/server/bin/vmware-config.pl.
> >  * VMware is not properly configured! See above.                               
> >                                                                                
> >  [ !! ]
> > 
> > The configuration of VMware Server e.x.p build-22088 for Linux for this running
> > kernel completed successfully.
> 
> For somereason vmware-config.pl did not remove /etc/vmware/not_configured. I've
> seen this before but never figgured out why that file was not automaticly
> removed.
> 

Thanx that did the job

Cheers
Heinzg

Ok, so as some of you may or may not know, there was a new version of
vmware-server out on the 30th of March.  The fixed some of the RPATH problems,
and added their code to fix the breakage on kernels > 2.6.15ish, so I've
dropped one of my patches.  The new version will be put into subversion once
Chris has put the new RPATH corrected libraries for this version up on his
webspace (which in case I haven't already mentioned, I'm very greatful for)! 
5:)

I'll post another message once it goes into subversion, this is just to keep
people informed.  As to the /etc/vmware/not_configured problem, if anyone can
recreate that, could they please email me their /etc/vmware/locations file, as
I think it's the content of that which is stopping the file being deleted...

Just a note that whilst testing the latest ebuilds the vmware-server-modules
ebuild failed until I ran --nodeps emerge -v vmware-server, and manually ran
the config script. This required entering the serial code as it was a new
install - I am not sure if it is possible to get the ebuild to handle that?
Other than that it seems to be working well here on two of my amd64 systems.

Hmmmm, Marcus, could you provide a little more information about how the
vmware-server-modules ebuild broke?  If I could get a log of the ebuild output,
see where in the compilation it failed, etc, that would help me figure out what
was going on a lot more...  The serial number should *not* be required for
compilation of the modules.  Also an emerge --info may also be useful.  If you
post those back here, I'll take a look into it and try and figure it out. 
Thanks  ... 5:)

VMware Server Beta 2 is now available. Anyone checked if the ebuild works with
this version?

The config patch #3 doesn't apply anymore, but doesn't even seem to be needed
anyway.
For the rest renamed ebuilds (with changed patches and filenames) works here.

(In reply to comment #157)
> I'm going to go away and figure out
> how to determine whether it's gcc-4+ being used to compile the system, and not
> apply the makefile2.patch if it is.  That should solve those problems, and I'll
> try to get that into the repository by this evening.
> 
> Thanks again for everybody's help bugtesting, it's been invaluable...  5:)

Mike, -Wno-attributes isn't recognized by gcc-4.0.x either. 

It all works fine once it's dropped from makefile2.patch (tried the renamed
ebuilds w/ latest beta2). Looks like you need to check for minor gcc version as
well (will probably need a separate patch for gcc-4.0.x, since gcc-4.0.x needs
that Wno-unused but fails with -Wno-attributes).

Ok, I'll try and get something fixed up and released when I release the new
version ebuilds.  At the moment we're just waiting for the new rpath-corrected
libraries to be put up on the webspace...

I just installed 1.0.0.2095 using this bugs' ebuilds. There are a few things I
had to do:

ln -s /etc/vmware/init.d/vmware /etc/init.d/vmware
chmod +x /opt/vmware/server/sbin/vmware-authd
chmod +x /opt/vmware/server/lib/bin/vmware-vmx
chmod +x /opt/vmware/server/lib/bin-debug/vmware-vmx

vmware-authd was using 100% cpu before doing the first two steps and didn't
output any meaningful information to the console/logs.

currently, I can start a vm but it remains in state "powering up"... nothing
else happening...

kernel: gentoo-sources-2.6.16

Well, it doesn't sound like the ebuild has been correctly set-up.  Firstly
there should be no need to symlink /etc/vmware/init.d/vmware anywhere, it
should be called by the /etc/init.d/vmware file which is installed by the
ebuild.  If it isn't installed, it means that you might have missed copying
vmware.rc into the files directory of the ebuild.  If you missed this, there
may be other files you missed that could cause further problems with the
installation.

Luckily, you can make the whole process much easier for yourself, and get the
very latest version, by using subversion to checkout a copy from the repository
very kindly maintained by Paul!  5:)  To do this, find an empty directory and
issue the command:

svn co http://callisto.cs.kun.nl:81/svn/trees/vmware/

And then add the new vmware directory as an overlay to portage.  If you don't
know about overlays, please look them up in the Gentoo documentation.

Once it's all installed you should run the configuration script and from that
point on it should hopefully all work.  If it doesn't please first have a quick
check through the previous posts here to see if there's anything similar to
your problem, and finally if there isn't, let me know and I'll try and help
further...  5:)

Yes, I did miss that file. I also wasn't in the vmware group so the chmod +x
aren't needed either.

The SVN is very convenient. Everything is working, installing an os now.

thank you!

(In reply to comment #191)
> The config patch #3 doesn't apply anymore, but doesn't even seem to be needed
> anyway.
> For the rest renamed ebuilds (with changed patches and filenames) works here.

Same thing here, renamed all the files, got the rpath fixed manually and
renamed it, Even the long waited vmware-cmd is finally working on my x86_64! 
Geez I'm an happy fellow!

Martin

(In reply to comment #197)
> Same thing here, renamed all the files, got the rpath fixed manually

How did you get the rpath problem fixed manually?

(In reply to comment #198)
> (In reply to comment #197)
> > Same thing here, renamed all the files, got the rpath fixed manually
> 
> How did you get the rpath problem fixed manually?
> 

nevermind, i fixed it, too (using the svn repository given above). sorry for
spam :D

Sorry, been really busy with real life and the libexpat update killed all
graphical stuff on my laptop while I recompiled nearly 200 apps... I was wrong
about the failure, it was not just due to the serial number entry. It fails
every time, but running vmware-config.pl manually allows me to use vmware
successfully. My laptop is amd64 running GCC 4.1 though, whereas my desktop
where the ebuild works OK is not using masked versions of GCC.

If it helps here is the failure, as I said manually running vmware-config.pl
works fine.

 * Preparing vmmon module
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.16-gentoo-r1'
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make
rule.
  CC [M] 
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:37:5:
warning: "VMW_HAVE_EPOLL" is not defined
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:43:5:
warning: "VMW_HAVE_EPOLL" is not defined
In file included from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:49:
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/./include/compat_wait.h:60:
error: conflicting types for 'poll_initwait'
include/linux/poll.h:45: error: previous declaration of 'poll_initwait' was
here
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:145:
warning: initialization from incompatible pointer type
/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.c:149:
warning: initialization from incompatible pointer type
make[2]: ***
[/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only/linux/driver.o]
Error 1
make[1]: ***
[_module_/var/tmp/portage/vmware-server-modules-1.0.0.22088/work/vmmon-only]
Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.16-gentoo-r1'
make: *** [vmmon.ko] Error 2

My emerge info,

Portage 2.1_pre7-r4 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.4-r2,
2.6.16-gentoo-r1 x86_64)
=================================================================
System uname: 2.6.16-gentoo-r1 x86_64 AMD Turion(tm) 64 Mobile Technology ML-37
Gentoo Base System version 1.12.0_pre16
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [disabled]
dev-lang/python:     2.3.5-r2, 2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildpkg confcache digest distlocks metadata-transfer
sandbox sfperms"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en_GB"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/sci /usr/local/vmware"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X aac aalib acpi aim alsa ati audiofile avi bash-completion berkdb
bitmap-fonts bootsplash bzlib cdparanoia cdr crypt cscope cups dbus dhcp
directfb divx4linux doc dri dvd dvdr dvdread eds emboss encode ethereal fbcon
fftw foomaticdb fortran gd gif gimpprint gmp gpm gstreamer hal icq ieee1394
imagemagick imap imlib ipv6 isdnlog jabber jikes jpeg jpeg2k kde kerberos lcms
lm_sensors lzw lzw-tiff madwifi mp3 mpeg ncurses netcdf nls nptl nptlonly
offensive oggvorbis openexr opengl pam pcre pdflib perl plotutils png povray
ppds pppd python qt quicktime readline rtc samba sasl scanner sdl slp speedo
spell ssl subversion svg tcpd tetex tiff truetype truetype-fonts type1-fonts
unicode usb videos wmf xine xinerama xpm xv xvid zeroconf zlib elibc_glibc
kernel_linux linguas_en_GB userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS

Marcus, this particular error tends to show up because vmware runs a check
function (called surprisingly vmware_check) inside the make files to determine
whether certain features are available or not.  Unfortunately these checks use
-Werror, which with the new 4.x series of compilers can cause problems.  Trying
*not* to reopen old arguements, we've decided to make specific patches for the
two errors seen on gcc-4.0 and gcc-4.1.  Gcc-4.0 requires the -Wno-used flag to
be added, and gcc-4.1 requires the -Wno-attributes flag.  Unfortunately
-Wno-attributes doesn't exist on older gcc versions, and as yet I haven't
modified the ebuilds to make the gcc-4.1 patch conditional on gcc-4.1 rather
than just gcc-4.*.  I intend to do that when I roll out the ebuild for the new
version (and I'm waiting on Chris to upload the corrected rpath libraries to
his devspace before I can do this).  So, for a quick fix, you can alter 
vmware-server-modules-1.0.0.22088-makefile2.patch and remove the
-Wno-attributes flag, or you can wait until we get the new ebuilds out.

I hope that helps, if it doesn't, there is a debugging process (the details of
which you can find around comment 142) you can use to see if there's a
different flag giving you problems.  Otherwise it looks like you're running
into exactly the same thing as Guillaume and Peter found in comment 155 and
comment 156 respectively...

Mike that sounds fair enough to me. I thought after I posted it could be some
GCC 4.1 weirdness, but didn't have time to read through all the comments on
this bug. As I said it is actually working just fine as I ran vmware-config.pl
manually, I was more reporting to give feedback on the new ebuild.

Great job anyway - keep up the good work. I hope Chris gets the new tarball up
soon, but I am in no major rush right now. Thanks.

Hi Mike,

Keep up the good work you are doing!

Back to bussiness. Do you know why virtual/x11 is a dependancy for
vmware-server? I have a headless amd64 server and I wish not to install x11 and
libraries.

To test if it works without X11 I modified the ebuild and removed the x11
dependancy. Vmware-server installed fine and works (I can add and boot a
virtual machine). I access it with the vmware server console from a windows
machine.

Maybe it is an idea to see is someone has the USE="-X" set? (I do.)

Hi dino.  Well, two things, firstly I'm not positive why vmware requires
virtual/x11, but I do know that some of the files it installs rely on the
gtk/x11.  If you run through all the files from a qlist output of
vmware-server, and ldd each of those, you should find the offending files. 
Secondly, if you're running with amd64 keywords, you shouldn't have virtual/x11
as a dependency, only as a subdependency of the emulated-gtk libraries... 

If it's of any help, Christophe in comment 174 stated a requirement for certain
X11 libraries for the /opt/vmware/server/bin/vmware file, so I'm probably going
to keep those in...

And lastly a little general news, sometime this evening or tomorrow, I'm going
to push out the 22874 build since Chris has uploaded the latest rpath fixes to
the webspace he's very kindly donated for doing this.  Thanks Chris!!!  5:)

As always, comments or questions, let me know here...  5:)

(In reply to comment #204)
> Hi dino.  Well, two things, firstly I'm not positive why vmware requires
> virtual/x11, but I do know that some of the files it installs rely on the
> gtk/x11.  If you run through all the files from a qlist output of
> vmware-server, and ldd each of those, you should find the offending files. 
> Secondly, if you're running with amd64 keywords, you shouldn't have virtual/x11
> as a dependency, only as a subdependency of the emulated-gtk libraries... 
> 
> If it's of any help, Christophe in comment 174 stated a requirement for certain
> X11 libraries for the /opt/vmware/server/bin/vmware file, so I'm probably going
> to keep those in...
> 
> And lastly a little general news, sometime this evening or tomorrow, I'm going
> to push out the 22874 build since Chris has uploaded the latest rpath fixes to
> the webspace he's very kindly donated for doing this.  Thanks Chris!!!  5:)
> 
> As always, comments or questions, let me know here...  5:)
> 


I have read the vmware docs about system requirements and maybe this helps:

http://www.vmware.com/pdf/server_admin_manual.pdf
Other Linux host operating system requirements include:

(In reply to comment #204)
> Hi dino.  Well, two things, firstly I'm not positive why vmware requires
> virtual/x11, but I do know that some of the files it installs rely on the
> gtk/x11.  If you run through all the files from a qlist output of
> vmware-server, and ldd each of those, you should find the offending files. 
> Secondly, if you're running with amd64 keywords, you shouldn't have virtual/x11
> as a dependency, only as a subdependency of the emulated-gtk libraries... 
> 
> If it's of any help, Christophe in comment 174 stated a requirement for certain
> X11 libraries for the /opt/vmware/server/bin/vmware file, so I'm probably going
> to keep those in...
> 
> And lastly a little general news, sometime this evening or tomorrow, I'm going
> to push out the 22874 build since Chris has uploaded the latest rpath fixes to
> the webspace he's very kindly donated for doing this.  Thanks Chris!!!  5:)
> 
> As always, comments or questions, let me know here...  5:)
> 


I have read the vmware docs about system requirements and maybe this helps:

http://www.vmware.com/pdf/server_admin_manual.pdf
Other Linux host operating system requirements include:
•Linux kernel 2.2.14-5.0 is not supported
•Standard Linux server installation is required with glibc version 2.1 or
higher and libXpm.so
•The inetd process, which must be configured and active for VMware Server
Console and VMware Management Interface connections
•Version 2.1.36 of the SCSI Generic (sg.o) driver is required to use generic
SCSI devices in virtual machines
•Perl 5.005x or higher is required to use VmPerl API
•X server is required to run the VMware Server Console

So it seems that only libXpm is needed and not X11 for the server according to
VMware Inc.

Hi
Quick question.

Will the ebuilds and patch files here work for
VMware-server-e.x.p-22874.tar.gz
VMware-mui-e.x.p-22874.tar.gz

Just downloaded these from vmware, but can't find the 20925 version that the
ebuild and patch are meant for.

Thanks,
vividvew

No.  You shouldn't use *any* of the ebuilds from this bug, but rather the ones
from subversion.  Mike is working on ebuilds for 22874, so there currently
aren't any around.

Ok, rather confusingly, when I run the script [1] (which I got from some gentoo
dev's scripts directory a while ago), I get the following dependency list:

app-arch/bzip2
dev-cpp/glibmm
dev-cpp/gtkmm
dev-cpp/libgnomecanvasmm
dev-libs/atk
dev-libs/expat
dev-libs/glib
dev-libs/libcroco
dev-libs/libsigc++
dev-libs/libxml2
dev-libs/openssl
dev-libs/popt
gnome-base/gconf
gnome-base/gnome-vfs
gnome-base/libbonobo
gnome-base/libglade
gnome-base/libgnomecanvas
gnome-base/librsvg
gnome-base/orbit
gnome-extra/libgsf
media-libs/fontconfig
media-libs/freetype
media-libs/glitz
media-libs/libart_lgpl
media-libs/libpng
sys-devel/gcc
sys-libs/glibc
sys-libs/libstdc++-v3
sys-libs/pam
sys-libs/zlib
x11-libs/cairo
x11-libs/gtk+
x11-libs/libICE
x11-libs/libSM
x11-libs/libX11
x11-libs/libXau
x11-libs/libXcursor
x11-libs/libXdmcp
x11-libs/libXext
x11-libs/libXfixes
x11-libs/libXft
x11-libs/libXi
x11-libs/libXrandr
x11-libs/libXrender
x11-libs/libXt
x11-libs/libXtst
x11-libs/pango

Now I haven't included anywhere near those dependencies, but I also don't see
libXpm listed anywhere in there.  Please also note that virtual/x11 should only
be pulled in if you're not using modular X, in which case I don't think you'll
be able to get libXpm on it's own anyway, but I could be wrong.  Anyway, if
someone can come up with a convincing way of figuring out the correct
dependencies, I'll be happy to update them.  I don't think the current ones are
correct, but I'm a little dubious about them being just libXpm, even if that's
what vmware says.  I've heard mention of scanelf -n being better at detecting
actual dependencies.  If anyone who knows what they're doing would like to
knock me up a script to get a dependency list I'd be very greatful, as it is I
don't know too much about the low level stuff to know if I'm producing an
accurate list.  Thanks!  5:)

Meanwhile, the good news it that I just pushed out into subversion the 22874
ebuilds, so grab 'em while they're hot.  No real changes (although as pointed
out some of the RPATH affect libraries have been fixed, making the secondary
download much smaller and one of the patches has been integrated upstream). 
Please note this ebuild also includes a fix for compilation on gcc-4.0.x, and
as always any problems, please let me know...  5:)

[1] Script:

#!/bin/bash
pkgs=""
files=""
libs=""

for file in $(qlist ${1}); do
        [[ -x "${file}" && -f "${file}" ]] && files="${files} ${file}"
done

for lib in $(echo ${files} | xargs ldd | grep "=>" | sed -re 's:\(.*\)\s*$::' |
sed -re 's:^.*=>::' )
do
        libs="${libs}${lib} "\\n
done

libs=$(echo -e ${libs} | sort | uniq)

for lib in ${libs}; do
        pkgs="${pkgs}$(qfile -qC ${lib} )"\\n
done

echo -e $pkgs | head --lines=-1 | sort | uniq

Oh yeah, one last thing, there does seem to be an issue compiling
vmware-server-modules-1.0.0.22874 on a 2.6.17_rc1+ kernel.  Something about
exepected specifier-qualifier-list before u8...  If anyone's got any ideas on
that I'd be much obliged, I'm completely mystified by that one...

When running vmware (no desktop entry with the latest svn checkout?), I get the
following:

/opt/vmware/server/lib/bin/vmware:
/opt/vmware/server/lib/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not
found (required by /usr/lib/libcairo.so.2)
/opt/vmware/server/lib/bin/vmware:
/opt/vmware/server/lib/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not
found (required by /usr/lib/libcairo.so.2)
/opt/vmware/server/lib/bin/vmware:
/opt/vmware/server/lib/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not
found (required by /usr/lib/libcairo.so.2)

I am using GCC4.1 if that helps.

(In reply to comment #210)
I am running gcc 4.1 as well and I don't have this problem. I don't even have
gcc 3.4 installed any more.

Did you use the latest svn ebuild ?

Hi Alex, firstly could you provide a few more details to try and identify the
problem?  I've been developing the ebuilds under gcc-4.1 and have successfully
had an image up and running under the server using the latest version of the
ebuild.   When you say you run vmware, what exactly do you mean?  Are you
trying to run the vmware-server-console to connect to the vmware-server, or are
you starting the vmware service (by running /etc/init.d/vmware start) or are
you using the workstation version?

If it's vmware-server-console, let me know and I'll look into it further
(vmware-server-console should also provide a desktop entry, if it doesn't
please let me know)...

If you're running the server could you please provide the complete output from
/etc/init.d/vmware so that I can see where in the start-up process it's
failing?

If you're trying to use the workstation, then that's a bug for a different
package and you should refile it and provide them with as much information as
you can...

(In reply to comment #212)
> (vmware-server-console should also provide a desktop entry, if it doesn't
> please let me know)...

vmware-server-console does provide a desktop entry. However, you are patching
vmware-server to remove its own desktop entry - that's kinda annoying since
it's not possible to connect to vmware server running on localhost via
vmware-console (at least, doesn't work at all for me; works fine if you run
vmware from vmware-server ebuild, offers you localhost or remote host).

Jakub, I am at this very moment connected to a local instance of vmware-server
using the vmware-server-console package.  It appears that xinetd blocks
connections to 127.0.0.1 if the only_from line reads localhost.  I realize
that's a little counter-inuitive, but commenting out the only_from line allows
connection to the vmware-server without problems.  I'm just about to post
another message that I was in the middle of writing when I received yours...

Oh, and for anyone that's been wondering like I have, I just discovered why
there are X dependencies in the files installed by vmware-server.  It turns out
that the server installs a local copy of the console, separate from the
vmware-server-console.  This console can be started by running
/opt/vmware/server/bin/vmware.  What this means is that I can potentially chop
out large chunks of libraries that vmware-server itself installs incase the
system doesn't have them (such as, it comes with a complete copy of all the
required gtk libraries to run the console).

So, I've got two questions, firstly does anyone know an easy way of creating a
sort of an ldd tree view, showing binaries at the top, and their dependencies
below, so that I could see which files are no longer required if I remove
/opt/vmware/server/lib/bin/vmware?

Secondly, what are people's thoughts on this?  Would they prefer to have a
vmware-server that can be installed on a non-X machine, and then have to
install vmware-server-console if they wanted to control it locally?  Or would
they prefer to get everything they might ever need in the one vmware-server
package?

Lemme know and when I get some free time, I'll start work on (note that this
won't be a quick process, and I shouldn't think a cut down version will be out
in anything less than a couple of months)...

(In reply to comment #214)
> xinetd blocks connections to 127.0.0.1 if the only_from line reads localhost. I > realize that's a little counter-inuitive, but commenting out the only_from line > allows connection to the vmware-server without problems. 

Well, I've removed that line quite some time ago - not a solution. Never
connects, and the console needs to be killed.

IMHO it makes sense to remove all X related programs and / or UI tools from the
vmware-server package. It will be possible to set up a VMWare server farm this
way. I don't know if someone wants to do it - but it would make sense for
headless systems.

Ok, Jakub and I got it all sorted out on IRC, it turns out xinetd's a little
bit restrictive in how you can specify addresses that are allowed to connect.

Firstly xinetd.conf's only_from line will take effect unless there's an
only_from line in the service specific file (such as
/etc/xinetd.d/vmware-authd).

Second, you can't specify multiple addresses very easily, so wanting to allow
access from 192.168.0.0/24 and 127.0.0.1/8 can't really be specified.  Which is
a pain.

Thirdly, even though it's supposed to do reverse name lookups, it appears not
to, so the only_from = localhost line will still reject entries from 127.0.0.1.
 That could probably be fixed by jiggering with your host file, but we decided
a simpler solution is to change the localhost entry to a 127.0.0.1 entry.

Either that or you can always address the machine by it's external IP address,
assuming your xinetd rules allow it.

Of further frustration is the fact that if xinetd does drop the connection, I
don't think it sends back a reset, leaving vmware-console taking up 100% of CPU
and looking basically crashed.  That's probably a vmware problem, but given
that I don't have an exact cause or a solution for them yet, I'll let someone
else report it to them...

Well, that's it for now, so far I've had a couple of votes for stripping out
the UI so that's gonna be my next project.  Stay tuned...  5:)

Mike would be nice if you get it to run without the X dependencies, but
sometime ago I also tried that. But if i remember correctly i didnt get it
running without, because the vmware-config.pl script want the serial number for
the installation, and check it with the lib/bin/vmware-vmx program. And this
have the deps on the X libs.
I dont know if this is also right for the actual version, because i haven

Mike would be nice if you get it to run without the X dependencies, but
sometime ago I also tried that. But if i remember correctly i didnt get it
running without, because the vmware-config.pl script want the serial number for
the installation, and check it with the lib/bin/vmware-vmx program. And this
have the deps on the X libs.
I dont know if this is also right for the actual version, because i haven´t
upgraded yet.

At least older versions of the server did run without the serial number. Of
course that means that the vmware console must be used to enter the serial
number.

As far as I was aware, the serial number is always entered during the
vmware-config.pl stage?  If you've already given one, then it will ask if you
want to provide one, but I think on a first time install it won't let the
configure go through cleanly without one...  I've never really used the in
built console before, I hadn't even known it had existed, so it is possible to
run the whole thing without it...

The method I am starting vmware was with the command "vmware". I wanted to get
the gui like I can in windows with the same program (vmware-server). 

I don't know which package is supposed to give the GUI like the one in windows.

/etc/init.d/vmware works just fine and prints no errors.

Also I have tried vmware-server and vmware-server-console, both output the same
problems when running their respective binaries (vmware for vmware-server, and
vmware-console for vmware-console)

I don't know what else you could possible need. But I do use nxsty's
glibc-2.4-r1, but I doubt that has to do with the gcc errors. If you want my
emerge --info I will provide it.

All I am trying to do really is use vmware-server becuase I don't want to pay
for workstation.

Sorry if I wasn't of much help in providing the information you need.

No, that's fine Alex, I was just trying to get a little more info on what was
going wrong.  I hadn't known that vmware-server came with it's own copy of the
console, but as I say, chances are I'll be looking to strip that out of the
final version so that people can have headless servers...

In answer to your problem, whilst you may be using gcc-4.1 the only reports of
your problem have been with people who still have gcc-3.4 installed so perhaps
you haven't done an "emerge -e world" and are still running with some packages
compiled under gcc-3?  Anyway, here are the references I've tracked down.

http://www.vmware.com/community/message.jspa?messageID=378384

Please note it appears this happening because vmware is reverting to it's own
libraries for certain features, but because you have cairo installed, it's
getting confused.  The fix at:

http://www.vmware.com/community/thread.jspa?messageID=370107

Sounds a little dubious, but is worth a shot.  I'm afraid this is probably
going to have to be classed as a vmware problem, since it's so deeply rooted I
don't think there's much I can do to fix it.  Also, other people myself
included have reported success with gcc-4.1, so it seems to be a peculiarity of
your setup.  I hope this fixes it for you.  Please let me know the outcome
either way...

Thanks, I will take a look at those once their site is working again (Getting a
500 internal error). I don't have gcc-3.4 installed (I am a pretty intermediate
user for Gentoo, and I have done about 3-4 emerge -e world's this week so I
know there is nothing built against the old gcc-3.4)

Will report later what happens.

I've been following this tracker and have successfully gotten vmware-server
installed through portage, however I fired it up today and it told me I
couldn't start my VM because the product had expired (its not a serial
problem). It then informed me there was an updated version of vmware-server at
vmware.com. Just wondering if there will be updated ebuilds for the new
versions. BTW: Thanks for all the work on this, it made it real easy to
install. 

Hi, you haven't specific which version you're using.  At the moment the latest
version for which there are ebuilds is 22874, this is also the latest version
available from the vmware website as of just now.  You get the very latest
ebuilds from the subversion repository that Paul has very kindly set up. 
Please see comment 195 for instructions on checking out the latest copy from
subversion, and also do please have a read of the rest of the bug.  Whilst
there is a lot to go through it's quite common to have had a problem already
identified and possibly answered earlier in the bug.  Thanks...  5:)

Also remember that if you don't want to set up subversion. You can also just
download the relevant files from that location. It's a bit more complex (it are
various files that all must be downloaded), but as the repository is http based
it just works.

(In reply to comment #181)
> Ok. The four missing libraries were libXtst libXt libICE libSM. Once emerged,
> vmware configuration script runs fine. I forgot before to mention this was on a
> x86 machine. (I installed it 3 times already on amd64 without the problem). 
> 
> But - new problem is with init script. vmware was started at the end of
> configuration. But I cannot stop it, or stop/restart xinetd now :
> 
> >>/etc/init.d/vmware stop
> /etc/vmware/init.d/vmware: line 667: [: -: integer expression expected
> /etc/vmware/init.d/vmware: line 684: [: -: integer expression expected
> * Stopping VMware services:                            [ ok ]
> *   Virtual machine monitor                            [ !! ]
> *   Bridged networking on /dev/vmnet0                  [ ok ]
> *   Virtual ethernet                                   [ !! ]
> 
> The server itself works fine.. as I was able to connect to it remotely.
> 
I had the same problem as of 4/17/2006. I resolved the issue by enabling module
unloading in my kernel, recompiling the kernel, re-emerging vmware-server and
vmware-server-modules, then re-runing vmware-config.pl.

*** Bug 122670 has been marked as a duplicate of this bug. ***

Thanks for your work on the vmware-client-tools Anthony.  I'll work on
integrating it with the existing ebuilds and adding them to the subversion
repository.  I'm afraid that may not happen by the end of this week, but
hopefully I'll get some time to work on them over the weekend.  As always if
you've got any comments or suggestions, please do post them here...  5:)

I am happy of to have been useful, for the moment I do not have no suggestion
to give but I will see to follow the bug report and eventually give a my
opinion later on.

Hey everybody, just a quick interim update that alters the dependencies of the
vmware-server ebuild.  I've taken these directly from the
/opt/vmware/server/lib/bin/vmware-vmx file.  This, as far as I'm aware, is the
main vmware binary.  Also in that directory is the vmware console app, which
requires several more libraries.  These have not been added to the dependencies
list, since the eventual idea is to remove these completely.  I've also
discovered that the reason only libXpm is reported as required, is that
precompiled fallback versions of the libraries are packaged with vmware.  As
such I still intend to leave the remaining X dependencies (such as libX11, etc)
in the list, since native versions will probably work better than the
prepackaged libraries.  They should be a minimal list though, and not require
the entirety of the xorg-server to be installed.  I'm going to further work on
trimming out the local console, so that we don't install anything that's broken
(since I don't intend to add all the gnome libraries as dependencies).  As
always comments and suggestions are welcome...  5:)

Just a small comment: If you make changes to the ebuild you should bump the
revision number so everybody's installation will be upgraded and they can
actually test your changes ;)

Other than that everything seems to be working fine here on ~amd64.

just something small i noticed...

>>> Safely unmerging already-installed instance...
No package files given... Grabbing a set.
>>> Original instance of package unmerged safely.
/usr/local/portage/app-emulation/vmware-server/vmware-server-1.0.0.22874.ebuild:
line 236: update-mime-database: command not found
 * Updating /etc/vmware/locations

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

Portage 2.1_pre7-r5 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r2,
2.6.15-ck3-r1 i686)
=================================================================
System uname: 2.6.15-ck3-r1 i686 Pentium III (Coppermine)
Gentoo Base System version 1.12.0_pre17
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5-r2, 2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.16
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/bind /var/qmail/alias
/var/qmail/control /var/vpopmail/domains /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer nostrip
sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.pacific.net.au/linux/Gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://ftp.cc.swin.edu.au/gentoo-portage"
USE="alsa apache2 apm avi bash-completion berkdb bitmap-fonts bzip2 calendar
cli crypt cups curl dba debug dhcp divx4linux dri dv dvb dvd dvdread eds eix
emboss encode esd exif extraengine fam ffmpeg foomaticdb fortran ftp gd gdbm
gif gpm gstreamer hash imap imlib innodb isdnlog jabber jpeg kerberos ldap
libclamav libg++ libwww logrotate mad maildir mcal mhash mikmod mmx motif mp3
mpeg mysql mysqli ncurses nls nptl nptlonly ogg opengl pam pcntl pcre pdflib
perl pic pie png posix postgres pppd python quicktime radius readline
reflection samba sdl session simplexml snmp soap sockets spamassassin spell spl
sqlite ssl tcpd tidy tiff tokenizer truetype truetype-fonts type1-fonts udev
unicode usb userlocales utf8 v4l vhosts vorbis wddx x86 xml xml2 xmlrpc xmms
xorg xv xvid zaptel zlib dvb_cards_usb-vp7045 elibc_glibc input_devices_evdev
input_devices_keyboard input_devices_mouse kernel_linux userland_GNU
video_cards_ati"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS

Michael, you're quite right.  The lack of revision numbers is from the early
days when I was churning out a new version every couple of days.  I will in the
future attempt to use revisions numbers, but bear in mind not all modifications
warrant a version bump (people would get quite irritated with me if they had to
reinstall for each minor fix), so I'll still post here to inform people of any
changes.  I'm glad you haven't encountered any issues on amd64, hopefully
they've all been ironed out now, thanks for reporting that...  5:)

Nathan, I'm not sure what that update-mime-database is doing there.  If it
turns out to be necessary it'll simply require adding x11-misc/shared-mime-info
into the dependencies.  Can anybody give me an idea of what it's supposed to
do?  Best I can figure out, it's supposed to update the local mime database so
that if a file has a mime-type of x-application/vmware-server or something,
it'll get openned by vmware.  I have the feeling this is relevant only for the
local console, so I'd be very tempted to remove it.  If no-one can give me a
reason not to, it'll be gone when I start cutting out the local console. 
Thanks for spotting that Nathan!  5:)

(In reply to comment #215)
> Secondly, what are people's thoughts on this?  Would they prefer to have a
> vmware-server that can be installed on a non-X machine, and then have to
> install vmware-server-console if they wanted to control it locally?  Or would
> they prefer to get everything they might ever need in the one vmware-server
> package?

The smallest dependencies package. Thats for sure.  I'm currently running
vm-ware server host that takes less than 35Mo once booted.  Still trying to
find way to strip this even more.

Martin

(In reply to comment #209)
> Oh yeah, one last thing, there does seem to be an issue compiling
> vmware-server-modules-1.0.0.22874 on a 2.6.17_rc1+ kernel.  Something about
> exepected specifier-qualifier-list before u8...  If anyone's got any ideas on
> that I'd be much obliged, I'm completely mystified by that one...
> 
Hi

that's due to a change in asm/bitops.h, that includes the new
asm/alternatives.h. This last file use the u8 type, that's defined in
asm/types.h which is not included. So it should be enough to add the include
directive, I'll post the patch in a minute.

Hope this helps.

Created an attachment (id=85453) [details]
Patch to fix compiling modules against 2.6.17

Here it is. Tested with vanilla 2.6.17-rc2 and gentoo 2.6.16-r3. Built on
vmware-server-modules-1.0.0.22874 (subversion r31).

That's fantastic Daniele, thanks!  I'll check that over and get that into the
subversion repository as soon as I can, which sadly will probably not be before
Saturday.  I'm also going to work on preparing this ebuild to go into the main
portage tree (with help), so look forward to that too (it'll be masked
obviously, but still, it's a start...)!  5:)

Please don't put this into the tree yet.

For one, I don't want to see a vmware-server-modules ebuild go into the tree
*ever*, as a more general vmware-modules ebuild which covers all vmware
products is instead the way to go.

The truth is that I would prefer that this stay out of the tree until I can
rework some of the vmware stuff that we currently have, because it is all in a
very sad shape.  Also, congratulations on becoming a developer.  Feel free to
add yourself to the vmware alias and also to the vmware herd.

Check out http://dev.gentoo.org/~wolf31o2/vmware.txt for my (current) list of
priorities and how I want to keep doing the vmware stuff.  The main reason is
for maintainability, as it'll give us only a single spot to do upgrades that'll
affect all of the ebuilds, rather than having to duplicate so much work.

Sorry Chris, I really wasn't being very clear in my last post.  I'm quite torn
at the moment between being petrified of putting anything into the tree for
fear of disgruntling even a single user, and the fact that as a Dev I'm sort of
expected to contribute (Marcelo told me he was happy for me to commit a patch
I'd made into the tree, and I told him I really didn't want to and didn't
really know how!).

I had initially thought a good start would be to work towards getting this
ebuild into portage, but please believe I would never put anything into the
tree that clearly falls in the vmware (or anyone else's) herd's domain without
checking and making sure they're very happy for it to go in (and getting help
from them on putting it in too!).  I will most assuredly be taking things
*extremely* slowly checking-in wise.

I will, however, take a look through your priority list at some point and see
if there are any bits and pieces I can help out with, thanks!  5:)

Hi,

wanted to refresh the VMware server install I did back in March with the 22088
build to the new Beta 2 22874 build, so I downloaded with wget -r the latest
overlay from:

http://callisto.cs.kun.nl:81/svn/trees/vmware/

and installed it into my local overlay.

Unfortunately the build fails right away, with this error message:

# emerge vmware-server
Calculating dependencies... done!
>>> Emerging (1 of 2) app-emulation/vmware-server-modules-1.0.0.22874 to /
>>> checking ebuild checksums
!!! Digest verification failed:
!!!
/usr/local/portage/app-emulation/vmware-server-modules/vmware-server-modules-1.0.0.22874.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 1540
!!! Expected: 1614

and infact the ebuild is 1540 bytes long while the Manifest file wants 1614.

Is this snafu sign of a problem of some kind with the ebuild, or shall I just
rebuild the Manifest file and re-emerge?

Many thanks to all for the great work done so far!

Bye, Luca

(In reply to comment #242)
> Is this snafu sign of a problem of some kind with the ebuild, or shall I just
> rebuild the Manifest file and re-emerge?

You need to run ebuild ..... digest everytime you change the ebuild.

@242: The problem is caused by the fact that you're not using the subversion
client to retrieve the ebuilds. When using normal web access the Id attribute
is not inserted. As such the digests are invalid.

(In reply to comment #244)
> @242: The problem is caused by the fact that you're not using the subversion
> client to retrieve the ebuilds. When using normal web access the Id attribute
> is not inserted. As such the digests are invalid.

thanks Paul, just installed svn (I am not a developer!), checked out and diff'd
the files, and now I see exactly what I was missing and why the digest was
failing.  I guess I will be using svn from now on!  ;-)  --Luca

Hello,

I installed a new gentoo System, put my user in the vmware group. 

I do this:

vmware
/usr/bin/vmware: line 85: /etc/vmware/locations: Permission denied
/usr/bin/vmware: line 177: /lib/wrapper-gtk24.sh: No such file or directory
/usr/bin/vmware: line 177: exec: /lib/wrapper-gtk24.sh: cannot execute: No such
file or directory


But as root all works fine.

Regards Roland

Hi Roland, the trouble is that you're trying to run the vmware-server directly
on the local machine.  I'll hopefully be removing the local console to remove
this functionality, since the same thing can be achieved by installing and
running the vmware-server-console and pointing it at localhost.  It will then
ask you for a username and password, and *that* user must be a member of the
vmware group (even if it it's root).  Also you may experience some difficulties
with xinetd not allowing access to localhost from localhost.  This is a name
lookup problem and has been discussed earlier in this bug, in comment 218.  If
you're still having trouble, please come back and ask again and we'll see if we
can get it sorted out...  5:)

Hello,

after every reboot J get the Error Message:

unable to change virtual machine power state

vmmon not loaded
If I rerun vmware-config.pl all works fine.

I use:
ls /usr/local/portage/app-emulation/vmware-server
Manifest  files  vmware-server-1.0.0.22874.ebuild

ls /usr/local/portage/app-emulation/vmware-server-modules/
Manifest  files  vmware-server-modules-1.0.0.22874.ebuild

R. R.

R. May, the very first thing to check is that the vmware services are starting
properly as part of your default runlevels.  Not only should xinetd be running
if you want remote access, but also you're going to need the vmware services
starting (which basically loads the vmmon and vmnet modules for you, as well as
the nat service and dhcp networking stuff using by vmware).  Re-running the
config script will cure this since it starts the services once it's complete to
check they're working.  To add the vmware service to your default runlevel use
the command:

rc-update add vmware default

If this cures your problem then that's excellent, but if you're still having
trouble please mail the output and any errors you get during the default
runlevel startup for the vmware service.  That should help us diagnose you
problem a little more thoroughly.  Thanks...  5:)

Hi all, can't load the vmmon or vmnet modules.. any ideas?

dmesg output:

vmmon: no version for "struct_module" found: kernel tainted.
vmmon: no version magic, tainting kernel.
vmmon: module license 'unspecified' taints kernel.
vmmon: Unknown symbol force_evtchn_callback
vmmon: Unknown symbol xen_features
vmnet: no version magic, tainting kernel.
vmnet: Unknown symbol force_evtchn_callback
vmnet: Unknown symbol force_evtchn_callback
vmmon: no version magic, tainting kernel.
vmmon: Unknown symbol force_evtchn_callback
vmmon: Unknown symbol xen_features
vmnet: no version magic, tainting kernel.
vmnet: Unknown symbol force_evtchn_callback
vmmon: Unknown symbol force_evtchn_callback
vmmon: Unknown symbol xen_features


emerge --info:

Portage 2.1_pre10-r2 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.4-r1,
2.6.16-xen i686)
=================================================================
System uname: 2.6.16-xen i686 AMD Athlon(tm) XP 2000+
Gentoo Base System version 1.12.0_pre18
dev-lang/python:     2.4.3
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer
-mno-tls-direct-seg-refs"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/env.d"
CXXFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer
-mno-tls-direct-seg-refs"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms"
GENTOO_MIRRORS="ftp://mirror.aarnet.edu.au/pub/gentoo/"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow X acpi alsa apache2 avi bash-completion berkdb bitmap-fonts cli
crypt cups dri eds emboss encode esd foomaticdb fortran gdbm gif gstreamer gtk
gtk2 imlib isdnlog java jpeg libg++ libwww mad mikmod mmx motif mp3 mpeg
ncurses nls nptl nptlonly offensive ogg opengl oss pam pcre pdflib perl png
pppd python quicktime readline reflection screen sdl session spell spl sse sse3
ssl tcpd truetype truetype-fonts type1-fonts udev usb vorbis x86 xml xmms xorg
xv zlib elibc_glibc kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS, MAKEOPTS

Tom, at first glance it appears it's related in some way to the fact you're
running on the xen-sources.  I probably wouldn't recommend using two
virtualization systems on top of each other.

On further investigation it appears that it is definitely related to the xen
sources, and apparently they make use of some extra functions that the vmware
modules (and several other third party modules) don't know about when they're
compiled (such as nvidia, openafs and now vmware).  If you can understand
what's going on at:

http://www.nvnews.net/vbulletin/showthread.php?t=68703

then you might be able to patch the module sources (note in particular step 3,
since you'll have to do that for the two calls that are undefined for you.  If
you don't understand what's going on there, then I *wouldn't* go tinkering with
any sources.  If possible move to/boot a different kernel, if not, then ask on
the Xen mailing list, or as a last resort on vmtn.  I hope that's of some
help...

Mike, you are fantastic. I very much appreciate your suggestion and link.
I applied these static symbol defs to the vmmon and vmnet modules (after
rebuilding them from source) and they loaded perfectly. :)


For anyone else looking to run vmware-server in a Xen domainU (I haven't
verified that it actually WORKS yet, but its installed and the modules are
loaded), something similar to the following might help:

grep force_evtchn_callback$ /path/to/your/System.map
grep xen_features$ /path/to/your/System.map

 == record the two expressions in the left column (should be 8 digits) for the
corresponding function names ==

cd /usr/src

tar zxvf VMware-server-e.x.p-20925.tar.gz

tar xvf vmware-server-distrib/lib/modules/source/{vmmon,vmnet}.tar

cd vmmon-only && patch -p0 vmware-server-modules-1.0.0.20925-makefile.patch &&
sed -i 's:SUBDIRS=:M=:g' Makefile && make

ld -m elf_i386 --defsym force_evtchn_callback=0x{EXPRfromGREP} --defsym
xen_features={EXPRfromGREP} -r -o ../vmmon.ko vmmon.o vmmon.mod.o

cd ..

cd vmnet-only && patch -p0 vmware-server-modules-1.0.0.20925-makefile.patch &&
sed -i 's:SUBDIRS=:M=:g' Makefile && make

ld -m elf_i386 --defsym force_evtchn_callback=0x{EXPRfromGREP} --defsym
xen_features={EXPRfromGREP} -r -o ../vmnet.ko vmnet.o vmnet.mod.o

cd ..

cp /lib/modules/`uname -r`/misc/{vmmon,vmnet}.ko /some/backup/dir/

cp vmmon.ko vmnet.ko /lib/modules/`uname -r`/misc/

Erm, note the two patch's in the above should be: patch -p0
</path/to/vmware-server-modules-1.0.0.20925-makefile.patch

There's probably an easier (and better) way of the above, but it seemed to work
for me.

I'm receiving error messages trying to launch a VM.

"Not enough physical memory is available to power on this virtual machine."
and
"Unable to change virtual machine power state: Operation failed to change the
VM to the expected power state."

This is a blank VM with no OS installed as of yet. It doesn't seem to matter
how much memory I assign to the VM, it just won't boot. The host machine
physically has plenty of mem left to boot a virtual machine.

Last thing to note is that vmware is running under Xen, so that might have
something to do with it.

Tom, I'm afraid we're completely out of my league at this point.  Sorry...  5:\

The good news for everybody, however, is that I've just pushed a new
vmware-server build into the repository.  I'm afraid it's not all singing, all
dancing because I haven't had a chance to strip out the built-in console, or
teach it how to sing or for that matter dance.  What I have done however is
migrate the vmware-server-modules ebuild over to a new vmware-modules ebuild,
which is now based upon petr's vmware-any-any-update101 package.  This actually
solves several problems, since the gcc-4 compilation patches and the
kernel-2.6.17 patch are already fixed in petr's modules.  It's also the first
step to clearing up Chris's priority list that's holding this ebuild from
making it into the main tree...

So what I'd like every body to do is update their subversion repository (it
turns out now that because of the versioning we've got enabled, you have to use
subversion to get it, or use --digest during installation).  The revision
number has been bumped, so you should simply be able to do an emerge --update
world.  After that just use it as normal and tell me if you run into any
problems with vmware (specifically module related problems, but any will do).

Once that's running smoothly I'm going to ask Chris for some help getting some
of the other vmware ebuilds (workstation, player, servers, etc) put into this
repository, with the modifications to use the vmware-modules ebuild rather than
building them directly within the config script.  I'll also ask Gunnar if he
can add the repository to the layman list, after which we should get a larger
test crew to make sure everything works ok.  Once *that's* all sorted, then
we'll make a move on the other tasks (stripping out the local console, getting
vmware-server into the tree, and migrating the perl config script over to an
ebuild script)...

As always, let me know what you're thinking and how it's all running.  Thanks! 
5:)

I just synced to the svn overlay which now seems to come with vmware-modules
instead of vmware-server-modules. The merge fails on my amd64 system :

Building for VMware Server 1 beta 1 or beta 2.
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'
make[1]: Warnung: Kein Jobserver verf

I just synced to the svn overlay which now seems to come with vmware-modules
instead of vmware-server-modules. The merge fails on my amd64 system :

Building for VMware Server 1 beta 1 or beta 2.
Using 2.6.x kernel build system.
make -C /usr/src/linux/include/.. M=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.15-gentoo-r7'
make[1]: Warnung: Kein Jobserver verfügbar: setzen -j1. Fügen »+« zur
Ursprungsregel hinzu.
  CC [M]  /var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.o
In file included from include/asm/hardirq.h:8,
                 from include/linux/hardirq.h:7,
                 from include/linux/interrupt.h:11,
                 from
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.c:24:
include/asm/apic.h: In Funktion »apic_write_atomic«:
include/asm/apic.h:47: Warnung: berechneter Wert ist unbenutzt
In Datei, eingefügt von
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.h:20,
                    von
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.c:53:
/var/tmp/portage/vmware-modules-101/work/vmmon-only/./include/compat_wait.h:37:5:
Warnung: »VMW_HAVE_EPOLL« ist nicht definiert
/var/tmp/portage/vmware-modules-101/work/vmmon-only/./include/compat_wait.h:43:5:
Warnung: »VMW_HAVE_EPOLL« ist nicht definiert
In file included from
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.h:20,
                 from
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.c:53:
/var/tmp/portage/vmware-modules-101/work/vmmon-only/./include/compat_wait.h:
Auf höchster Ebene:
/var/tmp/portage/vmware-modules-101/work/vmmon-only/./include/compat_wait.h:60:
Fehler: conflicting types for »poll_initwait«
include/linux/poll.h:45: Fehler: previous declaration of »poll_initwait« was
here
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.c:160:
Warnung: Initialisierung von inkompatiblem Zeigertyp
/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.c:164:
Warnung: Initialisierung von inkompatiblem Zeigertyp
make[2]: ***
[/var/tmp/portage/vmware-modules-101/work/vmmon-only/linux/driver.o] Fehler 1
make[1]: *** [_module_/var/tmp/portage/vmware-modules-101/work/vmmon-only]
Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r7'
make: *** [vmmon.ko] Fehler 2

!!! ERROR: app-emulation/vmware-modules-101 failed.
Call stack:
  ebuild.sh, line 1525:   Called dyn_compile
  ebuild.sh, line 928:   Called src_compile
  ebuild.sh, line 1237:   Called linux-mod_src_compile
  linux-mod.eclass, line 512:   Called die

!!! Unable to make                                   auto-build.
!!! If you need support, post the topmost build error, and the call stack if
relevant.

Ok thanks very much for the feedback Norman, and sorry for the breakage.  I'll
start looking into it.  Could you please let me know which version of gcc
you're using?

I've compiled it ok with 4.1.0, but I haven't tested it with 4.0.x or 3.4.x.  I
have the feeling it may need a couple more patches, but now I know what I'm
looking for it should be easier.  Hopefully I'll have a fix out by tomorrow
afternoon sometime...  5:) 

I am using gcc 4.1.0 as well. Thanks for looking into it.

Hmmmm, well that is weird.  Any chance you could post your 'emerge --info'
please?

Please note that the relevant part is this :

/var/tmp/portage/vmware-modules-101/work/vmmon-only/./include/compat_wait.h:60:
Error: conflicting types for 

Please note that the relevant part is this :

/var/tmp/portage/vmware-modules-101/work/vmmon-only/./include/compat_wait.h:60:
Error: conflicting types for »poll_initwait«
include/linux/poll.h:45: Error: previous declaration of »poll_initwait« was
here

poll_initwait seems to be already declared by the linux header file
include/linux/poll.h and it is being declared in
/vmmon-only/include/compat_wait.h again with a diffferent type.

I am not sure who wrote it ( you or the vmware devs, but that is even
documented in compat_wait.h line 60 :

/* If prototype does not match, build will abort here */
extern void poll_initwait(compat_poll_wqueues *);

Original definition in linux headers is

extern void poll_initwait(struct poll_wqueues *pwq);

This is easy to fix - yet the questuion is how to do it in a sane way.

Which version of the kernel-headers do you have installed. Mine is
sys-kernel/linux-headers-2.6.11-r2. IMHO it should fail for anybody having
these installed.

I know, it's the same bug we've seen before (search this bug for
poll_initwait).  It seems to occur when the test for whether epoll is present
or not fails.  This is usually because gcc-4.x throws up some warning which
gets treated as an error and the test fails.  However, since I compiled it
successfully on my gcc-4.1, I'm a little confused.  I'll need to dig into this
tomorrow and find out what's going on.  If you're going to take alook yourself,
it's the vmware_check functions that you should be looking at.  Once again,
thanks for you help...  5:)

installation of vmware-server/modules/console two days ago
on an Intel x64 machines works perfectly.

However, install vmware-server/modules/console today on an
amd64... not so much.

Using the gentoo cvs ebuilds I installed the latest vmware-server
beta on my intel x64 machine at the office and it works
fantastically... thanks!

However, doing the same thing on my home's amd64 machine
resulted in a console which cannot connect.

vmware-server starts and configures just fine.

But when any user (including root) tries to connect with the
console the console app hogs as much processor time as it
can and just hangs. Nothing is printed and nothing seems to
be appearing in the logs.

The vmware-console launches just fine and acts normal until
a connection is attempted. As soon as you press "connect"
it's a run away process.

Any ideas on what I did wrong or how to fix this? The only
variables I can think of are: Different USE flags on the
home machine to support my multimedia crap, The different
days of installation and most importantly the processor.
(Intel x86 vs amd athlon64-FX)

Thanks for the work on this package!

Hi Jeff, Sadly this issue isn't just limited to AMD64.  The console sadly
doesn't take to kindly to not receiving replies from the machine it's trying to
contact.  If it doesn't get any it sits there in a huge process munching loop. 
So double check two things for me please, first make sure that xinetd is allow
the connection (you can potentially find out in your syslogs.  Secondly double
check that the user you're trying to log in as (including root) is a member of
the vmware group.  Even root will be denied access, although if xinetd is
allowing the connection through, the auth daemon should be cleanly rejecting
it, and it shouldn't cause the CPU hogging.  If neither of these help, please
get back to me and we'll see if we can't diagnose the problem further...  5:)

Here's the only thing I see in my logs that seems relevant:

  May  4 22:54:24 mail xinetd[29869]: FAIL: vmware-authd address from=127.0.0.1
  May  4 22:54:24 mail xinetd[13925]: START: vmware-authd pid=29869
from=127.0.0.1

Which is very strange since:

  # /etc/xinetd.conf: sample configuration file for xinetd

  defaults
  {
        only_from      = localhost
        instances      = 60
        log_type       = SYSLOG authpriv info
        log_on_success = HOST PID
        log_on_failure = HOST
        cps            = 25 30
  }

  includedir /etc/xinetd.d

Which means that the default is to allow connections from
localhost and xinetd failed for address from 127.0.0.1
(which is localhost.) [and the starts something anyways...?]

and...
  root@mail:/etc/xinetd.d# more vmware-authd
  # default: on
  # description: The VMware remote access authentification daemon \
    service vmware-authd
  {
    disable         = no
    port            = 902
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = root
    server          = /opt/vmware/server/sbin/vmware-authd
  }

Which does not override the only_from specified in the default
configuration file. (or if it does do to absence then it should
be removing all restrictions.)

Both my root and normal user accounts are members of the vmware
group:
  jeffw@mail:~$ groups
  wheel floppy audio cdrom users jeffw vmware

My guess is that it would be the xinetd thingy. However,
The xinetd.conf and xinetd.d/vmware-authd files on both the
working machine AND the non-working machine are exactly the
same as reported by md5sum.
But it is hard to argue around the fact that
   grep FAIL /var/log/messages | grep xinet
on the working machines yeilds no line matches and on the
non-working machine a matching line is generated for every
connection attempt.

Sorry, that's all I have for tonight. There is a new beta
version of vmware out tonight. If I could choose, I would
rather see that in the cvs and ready for use before this
client/connect bug gets fixed.

Quicky update... I think its definitely an xinetd thing.
even though my defaults has only_from=localhost if I put
an explicit only_from=0.0.0.0/0 in the vmware-authd file
then the client is allowed.

strange that I don't need this on the other machine.

I'll try figuring out why tomorrow.
maybe one machine is able to reverse lookup localhost
and the other cannot (though both machines can "ping localhost").
hmmmm...

Is there a limit on how many times you can answer yourself?

Here's the deal (and I don't know why...)

On the functioning machine /etc/hosts had:

  127.0.0.1       localhost
  172.16.10.2     office office.work.com

On the non-functioning machine /etc/hosts had:
  127.0.0.1       mail.home.com mail localhost
  127.0.0.1       svn.home.com

Apparently, (I can't prove it nor do I know specifically)
xinetd looks like it is consulting /etc/hosts and is only
smart enough to look at the first machine name for each
IP entry. Thus it thinks 127.0.0.1 is mail.home.com.

I know this because if I change the non-working machine's
/etc/hosts to:
  127.0.0.1       localhost
  127.0.0.1       mail.home.com mail
  127.0.0.1       svn.home.com

Then DING! vmware-console works like a charm now with the
original xinetd configurations (i.e. the 0.0.0.0/0 test has
been reverted)

My guess would be that this is a bug in either xinetd or
some sort of resolver library; though I don't know what
"resolver" libraries exist or how they function and I doubt
xinetd parses the /etc/hosts file itself.

Anyhow, that's what I have for tonight. Sorry that I can't
provide an elegant/proper fix for the actual wrong thing
but my guess is that every soul having the same problem as
me has an /etc/hosts file that does not have localhost
defined as the first entry for 127.0.0.1. Even localhost.localdomain
as the first machine will screw it up.

Maybe somebody who understands the reverse name service that xinetd
is using to resolve localhost can take it from here. In any case I
think everybody should be able to get a functioning console now.

Thanks! (again)

No problem Jeff, I'm glad you got it sorted out, and thanks for giving people a
clear description of the problem, previously we only had comment 218 to go
which says effectively the same thing but no quite so clearly...   5:)

It's an xinetd bug and not really something I can fix unfortunately, however,
since it causes such an unfortunate effect on the console, I'm tempted to put a
comment about it in the vmware-server's end messages.

Also thanks for the heads-up on the new version, hopefully I'll get that pushed
out over the weekend sometime...  5:)

Hmm, I have a strange feeling that any-any update in vmware-modules ruins the
whole thing:

<snip>
Unable to change virtual machine power state: The process exited with an error:
vmxvmdb: Index name being generated from config file
POST(no connection): Version mismatch with vmmon module: expecting 138.0, got
137.0.
You have an incorrect version of the `vmmon' kernel module.
Try reinstalling VMware Server.
</snip>

Re-installing of course doesn't help, that's what was done right after emerging
 vmware-modules-101.

(In reply to comment #269)
> Hmm, I have a strange feeling that any-any update in vmware-modules ruins the
> whole thing:
> 
> <snip>
> Unable to change virtual machine power state: The process exited with an error:
> vmxvmdb: Index name being generated from config file
> POST(no connection): Version mismatch with vmmon module: expecting 138.0, got
> 137.0.
> You have an incorrect version of the `vmmon' kernel module.
> Try reinstalling VMware Server.
> </snip>

You're right. Installs and configures just fine, but displays this error when
trying to power on a virtual machine.

Ok, sorry about there.  There was a slight breakage for those of you who
installed the modules without already having a version of vmware installed. 
I'll fix this up when I release the updated ebuild for the new build version
(23869) over this weekend.

In the meantime, the best workaround is the following:

/etc/init.d/vmware stop
emerge --oneshot vmware-modules
/etc/init.d/vmware start

After this everything should work fine.  Stay tuned for the new version...  5:)

(In reply to comment #271)
> Ok, sorry about there.  There was a slight breakage for those of you who
> installed the modules without already having a version of vmware installed. 
> I'll fix this up when I release the updated ebuild for the new build version
> (23869) over this weekend.

Well no, I had vmware already installed..

> In the meantime, the best workaround is the following:
> 
> /etc/init.d/vmware stop
> emerge --oneshot vmware-modules
> /etc/init.d/vmware start

Tried already bunch of times, doesn't work. As said, the references I could
find suggest that the any-any-updates are to blame... It works fine w/ original
vmware-server-modules

Thanks for the feedback, Jakub.  I have tested the build successfully with the
vmware-any-any update (I try not to release completely broken builds!).  5:)  I
managed to replicate your problem, and I can tell you what to look for while
you're compiling the modules.  About two or three lines down it should say
something like "Building for Vmware Server 1 beta 1 or beta 2."  If it says
"Vmware 2 or VMware Express detected, building for VMware 2, VMware Express and
VMware Workstation 4.0.x."  Then something's gone wrong and the server
installation isn't working properly. 

Please note you MUST stop vmware (which should unload the modules) so that
you're not using the old modules.  If your kernel doesn't support module
unloading then you MUST reboot your machine to get the workaround to work. 
Please see if that helps, and if it *still* doesn't, then let me know...  5:)

(In reply to comment #273)
> About two or three lines down it should say
> something like "Building for Vmware Server 1 beta 1 or beta 2."  If it says
> "Vmware 2 or VMware Express detected, building for VMware 2, VMware Express and
> VMware Workstation 4.0.x."  Then something's gone wrong and the server
> installation isn't working properly. 

Hmmm, indeed. :=(

<snip>
>>> Compiling source in /var/tmp/portage/vmware-modules-101/work ...
 * Preparing vmmon module
VMware 2 or VMware Express detected, building for VMware 2, VMware Express and
VMware Workstation 4.0.x.
Using 2.6.x kernel build system.
</snip>

Ok, well the version detection system uses /etc/vmware/ (checking for
/etc/vmware/locations).  Once it's found that it uses the information in there
somehow to locate the /opt/vmware/server/bin/vmware file, which it then checks
for the version/build number.  That's as best as I'm aware of at the moment,
and those are the best places to look to track down the error.  Unfortunately,
it's going to be a little hard for me to replicate since my setup works.  I'd
recommend unpacking one of the tar files and trying to compile it manually. 
Follow through the checks it does of stuff in /etc/vmware and finally check
that it locates the right file under /opt/vmware/server.  The only other option
is to make a patch to the getversion.pl file that forces it always to print
"VME_S1B1".  That's definitely just a workaround, and it'd be more useful to
find out why it's breaking, but if you're desperate to get vmware working again
that should force it to work.  Sorry I can't be of more help...  5:\

Ok, thanks to another quick IRC session, Jakub and I tracked down the problem
to FEATURES="userpriv".  If the system is building as a user, that user can't
read /etc/vmware/locations and hence can't determine the correct vmware product
version, and so builds the lowest possible version (which won't work with
server).  I've just pushed out vmware-modules-101-r1.  If it currently works
for you there's no need to update, if you've been having trouble, please try
this...  I'm off to bed!  5:P

(In reply to comment #276)
> I've just pushed out vmware-modules-101-r1.  If it currently works
> for you there's no need to update, if you've been having trouble, please try
> this...  I'm off to bed!  5:P

Great, this works just fine.

BTW, why do the vmware init-scripts output so many empty lines during startup
and shutdown?

The various lines show each of the components that vmware starts and stops (so
for the various network adaptors there are individual NAT systems, DHCP
systems, etc that must be started).  By showing each step it can help us
diagnose exactly which component is failing at both startup and shutdown, if
any do fail.  The gentoo startup script is infact simply a wrapper around the
original vmware init script, so the output you're seeing is just a
"gentoo-ified" version of what everybody else running vmware would see.  I hope
this answers your question...  5:)

Ok, everybody, a BIG new update for you to try.  Yep, I've pushed build 23869
out to the subversion server and there's a *lot* changes that've gone on so try
to keep up...  5:)

vmware-modules:
* Now keeps track of which package it was built for (/opt/vmware/module-build)
* Features RESTRICT="userpriv" to ensure correct vmware version detection

vmware-server:
* Obviously now for build 23869
* vmware-pkg.eclass: will stop the ebuild if the modules are built incorrectly
* AMD64 vmware-authd jiggery pokery now done in the ebuild with dosed
* Patches moved to individual directory and bzipped up
* Modules are now built *after* vmware's installed, using PDEPEND (ugly)  5:\
* Rpath auxiliary download moved to my devspace for quicker updates

vmware-server-console:
* Vmware decided to officially rename it vmware-server-console to work with GSX
* Got sick of the hardcoded /etc/vmware-console path so made it into a variable
* Guest OS help is no longer included by vmware

Right, I *think* that's everything.  Then of course there's what vmware've done
(which you can find more about at
http://www.vmware.com/support/server/doc/releasenotes_server_beta.html).  Oh,
and this product will expire on the 16th of June, so expect another update
before then...  5:)

Finally then, I'd really like some testing on the AMD64 front (since I changed
the way the vmware-authd pam file is dealt with).  It'd be great if someone
could completely clear out vmware (including /etc/pam.d/vmware-authd) and try a
reinstall and see if it all works (or more specifically check that the
emulation paths are present in vmware-authd, I really don't trust dosed).  5:) 
And as ever comments and suggestions are more than welcome!  Have a good
weekend everybody!

One request and a comment.
Please stop removing the previous ebuilds...  They don't cause any harm being
there and portage wreaks havoc when things like this happen:

I don't have /usr/portage/eclass/vmware-pkg.eclass...  Is it something that
should be downloaded from your site?  If so, won't an emerge sync remove it for
us?

Help!!

(In reply to comment #280)
> I don't have /usr/portage/eclass/vmware-pkg.eclass...  Is it something that
> should be downloaded from your site?  If so, won't an emerge sync remove it for
> us?

eclass is on svn too :
svn co http://callisto.cs.kun.nl:81/svn/trees/vmware/eclass

This new version seems to work for me, thanks !

Thank you...  I didn't realize the portage overlay included eclass-type
directories...  Compiling now...

Ok, sorry, one minor revision bump that adds virtual/pam to the dependency list
and finally removes the amd64 kludge once and for all (thanks Deigo!!!)  5:)

Once again it'd be handy for some amd64 users to test this after a completely
clean install, which means removing:

/etc/init.d/vmware
/etc/pam.d/vmware-authd
/etc/xinetd.d/vmware-authd
/etc/vmware/
/etc/vmware-console
/etc/vmware-server-console
/opt/vmware
and possibly some directories in /var and /tmp, but they don't matter so
much...

Also, as requested from now on I'm going to try and keep *one* revision around,
should you need any older revisions, please revert your subversion repository
to an earlier checkout...

Once again thanks very much to all those of you who report bugs, or offer help
on this bug, it's really appreciated!  5:)

Added the overlay to layman. So you can now 

emerge layman
layman -f -a vmware

to install it.

(In reply to comment #278)
> The various lines show each of the components that vmware starts and stops (so
> for the various network adaptors there are individual NAT systems, DHCP
> systems, etc that must be started).  By showing each step it can help us
> diagnose exactly which component is failing at both startup and shutdown, if
> any do fail.

Thanks for the reply. I should have been more specific, though. I've thought
that the debug stuff should only be visible, when RC_VERBOSE="yes" in
/etc/conf.d/rc. That way it would be a lot easier to give better debug
messages, too.

It's quite ok right now, but I'm using the parallel startup and the init
process outputs a huge amount of stuff on startup. Hiding these blank lines
would make the messages more consistent and help tracking down unusual
behaviour. I don't know, how do patch this, but I guess some kind of
conditional around the messages does it. Please consider this as a minor
enhancement after all the important stuff is ready. Thanks in advance.

The new ebuild and layman stuff works fine here. (x86)

I inheritted the vmware initscript wrapper and it's unfortunately not one of my
higher priorities, but if someone submits me a patch I'll be happy to check it
though and add it to the patchset...  5:)

Glad it's all working!  5:)

Here is my $0.02 and observations:

If vmware-config.pl is going to modify /etc/xinetd.d/vmware-authd in any way,
it ought to ask the user for the value of "only_from" as well to make it more
complete.

"/etc/pam.d/vmware-authd" ought to be installed during the emerge instead of
having "vmware-config.pl" create/overwrite it.  This file is static in nature
and doesn't need to be overwritten each time "vmware-config.pl" is run.  Also,
"/etc/pam.d/vmware-authd" should include system-auth instead of defining its
own stack.

The "/etc/pam.d/vmware-authd" file should be as follows (The order of
pam_listfile.so might need to be changed but i'm not for sure):

#%PAM-1.0
auth       include      system-auth
auth       required     pam_nologin.so
account    include      system-auth
account    required     pam_listfile.so item=group sense=allow
file=/etc/vmware/vmwaregroup onerr=fail
password   include      system-auth
session    include      system-auth
-----

If "vmware-config.pl" is going to probe for unused private subnets, an
enhancement might be to save the results of the last probe so that it does not
have to be done again---that is if the probe does not stop after finding the
first unused subnet.

If the "/etc/xinetd.d/vmware-authd" file already exists, "vmware-config.pl"
states the following:

The default port : 902 is not free. We have selected a suitable alternative
port for VMware Server use. You may override this value now.
Remember to use this port when connecting to this server.
Please specify a port for remote console connections to use [903]
-----

An enhancement to "vmware-config.pl" would be to parse the
"/etc/xinetd.d/vmware-authd" file if it exists and use the port value found in
it instead of stating the above message.

"vmware-config.pl" does not remove "/etc/vmware/not_configured" after
completing the configuration but before trying to start the vmware services,
which results in the following:

* VMware Server is installed, but it has not been (correctly) configured
* for the running kernel. To (re-)configure it, invoke the
* following command: /opt/vmware/server/bin/vmware-config.pl.
* VMware is not properly configured! See above. [ !! ]
-----

Steven, thank you for your insightful two cents, and let me be the first to say
that I agree with you on each and every point you're making.  However, I'm
afraid that save for perhaps the very last point, you're making your case in
the wrong location.  These issues that you're finding are all with the vmware
configuration script, and I'm afraid I didn't write that.  I'm sure anyone
would agree that it's a little unreasonable for us to completely rewrite
someone else's configuration utility of 9000 lines because it has some
problems.  None-the-less that's actually one of the priority points on Chris's
list that is blocking this package from entering the main tree.

Whilst we are working towards this, I must put cosmetic issues and mild
annoyances at the very bottom of my list, which unfortunately includes your
point about the only_from field, which we already draw the user's attention to;
patching the config so that it does *not* recopy the vmware-authd file, and
then writing further code to do it ourselves; writing additional code to reduce
the amount of time that a probe takes, by caching the results and assuming
they're correct the next time and finally writing additional code to ensure
that the myriad ways the vmware-configure script uses to determine whether a
port is free, are disabled even when the port isn't free, as long as it's
vmware itself that's taking it.

I'm afraid that you've picked a rather unfortunate point, since the vmware
installation and configuration scripts have caused myself and numerous other
developers a great deal of pain in attempting to work with them.  It's quite
clear from your comments that you haven't spent time investigating some of your
requests for their feasability, because you'd soon find that the check to
determine whether port 902 is in use or not, doesn't care about the existance
of vmware-authd.  It in fact checks the netstat results to determine whether
the port is in use (if an old xinetd is still running, then it will be taken)
and even if it passes that, it appears that should it be registered in the
/etc/services file (which vmware-config thoughtfully does for it) then the port
is assumed to be taken.  Now, not to push a point home, but if you'd like to
find a solution to that particular problem, you can find the relevant code
snippet at the end of this (well, sadly now it's a) rant.  I'm sorry.

Now vmware is not entirely to blame.  We've done the installation ourselves
rather than using vmware's installation script, and as such we may not be
keeping a precise database of the times and locations of every file in
/etc/vmware/locations, but unfortunately that's exactly what the configure
script is expecting.  What this means is that it's possible that the
not_configured file isn't removed, because we haven't correctly inserted it
into the configuration database along with the exact modification time, so that
vmware feels safe in the knowledge that it can remove it without harm.  This
file however might be created by the config script, or because their init
script feels like it, or because the moon happens to be in the eigth quadrant. 
That point, however, I will look into, eventually, when I have more free time
to donate to the search.

As to the pam file, thank you for asserting how it should be, but I'm afraid I
must've missed the explanation that you will have provided telling me why it
needs changing and exactly which versions of pam it will work with, which it
won't, and generally providing me with a little more information, so that I
don't have to go out and do homework to determine whether your suggestion is a
good one (which from what I've heard from others, it is).   

And finally, since I try always to be constructive in my comments, please find
a link where you *can* best direct all of the points you've made:
http://www.vmware.com/requestsupport.  Note however that since Gentoo is an
unsupported operating system for Vmware, and that the chances are very high
that half of the jiggery-pokery we're doing to get vmware installed using
portage (so that you don't have to worry about it), is causing some of the
symptoms that you've reported.

I hope this has at least not been rude at any point, and if it has been, or has
even sounded as such, please accept my appologies.  It wasn't intended to be...

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

# Check the validity of an answer whose type is authdport
# Return a clean answer if valid, or ''
sub check_answer_authdport {
  my $answer = shift;
  my $source = shift;

  if ($source eq 'default') {
    if (check_if_port_free($answer) != 1) {
      return '';
    }
  }

  if (($answer =~ /^\d+$/) && ($answer > 0) && ($answer < 65536)) {
    return $answer;
  }

  if ($source eq 'user') {
    print wrap('The answer "' . $answer . '" is invalid. Please enter a valid '
               . 'port number in the range 1 to 65535.' . "\n\n", 0);
  }

  return '';
}
$gAnswerSize{'authdport'} = 5;
$gCheckAnswerFct{'authdport'} = \&check_answer_authdport;

# Check the validity of an answer whose type is number
# Return a clean number if valid, or '0'
# Default value for the 'number' type of answer.
# This $gMaxNumber as well as the $gAnswerSize{'number'} has to be updated
# before calling get_*_answer functions so that wrap() leaves enough room
# for the reply.
my $gMaxNumber = 0;
sub check_answer_number {
  my $answer = shift;
  my $source = shift;

  if (($answer =~ /^\d+$/) && ($answer > 0) && ($answer <= $gMaxNumber)) {
    return $answer;
  }

  if ($source eq 'user') {
    print wrap('The answer "' . $answer . '" is invalid. Please enter a valid '
               . 'number in the range 1 to ' . $gMaxNumber . "\n\n", 0);
  }

  return '';
}
$gAnswerSize{'number'} = length($gMaxNumber);
$gCheckAnswerFct{'number'} = \&check_answer_number;

my %gPortCache;
# Check $cServices file for specified port
# If $cServices cant be read, return -1
# If port not in $cServices return 1
# If port is in $cServices return 0
sub check_port_not_registered {
  my $port = shift;
  if (defined($gPortCache{$port}) && $gPortCache{$port} == 2) {
    return 0;
  }
  if (not open(CONF, $cServices)) {
    return -1;
  }
  while (<CONF>) {
    if (/\b(\d+)\/(tcp)\b/i) {
      $gPortCache{$1} = 2;
    }
  }
  close(CONF);
  if (defined($gPortCache{$port}) && $gPortCache{$port} == 2) {
    return 0;
  }
  return 1;

}


# Check the $cServices file and use /proc/net/tcp to see
# if the port is already in use.
# If we fail to check, return -1
# If port is free, return 1;
# If port is in use, return 0;
sub check_if_port_free {
  my $port = shift;
  if (defined($gPortCache{$port})) {
    return 0;
  }
  # Check /proc/net/tcp and /proc/net/udp
  if (open(TCP, "</proc/net/tcp")) {
    while (<TCP>) {
      if
(/^\s*\d+:\s*[0-9a-fA-F]{8}:([0-9a-fA-F]{4})\s*[0-9a-fA-F]{8}:[0-9a-fA-F]{4}\s*([0-9a-fA-F]{2}).*$/)
{
        # We'll consider a socket free if it is in TIME_WAIT state
        if ($2 ne "06") {
          $gPortCache{hex($1)} = 1;
        }
      }
    }
    close TCP;
  }
  if (defined($gPortCache{$port})) {
    return 0;
  }
  return check_port_not_registered($port);
}

I just cleaned out my beta2 Server installation and tried the latest ebuilds. I
ran into a similar problem with the vmware-modules version detection routine.
It didn't have a problem hitting /etc/vmware/locations, but it then runs
'/opt/vmware/server/bin/vmware -v' to get the version string. Since Server
hasn't been configured yet, the 'vmware' script just stops and complains about
running vmware-config, which leads vmware-modules to just default back to
VMware 2/Express/4.0. Running vmware-config before building the modules makes
it work, although I had to manually delete not_configured for some reason. With
that out of the way, everything else worked great!

Hi Brendan, the getversion.pl script should continue trying other binaries if
/opt/vmware/server/bin/vmware doesn't return an answer it's after.  I've
checked an unconfigured system, and even though /opt/vmware/server/bin/vmware
-v fails, the script then checks /opt/vmware/server/lib/bin/vmware -v (which
fails when looking for an expat.so library) and then
/opt/vmware/server/lib/bin/vmware-vmx -v, which successfully returns: VMware
Server e.x.p build-23869 Release.  Could you please try running the binaries in
the lib/bin directories and reporting the output here?  To deconfigure it,
simply touch /etc/vmware/not_configured, but remember you'll have to to remove
it manually afterwards.  Thanks...  5:)

As to the not_configured file, I'll try and investigate that sometime in the
coming week.  If anyone can get into a situation where they can't start service
after running the config script, could they please attach their
/etc/vmware/locations, and also the fstype and mount options of /etc/vmware? 
At the moment the config script treats not_configured as a file that it will
only remove if it put it there (which is a little daft, given the nature of the
file).  Reasons it can fail are not finding an entry in the
/etc/vmware/locations file, or if the modification time doesn't match.  So
either it's on a filesystem that doesn't store the mtime, or the file isn't
getting listed under /etc/vmware/locations.  Either way this should help me
further diagnose the problem...

My install went smoothly (8-5-06) but now there is the problem with connecting
the vmware console from a windows machine to my gentoo server. 

The errors are:
from the /var/log/vmware/vmware-serverd.log...
May 08 16:20:04: app| New connection on socket server-vmdb from host
pvf-beheer-02.pvf.intern (ip address: 192.168.10.24) , user: pvf
May 08 16:20:04: app| SP: New user session for user: pvf, pos: 0
May 08 16:20:04: app| The vm-list file has changed! Reloading the list of
registered vms
May 08 16:20:04: app| SSL: Unknown SSL Error
May 08 16:20:04: app| SSL Error: error:140940F6:SSL
routines:SSL3_READ_BYTES:unknown alert type
May 08 16:20:04: app| OvlHostStartIo: errno 104
May 08 16:20:04: app| vmdbPipe_Streams: Couldn't read
May 08 16:20:04: app| Failed to add connection to database : -32
May 08 16:20:04: app| Failed to accept new client vmdb connection
May 08 16:20:04: app| SP: Deleting user session: 0 username: pvf

and the ssl stream:

pvf-g-01 # ssldump  -dH
New TCP connection #2: pvf-beheer-02.pvf.intern(4302) <-> pvf-g-01(902)
0.0051 (0.0051)  S>C
---------------------------------------------------------------
220 VMware Authentication Daemon Version 1.10: SSL Required,
MKSDisplayProtocol:VNC
---------------------------------------------------------------

2 1  0.0060 (0.0008)  C>S  Handshake
      ClientHello
        Version 3.0
        cipher suites
        Unknown value 0x39
        Unknown value 0x38
        Unknown value 0x35
        SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        Unknown value 0x33
        Unknown value 0x32
        Unknown value 0x2f
        SSL_DHE_DSS_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_MD5
        SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
        SSL_DHE_RSA_WITH_DES_CBC_SHA
        SSL_DHE_DSS_WITH_DES_CBC_SHA
        SSL_RSA_WITH_DES_CBC_SHA
        SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
        SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
        SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
        SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
        SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
        SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
        SSL_RSA_EXPORT_WITH_RC4_40_MD5
        compression methods
                  NULL
2 2  0.0066 (0.0005)  S>C  Handshake
      ServerHello
        Version 3.0
        session_id[0]=

        cipherSuite         Unknown value 0x35
        compressionMethod                   NULL
2 3  0.0066 (0.0000)  S>C  Handshake
      Certificate
2 4  0.0066 (0.0000)  S>C  Handshake
      ServerHelloDone
2 5  0.1031 (0.0964)  C>S  Handshake
      ClientKeyExchange
2 6  0.1031 (0.0000)  C>S  ChangeCipherSpec
2 7  0.1031 (0.0000)  C>S  Handshake
2 8  0.1082 (0.0051)  S>C  ChangeCipherSpec
2 9  0.1082 (0.0000)  S>C  Handshake
2 10 0.2115 (0.1032)  C>S  application_data
2 11 0.2115 (0.0000)  C>S  application_data
2 12 0.2116 (0.0000)  S>C  application_data
2 13 0.2116 (0.0000)  S>C  application_data
2 14 0.2120 (0.0004)  C>S  application_data
2 15 0.2120 (0.0000)  C>S  application_data
2 16 0.2149 (0.0028)  S>C  application_data
2 17 0.2149 (0.0000)  S>C  application_data
2 18 0.2153 (0.0003)  C>S  application_data
2 19 0.2153 (0.0000)  C>S  application_data
Unknown SSL content type 70
2 20 0.2161 (0.0007)  C>S  Alert
2 21 0.2161 (0.0000)  S>CShort record
Unknown SSL content type 70
2    0.2167 (0.0006)  C>S  TCP RST

Does anybody know something about this? 
Can you turn SSL off (just for testing)?

I commented out the mdns line in /etc/host. 
If this is the wrong place for this problem, sorry! and tell me  where I should
have asked it. If you need more info ask please.

(In reply to comment #283)
> Once again it'd be handy for some amd64 users to test this after a completely
> clean install, which means removing:

Hi there :)

I'm keen to try the ebuild on my amd64 rig, but ran into a problem trying to
digest the vmware-server ebuild (the modules and console 'digested' fine):

ebuild
/etc/portage/overlay/app-emulation/vmware-server/vmware-server-1.0.0.23869-r1.ebuild
digest
/usr/lib/portage/bin/ebuild.sh: line 1524:
/usr/portage/eclass/vmware-pkg.eclass: No such file or directory

!!! ERROR: app-emulation/vmware-server-1.0.0.23869-r1 failed.
!!! Function inherit, Line 1525, Exitcode 1
!!! died sourcing /usr/portage/eclass/vmware-pkg.eclass in inherit()
!!! If you need support, post the topmost build error, NOT this status message.


aux_get(): (0) Error in app-emulation/vmware-server-1.0.0.23869-r1 ebuild. (1)
               Check for syntax error or corruption in the ebuild. (--debug)

/usr/lib/portage/bin/ebuild.sh: line 1524:
/usr/portage/eclass/vmware-pkg.eclass: No such file or directory

!!! ERROR: app-emulation/vmware-server-1.0.0.23869-r1 failed.
!!! Function inherit, Line 1525, Exitcode 1
!!! died sourcing /usr/portage/eclass/vmware-pkg.eclass in inherit()
!!! If you need support, post the topmost build error, NOT this status message.


aux_get(): (0) Error in app-emulation/vmware-server-1.0.0.23869-r1 ebuild. (1)
               Check for syntax error or corruption in the ebuild. (--debug)

Traceback (most recent call last):
  File "/usr/bin/ebuild", line 71, in ?
    a = portage.doebuild(ebuild, arg, portage.root, tmpsettings, debug=debug,
cleanup=("noauto" not in portage.features), tree=mytree)
  File "/usr/lib/portage/pym/portage.py", line 2435, in doebuild
    eapi = db[root][tree].dbapi.aux_get(mycpv, ["EAPI"])[0]
  File "/usr/lib/portage/pym/portage.py", line 5407, in aux_get
    raise KeyError
KeyError

Care to lend a guy a hand? :) Kernel is 2.6.15.

Thanks

Marteen, I'm not certain what to suggest I'm afraid, other than ensuring that
you're using the same build number for the windows console as you have built
for the server.  The latest server build number is 23869, and you should aim to
use the same windows console build number.  mdns should not be required, and as
to turning off SSL, I'm not sure but it may be possible, try VMTN for the
information.  Sorry I can't be of more help at the moment, but I'll keep
looking at my end too...

Darren, yeah, your problem looks as though you got everything from
app-emulation, but not from eclass.  In the subversion repository there's now
an eclass directory containing the vmware-pkg.eclass (soon to be vmware.eclass)
that should be what you need to get the digest made correctly, and to have the
install all work...  5:)

Additional Comment on #291..

Thanks for your advice. I upgraded the windows console to the latest (and same
as server) built. 
The errors are the same on the server, but now the console errors:

"Connection terminated by server,
C:/ob/bora-23869/pompeii2005/bora/lib/connect/authdConnection.c:875 ret -1 err
0"

I wasn't able to find anything yet. 

Maarten

Maarten, could you also please ensure that the connection works with the linux
vmware-console.  It doesn't sound like an xinetd issue, but there's always the
chance, so I'd just like to make sure the linux console (from a *different*
computer) works fine without any problems.  If it does, then I'm still stumped,
but apparently I'm in good company.  The thread on vmtn is at: 

http://www.vmware.com/community/thread.jspa?messageID=391942

and save for double checking your xinetd configuration files, they don't know
what's causing it either...  5:\

Mike, 
I installed the linux version on my laptop. Damn... only 2 minutes work!
Now my nice errors: 

The "VMware server Console" Error box:
Unable to connect to the remote host: Error reading from vmware-authd socket.
Reason: Success.

"VMware server Console" xterm output:
tux portage # vmware-server-console
Using log file /tmp/vmware-root/ui-27223.log
Cannot load message dictionary
"/opt/vmware/server/console/lib/messages/en/tip_l ist.vmsg".
*** attempt to put segment in horiz list twice
Dlg::GetButtonInfo(): Duplicate GTK icon/label pair: _Stop and _Stop
Dlg::GetButtonInfo(): Duplicate GTK icon/label pair: _Forward and _Forward
Dlg::GetButtonInfo(): Duplicate GTK icon/label pair: _Information and
Informatio n
Http_GetData: failed to get data for url http://www.vmware.com/info?id=181:
can' t create request
SSL: Unknown SSL Error
SSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number


"VMware server Console" last part of logfile output:
May 09 15:09:04: vmui| VmdbVmCfg_UpdateFile: Could not load dictionary file
/root/.vmware/preferences: Unable to get information about file
"/root/.vmware/preferences": No such file or directory.
May 09 15:09:04: vmui|
May 09 15:09:04: | Unrecognized HTTP proxy URL
"http://internet:internet@proxy:8080".
May 09 15:09:04: | Http_GetData: failed to get data for url
http://www.vmware.com/info?id=181: can't create request
May 09 15:09:16: vmui| SSL: Unknown SSL Error
May 09 15:09:16: vmui| SSL Error: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number

So, I think it's the same error... I think my xinetd is fine. I authenticates
to   vmware-authd.

Is it possible the problem is in the "vmware-auth socket". 
The vmware-server is installed on a server and I remotely connects to it from
my gentoo-laptop or from another windows 2003 computer. On the vmware server
there is no X installed

Hi Maarten, no, it's a bit of a weird error.  From what I can see the SSL3
connection is dying because it's getting something it didn't expected (and SSL
as a security features breaks the connection if anything fishy starts
happeneing).

Some things to look into are: which port is the console trying to connect to
and which port is the server running on.  You said it was currently running on
904.  Please check there's nothing running on 902 normally by:

/etc/init.d/xinetd stop
netstat -lnp | grep :902

If there's nothing reported then you should be fine to re-run the server config
and force it to use port 902.

(The reason it says it's not free is because of either an already running
xinetd instance that's serving out 902, or from the entry to services which
vmware itself adds.  If you stop /etc/init.d/xinetd, remove
/etc/xinetd/vmware-authd and remove the two vmware-authd entries at the end of
/etc/services/ then it should say it's free and let you have it anyway.)

Once it's running on that port, please try the linux connection again, and
report back what results you get.  Thanks!  5:)

Thanks for you help Mike, looks like I did indeed slip up with the svn checkout
:$

Anyway, all packages emerged and running sweet as a nut. Was able to fire up
the neccesary daemons and start the console on my box. The problem I've hit is
that, when trying to create a new vm, the console errors saying that the vmmon
module is a lower version than expected:

Unable to change virtual machine power state: The process exited with an error:
vmxvmdb: Index name being generated from config file
POST(no connection): Version mismatch with vmmon module: expecting 138.0, got
137.0.
You have an incorrect version of the `vmmon' kernel module.
Try reinstalling VMware Server.

POST(no connection): Failed to initialize monitor device.

Failed to initialize VM.
End of error message.

I double checked to make sure I checked out the lastest vmware-modules ebuild
and indeed I have (revision 42).

I then --unmerged the vmware-modules package, and re-emerged it, ran the config
script again... and it worked. Cant explain it :S

Both my Linux console and a Windows console of the same version can connect and
manipulate the vms happily. Great stuff :)

Yeah, not to worry about the lower module version thing Darren, rebuilding was
the right choice.  I think it goes wrong if you've got FEATURES="userpriv"
(although that's restricted now thanks to revision 42) and it could also go
wrong if you build the modules before building the vmware-server (which might
have been the case in an earlier revision too).  Glad it's all working for you
though, keep the bug reports coming in...  5:)

Humm, I'm getting strange behavior digesting revision 45 of vmware-server, it
looks like it is looking for an eclass directory that doesn't exist on my local
portage.

Martin

Martin, I sneaked out revision 45 since Chris suggested that we keep all the
vmware stuff in a single vmware.eclass (rather than a vmware-pkg.eclass for
packages, vmware-mod for modules etc).  What that means is that you're probably
missing the eclass/vmware.eclass file from your subversion repository...  If
you're still getting digest problems, give me a shout and I'll sort it out... 
5:)

One thing that may've been causing you trouble is unmerging the previous
version, because the vmware-pkg eclass was no longer present (and it doesn't
get copied for the uninstallation unlike ebuilds).  I've checked it back in
temporarily, but have intentions of removing it a few days after I push out the
next revision.  Sorry for the inconvenience...  5:\

Mike, I don't use port 904, but anyways.. I checked it yesterday an posted my
results, but my post is lost somehow.
When I stop xinetd, ther is only sshd listening on port 22, nothing else.
I rerun the server-config script, and set it again at port 902. 
The results when I try my linux connection are exactly the same.

On the VMTN i found this link:
http://www.vmware.com/community/thread.jspa?messageID=359503&#359503

I run vmware-server on a JFS filesystem!!. To ben honest, I built this server
with EVMS and JFS filesystem only to run vmware server. Maybe I've got 

problems now...

This morning I checked out the revision 46 an did a 'emerge --unmerge
vmware-server vmware- modules' 
and emerge vmware-server..

But same error again : SSL Error: error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number in vmware-console logs
I tried it from my windows machine, my gentoo laptop, and local with 
Xforwarding to my laptop. Same error. 
Only windows errors also:
C:/ob/bora-23869/pompeii2005/bora/lib/connect/authdConnection.c:875 ret -1 err
0
And vmware-auth errors: 
May 11 13:12:32: app| SSL: Unknown SSL Error
May 11 13:12:32: app| SSL Error: error:140940F6:SSL
routines:SSL3_READ_BYTES:unknown alert type

I think it's clearly an SSL error.

Should I ask it on the VMTN? Any ideas? I ran out of ideas.... 
Maarten

Maarten, best I can suggest is to try out the suggestion in comment 94.  It's
the only other reported case of people having trouble with JFS on this bug, and
it offers a workaround.  If the machine's been built purely for using as a
vmware-server could I suggest ext3 or reiserfs for the file system instead?  I
don't know exactly why vmware has issues with JFS, but I've already added a
comment to the end of the package installation, so I'm not really sure what
else I can do...  Anyway, give that workaround a try and see if it solves the
problem...

(You could also try that logEnabled stuff that petr mentions in the second to
last post, and see what turns up?  If you're also getting file not found
issues, I reckon it's vmware having difficulty reading from the partition
/var/run/vmware's on...)

GOT IT WORKING... ak SOLVED SSL error....

Mike, thank u very much for you fast replies!
Indeed it's the JFS, I missed the comment in the ebuild the first time...
sorry.
I did (by heart):
* dd if=/dev/zero /var/filesystem.img bs=100M count=1
* mkfs.ext3 /var/filesystem.img
* mkdir /mnt/vm_ext3
* mount -o loop /var/filesystem.img  /mnt/vm_ext3
* ln -s /mnt/vm_ext3/etc/vmware /etc/vmware
* ln -s /mnt/vm_ext3/var/log/vmware /var/log/vmware
* mv /etc/vmware/* /mnt/vm_ext3/etc/vmware
* mv /var/log/vmware/* /mnt/vm_ext3/var/log/vmware

But why the SSL error ????? That way it's impossible to find the problem...

Thanks Mike, I will post this also in the VMTN....

Mike, do you have any plans to work on an ebuild for the web based management
package vmware provide?

I do, but they're extremely low down on my list of priorities, mostly because
I've never used them myself and don't know much about them.  As always if
anyone wants to contribute one (as has been done for the vmware-server-tools
package which I'm reviewing), please feel free to attach it here, and I'll give
it a look through and add it to the repository once it's ready...  5:)

Hello.

I downloaded the overlay from http://callisto.cs.kun.nl:81/svn/trees/vmware/
and installed vmware server. After installation, I ran vmware-config.pl. At the
end, it fails to start bridged networking:

 * Starting VMware services:                                       [ ok ]
 *   Virtual machine monitor                                       [ ok ]
 *   Virtual ethernet                                              [ ok ]
 *   Bridged networking on /dev/vmnet0                             [ !! ]

I suppose because of that failure, I cannot run "eselect rc start vmware":

alexander@blatt /Gentoo/Portage/local-tree/overlays/vmware $ sudo eselect rc
start vmware
Starting init script
 * VMware Server is installed, but it has not been (correctly) configured
 * for the running kernel. To (re-)configure it, invoke the
 * following command: /opt/vmware/server/bin/vmware-config.pl.
 * VMware is not properly configured! See above.                  [ !! ]

In /etc/vmware, I've got the not_configured file.

I use suspend2-sources and a wlan NIC which uses madwifi-ng and thus ath0. I've
also got an unused eth0. During vmware-config run, I gave the following
answers:

Do you want networking for your virtual machines? (yes/no/help) [yes] yes
Your computer has multiple ethernet network interfaces available: ath0, eth0.
Which one do you want to bridge to vmnet0? [eth0] ath0

. vmnet0 is bridged to ath0

Do you wish to configure another bridged network? (yes/no) [no] no
Do you want to be able to use NAT networking in your virtual machines? (yes/no)
[yes] yes

Configuring a NAT network for vmnet8.

Do you want this program to probe for an unused private subnet? (yes/no/help)
[yes] yes

. vmnet8 is a NAT network on private subnet 192.168.158.0.


Probing for an unused private subnet (this can take some time)...

The subnet 192.168.158.0/255.255.255.0 appears to be unused.

The following NAT networks have been defined:

Do you wish to configure another NAT network? (yes/no) [no] no
Do you want to be able to use host-only networking in your virtual machines?
[yes] yes


Do you want this program to probe for an unused private subnet? (yes/no/help)
[yes] yes

. vmnet1 is a host-only network on private subnet 172.16.184.0.


Probing for an unused private subnet (this can take some time)...

The subnet 172.16.184.0/255.255.255.0 appears to be unused.

The following host-only networks have been defined:

Do you wish to configure another host-only network? (yes/no) [no] no
Please specify a port for remote console connections to use [903] 902

The file "/etc/xinetd.d/vmware-authd" already exists and seems to have been
modified manually.  Overwrite? [no] yes
Configuring the VMware VmPerl Scripting API.

Building the VMware VmPerl Scripting API.

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

Installing the VMware VmPerl Scripting API.

The installation of the VMware VmPerl Scripting API succeeded.

The file /etc/pam.d/vmware-authd that this program was about to install already
exists.  Overwrite? [yes] yes

Configuring the VMware VmPerl Scripting API.

Building the VMware VmPerl Scripting API.

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

Installing the VMware VmPerl Scripting API.

The installation of the VMware VmPerl Scripting API succeeded.

The file /etc/pam.d/vmware-authd that this program was about to install already
exists.  Overwrite? [yes] yes

Generating SSL Server Certificate

In which directory do you want to keep your virtual machine files?
[/var/lib/vmware/Virtual Machines] /var/lib/vmware/Virtual Machines

The path "/var/lib/vmware/Virtual Machines" does not exist currently. This
program is going to create it, including needed parent directories. Is this
what you want? [yes] yes

Please enter your 20-character serial number.

Type XXXXX-XXXXX-XXXXX-XXXXX or 'Enter' to cancel:  $SN


 * Starting VMware services:                                [ ok ]
 *   Virtual machine monitor                                [ ok ]
 *   Virtual ethernet                                       [ ok ]
 *   Bridged networking on /dev/vmnet0                      [ !! ]
 *   Host-only networking on /dev/vmnet1 (background)       [ ok ]
 *   Host-only networking on /dev/vmnet8 (background)       [ ok ]
 *   NAT service on /dev/vmnet8                             [ ok ]
The configuration of VMware Server e.x.p build-23869 for Linux for this running
kernel completed successfully.


Something to explain - before I wrote this bug report, I already had
vmware-server installed. Because of that, the pam and xinetd files existed.


/etc is on a xfs.


Why is bridged network setup failing?

alexander@blatt ~ $ uname -a
Linux blatt 2.6.16-suspend2-r5.043.security-models #1 PREEMPT Thu May 4
20:49:26 CEST 2006 i686 Intel(R) Celeron(R) M processor         1.50GHz
GNU/Linux

alexander@blatt ~ $ cat /etc/vmware/locations
answer BINDIR /opt/vmware/server/bin
answer SBINDIR /opt/vmware/server/sbin
answer LIBDIR /opt/vmware/server/lib
answer MANDIR /opt/vmware/server/man
answer DOCDIR /opt/vmware/server/doc
answer RUN_CONFIGURATOR no
answer INITDIR /etc/vmware/init.d
answer INITSCRIPTSDIR /etc/vmware/init.d
directory /etc/vmware
directory /etc/vmware/pam.d
file /etc/vmware/pam.d/vmware-authd 1147605256
file /etc/vmware/signing-key.pub 1146002398
file /etc/vmware/installer.sh 1146002398
file /etc/vmware/not_configured
directory /etc/vmware/init.d
directory /etc/vmware/init.d/rc0.d
file /etc/vmware/init.d/rc0.d/.keep 1147605316
directory /etc/vmware/init.d/rc1.d
file /etc/vmware/init.d/rc1.d/.keep 1147605316
directory /etc/vmware/init.d/rc2.d
file /etc/vmware/init.d/rc2.d/.keep 1147605316
directory /etc/vmware/init.d/rc3.d
file /etc/vmware/init.d/rc3.d/.keep 1147605316
directory /etc/vmware/init.d/rc4.d
file /etc/vmware/init.d/rc4.d/.keep 1147605316
directory /etc/vmware/init.d/rc5.d
file /etc/vmware/init.d/rc5.d/.keep 1147605316
directory /etc/vmware/init.d/rc6.d
file /etc/vmware/init.d/rc6.d/.keep 1147605316
file /etc/vmware/init.d/vmware 1147605255
file /etc/vmware/init.d/xinetd 1147609165
file /etc/vmware/vmwaregroup 1147605316
file /etc/vmware/locations
answer EULA_AGREED yes
remove_file /opt/vmware/server/lib/libconf/etc/pango/pangorc
file /opt/vmware/server/lib/libconf/etc/pango/pangorc 1147609344
remove_file /opt/vmware/server/lib/libconf/etc/pango/pango.modules
file /opt/vmware/server/lib/libconf/etc/pango/pango.modules 1147609344
remove_file /opt/vmware/server/lib/libconf/etc/pango/pangox.aliases
file /opt/vmware/server/lib/libconf/etc/pango/pangox.aliases 1147609344
remove_file /opt/vmware/server/lib/libconf/etc/gtk-2.0/gdk-pixbuf.loaders
file /opt/vmware/server/lib/libconf/etc/gtk-2.0/gdk-pixbuf.loaders 1147609344
remove_file /opt/vmware/server/lib/libconf/etc/gtk-2.0/gtk.immodules
file /opt/vmware/server/lib/libconf/etc/gtk-2.0/gtk.immodules 1147609344
answer NETWORKING yes
answer VNET_0_INTERFACE ath0
remove_answer VNET_0_INTERFACE
answer VNET_0_INTERFACE ath0
answer VNET_8_NAT yes
answer VNET_8_HOSTONLY_HOSTADDR 192.168.158.1
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
directory /etc/vmware/vmnet8
directory /etc/vmware/vmnet8/dhcpd
file /etc/vmware/vmnet8/dhcpd/dhcpd.conf 1147609425
file /etc/vmware/vmnet8/dhcpd/dhcpd.leases
file /etc/vmware/vmnet8/dhcpd/dhcpd.leases~
directory /etc/vmware/vmnet8/nat
file /etc/vmware/vmnet8/nat/nat.conf 1147609425
answer VNET_1_HOSTONLY_HOSTADDR 172.16.184.1
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
directory /etc/vmware/vmnet1
directory /etc/vmware/vmnet1/dhcpd
file /etc/vmware/vmnet1/dhcpd/dhcpd.conf 1147609578
file /etc/vmware/vmnet1/dhcpd/dhcpd.leases
file /etc/vmware/vmnet1/dhcpd/dhcpd.leases~
answer AUTHDPORT 902
file /etc/xinetd.d/vmware-authd 1147609665
file /etc/pam.d/vmware-authd 1147609697
directory /etc/vmware/ssl
file /etc/vmware/ssl/rui.key 1147609697
file /etc/vmware/ssl/rui.crt 1147609697
file /opt/vmware/server/lib/serverd/init.pl 1147609697
file /etc/vmware/init.d/rc2.d/S90vmware
file /etc/vmware/init.d/rc2.d/K08vmware
file /etc/vmware/init.d/rc3.d/S90vmware
file /etc/vmware/init.d/rc3.d/K08vmware
file /etc/vmware/init.d/rc5.d/S90vmware
file /etc/vmware/init.d/rc5.d/K08vmware
file /etc/vmware/init.d/rc0.d/K08vmware
file /etc/vmware/init.d/rc6.d/K08vmware
answer VMDIR /var/lib/vmware/Virtual Machines
directory /var/lib/vmware/Virtual Machines
file /etc/vmware/config 1147609775
remove_file /etc/vmware/not_configured
file /etc/vmware/not_configured 1147609810

alexander@blatt ~ $ emerge --info
Portage 2.1_rc1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.4-r3,
2.6.16-suspend2-r5.043.security-models i686)
=================================================================
System uname: 2.6.16-suspend2-r5.043.security-models i686 Intel(R) Celeron(R) M
processor         1.50GHz
Gentoo Base System version 1.12.0_pre19
ccache version 2.4 [enabled]
dev-lang/python:     2.3.4-r1, 2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r1
dev-util/confcache:  0.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -mtune=pentium-m -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-O2 -mtune=pentium-m -pipe -fomit-frame-pointer"
DISTDIR="/Gentoo/Portage/distfiles"
EMERGE_DEFAULT_OPTS="--alphabetical"
FEATURES="autoconfig buildpkg ccache collision-protect confcache distlocks
metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="        http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/  
http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/  
ftp://ftp.tu-clausthal.de/pub/linux/gentoo/    
http://distro.ibiblio.org/pub/linux/distributions/gentoo/     
ftp://distro.ibiblio.org/pub/linux/distributions/gentoo        
http://distfiles.gentoo.org/ "
LANG="de_DE.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="de"
PKGDIR="/Gentoo/Portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/Gentoo/Portage/build"
PORTDIR="/Gentoo/Portage/tree"
PORTDIR_OVERLAY="/Gentoo/Portage/local-tree/misc
/Gentoo/Portage/local-tree/overlays/nx
/Gentoo/Portage/local-tree/overlays/gentoo-de
/Gentoo/Portage/local-tree/overlays/vmware"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 GAPING_SECURITY_HOLE X acpi alsa amd apache2 apm arts artswrappersuid
async avi bash-completion bdf berkdb bitmap-fonts bluetooth bootsplash cairo
caps cardbus ccache cdda cddb cdio cdparanoia cdr cdrom cle266 cli crypt css
curlwrappers dbus devmap dillo divx4linux dlloader dri dvd dvdread emoticon esd
exif fam fbcon fbdev firefox fping freetype gdbm gif gnokii gnome gstreamer gtk
gtk2 hal hpn icc id3 idn imap imlib imlib2 insecure-drivers insecure-savers
isdnlog javascript jikes jpeg kde kdeenablefinal libedit libwww
linuxthreads-tls logrotate lynxkeymap mad madwifi maildir matroska mbox mmx
mmxext mozilla moznoirc mozsvg mp3 mpeg mpeg2 mpeg4 mplayer multicall ncurses
netboot network new-login nfs nis nls no-old-linux no-suexec noantlr nobcel
nobeanutils nobsf nobsh nocd nocommonslogging nocommonsnet nodrm nogg nogulm
nojsch nojython nolog4j nomac nooro nopri norhino noxalan noxerces nozaptel
nptl nsplugin offensive ogg opengl openssh pam_console pam_timestamp passfile
password patented pccts pcmcia pcre perl perlsuid pic player png pnp pppd qt
quicktime rar readline real recode reflection reiserfs sdl sendfile sensord
session sftp sms spell spf spl sse sse2 ssl startup-notification stream subp
subtitles suid symlink sysfs syslog tiff transcode truetype truetype-fonts
trusted type1-fonts udev underscores unichrome unicode unsafe usb utf8 uudeview
vim vim-pager vlm vorbis wifi win32codecs wma123 x11vnc xinetd xml xmms xorg
xpm xprint xscreensaver xv xvid xvmc zlib elibc_glibc input_devices_evdev
input_devices_keyboard input_devices_mouse input_devices_-synaptics
kernel_linux linguas_de userland_GNU video_cards_fbdev video_cards_vesa
video_cards_vga video_cards_via"
Unset:  ASFLAGS, CTARGET, INSTALL_MASK, LC_ALL, MAKEOPTS,
PORTAGE_RSYNC_EXTRA_OPTS

alexander@blatt ~ $

(In reply to comment #308)
> I use suspend2-sources and a wlan NIC which uses madwifi-ng and thus ath0. I've
> also got an unused eth0. 

Bridging wireless devices is known to produces notoriously weird/bad/completely
broken results, depending on involved drivers, so I'm not really surprised this
doesn't work...

(In reply to comment #309)
> (In reply to comment #308)
> > I use suspend2-sources and a wlan NIC which uses madwifi-ng and thus ath0. I've
> > also got an unused eth0. 
> 
> Bridging wireless devices is known to produces notoriously weird/bad/completely
> broken results, depending on involved drivers, so I'm not really surprised this
> doesn't work...

Okay. I also got problems with NAT:

 *   NAT service on /dev/vmnet8             [ !! ]

Is that also a known issue?

Hello,

after a svn up I get this:

Calculating world dependencies  /usr/lib/portage/bin/ebuild.sh: line 1562:
/usr/
portage/eclass/vmware.eclass: No such file or directory

!!! ERROR: app-emulation/vmware-server-1.0.0.23869-r1 failed.
!!! Function inherit, Line 1563, Exitcode 1
!!! died sourcing /usr/portage/eclass/vmware.eclass in inherit()
!!! If you need support, post the topmost build error, NOT this status message.


aux_get(): (0) Error in app-emulation/vmware-server-1.0.0.23869-r1 ebuild. (1)
               Check for syntax error or corruption in the ebuild. (--debug)

/usr/lib/portage/bin/ebuild.sh: line 1562: /usr/portage/eclass/vmware.eclass:
No
 such file or directory

!!! ERROR: app-emulation/vmware-server-1.0.0.23869 failed.
!!! Function inherit, Line 1563, Exitcode 1
!!! died sourcing /usr/portage/eclass/vmware.eclass in inherit()
!!! If you need support, post the topmost build error, NOT this status message.


aux_get(): (0) Error in app-emulation/vmware-server-1.0.0.23869 ebuild. (1)
               Check for syntax error or corruption in the ebuild. (--debug)

Where is my Error?

Regards Roland

Roland, please double check that you have checked out the complete repository. 
That contains both /app-emulation/vmware-... and also /eclass/vmware.eclass. 
You'll need that to be able to complete the installation.  If you need further
details please see comment 292.

As always, I realize it's a long bug, but please do have a read through at
least the most recent comments to see if someone's already got a solution that
might work for you.  Thanks...  5:)

Hi again Mike,

I'm hitting unexplained oddness unfortunately. Fairly often, when I restart
this box, vmware becoimes unresponsive. The server console takes ages to start
up, I'm unable to power on Virtual Machines, and have trouble even stopping the
server via the init script.

So far the only way I've found to stop it is unmerge the packages, reboot the
system, and re=merge the packages... making it fine until next boot. Any
immediate thoughts?

Just for example:

/opt/vmware/server/bin/vmware-cmd /vms/XP\ Client/XP\ Client.vmx start
/opt/vmware/server/bin/vmware-cmd: Could not connect to VM /vms/XP Client/XP
Client.vmx
  (VMControl error -14: Unexpected response from vmware-authd: The
"/opt/vmware/server/lib/bin/vmware-vmx" process did not start properly
 Try running "/opt/vmware/server/lib/bin/vmware-vmx /vms/XP Client/XP
Client.vmx" from the command-line on the server.)

From the serverd log:

ay 16 18:28:22: app| Adding to list of running vms: /vms/XP Client/XP
Client.vmx
May 16 18:28:22: app| Attempting to launch vmx : /vms/XP Client/XP Client.vmx
May 16 18:28:53: app| Error during launch: 11, Error connecting to
/opt/vmware/server/lib/bin-debug/vmware-vmx process.
May 16 18:28:53: app| VmsdVmStatePendingCmdFailed: cmd status is already set

Hiya Darren,

Best I can come up with is the following link:

http://www.vmware.com/community/thread.jspa?threadID=15082&tstart=120

which suggests you double check your vm machine permissions.  Doesn't sound
like a valid fix (since re-installing vmware-server shouldn't change any
permissions) but please give it a check just in case.  Otherwise you've got me
stumped, I've never heard of it before, and I don't run my virtual machines
often enough to come across the problem myself I'm afraid.  If anyone else has
experienced this, please do post and maybe we can find the common thread...

Other possibly related links are:

http://www.vmware.com/community/thread.jspa?messageID=97503&#97503
http://www.vmware.com/community/thread.jspa?messageID=15001&#15001

They do all seem to be permission problems, so please also double check that
the user you're logging in as can create a vmware directory or .vmware
directory or whatever in their home directory.

Finally, please try out what the error message suggested (the "Try running..."
line)...

Ok Mike, I'll go through those links and check my persmission, though root
experiences the same behaviour so you wouldn't think that's the culprit.

Oh, and thet 'please try' message came from running that exact command ;)

Silly little issue that might be able to fixed in the ebuild...

for virtual interfaces you can either run your own dhcp server
or you can let vmware run its own internal dhcp server.

Personally I hate the latter since I'm already running a dhcp
server for other physical interfaces why not just add vmnet1
to the list of interfaces?

Anyways, /opt/vmware/server/bin/vmware-config.pl does a test to
see if you are already running your own dhcpd server. however
the test looks for /etc/dhcp.conf. Of course this never exists
on a gentoo machine because it is /etc/dhcp/dhcp.conf.

Maybe a patch should be created to modify vmware-config.pl to
check the normal gentoo location instead.

Checked the ebuilds out from the svn repository and installed on two machines
today, both worked perfectly!  The ebuilds rock.

However, I do happen to have one machine that does not have pam installed.  It
would be nice to have the pam specific items in the ebuild and the dependency
on pam to only apply to installations using pam ;)  It appears to me that
vmware-server uses its own internal pam libraries so I wonder if the dependency
is really needed at all...

Jeff, your change doesn't look too difficult, and assuming the vmware logical
correctly detects that you may have dhcpd installed but not be using it, I'm
very happy to make the change.  If you don't see it in the next subversion
update for the ebuild (not sure how soon that will be), feel free to poke me
repeatedly until it's there...  5:)

Mike, glad to hear it's all working.  You're quite right, vmware ships with
just about every single library it could possibly need, ever, including the pam
ones, however these are almost always fallback libraries, with it prefering to
use the system libraries if possible.  So I guess basically the answer is, I'm
not certain whether I can remove the pam libraries or not, but I'll consult
with some of my colleagues on the matter, and see if I can't get back to you
with a yay or a neigh, ok?  5:)  Again, give me a good prodding if I haven't
responded by Monday...

(In reply to comment #319)
> ones, however these are almost always fallback libraries, with it prefering to
> use the system libraries if possible.  So I guess basically the answer is, I'm
> not certain whether I can remove the pam libraries or not, but I'll consult
> with some of my colleagues on the matter, and see if I can't get back to you
> with a yay or a neigh, ok?  5:)  Again, give me a good prodding if I haven't
> responded by Monday...

Don't get me wrong, I'm not suggesting to get rid of the pam libraries in the
package itself, only the dependency on pam in the ebuild DEPEND statement...

(In reply to comment #320)
> Don't get me wrong, I'm not suggesting to get rid of the pam libraries in the
> package itself, only the dependency on pam in the ebuild DEPEND statement...

Well, AFAIK know there's a stance to prefer system libs to bundled ones
whenever possible, esp. wrt potential security issues. Prevents need to fix
tons of ebuilds once a vulnerability appears.

Mike, yeah, sorry, my bad I missed out the word dependecies when I said
removing the pam libraries.  However, Jakub's provided a pretty good reason for
keeping them in, so I'd prefer to do that for the time being.

I don't think a pam flag that could turn the dependency off would really be
feasible either, since pam would still be installed with vmware (and since
vmware does rather rely upon it), I have the feeling that it would end up being
too confusing.  Sorry...  5:(

From a PAM team POV, if VMware uses PAM, it will need PAM installed in system.

(In reply to comment #321)

> Well, AFAIK know there's a stance to prefer system libs to bundled ones
> whenever possible, esp. wrt potential security issues. Prevents need to fix
> tons of ebuilds once a vulnerability appears.

Well, that makes sense when you are compiling your own packages, but
vmware-server cannot be compiled from source, it has proprietary binaries.  I
have no idea if the components _require_ the versions of the libraries shipped
with vmware or not, or if they require the libraries that vmware originally
linked them with.

Either way people who don't have pam installed should not be forced to install
it just to use vmware-server when it works perfectly fine with only the bundled
version.

(In reply to comment #322)
> I don't think a pam flag that could turn the dependency off would really be
> feasible either, since pam would still be installed with vmware (and since
> vmware does rather rely upon it), I have the feeling that it would end up being
> too confusing.  Sorry...  5:(
> 

Looks like we had a mid-air collision ;)  It works fine without installing pam
via portage, I am running it that way right now.  How would one go about
figuring out if it even uses the host's pam libraries instead of the bundled
ones anyway?

I will just maintain my own ebuilds in an overlay to avoid the unnecessary pam
dependency if it is this big of a deal...

Mike, I'm afraid I am going to have to keep the dependency in, however since
we're depending on virtual/pam you might find it easier to override this with
an empty ebuild, after which you can continue to get updates to vmware-server
without having to rewrite each ebuild?  Again, I'm sorry about this, but I
similarly require perl rather than relying on the packaged perl-5.005...

(In reply to comment #326)
> Mike, I'm afraid I am going to have to keep the dependency in, however since
> we're depending on virtual/pam you might find it easier to override this with
> an empty ebuild, after which you can continue to get updates to vmware-server
> without having to rewrite each ebuild?  Again, I'm sorry about this, but I
> similarly require perl rather than relying on the packaged perl-5.005...
> 

Messing with pam on a server that was built without it is extremely hazardous
to your health ;)  Installing a fake pam might bring about some nasty surprises
during updates to other packages that might see it installed and assume I have
a real pam installed.  I am probably just being paranoid.

Not to mention the fact that the pam version bundled with vmware-server is
newer than the current stable version in portage.  If vmware relies on features
being available in the later version of pam, I would rather use the bundled
version.  Good luck getting bugs fixed upstream when you are using the older
system-provided pam implementation ;)

Is there a plan in place to get it into portage masked or under ~x86?

Hi Sunil, at the moment, there aren't any immediately plans to get this into
portage, until several other vmware issues have been sorted out first.  You can
find Chris's list of priorities in comment #240.  It sounds as though we have
to get through those before we can finally get this package into portage, but
with a little luck, this'll get sorted by the time Vmware Server goes stable
(but don't quote me on that).

In the meantime, there's been a tiny update in the subversion repository.  The
dhcpd.conf patch has now made it in (sorry it took longer than expected Jeff). 
Also the vmware-player and vmware-workstation ebuilds in there have been
updated to work with the vmware-module ebuild, and have been slightly more
integrated with the vmware.eclass we're developing.  As usual please report any
problems, issues or suggestions here and I'll try and get on top of them... 
5:)

Apologies for not being helpful, but is there an issue with the SVN server?
"tux-162 ccaaruk # layman -a vmware
* Running command "/usr/bin/svn co
http://callisto.cs.kun.nl:81/svn/trees/vmware//
/usr/portage/local/layman/vmware"...
svn: PROPFIND request failed on '/svn/trees/vmware'
svn: PROPFIND of '/svn/trees/vmware': could not connect to server
(http://callisto.cs.kun.nl:81)
* Failed to add overlay "vmware".
* Error was: Adding the overlay failed!"

I've been getting that the last few days now. I'm looking forward to trying
vmware server. Is there anywhere else I can grab all the relevant files?
Thanks

Russell, it could be the proxy if you are behind one. refer:

http://subversion.tigris.org/faq.html#proxy

Check ~/.subversion/proxies and edit appropriate entries.

Ok, I tested your ebuilds from svn. They work pretty smooth here. I see no
problems. I even renamed it to the latest RC1 build and it emerges and works
fine. I am not sure which of the items on the list are pending, but I think
these are ready for tree as hard masked packages. Rest is upto you.

Russell, I agree with the proxy suggestion. The server has been running the
last days. It is currently also running. You could try to use https (on the
standard port) instead of http. Http is on a different port because of the
firewall. The firewall does not block the https port.

Thank you all. There is no proxy running here, its was a simple case of the
"corperate firewall" doing its job. I've manage to retrieve the overlay now
using the https method. Look forward to testing and hopefully providing useful
feedback. Cheers

(In reply to comment #329)

Hi guys,

Just noticed that there's a new release (24927) on the VMware site. Looks like
that is not reflected in SVN yet. Can anyone provide an ETA?

Thanks!

(In reply to comment #329)

Hi guys,

Just noticed that there's a new release of Server (24927) on the VMware site.
Looks like that is not reflected in SVN yet. Can anyone provide an ETA?

Thanks!

The new version is ready to go into subversion however we're still reworking
the system for installing the vmware-modules.  I'm going to ensure that's all
good and working before putting the new version into tree, expect it sometime
between now and next Monday (I'm away on Thursday/Friday/possibly Saturday)...

Hi everybody, very quick update to say I've pushed out the new build (24927)
for both server and server-console.  They're using the new module-build system,
but sadly are having to rely on a handrolled copy of the vmware modules until
the any-any updates catch up (older versions of the modules won't work in the
latest version of vmware-server)...

I won't be able to fix anything up until Saturday evening at the earliest, but
since your old builds are about to expire, I thought I'd try and get something
out for you today.  I've tested it and it built fine here, but as always you
may encounter problems.  If you do, as ever, please report them here and maybe
someone will be able to help you out before I get back...  Lemme know how it
goes!  5:)

FWIW; Re #260 & #261 I just tried emerging vmware-modules-101-r3 and got the
<poll_initwait> error for module.c. There don't seem to be any comments about
this problem since those reports.

My config is:

i686-pc-linux-gnu-3.4.5
linux-2.6.16-gentoo-r7

I suppose I will upgrade to gcc-4.1.1~x86 and try again. It looks like people
have had success with that.

Hello,

I get alway's after a svn up today

Calculating dependencies -/usr/lib/portage/bin/ebuild.sh: line 1562:
/usr/portage/eclass/vmware-mod.eclass: No such file or directory

R. R.

Is there a ebuild for vmware-mui available?

Upgrading worked fine here on ~amd64 and gcc-4.1.1. The dependency caused
vmware-modules to downgrade to 1.0.0.15 (as wanted), but when i ran an "emerge
-avDu world" later portage naturally wanted to upgrade vmware-modules to 101-r3
again. If the latest build of vmware-server doesn't work with them I would
sugest a blockage in the ebuild.

Hmmm, that's what I was affraid of.  Unfortunately portage has been told that
vmware-server relies on exactly that version and *shouldn't* want to update
them unless there's the potential for slotting (which I made sure there
wasn't).  Grrrr...  Alright, I'll give it a look over the weekend at somepoint,
but I've not really got any initial thoughts on how to get around it...  5:(

You're right, portage should not be upgrading vmware-modules. I investigated a
little further and found out the following:
- If vmware-modules is just installed as a dependency of vmware-server it will
not be upgraded.
- If vmware-modules is for some reason in the world-file it will be upgraded.
Now why would vmware-mopdules be in the world file? Easy enough, after a kernel
upgrade I recompiled it with "emerge vmware-modules" without the --oneshot
option and there it went into the world file.

I've added a new ebuild for vmware.modules-101-r3 which blocks
vmware-server-1.0.0-24927 and newer. If you don't have vmware-modules in
/var/lib/portage/world this doesn't affect you in any way. If you do it spews
out a blockage warning.

Created an attachment (id=88731) [details]
new ebuild which blocks vmware-server build 24927

(In reply to comment #342)
> Hmmm, that's what I was affraid of.  Unfortunately portage has been told that
> vmware-server relies on exactly that version and *shouldn't* want to update
> them unless there's the potential for slotting 

No need to waste time on investigation, it's a portage bug (see Bug 48195). Not
much you could do here.

(In reply to comment #343)

> If vmware-modules is just installed as a dependency of vmware-server it will
> not be upgraded.
> If vmware-modules is for some reason in the world-file it will be upgraded.

That's correct.

Ok, very quickly since I'm *really* sleepy.  Thanks Michael and Jakub for
looking into the problem and providing some very handy information.  Michael,
you might be interested in a little script called module-rebuild (which you can
emerge) that'll create and maintain all the kernel dependent modules, and
rebuild them for you when necessary.  As to the rest of the problem, thanks for
the ebuild Michael, I'll add the blocker in as soon as I can, hopefully
sometime tomorrow, but by Monday at worst...  5:)

The ebuild does not appear to work on ~amd64. I think it has something to do
with missing libraries or trying to use the wrong ones. Everything emerges
properly, but when I run vmware-config.pl I get the following:

# ./vmware-config.pl
/usr/bin/ldd: line 167: /lib/ld-linux.so.2: No such file or directory
ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)

The script then continues, until it produces the following errors:
---
Configuring the VMware VmPerl Scripting API.

Building the VMware VmPerl Scripting API.

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

Installing the VMware VmPerl Scripting API.

The installation of the VMware VmPerl Scripting API succeeded.

Generating SSL Server Certificate

Unable to get the last modification timestamp of the destination file
/etc/vmware/ssl/rui.key.
---

Last svn update was 6-11-2006, using the following:

*  app-emulation/vmware-server
      Latest version available: 1.0.0.24927
      Latest version installed: 1.0.0.24927

*  app-emulation/vmware-modules
      Latest version available: 101-r3
      Latest version installed: 1.0.0.15

(oddly, it says latest version installed is 1.0.0.15, but I just emerged
101-r3...in any case, both 1.0.0.15 and 101-r3 have given the same results)

JG, first off please don't install vmware-modules-101.  Portage downgraded you
for a reason, please let it figure out the dependencies required.  The 101
version number was from an earlier experiment with getting vmware-modules to
build properly, and vmware-server won't work with it afterwards.  I'm going to
add in a blocker as soon as possible, but for the time being please downgrade
to 1.0.0.15 (it must be 1.0.0.15 for vmware-server-1.0.0.24927).

As for why the config perl script isn't working on your setup, I can't really
tell from what you've provided.  It appears as though ldd is having issues
locating a particular file it's trying to use, could you please ensure your
glibc installation is working correctly?  Also please attach your "emerge
--info" output so I can verify what version of glibc/gcc you're using...

Also, if anyone else has had either success or failure getting this version to
run on amd64, please let me know...  5:)

Re 348, Mike, I've been quiet for a while because I had your code running
nicely
on this ~amd64 box. Well, I couldn't get sound, printing or network shares to 
work right, but I reckoned I just had to plug away at those.

The other day though I saw there was a new version and used layman to get it.
Emerging the upgrade went smoothly but now I can't connect to the server,
neither as myself nor as root on the local box where the server is running. The
WinXPPro OS is there where it was, but it doesn't appear in the list (the list
is empty). If I browse to it and attempt to open it I'm told I don't have
permission, even if I'm root. I am still in the vmware group, and I've even
added root to that group but to no avail.

I really don't want to have to reinstall Win XP yet again - I've had to ring
Microsoft twice already to get another batch of registrations. Let alone
getting it all back up to date. Have I missed something simple?

$ qpkg -v -I vmware
x11-drivers/xf86-video-vmware-10.12.0.0 *
app-emulation/vmware-server-console-1.0.0.24927 *
app-emulation/vmware-modules-101-r3 *
app-emulation/vmware-server-1.0.0.24927 *


$ emerge --info | grep glibc
Portage 2.1 (default-linux/amd64/2006.0, gcc-3.4.6/amd64-vanilla, glibc-2.4-r3,
2.6.16-gentoo-r8 x86_64)
USE="amd64 X alsa avi bash-completion berkdb bitmap-fonts bzip2 cdr cli crypt
cups dri dvd eds emboss encode foomaticdb fortran gif gpm gstreamer gtk gtk2
imlib ipv6 isdnlog ithreads javascript jpeg kde kdeenablefinal lm_sensors
logitech-mouse logrotate lzw lzw-tiff mp3 mpeg ncurses nls nptl nptlonly nvidia
ogg opengl pam pcre pdflib perl png ppds pppd python qt quicktime readline
reflection sample scanner session spell spl ssl symlink tcpd tiff truetype
truetype-fonts type1-fonts unicode usb userlocales vorbis wmf xml xml2 xorg xpm
xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux
linguas_en_GB userland_GNU video_cards_nv"

Hiya Peter, sorry to hear you've been having such trouble recently.  First off,
don't panic about the XP install, if it was working under the previous version
there's no reason for it not to work under the new version.  The very first
thing I'd like you to do is "emerge =vmware-modules-1.0.0.15".  As I explained
in the previous comment the vmware-modules-101-r1 won't work with the recent
build of vmware-server, which could well cause the server not to want to start.
 So, step by step...

Close all VMs down
/etc/init.d/vmware stop
lsmod (to check all the vm* modules are unloaded)
rmmod vmmon vmnet (if they're not)
emerge -C vmware-modules
emerge =wmware-modules-1.0.0.15
Edit your package.mask file to stop portage wrongly upgrading to 101-r3
/etc/init.d/vmware start
Try starting you vm again

If that doesn't work, post back here and we'll start looking through your file
permissions and the logs to see if we can't narrow down the problem a bit, ok? 
5:)

(In reply to comment #348)
> As for why the config perl script isn't working on your setup, I can't really
> tell from what you've provided.  It appears as though ldd is having issues
> locating a particular file it's trying to use, could you please ensure your
> glibc installation is working correctly?  Also please attach your "emerge
> --info" output so I can verify what version of glibc/gcc you're using...
> 
> Also, if anyone else has had either success or failure getting this version to
> run on amd64, please let me know...  5:)

Yes, the reason possibly is that the file gcc is complaining about does not in
fact exist on amd64 systems :) (unless I am missing a 32bit compatibility
package of some kind, but if so, the vmware ebuild should have it as a
dependency). The equivalent file on an amd64 system is
/lib/ld-linux-x86-64.so.2. This appears to be at least partially compatible,
because if I symlink the file its looking for (/lib/ld-linux.so.2) to
ld-linux-x86-64.so.2, I get the following output:

-----
# ./vmware-config.pl 
Making sure services for VMware Server are stopped.

 * WARNING:  vmware has not yet been started.

Configuring fallback GTK+ 2.4 libraries.

You have already setup networking.

Would you like to skip networking setup and keep your old settings as they are?
[snip]
Using compiler "/usr/bin/gcc". Use environment variable CC to override.

Installing the VMware VmPerl Scripting API.

The installation of the VMware VmPerl Scripting API succeeded.

Generating SSL Server Certificate

Unable to get the last modification timestamp of the destination file 
/etc/vmware/ssl/rui.key.

Execution aborted.
-----

Note the first error complaining about ld-linux.so.2 has gone away (I have no
idea if this is a "proper" fix, and it seems like a hack, it was just a shot in
the dark), but it still fails to get the lastmod time on the certificate. I am
sure that this is stemming from the same issue, in that its trying to use a
32bit perl library. I did some digging around on the vmware forums and saw
discussion of 32bit perl library binaries, maybe this has something to do with
it.

Interestingly, if I follow the gentoo guide for setting up a 32bit chroot, I
dont get any of these errors (but I do get a lot of other errors when it tries
to mess with my mount points and network interfaces, which is to be expected in
a chroot, but that seems to suggest its something different about 64 bit
binaries).

Again, Im certain it wasnt the incorrect modules version as Ive tried both.
Using the old version is likely to create problems, but this isnt one of them.
In any case, I have emerged the correct version now and verified that the
problem persists:

*  app-emulation/vmware-server
      Latest version available: 1.0.0.24927
      Latest version installed: 1.0.0.24927

*  app-emulation/vmware-modules
      Latest version available: 1.0.0.15
      Latest version installed: 1.0.0.15

I also dont think its GCC, as I have just done multiple emerge -e world without
problems.

Basically I get the impression that there are 2 possibilities; either the
package has to be modified for amd64 systems to use the correct path, or I am
missing some kind of 32bit compatibility libraries (if so, which ones, and they
should be added as dependencies). I do have
app-emulation/emul-linux-x86-baselibs, app-emulation/emul-linux-x86-compat, and 
app-emulation/emul-linux-x86-xlibs installed FWIW.

As requested, here is my emerge --info (I have omitted my USE flags, let me
know if you want them too):

---
# emerge --info       
Portage 2.1 (hardened/amd64, gcc-3.4.6/hardened, glibc-2.3.6-r4,
2.6.16-hardened-r7 x86_64)
=================================================================
System uname: 2.6.16-hardened-r7 x86_64 Dual Core AMD Opteron(tm) Processor 285
Gentoo Base System version 1.12.1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.16
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -msse3 -O3 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf
/etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-march=athlon64 -msse3 -O3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
---

Ok, I've done that, and I'm now back to where I was two days ago and with the
same problem: the VM is there, but it doesn't show up in the list of VMs to
connect to and when I specify it I'm not allowed to connect to it. Only
yesterday did portage upgrade me to 101-r3; that isn't what broke my setup. (I
let it do that because I was unsure from earlier comments precisely which
versions were wrong; I thought the most recent version might have been
corrected but maybe it hasn't.)

# qpkg -v -I vmware
x11-drivers/xf86-video-vmware-10.12.0.0 *
app-emulation/vmware-server-console-1.0.0.24927 *
app-emulation/vmware-server-1.0.0.24927 *
app-emulation/vmware-modules-1.0.0.15 *

emerge -C didn't remove /lib/modules/2.6.16-gentoo-r9/misc/vm???.ko so I
removed them by hand before emerging modules-1.0.0.15.

One thing: I noticed I was getting the not-configured error again when stopping
vmware-server, so I reran /opt/vmware/server/bin/vmware-config.pl and told it
to reset the file permissions. Now when I look over the VMs directory I see
root:root on the files and directories; is that right? (I haven't been
exhaustive about this.)

I'm tempted to uninstall the whole of vmware-server, pruning out all the files
that get left over, then install afresh; will I then be forced to reinstall the
Win VM?

I ran revdep-rebuild, but it only found the usual openoffice-bin breakages and
remerged that package.

Incidentally, I haven't seen the problem reported by JG; I have the following
32-bit libraries installed: emul-linux-x86-compat-1.0-r1, baselibs-2.5,
xlibs-7.0-r1, qtlibs-3.4.4 and gtklibs-2.8.8.

JG, I'm afraid I'm still uncertain what's causing your problem.  I realise it
isn't the version of the modules, but I wanted to clear it up for everyone
which version should be used.  Setting the dynamic loader library to be the
correct one with a symlink is a dirty hack and I wouldn't recommend it!  Leave
it there until we sort out the other problem, then once it's all fixed and
usable, we can go back and see if we can find a more elegant soltuion.

Right, as to what seems to be going wrong, it appears that it's trying to run
openssl to create you some certificates, but that the process fails, and hence
the files are written, and it then can't add them to the database.  Can you
please verify you've got openssl installed?


Peter, don't give up on it just yet!  5:)  You should have the following
permissions set:  

root:vmware on everything under /etc/vmware
<user>:<usergroup> on the VM directory and everything under it

What this means is that whilst root owns the folder that contains the virtual
machine folder, each virtual machine must be owned by a user (in the vmware
group) with writable access and with permission to traverse the directories up
to that point.

Also, please attach the /var/log/vmware/vmware-serverd.log file from your last
attempt to log in.  That might shed some light on what's going wrong...  5:)

(In reply to comment #353)
> Setting the dynamic loader library to be the
> correct one with a symlink is a dirty hack and I wouldn't recommend it!  Leave
> it there until we sort out the other problem, then once it's all fixed and
> usable, we can go back and see if we can find a more elegant soltuion.

Dirty hack indeed :) It does not work anyway, it just delays the failure
slightly.

> Right, as to what seems to be going wrong, it appears that it's trying to run
> openssl to create you some certificates, but that the process fails, and hence
> the files are written, and it then can't add them to the database.  Can you
> please verify you've got openssl installed?

Openssl is installed and works fine. It is actually not failing on the Openssl,
I dug around the perl script briefly and inserted a few debugging flags and it
fails before the actual certification generation, while it is still doing
filesystem i/o. I believe the failure is during the stat() call, presumably due
to using an incorrect perl library (such as a 32bit one). I noticed that vmware
has included some binary libraries in their tarball, when I get a chance I'll
see if I can get it to use those perhaps. I dug around the vmware forums and
saw mention of them including 32bit modules, so maybe its just a matter of
installing those correctly.

For peace of mind though, here is my OpenSSL version:

*  dev-libs/openssl
      Latest version available: 0.9.7j
      Latest version installed: 0.9.7j

btw, why are you worried about XP install anyway? you should tar up all the VM
files and keep them locked and backed up somewhere. Those would work anywhere,
and with most newer vmware products. Your VMs are not the problem.

Created an attachment (id=89256) [details]
emerge --info on 15 Jun 2006

Having set root:portage ownership of /srv/VMs (my container for the virtual
machines) and prh:portage on everything under it, I tried connecting to the VM
as me (prh) and was refused permission again. This is the text of the error:

-- 
Unable to add virtual machine "/srv/VMs/WinXPPro/WinXPPro.vmx" to the
inventory: No permission to perform this operation
-- 

(Once again I'd had to browse to find the VM.)

The relevant section of the log is:

-- 
Jun 15 17:31:32: app| New connection on socket server-vmdb from host localhost
(ip address: 127.0.0.1) , user: prh
Jun 15 17:31:32: app| SP: New user session for user: prh, pos: 0
Jun 15 17:31:32: app| The vm-list file has changed! Reloading the list of
registered vms
Jun 15 17:31:37: app| SP: Retrieved username: prh
Jun 15 17:31:38: app| SP: Retrieved username: prh
Jun 15 17:31:40: app| SP: Rejecting command base on path: : 0
Jun 15 17:31:45: app| vmdbPipe_Streams Couldn't read: OVL_STATUS_EOF
Jun 15 17:31:45: app| SP: Deleting user session: 0 username: prh
-- 

I don't know why the vm-list file is supposed to have changed:

-- 
$ ls -l /etc/vmware
total 456
-rw-rw-r-- 1 root vmware    613 2006-06-15 09:44 config
drwxr-xr-x 9 root vmware   4096 2006-06-13 23:02 init.d
-rwxr-xr-x 1 root vmware  16606 2006-06-13 23:02 installer.sh
-rw-r--r-- 1 root vmware    425 2006-05-23 17:02 license.vs.1.0-80
-rw-r--r-- 1 root vmware 393892 2006-06-15 09:44 locations
-rw-r--r-- 1 root vmware     86 2006-05-23 17:03 netmap.conf
drwxr-xr-x 2 root vmware   4096 2006-05-23 16:59 pam.d
-rw-r--r-- 1 root vmware    182 2006-06-13 23:02 signing-key.pub
drwxr-xr-x 2 root vmware   4096 2006-05-23 17:00 ssl
-rw-r--r-- 1 root vmware    127 2006-05-23 17:05 vm-list
-rw-r--r-- 1 root vmware    132 2006-05-23 17:05 vm-list-private
drwxr-xr-x 3 root vmware   4096 2006-05-23 17:00 vmnet1
-rw-r--r-- 1 root vmware      7 2006-06-13 23:02 vmwaregroup
-- 

(BtW, I don't know how I've given the impression of cluelessness, but I don't
think it's accurate really. I'm not a coder these days - not since about 1991
in fact - but I can find my way around the file system. No offence.)

These are my current versions:
-- 
$ qpkg -v -I vmware
x11-drivers/xf86-video-vmware-10.12.0.0 *
app-emulation/vmware-server-console-1.0.0.24927 *
app-emulation/vmware-server-1.0.0.24927 *
app-emulation/vmware-modules-1.0.0.15 *
-- 

I've attached my emerge --info.

Peter, I'm sorry you're feeling as though you come across as clueless, it
wasn't my intention to make you feel that way, and I've never thought of you as
such.  It's difficult when there are so many people asking for requests to
determine what level of knowledge everybody's working at, so in general I try
to ensure that I've explained what I'm trying to do, and possibly repeat in
terms easier to understand so that everyone can follow along (so that I can
refer anyone to a previous comment).  I'm sorry if this came across as
condescending, I try very hard not to, sorry.  As I recall you've been
providing contributions to this bug from very early on, and I'm very greatful
for your help in testing the ebuild out!  5:)

As to your problem, when you request to add some files as a virtual machine to
vmware-server, it keeps a record of the vm in a file called vm-list.  Since in
your directory listing the vmware group does not have write access, it's giving
you a permission denied error.  I'd try adding write acces for the group to
both vm-list and vm-list-private.  I'm not certain how those permissions got
set, I've taken a look through the ebuild and eclass but haven't found an area
where it might reset those permissions, so I'm a bit baffled, but hopefully
that'll fix you problem.  As always, gimme a shout if it doesn't...  5:)

No problem, Mike - as I said, no offence, neither taken nor I hope given.
Thanks for your kind words, and of course for your hard work.

I've set root:portage on /etc/vmware and its contents but that made no
difference. I also discovered that I was out of step with kernel versions (I
was running 2.6.16-r8 and the modules had been compiled for 2.6.16-r9, so of
course I compiled and installed the -r9 kernel, then recompiled the vm modules
to be sure, but I'm no better off.

I've been browsing this nice, long bug for authd notes, thinking there may be a
connection, but I came to no conclusion. I have no only_from in
/etc/xinetd.d/vmware-auth. Which package installs this file, by the way? equery
and qpkg both return a null result, i.e. qpkg -f /etc/xinetd.d/vmware-authd
returns nothing.

I get these two entries in /var/log/messages when I attempt to connect:

-- 
Jun 16 19:25:07 wstn xinetd[9883]: START: vmware-authd pid=14022 from=127.0.0.1
Jun 16 19:25:07 wstn xinetd[9883]: EXIT: vmware-authd status=0 pid=14022
duration=0(sec)
-- 

That all seems fine to me.

What else can I try? I don't want to ditch the whole shebang and reinstall as
long as you think it useful to persevere, Mike. It may come to that though.

...oh, and I meant to say that I'd already shown that the vm-list has not been
changed for three weeks or so, so that was a bit of a red herring.

Well, this might have something to do with it:

[pid 23131] execve("/opt/vmware/server/lib/bin/openssl",
["/opt/vmware/server/lib/bin/opens"..., "req", "-new", "-x509", "-keyout",
"/etc/vmware/ssl/rui.key", "-out", "/etc/vmware/ssl/rui.crt", "-config",
"/tmp/vmware-ssl-config4/certific"..., "-days", "5000"], [/* 28 vars */]) = -1
ELIBBAD (Accessing a corrupted shared library)

Apparently it doesn't use the existing openssl library, it ignores it and uses
its own 32bit library? Which doesnt seem like a logical way to do things,
unless Im missing something. So I ran that manually with the proper binary:

 # /usr/bin/openssl req -new -x509 -keyout /etc/vmware/ssl/rui.key -out
/etc/vmware/ssl/rui.crt -config /tmp/vmware-ssl-config0/certificate.cnf -days
5000
Generating a 1024 bit RSA private key
.............................................++++++
...++++++
writing new private key to '/etc/vmware/ssl/rui.key'
-----

Reran the script with this and the previous mentioned dirty hack (linking
ld-linux.so.2) and the script continues normally without errors until it
reaches:

The path "/opt/vmware/server/images" does not exist currently. This program is
going to create it, including needed parent directories. Is this what you want?
[yes]

sh: /opt/vmware/server/lib/bin/vmware-vmx: Accessing a corrupted shared library
Please enter your 20-character serial number.

Type XXXXX-XXXXX-XXXXX-XXXXX or 'Enter' to cancel:

So, I enter my serial and:

sh: /opt/vmware/server/lib/bin/vmware-vmx: Accessing a corrupted shared library
The serial number [removed] is invalid.

Please enter your 20-character serial number.

And it keeps asking me for it and giving me the vmware-vmx is a corrupt shared
library error and not accepting it.

How did others using amd64 get around these issues?

Ok, after several more dirty hacks I got past vmware-config.pl, but now
starting vmware fails with:

# vmware
/opt/vmware/server/lib/lib/wrapper-gtk24.sh: line 136:
/opt/vmware/server/lib/bin/vmware: Accessing a corrupted shared library

I'm afraid we're well out of my area of expertise...

The best I can guess is that something's not working quite correctly with your
emulation library setup, because it seems to be failing on each use of a 32-bit
library.  Since I don't really know much about how these work, all I can
recommend is perhaps attempting a revdep-rebuild and maybe reinstalling the
various emulation libraries.  Can anyone with a bit more amd64 32-bit emulation
experience jump in and help out?

Hi,

I'm not expert on 32 bit libraries on 64 bit systems either, but I wanted to
comment on two things. Firstly, I'm running Gentoo 2006.0 on AMD64 and the
upgrade to VMWare Server 1.0.0.24927 Just Worked for me, including the
downgrade to mware-modules-1.0.0.15; secondly I believe the "32 bit on 64 bit"
support is provided by the app-emulation/emul-linux-x86- * packages.

The problem seems to be that it isnt using my installed libraries anyway. That
wrapper script basically loads all of the libraries in the vmware package lib
folder, instead of using an existing local version. If it had a flag or
something that caused it to use the installed libraries there would be a lot
less problems. What I dont understand is how other amd64 users got it to work.

JG, I'm afraid it's more likely to be a failing with your existing installation
of something, than it is that your setup is fine and vmware-server doesn't work
on amd64, simply because we've had so many other people say theirs is working
fine.  As far as I was aware, vmware-server is all 32-bit, so it's either going
to use it's own 32-bit libraries, or it's going to use the 32-bit emulation
libraries that are a dependency of vmware-server.

It shouldn't matter which it chooses, because your system should automatically
figure out how to fulfill all the 32-bit dependencies of both your packages and
the pre-provided ones from vmware.  I think the fact that your system is
attempting to locate the dynamic loading library from it's 32-bit location and
failing is indicative that you have larger problems with your 32-bit setup.

I hate to sound repetitive, but from everything I've read it really, really
sounds as though you don't have your 32-bit emulation libraries installed
correctly.  Please double check that for me, so that I can definitely rule it
out as your problem.  One way to check that is to install adobe acrobat reader,
since that's also a binary 32-bit package that depends upon the emulation
libaries.  If that runs then you can run 32-bit programs, if it doesn't then
your setup has issues.

To test vmware-server again, once the symlink is gone, please re-emerge
app-emulation/emul-linux-x86-baselibs and ensure it installs without errors. 
See whether it runs, if it doesn't it may still be a permissions problem, but
you're probably better off asking for support directly at the #gentoo-amd64 IRC
channel on the freenode.net servers.

If you'd like to know where I've been reading about this, please look at:

http://www.vmware.com/community/thread.jspa?threadID=32130#350074
http://www.splunk.com/base/forum:SplunkGeneral/144/479#post

I hope this helps, but please realise it's a very difficult problem to remotely
diagnose...

Hi all,

we have moved the vmware repository to gentoo infrastructure. The new URL is:
http://overlays.gentoo.org/svn/proj/vmware/trunk

The overlay on my machine will remain available (read-only) for some while, but
not further updated.

I am starting to wonder if my "hardened" profile is causing the issue. We have
several users on amd64, but has anyone had this work with amd64 and hardened?

OK.  I'm sure someone will want to string me up for this, but I'm changing this
bug to be more of a tracker bug for the overlay.  The individual bugs that this
one depends on are the bugs for each package in the overlay.  If you're having
an issue, please try to put them in the proper location.  This will help us
track everything a bit easier, reduce the noise, and help us get this all into
the tree that much faster.

We're already on our way to getting everything done for tree inclusion, so we
should definitely have all of this moved by the time VMware Server comes out of
beta.  I'd like to thank Mike for all of his hard work in writing the
vmware-mods.eclass, vmware-modules ebuilds, and vmware-server ebuilds.  Without
him, this would have taken me just shy of forever to get done.  ;]

Re #368, I'm running two amd64 vmware server, one is running
gentoo-source-2.6.16-r9 (with vmware 24927) the other one is running
hardened-source-2.6.14-r8 (with vmware 23869-r1), for the second one, the
upgrade to 24927 is not possible as it refuses to compile vmware-modules, and
appart from the CPUs (242 on 1st and 280 on second), the computers are the
same, and use the same hardened profiles.

Bertrand, thanks for your reply.  Once I'm back on Saturday, I'll start looking
into why the modules fail to compile on 2.6.14, I may ask you to post the error
messages from that, but as Chris said, we've now split this bug up, so (and I'm
sorry this is going to require a little bit of work from everybody) could you
all please ensure that you're CCed on at least bugs 137422, 137424 and 137425?

So just to give everybody an idea of how this is supposed to work, Bertrand if
you could post your error messages when build the modules under 2.6.14 on bug
137422, and JG if you could post whether your emul-linux-x86-baselibs are
installed correctly under bug 137424, that'd be fantastic!  Thanks everybody
for your patience during this transition, it will really help us keep better
track of what's going on...

Also, just so everybody's aware, if you're using the old overlay
(http://callisto...) or the overlay from layman, you will need up update to the
new overlay (hosted on the shiny new overlays.gentoo.org).  I'll provide a few
further details on how to make the move for those that don't know, and I'll get
wrobel to update layman and provide instructions for doing the update there
too, but unfortunately not until I'm back on Saturday.

Please don't file any further replies on this bug unless it *directly* relates
to the vmware overlay, and not any of the underlying packages.  Thanks...  5:)

(In reply to comment #371)

> Also, just so everybody's aware, if you're using the old overlay
> (http://callisto...) or the overlay from layman, you will need up update to the
> new overlay (hosted on the shiny new overlays.gentoo.org).  I'll provide a few
> further details on how to make the move for those that don't know, and I'll get
> wrobel to update layman and provide instructions for doing the update there
> too, but unfortunately not until I'm back on Saturday.

Well, layman has already been updated.  I'm not sure when it happened, but it
works fine here.

I took care of updating layman when the new repository was running properly.

Ok, sorry, my mistake, I probably should have checked.  Hopefully now
everybody's synchronizing from the right overlay, and you should all be
beginning to reap the benefits of the new module system.  As always, let me
know (on the relevant bugs) if you get any problems...  5:)

Well, I seem to be doing something wrong again. Layman stops with an error:

-- 
# layman -f
# layman -a vmware
* Running command "/usr/bin/svn co
http://overlays.gentoo.org/svn/proj/vmware/trunk/
/usr/portage/local/layman/vmware"...
svn: PROPFIND request failed on '/svn/proj/vmware/trunk'
svn: PROPFIND of '/svn/proj/vmware/trunk': 400 Bad Request
(http://overlays.gentoo.org)
-- 

Links and Firefox can see the directory at
http://overlays.gentoo.org/svn/proj/vmware/trunk/

A week ago I committed the worst command-line sin a Linux sysadmin can be
guilty of and zapped half my system. So now I'm installing afresh and trying to
get the vmware overlays to install. I haven't changed anything on the
firewall/gateway box, and I've checked that my http_proxy is set right, so now
I'm stuck again. 

-- 
# env | grep proxy
http_proxy=http://192.168.129.1:3128/
ftp_proxy=http://192.168.129.1:3128/
-- 

Maybe I should take it as a sign of cluelessness after all, not just the result
of a string of late nights...

Mike, I'm sorry I can't continue with the earlier system as I said I would. Mea
culpa.

Hi Peter, not to worry, I'm just sorry to hear your system got zapped. 
Subversion doesn't make use of the standard http_proxy environment variables. 
If you want to use subversion through a proxy, you'll have to su to the user
you want to use subversion with, go to their ~/.subversion directory and edit
the servers file there.  Follow the configuration examples given in the
comments, and under [global] add an http-proxy-host and a http-proxy-port line,
and you should be good to go again.  Hope that helps!

Thanks for the tip, Mike. I found I also had to declare extension_methods to my
squid proxy. I'm certain I haven't had to do these things before, but there you
are. All is running nicely now.

today i tried the gentoo-sources-2.6.17 with vmware but wenn starting the
services i got this and the entire machin halts:

Jun 25 18:13:51 bigmichi1 vmmon: no version for "struct_module" found: kernel
tainted.
Jun 25 18:13:51 bigmichi1 vmmon: no version magic, tainting kernel.
Jun 25 18:13:51 bigmichi1 vmmon: module license 'unspecified' taints kernel.
Jun 25 18:13:51 bigmichi1 BUG: unable to handle kernel NULL pointer dereference
at virtual address 00000004
Jun 25 18:13:51 bigmichi1 printing eip:
Jun 25 18:13:51 bigmichi1 c01380a7
Jun 25 18:13:51 bigmichi1 *pde = 00000000
Jun 25 18:13:51 bigmichi1 Oops: 0000 [#1]
Jun 25 18:13:51 bigmichi1 SMP
Jun 25 18:13:51 bigmichi1 Modules linked in: via686a i2c_isa i2c_core
Jun 25 18:13:51 bigmichi1 CPU:    0
Jun 25 18:13:51 bigmichi1 EIP:    0060:[<c01380a7>]    Tainted: PF     VLI
Jun 25 18:13:51 bigmichi1 EFLAGS: 00010246   (2.6.17-gentoo-2006.0 #1)
Jun 25 18:13:51 bigmichi1 EIP is at sys_init_module+0x1127/0x19c0
Jun 25 18:13:51 bigmichi1 eax: 00000000   ebx: 00000000   ecx: c193bfa0   edx:
c193bfa4
Jun 25 18:13:51 bigmichi1 esi: 00000000   edi: 00000018   ebp: f92cdbe0   esp:
c193bed8
Jun 25 18:13:51 bigmichi1 ds: 007b   es: 007b   ss: 0068
Jun 25 18:13:51 bigmichi1 Process modprobe (pid: 5231, threadinfo=c193b000
task=f7c845c0)
Jun 25 18:13:51 bigmichi1 Stack: 00000001 f92cdbe0 c0417721 f7497f28 0000c94a
00000073 f92cdbec f92cdbe0
Jun 25 18:13:51 bigmichi1 00000000 00000000 00000000 00000000 00000007 00000000
00000000 00000009
Jun 25 18:13:51 bigmichi1 00000000 00000000 00000016 f8866f74 f7b17220 b7f4a8f0
f8862d94 f8862ca4
Jun 25 18:13:51 bigmichi1 Call Trace:
Jun 25 18:13:51 bigmichi1 <c015b600> __kmalloc+0x0/0x80  <c0115957>
do_page_fault+0x3b7/0x66e
Jun 25 18:13:51 bigmichi1 <c015f41c> vfs_read+0xbc/0x180  <c0102dc3>
sysenter_past_esp+0x54/0x75
Jun 25 18:13:51 bigmichi1 Code: 8b 8b ac 00 00 00 85 c9 74 42 31 f6 8b 6c 24 1c
8d 1c f5 00 00 00 00 8d 8c 24 c8 00 00 00 8d 94 24 cc 00 00 00 8b 85 a8 00 00
00 <8b> 44 18 04 c7 04 24 01 00 00 00 e8 89 de ff ff 85 c0 0f 85 04
Jun 25 18:13:51 bigmichi1 EIP: [<c01380a7>] sys_init_module+0x1127/0x19c0
SS:ESP 0068:c193bed8
Jun 25 18:13:51 bigmichi1 vmware-start: Virtual machine monitor       failed

Hi Michael, I'm afraid I'm going to need a bit more information from you to
help identify what might be causing the problem.

First off, please let me know what package you're trying to get going, is it
vmware-server, vmware-workstation, vmware-player or something else?  Once we've
figured out what package you're trying to get working, we'll move the report
over to the correct bug (probably bug 137422). 

Secondly, could you please let us know what version of the package you're
installing, so, for vmware-server, that'd be something like
vmware-server-1.0.0.24927-r1.

Finally, just to give us some basic information about your set-up please post
the output from 'emerge --info'.

Off the top of my head, I have no idea what's causing your kernel panic.  I've
successfully run vmware-server, with the latest modules on the 2.6.17 kernel...

ok here are the infos:

installed versions:

* app-emulation/vmware-modules [2]
     Available versions:  1.0.0.14 1.0.0.15 101-r3
     Installed:           1.0.0.15
     Homepage:
     Description:
* app-emulation/vmware-server [2]
     Available versions:  1.0.0.23869-r2 1.0.0.24927
     Installed:           1.0.0.24927
     Homepage:            http://www.vmware.com/
     Description:         VMware Server for Linux


bigmichi1 ~ # emerge --info
Portage 2.1.1_pre1-r2 (default-linux/x86/2006.0, gcc-4.1.1/vanilla,
glibc-2.4-r3, 2.6.16-gentoo-r10-2006.0 i686)
=================================================================
System uname: 2.6.16-gentoo-r10-2006.0 i686 Pentium III (Coppermine)
Gentoo Base System version 1.12.1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.59d
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/gcc-config: [Not Present]
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.16
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3 -fforce-addr -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf
/etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=pentium3 -fforce-addr -fomit-frame-pointer -pipe"
DISTDIR="/usr/local/portage/distfiles"
FEATURES="autoconfig collision-protect distlocks metadata-transfer
parallel-fetch sandbox sfperms strict test userpriv usersandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="C"
LC_ALL="C"
LDFLAGS="-Wl,-O1 -Wl,--sort-common"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/vmware"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X alsa apache2 apm authfile avi berkdb bitmap-fonts bzip2 cairo cli
crypt ctype cups curl curlwrappers dri eds emboss encode esd fontconfig
foomaticdb fortran ftp gcj gd gdbm gif glitz gmp gpm gstreamer gtk gtk2 hash
iconv imap imlib inifile ipv6 isdnlog java jpeg ldap libg++ libwww mad memlimit
mikmod mmx motif mp3 mpeg mpm-prefork mysql mysqli ncurses nfs nls no-old-linux
nptl nptlonly ogg opengl oss pam pcre pdflib pear perl php png ppds pppd python
qt quicktime readline reflection samba sasl sdl session simplexml soap sockets
softquota spell spl sse ssl swat symlink tcpd test truetype truetype-fonts
type1-fonts udev unicode vorbis xinetd xml xml2 xmlrpc xmms xorg xpm xsl xv
zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux
userland_GNU video_cards_r128"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LINGUAS,
PORTAGE_RSYNC_EXTRA_OPTS

Thanks Michael, since your problem seems to be concerning the vmware-modules,
please see the further comments on bug 137422.  I'll post all my further
comments concerning your situation there...  5:)

Also, whilst I remember, Bertrand, if you'd like to make your way to bug
137422, and post your compilation errors with the hardened-2.6.14 kernel and
the version of vmware-modules you're compiling against, I'll take a look and
we'll see if we can figure out what's going wrong.  Thanks...  5:)

Re #382, It did compile this morning with not a single problem ... the only
thing that was changed, is the version of ncurses (5.4-r6 to 5.5-r2)

Bizarre, still, I'm glad it's all working for you now...  5:)

I have a slight problem with the -27828 build of VMware Server.  The problem is
with PAM and vmware-authd -- I've had to add the /emul/linux/x86/lib/security
path to the pam module names in order to make it work.  Now I can log on, but I
get the following error:

Jun 28 01:30:44 enterprise xinetd[12657]: START: vmware-authd pid=18702
from=172.22.11.156
Jun 28 01:30:44 enterprise vmware-authd[18702]: PAM unable to
dlopen(/lib/security/pam_deny.so)
Jun 28 01:30:44 enterprise vmware-authd[18702]: PAM [error:
/lib/security/pam_deny.so: cannot open shared object file: No such file or
directory]
Jun 28 01:30:44 enterprise vmware-authd[18702]: PAM adding faulty module:
/lib/security/pam_deny.so
Jun 28 01:30:44 enterprise vmware-authd[18702]: login from 172.22.11.156 as
root
Jun 28 01:30:46 enterprise xinetd[12657]: EXIT: vmware-authd status=0 pid=18702
duration=2(sec)

I read someplace that there's an "implicit pam_deny" at the end of each
section, which is probably causing the message.  Whatever's causing it, I just
can't work out how to get rid of the message.  My /etc/pam.d/vmware-authd looks
like this now:

#%PAM-1.0
auth       sufficient       /emul/linux/x86/lib/security/pam_unix.so shadow
nullok
auth       required         /emul/linux/x86/lib/security/pam_unix_auth.so
shadow nullok
auth       required         /emul/linux/x86/lib/security/pam_deny.so
account    required         /emul/linux/x86/lib/security/pam_listfile.so
item=group sense=allow file=/etc/vmware/vmwaregroup onerr=fail
account    sufficient       /emul/linux/x86/lib/security/pam_unix.so
account    required         /emul/linux/x86/lib/security/pam_unix_acct.so
account    required         /emul/linux/x86/lib/security/pam_permit.so
password   required         /emul/linux/x86/lib/security/pam_permit.so
session    required         /emul/linux/x86/lib/security/pam_permit.so

I added the pam_deny.so to the end of auth, the pam_permit at the end of
account, and the password and session sections with a pam_permit (since they
were not there before anyway, a permit shouldn't hurt) to try and get rid of
the message.  I also tried changing "required" to "sufficient" on the
pam_permit lines to see if that made any difference, to no avail.  I think I'm
going to have to live with it, unless anyone else has an idea on it...

Sorry everyone, I should have mentioned that this is on amd64!  (I originally
had a much more thorough append prepared, complete with emerge --info, because
I couldn't get it to work at all -- but then I was able to log on successfully
so I trashed that one.)

Don't know whether this belongs here or in 137425, but since upgrading to 27828
I cannot log in to the console: I get wrong-password errors. My
/etc/xinetd.conf looks like this:

defaults
{
        log_type        = SYSLOG daemon info
        log_on_failure  = HOST
        log_on_success  = PID HOST DURATION EXIT
        only_from       = 192.168.0.0/16
        cps             = 50 10
        instances       = 50
        per_source      = 10
        v6only          = no
        groups          = yes
        umask           = 002
}
includedir /etc/xinetd.d

I changed the only_from line to allow logon from my laptop as well as on the
host that runs the vmware server. I don't think this is my problem though, as
changing it back and restarting xinetd doesn't change anything.

I have rerun the config.pl scripts, of course. Even rebooted the machine.

Vic, you bug report belongs on bug 137424, I'll answer you there.

Peter, you're absolutely right, your bug does now belong on 137425.  I'll be
answering you there.

Please guys, this bug is no longer the place to send general comments, it is
specifically for bugs relating to the overlay itself (which are rare, so you
should probably ALWAYS be filing in one of the other bugs).  All reports
relating to a single vmware product, should go in the relevant product's bug
numbers.  Here's a list for the lazy just to make it clear what goes where:

137422 - vmware-module problems
137423 - vmware-player problems
137424 - vmware-server problems
137425 - vmware-server-console problems
137426 - vmware-workstation problems
137428 - vmware-workstation-tools problems

This bug is now 387 comments long with problem fixes for at least 3 different
ebuilds in here and it's getting unmanagable.  We've split it up, which means
it'll be easier for you guys to find solutions to problems you might be having,
but it won't work unless you start posting in the right places.  Help me help
you, and please try to file your comments in the right location, thanks...  5:)

I updated my recipe that explains the new layman-based installation process.

http://diaryproducts.net/about/operating_systems/unix/installing_vmware_server_on_gentoo_linux_part_3

Thank you for the ebuilds and keep up the good work!

!!! Digest verification failed:
!!! /usr/portage/distfiles/VMware-server-1.0.0-28343.tar.gz
!!! Reason: Failed on MD5 verification
!!! Got: 221469ca1e4bd5ac0a1a5fca114b1cd5
!!! Expected: a25b4beb53785c05ef3b3077d87f6e2b

after modifying the hash value with 'ebuild xxx digest'

it is stated:
>>> Unpacking VMware-server-1.0.0-28343.tar.gz to /var/tmp/portage/vmware-modules-1.0.0.15/work

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.

Ok, firstly for everyone still watching this bug,
Vmware-server{-console}-1.0.0.28343 has been released.  This is the final
version 1.0.0 of Vmware and is in the overlay now.

Use, in answer to your question, yes, the reason that you were told the file
you had didn't match what was expected, and the reason it then broke, is
because you didn't have what was expected, and it was broken.  Please try
removing the file from /usr/portage/distfiles and re-download it.  The MD5sum
of the digest matches the MD5sum on the vmware site, and not the one you
created the digest for.  Should you have any further problems, please report
them in bug 137424 rather than on this bug.  This bug is only for bugs relating
to the overlay as a whole...

Mike, I have used this pretty sussessfully on my machine. But I have this issue
which I failed to report earlier. Some times '/etc/init.d/vmware stop' just
doesn't stop anything, it just comes out saying that vmware is not running,
although it is running. If I run the script which '/etc/init.d/vmware stop'
calls directly, that does stop the vmware services correctly. Moreover, it
doesn't happen during shutdown, it happens only doing it manually. I am not
sure why /sbin/runscript determines that it doesn't need to call the stop
function of the script. Is there a PID in /var/run that its looking for and is
not present?

Hi Sunil, thanks for your question, but again this is more directly relevant to
just vmware-server, rather than the overlay as a whole, so I'm going to post my
answer on bug 137424.  I hate to keep doing this, but we really are trying to
get everybody using the new more specific bugs, rather than continue this bug
which is now nearly 400 comments long.

Please everybody, do try and use the dependent bugs for your problems first...

would it be possible to tie the dependencies to the X-libs to an X USEflag. I
don't use X on my server, and it would be nice to do USE="-X" emerge
vmware-server

EVERYBODY

This bug is for the OVERLAY as a WHOLE and that's it.

Bugs for SERVER go in bug #127424.

Bugs for CONSOLE go in bug #137425.

Bugs for MODULES go in bug #137422.

Anything else pretty much should ALSO go in ONE OF THOSE BUGS

Please, come on, I've taken the time to explain this four times already.  At
least have the courtesy to read the previous few comments before posting, even
just the previous one.  Nameless, see the answer to your question in bug
137424.

Sigh.  It would've helped had I not made a typo.

Bugs for SERVER go in bug 137424 (not in bug 127424).

Sorry if you've already heard this, but it seems there's still a fair number of
people who are subscribed to this bug rather than 137424, so I thought I'd let
them know too...

Well, not two minutes ago I finally unmasked the ~x86 and ~amd64 versions of
vmware-server and vmware-server-console in the main portage tree!  Hurray!  5:)
 It should be ready and distributed to all the rsync servers in about an hour
or two, after which it's all yours for the using...

So now it's your job to go out there and use it, and hopefully file not too
many bug reports against it.  Enjoy!  5:)

(In reply to comment #397)

> Well, not two minutes ago I finally unmasked the ~x86 and ~amd64 versions of
> vmware-server and vmware-server-console in the main portage tree!  Hurray!  5:)

Does this mean, that the overlay is obsolete now?

Well, there's no longer a need to use the overlay unless you want *definitely*
broken stuff!  5:)

It's basically going to become my pre-tree testbed, where I'll put stuff to
test myself before it goes into the full tree.  I think Chris is going to take
out the stable ebuilds from here (so that there's less confusion going on) and
eventually I'll do the same, but if there's ever a new version of something, or
we're working on a major refactoring of the ebuild mechanism, it'll probably go
on in the overlay.  Hope that helps answer your question...  5:)

Are there any plans to include and ebuild for the VMware Management User
Interface?

I don't know what VMware's plans are regarding the MUI(seeing how they are
pushing for people to buy thier virtual infrastructure package and have removed
most links to vmware-mui) but vmware-mui is still available for download. I
have just fetched VMware-mui-1.0.1-29996.tar.gz and installed it fine (I
installed it into /opt/vmware/server/mui). The only thing I had to do was
symlink /opt/vmware/server/sbin/vmware-authd to /usr/sbin/vmware-authd to get
it to work.

Incidently, maybe this symlink should be created by default when ever
vmware-server is installed, as it has now given me a "Local Host" option in the
"Connect to Host" dialogue of vmware-server-console (Its very handy - I no
longer have to keep re-typing my username and password :-)

The only work I can see that the mui requires is its own init script so it
conforms to the proper Gentoo style.

First off, Happy 401st Comment!!!!  5:)

At the moment there aren't any immediate plans to deal with the mui, simply
because hooking it into apache and fixing all the bugs for it are lower on the
vmware group's priority list than removing all the perl
configuration/installation scripts.

However, if someone's willing to try their hand at writing an ebuild for it,
I'll be happy to give it a look through and if it's all good add it to the
overlay, and if it's not, I can point them to the information to help fix it
up...  5:)

Could we get a separate bug opened for the mui? I'd like to try an ebuild for
it, but there are some sticky decisions that have to be made first. For
example, the mui includes a binary apache module (mod_vmdb), so I don't think
the webapp eclass and the user's existing apache can be used. Although the
method of dropping an entire binary apache and openssl installation onto the
system seems pretty dirty, wouldn't that be par for the course with VMware ;-)?

Brendan, all done, please feel free to start posting to it, including any
ebuilds you might want to test.  I'll give them a check through, make sure
they're all ok and if they are put them in the overlay for you.  Gimme a shout
if there's anything else I can do...  5:)

Mike, I have always wondered why is there nothing like vmware-tools in the
portage. The vmware-tools tar is present in the vmware-server tar and has a
different structure than the one required by vmware-workstation-tools., which
IMO is based on a very old build. Moreover, it asks the user to mount the CD
before hand.

Can we have a vmware-tools package which 1.) checks if we are running in a VM,
2.) extracts vmware-tools tar from within vmware-server package and installs
it.

The pain of managing /etc/rc*.d for vmware-tools is same within the VM as it is
on host with vmware-server.

There is a vmware-server-tools ebuild that I started working on in the overlay.
 However it turns out not to be a simple task, because of the extra modules
that need to be installed, and then as you pointed out jiggering with all the
init scripts.  Also, the ebuild would not modify the xorg configuration, so the
user would still have to know to request the vmware monitor and vmmouse drivers
for xorg, and then configure them.  Once the user's doing that, it's not
entirely clear how much benefit they receive from the tools.  However, if you'd
like to look into it, or send me patches for the existing one to bash it into
shape, I'd be happy to look them through and commit them for you (and who knows
if I manage to find time to do that, I may even poke at them myself a bit
more)...  5:)

Hi,

I'm seeing the exact problems as described in:
http://www.vmware.com/community/thread.jspa?threadID=67572&tstart=0

Basically vmware-server freezes on dual-core processors.
It hard locks the entire system and no actiuvity.

As suggested in the thread, patchset any_any_update106 solves this.
I changed the value for ANY_ANY in the eclass, is that the way this dependency
is meant to be updated ?

Hi.  We've just had an eagle eyed user spot that any-any107 is now out, we'll
be updating the vmware overlay sometime today, and pushing it into the main
tree in a few days (assuming there are no issues with the new version).  I'll
be posting on bug 157307 when the new version is available so please keep an
eye on if you'd like to test the overlay version...  5:)

Closing this tracker since the overlay is now only for testing.

(In reply to comment #94)
> Here's an interesting observation:
>    I wanted to install vmware-server on a JFS partition, which has pretty
> decent speed when updating/copying large atomic files. However, vmware-server
> doesn't recognize jfs as a partition type, and the server refuses to start. I
> found a workaround, which is that vmware only expects /etc/vmware and
> /var/log/vmware to be of a certain fs type, so I created small loopback
> filesystems (ext2/3 and reiserfs both worked) and then re-ran the setup script.
> It works like a charm. I know this is a bug with vmware, but you might want to
> add an info line to ebuild to let people know of this limitation. =)
> 
> Great work, thanks for putting in the effort!
> 

just for the record:
I installed vmware-server-1.0.6.91891 from portage on a JFS partition without
any problem