Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 122500 - [Tracker] vmware overlay
Summary: [Tracker] vmware overlay
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo VMWare Bug Squashers [disabled]
URL: http://overlays.gentoo.org/svn/proj/v...
Whiteboard:
Keywords: Tracker
: 56881 122670 (view as bug list)
Depends on: 137422 137423 137424 137425 137426 137428 149573
Blocks:
  Show dependency tree
 
Reported: 2006-02-11 13:58 UTC by Mike Auty
Modified: 2008-09-09 19:22 UTC (History)
62 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
vmware-server-1.0.0.20925.ebuild - Version 0.0.5 (vmware-server-1.0.0.20925.ebuild,7.71 KB, text/plain)
2006-02-11 14:02 UTC, Mike Auty
Details
vmware-server auxiliary file - 90vmware-server (90vmware-server,91 bytes, text/plain)
2006-02-11 14:03 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware.rc (vmware.rc,1.39 KB, text/plain)
2006-02-11 14:03 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware.xml (vmware.xml,1.55 KB, text/plain)
2006-02-11 14:04 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-config.patch (vmware-server-1.0.0.20925-config.patch,1.10 KB, patch)
2006-02-11 14:04 UTC, Mike Auty
Details | Diff
vmware-server auxiliary file - vmware-server-1.0.0.20925-config2.patch (vmware-server-1.0.0.20925-config2.patch,647 bytes, patch)
2006-02-11 14:04 UTC, Mike Auty
Details | Diff
vmware-server auxiliary file - vmware-server-1.0.0.20925-config3.patch (vmware-server-1.0.0.20925-config3.patch,677 bytes, patch)
2006-02-11 14:05 UTC, Mike Auty
Details | Diff
vmware-server-console-1.0.0.20925.ebuild - Version 0.0.3 (vmware-server-console-1.0.0.20925.ebuild,4.93 KB, text/plain)
2006-02-11 14:08 UTC, Mike Auty
Details
vmware-server-console auxiliary file - 99vmware-console (99vmware-console,76 bytes, text/plain)
2006-02-11 14:09 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.0.6 (vmware-server-1.0.0.20925.ebuild,8.21 KB, text/plain)
2006-02-14 02:37 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-amd64 (vmware-server-1.0.0.20925-vmware-authd-amd64,324 bytes, text/plain)
2006-02-14 02:38 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-x86 (vmware-server-1.0.0.20925-vmware-authd-x86,208 bytes, text/plain)
2006-02-14 02:39 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.0.7 (vmware-server-1.0.0.20925.ebuild,8.33 KB, text/plain)
2006-02-19 09:57 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-config4.patch (vmware-server-1.0.0.20925-config4.patch,589 bytes, patch)
2006-02-19 09:59 UTC, Mike Auty
Details | Diff
vmware-server-modules-1.0.0.20925.ebuild - Version 0.0.1 (vmware-server-modules-1.0.0.20925.ebuild,1.47 KB, text/plain)
2006-02-19 10:00 UTC, Mike Auty
Details
vmware-server-modules auxiliary file - vmware-server-modules-1.0.0.20925-makefile.patch (vmware-server-modules-1.0.0.20925-makefile.patch,343 bytes, patch)
2006-02-19 10:00 UTC, Mike Auty
Details | Diff
vmware-server-1.0.0.20925.ebuild - Version 0.1.0 (vmware-server-1.0.0.20925.ebuild,8.46 KB, text/plain)
2006-02-20 16:26 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-services.patch (vmware-server-1.0.0.20925-services.patch,448 bytes, patch)
2006-02-20 16:28 UTC, Mike Auty
Details | Diff
vmware-server-1.0.0.20925.ebuild - Version 0.1.1 (vmware-server-1.0.0.20925.ebuild,8.55 KB, text/plain)
2006-02-21 04:32 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.0 (vmware-server-1.0.0.20925.ebuild,8.59 KB, text/plain)
2006-02-21 15:03 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.1 (vmware-server-1.0.0.20925.ebuild,8.71 KB, text/plain)
2006-02-22 03:22 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.2 (vmware-server-1.0.0.20925.ebuild,8.82 KB, text/plain)
2006-02-23 09:22 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-amd64 - Version 0.0.2 (vmware-server-1.0.0.20925-vmware-authd-amd64,460 bytes, text/plain)
2006-02-23 09:24 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-x86 - Version 0.0.2 (vmware-server-1.0.0.20925-vmware-authd-x86,315 bytes, text/plain)
2006-02-23 09:24 UTC, Mike Auty
Details
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmwaregroup (vmware-server-1.0.0.20925-vmwaregroup,7 bytes, text/plain)
2006-02-23 09:25 UTC, Mike Auty
Details
vmware-server-console-1.0.0.20925.ebuild - Version 0.0.4 (vmware-server-console-1.0.0.20925.ebuild,4.95 KB, text/plain)
2006-02-23 09:27 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.3 (vmware-server-1.0.0.20925.ebuild,8.88 KB, text/plain)
2006-03-01 07:50 UTC, Mike Auty
Details
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.0 (vmware-server-console-1.0.0.20925.ebuild,4.98 KB, text/plain)
2006-03-01 07:51 UTC, Mike Auty
Details
vmware-server-modules-1.0.0.20925.ebuild - Version 0.1.0 (vmware-server-modules-1.0.0.20925.ebuild,1.45 KB, text/plain)
2006-03-01 07:52 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.4 (vmware-server-1.0.0.20925.ebuild,8.87 KB, text/plain)
2006-03-01 10:41 UTC, Mike Auty
Details
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.1 (vmware-server-console-1.0.0.20925.ebuild,4.97 KB, text/plain)
2006-03-01 10:42 UTC, Mike Auty
Details
vmware-server-modules-1.0.0.20925.ebuild - Version 0.1.1 (vmware-server-modules-1.0.0.20925.ebuild,1.41 KB, text/plain)
2006-03-01 10:42 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.5 (vmware-server-1.0.0.20925.ebuild,8.88 KB, text/plain)
2006-03-01 10:49 UTC, Mike Auty
Details
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.2 (vmware-server-console-1.0.0.20925.ebuild,4.97 KB, text/plain)
2006-03-02 14:50 UTC, Mike Auty
Details
vmware-server-1.0.0.20925.ebuild - Version 0.2.6 (vmware-server-1.0.0.20925.ebuild,8.89 KB, text/plain)
2006-03-09 15:02 UTC, Mike Auty
Details
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.3 (vmware-server-console-1.0.0.20925.ebuild,4.95 KB, text/plain)
2006-03-09 15:05 UTC, Mike Auty
Details
Fixes issue with vmware-config.pl overwriting /etc/xinetd.d/vmware-authd. (vmware-server-1.0.0.22088-config5.patch,2.02 KB, patch)
2006-03-17 14:01 UTC, Hannes Schmidt
Details | Diff
Patch to fix compiling modules against 2.6.17 (vcpuset-2.6.17.patch,1.31 KB, patch)
2006-04-25 05:50 UTC, Daniele Gaffuri
Details | Diff
new ebuild which blocks vmware-server build 24927 (vmware-modules-101-r4.ebuild,1.66 KB, text/plain)
2006-06-08 18:48 UTC, Michael Weyershäuser
Details
emerge --info on 15 Jun 2006 (emerge.info,2.82 KB, text/plain)
2006-06-15 09:51 UTC, Peter Humphrey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Auty gentoo-dev 2006-02-11 13:58:15 UTC
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.
Comment 1 Mike Auty gentoo-dev 2006-02-11 14:02:28 UTC
Created attachment 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...
Comment 2 Mike Auty gentoo-dev 2006-02-11 14:03:21 UTC
Created attachment 79529 [details]
vmware-server auxiliary file - 90vmware-server
Comment 3 Mike Auty gentoo-dev 2006-02-11 14:03:48 UTC
Created attachment 79530 [details]
vmware-server auxiliary file - vmware.rc
Comment 4 Mike Auty gentoo-dev 2006-02-11 14:04:10 UTC
Created attachment 79531 [details]
vmware-server auxiliary file - vmware.xml
Comment 5 Mike Auty gentoo-dev 2006-02-11 14:04:39 UTC
Created attachment 79532 [details, diff]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config.patch
Comment 6 Mike Auty gentoo-dev 2006-02-11 14:04:58 UTC
Created attachment 79533 [details, diff]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config2.patch
Comment 7 Mike Auty gentoo-dev 2006-02-11 14:05:18 UTC
Created attachment 79534 [details, diff]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config3.patch
Comment 8 Mike Auty gentoo-dev 2006-02-11 14:08:57 UTC
Created attachment 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).
Comment 9 Mike Auty gentoo-dev 2006-02-11 14:09:41 UTC
Created attachment 79537 [details]
vmware-server-console auxiliary file - 99vmware-console
Comment 10 Mike Auty gentoo-dev 2006-02-11 14:11:04 UTC
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...
Comment 11 Michiel de Bruijne 2006-02-11 14:19:17 UTC
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?
Comment 12 Mike Auty gentoo-dev 2006-02-11 14:23:35 UTC
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.
Comment 13 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-02-11 22:49:20 UTC
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.
Comment 14 Mike Auty gentoo-dev 2006-02-12 03:35:57 UTC
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!
Comment 15 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-02-12 07:18:30 UTC
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.
Comment 16 Mike Auty gentoo-dev 2006-02-12 07:29:59 UTC
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)...
Comment 17 Marcus D. Hanwell (RETIRED) gentoo-dev 2006-02-13 03:29:02 UTC
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.
Comment 18 Christian Faulhammer (RETIRED) gentoo-dev 2006-02-13 07:22:19 UTC
Just want to announce successful installation on an x86 (AMD Athlon 2500+) system, just using local.  Windows XP installation progresses.
Comment 19 Mike Auty gentoo-dev 2006-02-13 10:53:32 UTC
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...
Comment 20 John Mylchreest (RETIRED) gentoo-dev 2006-02-13 12:50:51 UTC
*** Bug 56881 has been marked as a duplicate of this bug. ***
Comment 21 John Mylchreest (RETIRED) gentoo-dev 2006-02-13 12:52:12 UTC
bug #56881 contains a few compatibility/clean-up comments. JFYI
Comment 22 dino7 2006-02-13 12:59:13 UTC
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
Comment 23 Mike Auty gentoo-dev 2006-02-13 15:07:00 UTC
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...
Comment 24 Paul de Vrieze (RETIRED) gentoo-dev 2006-02-14 00:36:35 UTC
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?
Comment 25 Paul de Vrieze (RETIRED) gentoo-dev 2006-02-14 00:39:00 UTC
Also pam_wheel should work with the "use_uid" parameter. And it's included in the main pam distribution.
Comment 26 Mike Auty gentoo-dev 2006-02-14 01:05:23 UTC
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:)
Comment 27 Mike Auty gentoo-dev 2006-02-14 02:37:55 UTC
Created attachment 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.
Comment 28 Mike Auty gentoo-dev 2006-02-14 02:38:38 UTC
Created attachment 79745 [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-amd64
Comment 29 Mike Auty gentoo-dev 2006-02-14 02:39:14 UTC
Created attachment 79746 [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-x86
Comment 30 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-02-14 02:57:29 UTC
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).
Comment 31 Mike Auty gentoo-dev 2006-02-14 03:09:09 UTC
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!
Comment 32 John Mylchreest (RETIRED) gentoo-dev 2006-02-14 03:22:07 UTC
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?
Comment 33 Mike Auty gentoo-dev 2006-02-14 03:28:55 UTC
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:)
Comment 34 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-14 07:39:29 UTC
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.
Comment 35 Mike Auty gentoo-dev 2006-02-14 08:29:28 UTC
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...
Comment 36 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-14 09:49:51 UTC
(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.
Comment 37 Mike Auty gentoo-dev 2006-02-19 09:57:55 UTC
Created attachment 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...
Comment 38 Mike Auty gentoo-dev 2006-02-19 09:59:19 UTC
Created attachment 80202 [details, diff]
vmware-server auxiliary file - vmware-server-1.0.0.20925-config4.patch
Comment 39 Mike Auty gentoo-dev 2006-02-19 10:00:10 UTC
Created attachment 80203 [details]
vmware-server-modules-1.0.0.20925.ebuild - Version 0.0.1
Comment 40 Mike Auty gentoo-dev 2006-02-19 10:00:52 UTC
Created attachment 80204 [details, diff]
vmware-server-modules auxiliary file - vmware-server-modules-1.0.0.20925-makefile.patch
Comment 41 Mike Auty gentoo-dev 2006-02-20 16:26:45 UTC
Created attachment 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:)
Comment 42 Mike Auty gentoo-dev 2006-02-20 16:28:15 UTC
Created attachment 80329 [details, diff]
vmware-server auxiliary file - vmware-server-1.0.0.20925-services.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).
Comment 43 Bertrand CHERRIER 2006-02-20 20:47:13 UTC
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
Comment 44 Mike Auty gentoo-dev 2006-02-21 01:11:40 UTC
(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...
Comment 45 Bertrand CHERRIER 2006-02-21 02:52:40 UTC
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] 
Comment 46 Mike Auty gentoo-dev 2006-02-21 04:32:28 UTC
Created attachment 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:\
Comment 47 Bertrand CHERRIER 2006-02-21 05:16:48 UTC
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 !
Comment 48 Bertrand CHERRIER 2006-02-21 05:31:04 UTC
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
Comment 49 Thomas Stein 2006-02-21 05:56:28 UTC
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.
Comment 50 Thomas Stein 2006-02-21 08:15:38 UTC
Okay. Version 0.1.1 fixes my error. Thanks.
Comment 51 Mike Auty gentoo-dev 2006-02-21 08:22:19 UTC
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...
Comment 52 Thomas Stein 2006-02-21 08:32:59 UTC
No Problem Mike. I know i play with unstable stuff. Keep up your good work. :-)

cheers
t.
Comment 53 Mike Auty gentoo-dev 2006-02-21 15:03:11 UTC
Created attachment 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...
Comment 54 Mike Auty gentoo-dev 2006-02-22 03:22:37 UTC
Created attachment 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:)
Comment 55 drumz 2006-02-22 15:43:53 UTC
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!
Comment 56 Mike Auty gentoo-dev 2006-02-22 16:39:01 UTC
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:)
Comment 57 drumz 2006-02-22 16:55:13 UTC
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.
Comment 58 Hannes Schmidt 2006-02-22 16:57:03 UTC
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.
Comment 59 dino7 2006-02-23 02:33:24 UTC
(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.

Comment 60 Mike Auty gentoo-dev 2006-02-23 09:22:37 UTC
Created attachment 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:)
Comment 61 Mike Auty gentoo-dev 2006-02-23 09:24:06 UTC
Created attachment 80527 [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-amd64 - Version 0.0.2
Comment 62 Mike Auty gentoo-dev 2006-02-23 09:24:36 UTC
Created attachment 80528 [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmware-authd-x86 - Version 0.0.2
Comment 63 Mike Auty gentoo-dev 2006-02-23 09:25:10 UTC
Created attachment 80529 [details]
vmware-server auxiliary file - vmware-server-1.0.0.20925-vmwaregroup
Comment 64 Mike Auty gentoo-dev 2006-02-23 09:27:22 UTC
Created attachment 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:)
Comment 65 drumz 2006-02-23 15:04:52 UTC
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.
Comment 66 Mike Auty gentoo-dev 2006-02-23 15:12:50 UTC
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...
Comment 67 drumz 2006-02-23 16:24:53 UTC
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.

Comment 68 Mike Auty gentoo-dev 2006-02-23 16:47:12 UTC
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...
Comment 69 drumz 2006-02-23 17:41:27 UTC
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....
Comment 70 Chris Pugrud 2006-02-24 22:27:43 UTC
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!
Comment 71 drumz 2006-02-25 09:45:38 UTC
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.

Comment 72 Mike Auty gentoo-dev 2006-02-25 13:13:24 UTC
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:)
Comment 73 drumz 2006-02-25 16:56:22 UTC
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.
Comment 74 Chris Pugrud 2006-02-26 13:55:06 UTC
(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.
Comment 75 Hubert Mercier (RETIRED) gentoo-dev 2006-02-27 06:18:34 UTC
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).
Comment 76 Ciaran McCreesh 2006-02-28 07:57:18 UTC
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.
Comment 77 Rasmus Jacobsen 2006-02-28 09:50:09 UTC
Why is it necessary to install xorg-x11 for the server to work?
Comment 78 Mike Auty gentoo-dev 2006-02-28 13:13:46 UTC
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:\
Comment 79 Ciaran McCreesh 2006-02-28 13:31:32 UTC
(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.
Comment 80 Mike Auty gentoo-dev 2006-02-28 15:34:49 UTC
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:)
Comment 81 Mike Auty gentoo-dev 2006-03-01 07:50:21 UTC
Created attachment 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:)
Comment 82 Mike Auty gentoo-dev 2006-03-01 07:51:30 UTC
Created attachment 81039 [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.0
Comment 83 Mike Auty gentoo-dev 2006-03-01 07:52:11 UTC
Created attachment 81040 [details]
vmware-server-modules-1.0.0.20925.ebuild - Version 0.1.0
Comment 84 Mike Auty gentoo-dev 2006-03-01 07:54:19 UTC
Also if you haven't started yet, Ciaran, the attachment numbers should now read: attachment 81038 [details], attachment 81039 [details] and attachment 81040 [details]...
Comment 85 Ciaran McCreesh 2006-03-01 09:41:21 UTC
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.
Comment 86 Mike Auty gentoo-dev 2006-03-01 10:40:56 UTC
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.
Comment 87 Mike Auty gentoo-dev 2006-03-01 10:41:41 UTC
Created attachment 81050 [details]
vmware-server-1.0.0.20925.ebuild - Version 0.2.4
Comment 88 Mike Auty gentoo-dev 2006-03-01 10:42:20 UTC
Created attachment 81051 [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.1
Comment 89 Mike Auty gentoo-dev 2006-03-01 10:42:44 UTC
Created attachment 81052 [details]
vmware-server-modules-1.0.0.20925.ebuild - Version 0.1.1
Comment 90 Mike Auty gentoo-dev 2006-03-01 10:49:43 UTC
Created attachment 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.
Comment 91 Maik Schreiber 2006-03-01 15:57:58 UTC
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.
Comment 92 horatio 2006-03-02 14:40:33 UTC
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? 
Comment 93 Mike Auty gentoo-dev 2006-03-02 14:50:16 UTC
Created attachment 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:)
Comment 94 John W Eckhart 2006-03-06 15:21:02 UTC
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!
Comment 95 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-07 01:19:01 UTC
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/
Comment 96 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-07 01:26:48 UTC
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).
Comment 97 John Mylchreest (RETIRED) gentoo-dev 2006-03-07 01:31:02 UTC
Does that mean you can give Mike & co access to the svn for dev purposes while this bug is open? :)
Comment 98 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-07 01:55:13 UTC
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.
Comment 99 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-07 02:16:51 UTC
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.
Comment 100 James Smith 2006-03-09 09:21:33 UTC
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?
Comment 101 Mike Auty gentoo-dev 2006-03-09 12:18:19 UTC
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:)
Comment 102 Mike Auty gentoo-dev 2006-03-09 15:02:04 UTC
Created attachment 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:)
Comment 103 Mike Auty gentoo-dev 2006-03-09 15:05:28 UTC
Created attachment 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:)
Comment 104 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-10 00:44:40 UTC
@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.
Comment 105 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-10 00:48:32 UTC
@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


Comment 106 R. May 2006-03-10 01:50:57 UTC
Hello,

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

Regards Roland
Comment 107 John Mylchreest (RETIRED) gentoo-dev 2006-03-10 02:15:37 UTC
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.
Comment 108 Stefan 2006-03-10 05:21:58 UTC
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
Comment 109 Mike Auty gentoo-dev 2006-03-10 06:37:40 UTC
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...
Comment 110 Peter Humphrey 2006-03-10 09:42:19 UTC
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
Comment 111 Mike Auty gentoo-dev 2006-03-10 09:53:08 UTC
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...
Comment 112 Peter Humphrey 2006-03-10 09:59:36 UTC
(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.
Comment 113 Guillaume Castagnino 2006-03-11 04:02:09 UTC
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
Comment 114 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-11 06:26:49 UTC
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.
Comment 115 R. May 2006-03-11 08:32:35 UTC
vmware server v. 22088 is online. Anyone tested it?

R. Roland
Comment 116 Rod Begbie 2006-03-11 09:04:24 UTC
(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.
Comment 117 Mike Auty gentoo-dev 2006-03-11 13:42:08 UTC
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:)
Comment 118 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-11 13:50:15 UTC
The GCC 4.1 fix is needed, or it will fail emerge as it was failing vmware-config before.
Comment 119 Peter Humphrey 2006-03-12 03:43:02 UTC
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...
Comment 120 Martin Berard 2006-03-14 17:01:59 UTC
(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
Comment 121 Mike Auty gentoo-dev 2006-03-14 17:06:00 UTC
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...
Comment 122 Hannes Schmidt 2006-03-15 09:50:20 UTC
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
Comment 123 Mike Auty gentoo-dev 2006-03-15 10:07:57 UTC
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...
Comment 124 Rajiv Aaron Manglani (RETIRED) gentoo-dev 2006-03-15 11:57:13 UTC
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.
Comment 125 Mike Auty gentoo-dev 2006-03-15 12:34:04 UTC
Comment on attachment 81809 [details]
vmware-server-console-1.0.0.20925.ebuild - Version 0.1.3

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...
Comment 126 Micheal Marineau (RETIRED) gentoo-dev 2006-03-15 14:32:13 UTC
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.
Comment 127 Micheal Marineau (RETIRED) gentoo-dev 2006-03-15 14:38:01 UTC
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.
Comment 128 Hannes Schmidt 2006-03-15 22:29:45 UTC
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?

Comment 129 Micheal Marineau (RETIRED) gentoo-dev 2006-03-16 00:14:33 UTC
(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.
Comment 130 Mike Auty gentoo-dev 2006-03-16 02:57:19 UTC
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...
Comment 131 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-16 08:42:07 UTC
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.
Comment 132 Mike Auty gentoo-dev 2006-03-16 15:56:05 UTC
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:)
Comment 133 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-17 04:57:17 UTC
(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.
Comment 134 Mike Auty gentoo-dev 2006-03-17 05:41:20 UTC
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...
Comment 135 Mike Auty gentoo-dev 2006-03-17 05:54:23 UTC
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:)
Comment 136 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-17 06:12:26 UTC
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.
Comment 137 Mike Auty gentoo-dev 2006-03-17 06:19:02 UTC
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
Comment 138 Ciaran McCreesh 2006-03-17 06:27:20 UTC
-Werror in C*FLAGS for any package in the tree is incorrect. It makes the package unusable with future and unexpected compilers.
Comment 139 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-17 06:48:02 UTC
-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?
Comment 140 Ciaran McCreesh 2006-03-17 06:58:31 UTC
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.
Comment 141 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-17 07:02:43 UTC
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.
Comment 142 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-17 07:50:09 UTC
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.
Comment 143 Ciaran McCreesh 2006-03-17 08:07:13 UTC
(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.
Comment 144 Paul de Vrieze (RETIRED) gentoo-dev 2006-03-17 08:25:57 UTC
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.
Comment 145 Hannes Schmidt 2006-03-17 08:39:35 UTC
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?
Comment 146 Ciaran McCreesh 2006-03-17 09:06:24 UTC
(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. 
Comment 147 Hannes Schmidt 2006-03-17 13:58:24 UTC
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 ...
Comment 148 Hannes Schmidt 2006-03-17 14:01:37 UTC
Created attachment 82407 [details, diff]
Fixes issue with vmware-config.pl overwriting /etc/xinetd.d/vmware-authd.
Comment 149 Mike Auty gentoo-dev 2006-03-19 08:35:42 UTC
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...
Comment 150 Mike Auty gentoo-dev 2006-03-19 09:39:32 UTC
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...
Comment 151 Mike Auty gentoo-dev 2006-03-20 12:42:27 UTC
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...
Comment 152 Guillaume Castagnino 2006-03-20 14:16:59 UTC
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
Comment 153 Guillaume Castagnino 2006-03-20 14:16:59 UTC
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
Comment 154 Mike Auty gentoo-dev 2006-03-20 16:24:16 UTC
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...
Comment 155 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-20 16:36:43 UTC
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 .
Comment 156 Guillaume Castagnino 2006-03-20 23:01:25 UTC
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"

Comment 157 Peter Humphrey 2006-03-21 03:31:54 UTC
(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!   :-(
Comment 158 Mike Auty gentoo-dev 2006-03-21 04:04:54 UTC
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:)
Comment 159 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-03-21 04:08:26 UTC
Hint: toolchain-funcs.eclass, gcc-major-version()  ;)
Comment 160 Mike Auty gentoo-dev 2006-03-21 04:22:13 UTC
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...
Comment 161 Mike Auty gentoo-dev 2006-03-21 08:01:24 UTC
Ok, all fixed up and checked into subversion.  Please keep the bug reports coming, the ebuild's looking pretty good now...  5:)
Comment 162 Guillaume Castagnino 2006-03-21 08:32:38 UTC
OK, all compile very well now with gcc 3.4.5
Thanks for all your work !
Comment 163 Rene Zbinden 2006-03-21 13:23:57 UTC
OK, which file do I have to use?
Comment 164 Rene Zbinden 2006-03-21 13:30:10 UTC
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.
Comment 165 Rene Zbinden 2006-03-21 14:03:36 UTC
A dependency to xinetd should be added.
Comment 166 Ciaran McCreesh 2006-03-21 14:06:38 UTC
(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?
Comment 167 Mike Auty gentoo-dev 2006-03-21 15:54:45 UTC
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:)
Comment 168 Rene Zbinden 2006-03-22 06:27:18 UTC
(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) 
Comment 169 Mike Auty gentoo-dev 2006-03-22 06:52:08 UTC
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...
Comment 170 Rene Zbinden 2006-03-22 11:15:24 UTC
(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.
Comment 171 Martin Berard 2006-03-24 10:20:16 UTC
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






Comment 172 Mike Auty gentoo-dev 2006-03-24 11:04:31 UTC
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:)
Comment 173 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-24 12:13:39 UTC
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.
Comment 174 Martin Berard 2006-03-24 20:19:40 UTC
(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
Comment 175 Mike Auty gentoo-dev 2006-03-25 02:41:59 UTC
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...
Comment 176 Martin Berard 2006-03-25 15:10:22 UTC
(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
Comment 177 Mike Auty gentoo-dev 2006-03-25 17:35:47 UTC
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...
Comment 178 Mike Auty gentoo-dev 2006-03-29 02:13:26 UTC
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:)
Comment 179 Christophe 2006-03-31 08:41:21 UTC
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 ?
Comment 180 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-31 08:54:55 UTC
The ebuild should list all of the required dependencies.
Comment 181 Mike Auty gentoo-dev 2006-03-31 09:45:38 UTC
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:)
Comment 182 Christophe 2006-03-31 10:40:06 UTC
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.
Comment 183 Mike Auty gentoo-dev 2006-03-31 10:49:38 UTC
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:)
Comment 184 Christophe 2006-03-31 15:30:32 UTC
> 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...
Comment 185 heinzg 2006-04-02 12:08:00 UTC
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
Comment 186 Micheal Marineau (RETIRED) gentoo-dev 2006-04-02 12:17:34 UTC
(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.
Comment 187 heinzg 2006-04-02 14:09:14 UTC
(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
Comment 188 Mike Auty gentoo-dev 2006-04-02 14:23:31 UTC
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...
Comment 189 Marcus D. Hanwell (RETIRED) gentoo-dev 2006-04-03 11:10:20 UTC
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.
Comment 190 Mike Auty gentoo-dev 2006-04-03 11:19:03 UTC
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:)
Comment 191 Rene Zbinden 2006-04-03 23:58:15 UTC
VMware Server Beta 2 is now available. Anyone checked if the ebuild works with this version?
Comment 192 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-04-04 00:17:24 UTC
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.
Comment 193 Jakub Moc (RETIRED) gentoo-dev 2006-04-04 09:16:29 UTC
(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).
Comment 194 Mike Auty gentoo-dev 2006-04-04 09:42:48 UTC
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...
Comment 195 Patrick Huber 2006-04-04 14:00:40 UTC
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
Comment 196 Mike Auty gentoo-dev 2006-04-04 14:35:29 UTC
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:)
Comment 197 Patrick Huber 2006-04-04 15:12:25 UTC
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!
Comment 198 Martin Berard 2006-04-06 11:26:23 UTC
(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
Comment 199 Alin Dobre (RETIRED) gentoo-dev 2006-04-07 00:07:28 UTC
(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?
Comment 200 Alin Dobre (RETIRED) gentoo-dev 2006-04-07 00:41:40 UTC
(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
Comment 201 Marcus D. Hanwell (RETIRED) gentoo-dev 2006-04-07 02:22:20 UTC
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
Comment 202 Mike Auty gentoo-dev 2006-04-07 04:58:55 UTC
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...
Comment 203 Marcus D. Hanwell (RETIRED) gentoo-dev 2006-04-07 05:31:41 UTC
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.
Comment 204 dino7 2006-04-09 23:37:53 UTC
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.)
Comment 205 Mike Auty gentoo-dev 2006-04-10 12:12:00 UTC
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:)
Comment 206 dino7 2006-04-10 12:39:43 UTC
(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:
Comment 207 dino7 2006-04-10 12:39:43 UTC
(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.
Comment 208 vividvew 2006-04-10 20:40:16 UTC
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
Comment 209 Chris Gianelloni (RETIRED) gentoo-dev 2006-04-11 13:11:06 UTC
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.
Comment 210 Mike Auty gentoo-dev 2006-04-11 18:53:56 UTC
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
Comment 211 Mike Auty gentoo-dev 2006-04-11 18:58:27 UTC
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...
Comment 212 Alex 2006-04-14 09:17:36 UTC
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.
Comment 213 Norman Jonas 2006-04-14 09:23:48 UTC
(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 ?
Comment 214 Mike Auty gentoo-dev 2006-04-14 09:31:27 UTC
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...
Comment 215 Jakub Moc (RETIRED) gentoo-dev 2006-04-14 09:41:33 UTC
(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).
Comment 216 Mike Auty gentoo-dev 2006-04-14 09:50:43 UTC
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...
Comment 217 Mike Auty gentoo-dev 2006-04-14 09:51:11 UTC
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)...
Comment 218 Jakub Moc (RETIRED) gentoo-dev 2006-04-14 09:58:35 UTC
(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.

Comment 219 @4u 2006-04-14 10:13:38 UTC
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.
Comment 220 Mike Auty gentoo-dev 2006-04-14 10:36:29 UTC
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:)
Comment 221 alexander.schneider 2006-04-14 11:10:19 UTC
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
Comment 222 alexander.schneider 2006-04-14 11:10:19 UTC
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.
Comment 223 Paul de Vrieze (RETIRED) gentoo-dev 2006-04-14 11:19:12 UTC
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.
Comment 224 Mike Auty gentoo-dev 2006-04-14 11:53:23 UTC
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...
Comment 225 Alex 2006-04-14 16:52:44 UTC
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.
Comment 226 Mike Auty gentoo-dev 2006-04-14 17:51:21 UTC
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...
Comment 227 Alex 2006-04-14 21:23:36 UTC
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.
Comment 228 Jack Vande Bunte 2006-04-15 14:18:13 UTC
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. 
Comment 229 Mike Auty gentoo-dev 2006-04-15 14:32:29 UTC
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:)
Comment 230 Paul de Vrieze (RETIRED) gentoo-dev 2006-04-17 06:50:31 UTC
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.
Comment 231 Rick Winkler 2006-04-17 11:42:13 UTC
(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.
Comment 232 Chris Gianelloni (RETIRED) gentoo-dev 2006-04-19 10:56:42 UTC
*** Bug 122670 has been marked as a duplicate of this bug. ***
Comment 233 Mike Auty gentoo-dev 2006-04-19 11:02:33 UTC
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:)
Comment 234 Antonio Rotundo 2006-04-19 11:23:07 UTC
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.
Comment 235 Mike Auty gentoo-dev 2006-04-21 15:02:01 UTC
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:)
Comment 236 Michael Weyershäuser 2006-04-21 18:48:14 UTC
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.
Comment 237 Nathan Sullivan 2006-04-21 19:10:39 UTC
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
Comment 238 Mike Auty gentoo-dev 2006-04-22 03:23:19 UTC
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:)
Comment 239 Martin Berard 2006-04-22 19:11:43 UTC
(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
Comment 240 Daniele Gaffuri 2006-04-25 05:48:01 UTC
(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.
Comment 241 Daniele Gaffuri 2006-04-25 05:50:11 UTC
Created attachment 85453 [details, diff]
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).
Comment 242 Mike Auty gentoo-dev 2006-04-25 10:00:24 UTC
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:)
Comment 243 Chris Gianelloni (RETIRED) gentoo-dev 2006-04-25 11:45:35 UTC
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.
Comment 244 Mike Auty gentoo-dev 2006-04-25 13:55:28 UTC
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:)
Comment 245 Luca Bertagnolio 2006-04-27 05:02:17 UTC
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
Comment 246 Jakub Moc (RETIRED) gentoo-dev 2006-04-27 05:05:47 UTC
(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.
Comment 247 Paul de Vrieze (RETIRED) gentoo-dev 2006-04-27 07:11:15 UTC
@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.
Comment 248 Luca Bertagnolio 2006-04-27 08:08:48 UTC
(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
Comment 249 R. May 2006-04-29 07:02:55 UTC
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
Comment 250 Mike Auty gentoo-dev 2006-04-29 07:08:44 UTC
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:)
Comment 251 R. May 2006-05-01 00:38:59 UTC
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.
Comment 252 Mike Auty gentoo-dev 2006-05-01 01:54:38 UTC
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:)
Comment 253 Tom Lanyon 2006-05-02 05:27:04 UTC
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
Comment 254 Mike Auty gentoo-dev 2006-05-02 05:58:40 UTC
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...
Comment 255 Tom Lanyon 2006-05-02 07:45:41 UTC
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/
Comment 256 Tom Lanyon 2006-05-02 07:47:55 UTC
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.
Comment 257 Tom Lanyon 2006-05-02 23:36:45 UTC
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.
Comment 258 Mike Auty gentoo-dev 2006-05-03 07:17:33 UTC
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:)
Comment 259 Norman Jonas 2006-05-03 11:40:22 UTC
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
Comment 260 Norman Jonas 2006-05-03 11:40:22 UTC
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.
Comment 261 Mike Auty gentoo-dev 2006-05-03 15:06:14 UTC
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:) 
Comment 262 Norman Jonas 2006-05-03 15:51:46 UTC
I am using gcc 4.1.0 as well. Thanks for looking into it.
Comment 263 Mike Auty gentoo-dev 2006-05-03 15:52:58 UTC
Hmmmm, well that is weird.  Any chance you could post your 'emerge --info' please?
Comment 264 Norman Jonas 2006-05-03 15:56:43 UTC
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 
Comment 265 Norman Jonas 2006-05-03 15:56:43 UTC
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.
Comment 266 Norman Jonas 2006-05-03 16:04:35 UTC
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.
Comment 267 Mike Auty gentoo-dev 2006-05-03 16:08:28 UTC
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:)
Comment 268 Jeff Wiegley 2006-05-04 12:28:25 UTC
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!
Comment 269 Mike Auty gentoo-dev 2006-05-04 13:57:09 UTC
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:)
Comment 270 Jeff Wiegley 2006-05-04 23:08:09 UTC
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.
Comment 271 Jeff Wiegley 2006-05-04 23:14:06 UTC
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...
Comment 272 Jeff Wiegley 2006-05-04 23:30:00 UTC
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)
Comment 273 Mike Auty gentoo-dev 2006-05-05 00:58:14 UTC
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:)
Comment 274 Jakub Moc (RETIRED) gentoo-dev 2006-05-05 02:01:18 UTC
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.
Comment 275 Jari-Matti Mäkelä 2006-05-05 12:51:32 UTC
(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.
Comment 276 Mike Auty gentoo-dev 2006-05-05 15:28:12 UTC
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:)
Comment 277 Jakub Moc (RETIRED) gentoo-dev 2006-05-05 15:48:04 UTC
(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

Comment 278 Mike Auty gentoo-dev 2006-05-05 15:55:29 UTC
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:)
Comment 279 Jakub Moc (RETIRED) gentoo-dev 2006-05-05 16:42:55 UTC
(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>
Comment 280 Mike Auty gentoo-dev 2006-05-05 16:47:51 UTC
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:\
Comment 281 Mike Auty gentoo-dev 2006-05-05 17:18:25 UTC
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
Comment 282 Jari-Matti Mäkelä 2006-05-06 04:52:30 UTC
(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?
Comment 283 Mike Auty gentoo-dev 2006-05-06 04:58:25 UTC
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:)
Comment 284 Mike Auty gentoo-dev 2006-05-06 05:50:39 UTC
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!
 
Comment 285 Paul Kronenwetter 2006-05-06 06:24:21 UTC
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!!
Comment 286 Guillaume Castagnino 2006-05-06 06:27:40 UTC
(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 !
Comment 287 Paul Kronenwetter 2006-05-06 06:31:18 UTC
Thank you...  I didn't realize the portage overlay included eclass-type directories...  Compiling now...
Comment 288 Mike Auty gentoo-dev 2006-05-06 07:00:29 UTC
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:)
Comment 289 Gunnar Wrobel (RETIRED) gentoo-dev 2006-05-06 07:02:28 UTC
Added the overlay to layman. So you can now 

emerge layman
layman -f -a vmware

to install it.
Comment 290 Jari-Matti Mäkelä 2006-05-06 11:22:02 UTC
(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)
Comment 291 Mike Auty gentoo-dev 2006-05-06 12:11:06 UTC
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:)
Comment 292 Steven Elling 2006-05-06 13:53:06 UTC
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. [ !! ]
-----
Comment 293 Mike Auty gentoo-dev 2006-05-06 15:10:37 UTC
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);
}
Comment 294 Brendan Shanks 2006-05-06 17:39:41 UTC
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!
Comment 295 Mike Auty gentoo-dev 2006-05-07 04:35:13 UTC
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...
Comment 296 Maarten -Alexander Jongepier 2006-05-08 05:43:59 UTC
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.
Comment 297 Darren Worrall 2006-05-08 15:42:31 UTC
(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
Comment 298 Mike Auty gentoo-dev 2006-05-08 16:09:14 UTC
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:)
Comment 299 Maarten -Alexander Jongepier 2006-05-09 02:19:52 UTC
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
Comment 300 Mike Auty gentoo-dev 2006-05-09 02:29:30 UTC
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:\
Comment 301 Maarten -Alexander Jongepier 2006-05-09 06:24:08 UTC
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

Comment 302 Mike Auty gentoo-dev 2006-05-09 06:36:24 UTC
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:)
Comment 303 Darren Worrall 2006-05-09 11:07:17 UTC
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 :)
Comment 304 Mike Auty gentoo-dev 2006-05-09 13:40:11 UTC
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:)
Comment 305 Martin Berard 2006-05-10 14:15:27 UTC
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
Comment 306 Mike Auty gentoo-dev 2006-05-10 14:17:52 UTC
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:)
Comment 307 Mike Auty gentoo-dev 2006-05-10 14:35:14 UTC
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:\
Comment 308 Maarten -Alexander Jongepier 2006-05-11 02:18:26 UTC
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
Comment 309 Mike Auty gentoo-dev 2006-05-11 02:26:26 UTC
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...)
Comment 310 Maarten -Alexander Jongepier 2006-05-11 03:13:45 UTC
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....
Comment 311 Darren Worrall 2006-05-12 11:55:38 UTC
Mike, do you have any plans to work on an ebuild for the web based management package vmware provide?
Comment 312 Mike Auty gentoo-dev 2006-05-12 15:29:11 UTC
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:)
Comment 313 Alexander Skwar 2006-05-14 05:34:39 UTC
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 ~ $

Comment 314 Jakub Moc (RETIRED) gentoo-dev 2006-05-14 05:46:51 UTC
(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...
Comment 315 Alexander Skwar 2006-05-14 06:01:59 UTC
(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?
Comment 316 R. May 2006-05-14 06:37:19 UTC
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
Comment 317 Mike Auty gentoo-dev 2006-05-14 06:47:47 UTC
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:)
Comment 318 Darren Worrall 2006-05-16 10:27:39 UTC
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?
Comment 319 Darren Worrall 2006-05-16 10:29:08 UTC
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

Comment 320 Mike Auty gentoo-dev 2006-05-16 11:34:49 UTC
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)...
Comment 321 Darren Worrall 2006-05-16 11:53:54 UTC
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 ;)
Comment 322 Jeff Wiegley 2006-05-17 18:31:15 UTC
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.
Comment 323 Mike Green 2006-05-18 16:35:45 UTC
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...
Comment 324 Mike Auty gentoo-dev 2006-05-18 16:57:15 UTC
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...
Comment 325 Mike Green 2006-05-19 12:13:04 UTC
(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...
Comment 326 Jakub Moc (RETIRED) gentoo-dev 2006-05-19 12:49:12 UTC
(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.
Comment 327 Mike Auty gentoo-dev 2006-05-19 15:42:17 UTC
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:(
Comment 328 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-05-19 15:53:03 UTC
From a PAM team POV, if VMware uses PAM, it will need PAM installed in system.
Comment 329 Mike Green 2006-05-19 15:53:35 UTC
(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.
Comment 330 Mike Green 2006-05-19 15:59:14 UTC
(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...
Comment 331 Mike Auty gentoo-dev 2006-05-19 16:22:05 UTC
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...
Comment 332 Mike Green 2006-05-19 17:30:04 UTC
(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 ;)
Comment 333 devsk 2006-05-31 09:48:51 UTC
Is there a plan in place to get it into portage masked or under ~x86?
Comment 334 Mike Auty gentoo-dev 2006-05-31 16:19:20 UTC
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:)
Comment 335 Russell Knighton 2006-06-05 07:50:06 UTC
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
Comment 336 devsk 2006-06-05 09:35:39 UTC
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.
Comment 337 devsk 2006-06-05 12:50:04 UTC
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.
Comment 338 Paul de Vrieze (RETIRED) gentoo-dev 2006-06-05 13:52:46 UTC
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.
Comment 339 Russell Knighton 2006-06-06 02:00:49 UTC
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
Comment 340 Andy Romeril 2006-06-06 17:39:04 UTC
(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!
Comment 341 Andy Romeril 2006-06-06 17:41:46 UTC
(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!
Comment 342 Mike Auty gentoo-dev 2006-06-07 00:31:09 UTC
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)...
Comment 343 Mike Auty gentoo-dev 2006-06-07 14:22:17 UTC
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:)
Comment 344 Craig 2006-06-08 04:26:51 UTC
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.
Comment 345 R. May 2006-06-08 04:57:21 UTC
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?
Comment 346 Michael Weyershäuser 2006-06-08 17:11:40 UTC
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.
Comment 347 Mike Auty gentoo-dev 2006-06-08 18:02:34 UTC
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:(
Comment 348 Michael Weyershäuser 2006-06-08 18:44:31 UTC
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.
Comment 349 Michael Weyershäuser 2006-06-08 18:48:03 UTC
Created attachment 88731 [details]
new ebuild which blocks vmware-server build 24927
Comment 350 Jakub Moc (RETIRED) gentoo-dev 2006-06-09 00:29:59 UTC
(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.
Comment 351 Mike Auty gentoo-dev 2006-06-10 16:27:03 UTC
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:)
Comment 352 JG 2006-06-13 11:43:10 UTC
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)
Comment 353 Mike Auty gentoo-dev 2006-06-13 13:53:22 UTC
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:)
Comment 354 Peter Humphrey 2006-06-13 14:48:35 UTC
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"
Comment 355 Mike Auty gentoo-dev 2006-06-13 16:29:19 UTC
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:)
Comment 356 JG 2006-06-13 18:12:14 UTC
(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"
---
Comment 357 Peter Humphrey 2006-06-14 01:19:25 UTC
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.
Comment 358 Mike Auty gentoo-dev 2006-06-14 03:11:40 UTC
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:)
Comment 359 JG 2006-06-14 09:09:02 UTC
(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
Comment 360 devsk 2006-06-14 10:28:58 UTC
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.
Comment 361 Peter Humphrey 2006-06-15 09:51:33 UTC
Created attachment 89256 [details]
emerge --info on 15 Jun 2006
Comment 362 Peter Humphrey 2006-06-15 09:52:39 UTC
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.
Comment 363 Mike Auty gentoo-dev 2006-06-15 13:12:54 UTC
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:)
Comment 364 Peter Humphrey 2006-06-16 11:28:34 UTC
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.
Comment 365 Peter Humphrey 2006-06-16 11:30:32 UTC
...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.
Comment 366 JG 2006-06-18 05:36:54 UTC
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?




Comment 367 JG 2006-06-18 06:17:03 UTC
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

Comment 368 Mike Auty gentoo-dev 2006-06-18 06:21:16 UTC
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?
Comment 369 Ian Donaldson 2006-06-18 16:07:53 UTC
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.
Comment 370 JG 2006-06-18 16:18:10 UTC
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.
Comment 371 Mike Auty gentoo-dev 2006-06-19 01:57:37 UTC
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...
Comment 372 Paul de Vrieze (RETIRED) gentoo-dev 2006-06-19 02:18:08 UTC
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.
Comment 373 JG 2006-06-20 10:33:30 UTC
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?
Comment 374 Chris Gianelloni (RETIRED) gentoo-dev 2006-06-20 14:46:51 UTC
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.  ;]
Comment 375 Bertrand CHERRIER 2006-06-20 15:00:18 UTC
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.
Comment 376 Mike Auty gentoo-dev 2006-06-21 00:30:55 UTC
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:)
Comment 377 Chris Gianelloni (RETIRED) gentoo-dev 2006-06-21 07:35:45 UTC
(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.
Comment 378 Paul de Vrieze (RETIRED) gentoo-dev 2006-06-22 01:15:47 UTC
I took care of updating layman when the new repository was running properly.
Comment 379 Mike Auty gentoo-dev 2006-06-22 07:58:53 UTC
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:)
Comment 380 Peter Humphrey 2006-06-22 08:08:37 UTC
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.
Comment 381 Mike Auty gentoo-dev 2006-06-22 08:13:38 UTC
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!
Comment 382 Peter Humphrey 2006-06-23 04:33:44 UTC
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.
Comment 383 Michael Cramer 2006-06-25 11:21:03 UTC
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
Comment 384 Mike Auty gentoo-dev 2006-06-25 11:33:11 UTC
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...
Comment 385 Michael Cramer 2006-06-25 11:51:17 UTC
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
Comment 386 Mike Auty gentoo-dev 2006-06-25 12:45:09 UTC
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:)
Comment 387 Mike Auty gentoo-dev 2006-06-25 12:55:30 UTC
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:)
Comment 388 Bertrand CHERRIER 2006-06-25 14:45:45 UTC
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)
Comment 389 Mike Auty gentoo-dev 2006-06-25 15:56:49 UTC
Bizarre, still, I'm glad it's all working for you now...  5:)
Comment 390 Vic Cross 2006-06-27 09:24:27 UTC
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...
Comment 391 Vic Cross 2006-06-27 09:31:33 UTC
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.)
Comment 392 Peter Humphrey 2006-06-27 09:43:42 UTC
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.
Comment 393 Mike Auty gentoo-dev 2006-06-27 09:59:18 UTC
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:)
Comment 394 Hannes Schmidt 2006-07-09 23:13:08 UTC
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!
Comment 395 use less 2006-07-14 10:46:57 UTC
!!! 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.

Comment 396 Mike Auty gentoo-dev 2006-07-14 10:56:58 UTC
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...
Comment 397 devsk 2006-07-14 13:00:45 UTC
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?
Comment 398 Mike Auty gentoo-dev 2006-07-14 13:14:31 UTC
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...
Comment 399 namelesspirate 2006-07-17 11:16:06 UTC
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
Comment 400 Mike Auty gentoo-dev 2006-07-17 11:47:01 UTC
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.
Comment 401 Mike Auty gentoo-dev 2006-07-17 11:48:47 UTC
Sigh.  It would've helped had I not made a typo.

Bugs for SERVER go in bug 137424 (not in bug 127424).
Comment 402 Mike Auty gentoo-dev 2006-08-01 13:23:51 UTC
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:)
Comment 403 Alexander Skwar 2006-08-28 04:51:17 UTC
(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?
Comment 404 Mike Auty gentoo-dev 2006-08-28 06:27:56 UTC
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:)
Comment 405 Russell Knighton 2006-09-18 06:46:21 UTC
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.
Comment 406 Mike Auty gentoo-dev 2006-09-18 16:26:22 UTC
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:)
Comment 407 Brendan Shanks 2006-09-29 16:52:33 UTC
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 ;-)?
Comment 408 Mike Auty gentoo-dev 2006-09-29 17:00:55 UTC
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:)
Comment 409 devsk 2006-10-01 10:09:57 UTC
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.
Comment 410 Mike Auty gentoo-dev 2006-10-01 10:38:59 UTC
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:)
Comment 411 Ramon 2007-01-30 19:51:42 UTC
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 ?
Comment 412 Mike Auty gentoo-dev 2007-01-31 08:02:04 UTC
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:)
Comment 413 Mike Auty gentoo-dev 2007-03-04 20:42:14 UTC
Closing this tracker since the overlay is now only for testing.
Comment 414 NightTwix 2008-09-09 19:22:24 UTC
(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