Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 137424 - [Tracker] vmware-server ebuilds
Summary: [Tracker] vmware-server ebuilds
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo VMWare Bug Squashers [disabled]
URL: http://overlays.gentoo.org/svn/proj/v...
Whiteboard:
Keywords: Tracker
: 140819 (view as bug list)
Depends on: 141967 148612
Blocks: 122500
  Show dependency tree
 
Reported: 2006-06-20 14:33 UTC by Chris Gianelloni (RETIRED)
Modified: 2017-01-24 16:17 UTC (History)
26 users (show)

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


Attachments
Log file from the emerge (emerge.log,5.00 KB, text/plain)
2006-08-05 10:22 UTC, M. Edward Borasky
Details
emerge --info output (emerge-info.log,3.25 KB, text/plain)
2006-08-05 10:23 UTC, M. Edward Borasky
Details
log of emerge after removing the vmware overlay (emerge.log,72.05 KB, text/plain)
2006-08-05 11:18 UTC, M. Edward Borasky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Gianelloni (RETIRED) gentoo-dev 2006-06-20 14:33:44 UTC
This is the tracker bug for the vmware-player ebuilds from the vmware overlay.  This is split off to try to reduce the pressure on bug #122500 by separating out issues to specific packages.
Comment 1 Chris Gianelloni (RETIRED) gentoo-dev 2006-06-20 14:34:42 UTC
Err... vmware-server, that is...
Comment 2 JG 2006-06-21 11:56:40 UTC
An update from the amd64-hardened issue that I was discussing in the original thread. I have solved my problem - my emulation libraries were fine, but I did not have a "multilib" profile. If you are using hardened, you must be using the hardened/amd64/multilib profile as opposed to the hardened/amd64 profile. Perhaps the ebuild should produce an error if it detects that the amd64 installation does not have multilib?
Comment 3 JG 2006-06-21 13:00:18 UTC
One more thing I encountered on amd64-hardened (would apply to any hardened however), after vmware-server was running...

The file 
/opt/vmware/server/sbin/vmware-serverd requires the PAGEEXEC privilege. If you use vmware-server-console to connect, you will get an error that the perl module could not set execute privileges. By default, a PaX enabled kernel will not allow this, so you must add the following lines to /etc/conf.d/chpax

vmware="/opt/vmware/server/sbin/vmware-serverd"

and add vmware to the PAGEEXEC_EXEMPT line as follows:

PAGEEXEC_EXEMPT="${vmware}"

Comment 4 Mike Auty gentoo-dev 2006-06-25 12:42:47 UTC
Quick update, build 27828 is now in the overlay...  5:)
Comment 5 Mike Auty gentoo-dev 2006-06-27 10:18:18 UTC
Ok Vic, good catch.  Somewhere in amongst the move to using the vmware.eclass, the bit that alters the pam file stopped altering the /etc/vmware/pam.d/vmware-authd file, and start altering the /etc/pam.d/vmware-authd file.  Since that wasn't getting installed, the file was never being updated.

I've pushed that into the subversion repository now, but I *haven't* bump the revision of the ebuild.  So to test out whether it's fixed please delete /etc/pam.d/vmware-authd, delete /etc/vmware/pam.d/vmware-auth, re-emerge vmware-server and then re-run the vmware-config.pl.  Once all that's been done, please double check the file /etc/pam.d/vmware-authd and ensure it contains the /emul/linux stuff in it.  Then please report back about the pam_deny problems you seemed to be getting, and we'll look into those separately if they're still around...

I've been given very conflicting information about what pam will when a 32-bit program requests the pam libraries without a location.  Seemingly from your report, it doesn't manage to figure it out automatically, so I'll continue patching the pam file for amd64.  If anyone can give me a definitive answer over the "best" solution to this problem, please let me know and we can test it out in the next build.  Thanks!  5:)
Comment 6 Vic Cross 2006-06-27 11:09:48 UTC
G'day Mike, apologies for using the wrong bug originally...  Followed your instruction to update from svn, delete the pam config files, remerge and rerun vmware-config.pl and (sorry) the vmware-authd file has no /emul/linux paths.  As expected, login from the console fails with all modules listed as faulty.
Comment 7 Mike Auty gentoo-dev 2006-06-27 11:29:15 UTC
Yep, sorry, sorry, my bad Vic.  There was, in fact, another typo in there, so the substitution wasn't happening (and handily failed silently).  That's been fixed up now, any chance you could give it another try for me?  Thanks...  5:)
Comment 8 Vic Cross 2006-06-28 02:01:28 UTC
Revision 69 from SVN sets up /etc/pam.d/vmware-authd as required -- thanks Mike!  The message about faulty pam_deny.so still appears, but this could be some effort in tackling by the looks -- in my Copious Free Time I'll see what I can find and report (in case no-one else is actively looking).

Now to hook it up to auth off LDAP -- wish me luck...  ;)

Cheers...
Comment 9 Peter Humphrey 2006-06-28 02:23:00 UTC
Minor feature request, please Mike:

/opt/vmware/server/bin/vmware-config.pl offers to set permissions on the VM directory. That's fine, but it would be helpful if it said to what.

I suspect that it sets root:root, but I was expecting it to set root:vmware.

Once again, thanks for the sterling work to date.
Comment 10 Mike Auty gentoo-dev 2006-06-28 04:29:10 UTC
Ok, Peter, I'll check out the message and see what's going on when I get a chance.  Remember that hopefully the config script will be completely eliminated, but for the time being I'll see if I can't fix it up...  5:)
Comment 11 Nick Ellson 2006-06-28 10:55:28 UTC
What method should I be using to keep vmware-server updated? I just did the "cvs up" on it and now have 1.0.0.24927. I am unable to redo the digests because of a vmware.eclass missing error.

Before I cry bug, was this the right way to stay up to date?
Comment 12 Chris Gianelloni (RETIRED) gentoo-dev 2006-06-28 11:29:26 UTC
emerge layman
layman -f
layman -a vmware
Comment 13 Nick Ellson 2006-06-28 12:15:30 UTC
Ahh, ok...  So after doing those three, an emerge vmware-server gives a new error. Was I to fill the tree differently than svn which grabbed revision 53?

>svn co http://callisto.cs.kun.nl:81/svn/trees/vmware/app-emulation

>layman -a vmware
Checked out revision 69.
<snip>
* Successfully added overlay "vmware".

>emerge vmware-server
Calculating dependencies     ... done!
>>> Emerging (1 of 2) app-emulation/vmware-modules-1.0.0.15 to /
>>> checking ebuild checksums
!!! A file listed in the Manifest could not be found: '/usr/portage/local/layman/vmware/app-emulation/vmware-modules/vmware-modules-101-r3.ebuild'
Comment 14 Nick Ellson 2006-06-28 13:17:08 UTC
Nevermind.. I have my svn in /usr/local/portage  not in the same layman tree.
I copied it over and all started compiling. :) 

Thanks!
Comment 15 Mike Auty gentoo-dev 2006-06-28 14:07:54 UTC
Thanks Nick, you did actually spot a small bug in there, the digests for the vmware-modules ebuilds hadn't been updated since I removed the vmware-modules-101 ebuild.  That's now been taken care of...  5:)
Comment 16 Nick Ellson 2006-06-28 15:13:58 UTC
Hey Mike, 

Happy to stumble around for ya :) I've tripped again. The configure.pl script set me all up, but when it tries to start the services the vmnet0 bridge and vmnet8 nat will not start. See below:

Type XXXXX-XXXXX-XXXXX-XXXXX or 'Enter' to cancel: <yadda>

 * 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                                                                                               [ !! ]

The configuration of VMware Server 1.0.0 build-27828 for Linux for this running
kernel completed successfully.

So I try:

goonie app-emulation #  /etc/init.d/vmware restart
 * %LONGNAME% 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! 

<sigh> Now I did erase all traces of the previous install done teh old way before I used the layman approach. I only kept my VM-Host files.

Nick

Comment 17 Nick Ellson 2006-06-29 06:15:11 UTC
Ok, scanning logs after logs.. the /dev/vmmon was missing and a modprobe for vmmon fixed that... which I think would have started if the init script would run.   Sooo.. I looked into the init script and saw it checking for the existance of /etc/vmware/not_configure flag file. I had one. I deleted it. All better. :) VMware starts fine, all networking is functional, and my Win 2K domain controller is back online as a VM Guest..

Could there be a bug in the vmware-config.pl that fails to clean up that one flag file?

Nick

Nick
Comment 18 Mike Auty gentoo-dev 2006-06-29 06:25:54 UTC
Nick, unfortunately, it's very difficult to identify whether there's a bug in the flag removal since once you've identified what was going wrong, you've usually changed the various files that caused the condition.

The problem is that vmware doesn't just create a flag file and check whether it exists, but also keeps a record of the flag file having been created in the /etc/vmware/locations database.    That flag gets removed after a successful run of the vmware-config.pl file, and gets replaced if the init script fails at any point.

The vmware-config.pl won't remove that file if it doesn't exactly match what's in that database, which I think could be where the problems are arising.  The next major task that we're looking at tackling is turning that huge perl config script into a tiny little configuration section of the ebuilds, however, that task will unfortunately take us a bit of time.  I guess what I'm trying to say is that the not_configured flag bug is fairly low on our list of priorities I'm afraid...

However, having re-read your issue, the vmware init script *should* have run a modprobe on vmmon, and so you shouldn't have been having those problems.  If you run into the issue again (say after a reboot or similar), please check your dmesg logs and let me know if there are any errors concerning the module loading.  Other than that, all I can suggest is wait for us to ditch the config scripts, sorry...  5:(
Comment 19 Nick Ellson 2006-06-29 06:38:36 UTC
If you need any testers, I am more than able to toss my VMWare load and reinstall for testing purposes. The guest VM that I need can always be ported to my second server. 

The vmmon seems to have no trouble loading.. never a glitch in demesg, just in the serverd.log in /var/log/vmware.

I do not expect the not_configured issue to be addressed if your main effort is the auto install from within an ebuild script. That's the spirit of Gentoo. :)

Anyway, let me know if I can help any. 
 
Nick

Comment 20 Michael Cramer 2006-07-04 00:52:44 UTC
are there any ebuilds available for the rc2 (Build 27828)?
Comment 21 Mike Auty gentoo-dev 2006-07-04 09:55:58 UTC
Yes there are, they've been in the overlay for a couple of weeks.  Please ensure you are using the correct repository.  If you're using layman, please do the following:

layman -f
layman -d vmware
layman -a vmware

If you've got >=layman-1.0.4 it should tell you during sync that the location of the repository has changed, if you're not looking at the right one.  The latest repository is at http://overlays.gentoo.org/svn/proj/vmware/.  Hope that helps...  5:)
Comment 22 Nick Ellson 2006-07-12 15:14:50 UTC
Ok, VMWare released it out of Beta, am I the first to ask what timeline Gentoo e-build's are on? :)

Comment 23 Bertrand CHERRIER 2006-07-12 23:30:45 UTC
Running in a vmware server x86_64 (1.0.0.28343), guest OS is Gentoo x86 2.6.14-hardened-r8, a little problem with vmware-server-tools-1.0.0.28343
SVN revision 79
first I had to digest the ebuild (seemed strange)
and after the emerge command I get this error :

>>> Install vmware-server-tools-1.0.0.28343 into /var/tmp/portage/vmware-server-tools-1.0.0.28343/image/ category app-emulation
 * Installing vmdesched module
 * Installing vmhgfs module
 * Installing vmmemctl module
 * Installing vmxnet module
!!! dosbin: sbin/vmware-checkvm does not exist

!!! ERROR: app-emulation/vmware-server-tools-1.0.0.28343 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_install
  ebuild.sh, line 1013:   Called src_install
  vmware-server-tools-1.0.0.28343.ebuild, line 56:   Called die
Comment 24 Mike Auty gentoo-dev 2006-07-13 01:28:03 UTC
Hiya Bertrand, yep, that's correct.  I'm currently in the middle of creating the tools package.  I meant to mask it off so that it doesn't get used, it's NOT functional yet, and it will break your system if you try and get it going.  I've now made sure it's masked off.  Hopefully however, we'll have one in place soon.  When we do, I'll be sure to announce it on either this bug, or in the original overlay bug (or possibly both)...  5:)
Comment 25 Andy Lutomirski 2006-07-13 14:22:56 UTC
Everything works for me, except that vmware-prettify in /etc/init.d/vmware doesn't give good directions after a kernel upgrade.  Purely cosmetic, but still.  Something like "VMware is not properly configured!  If you changed kernels, remember to remerge vmware-modules" might help.

That being said, I'm still dumb for getting this wrong.
Comment 26 use less 2006-07-14 11:26:50 UTC
My problem installing results in:

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

!!! ERROR: app-emulation/vmware-modules-1.0.0.15 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_unpack
  ebuild.sh, line 711:   Called src_unpack
  ebuild.sh, line 1248:   Called vmware-mod_src_unpack
  vmware-mod.eclass, line 65:   Called unpack 'VMware-server-1.0.0-28343.tar.gz'
  ebuild.sh, line 389:   Called die

!!! failure unpacking VMware-server-1.0.0-28343.tar.gz
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! This ebuild is from an overlay: '/usr/portage/local/layman/vmware'
Comment 27 Mike Auty gentoo-dev 2006-07-14 11:36:37 UTC
Use, thank you for your report.  Please see the response I gave on 122500.  You should revert your overlay to it's original state, with the original digest, and ensure that you have fully deleted the file with the bad digest from /usr/portage/distfiles.  Once this has been done, please double check that you're not getting the file through a proxy that may have cached the bad version and redownload the file.  The digest in the overlay is correct according to the vmware main distribution site...
Comment 28 Mike Auty gentoo-dev 2006-07-14 13:21:28 UTC
Ok, following on from bug 122500 comment 392, Sunil, unfortunately that's an issue with the gentoo runscript system.  The way they work is that when start is called, gentoo remembers it (I'm not entirely certain of the location, but it *isn't* a pid file, it's literally just a file saying whether the service has been started successfully or not).  Then when you try and stop the service, it will try to recall whether the service was running or not, and it will only attempt to stop the service if it believes it is already running.

Now since we're wrapping vmware's init script, and vmware does things in stages, it's quite possible that a large number of the vmware services will start up, but that the script as a whole will fail.  When that happens, gentoo will think that the service hasn't started, whereas vmware may actually be usable.  Either way, gentoo will not allow you to stop the service until it believes it has been started successfully.

The same problem exists when trying to start a service that died, but which gentoo believes is still running.  In this circumstance however, the developers provide the "zap" method on the service, which will reset it to a not started state.  Unfortunately there's no covnerse (or none that I know of) to force a service to believe it's started ok.

So, what I'm trying to say is that there isn't a lot that we can do about it at the moment (whilst we still rely on the vmware init scripts), so you'll have to bear with us.  If you ever get in a similar situation, please run zap the service and kill all the vmware-* processes running to reset the server to a not running state.  Hopefully if the vmware initscripts haven't spotted you doing this, they wont' created the hated not_configured file, and you should be ok to just start the service up again...  5:)
Comment 29 Mike Auty gentoo-dev 2006-07-14 13:23:15 UTC
Andy, sorry it took so long to get back to you, there should now be a patch in portage to alter the failure message.  It should tell you to try recompiling your modules first, and then attempt to reconfigure the product as well.  I hope that helps...  5:)
Comment 30 Peter Humphrey 2006-07-16 06:31:36 UTC
I've just had to rebuild my system again after a power outage that fried my md-raid partitions (just before taking a backup!), and now I have new difficulties. First, layman is dropping the host name from the target URL, so I can't use that tool to manage vmware-server sources (I've lodged a fault report). Secondly, having used a Web browser to get all the files (I hope) from http://overlays.gentoo.org/svn/proj/vmware/trunk/app-emulation, installation goes ok but my serial number is rejected. Have I cocked something up? (Vmware.com's Web site won't show me my serial numbers and I can't find where to request a new one, so I'm stuck with the one I have.)

I also can't run vmware-server-console because I've no authority, even though I am in the vmware group. What's the state of auth these days?

My gcc went up to 4.1.1 during the rebuild - is that a problem too? This is a ~amd64 box.
Comment 31 Mike Auty gentoo-dev 2006-07-16 06:51:03 UTC
Hiya Peter, sorry to hear about your raid getting fried...  5:(

First off you'll need the eclasses as well as app-emulation, but if you got vmware-server emerged ok, then you've probably got those.  Second since it's now out of beta, you'll have to re-register to get licenses for the latest version, if you go to download Vmware Server from the vmware site, you should see a bit "download now" button, above that, there should be an orange "register now" button.  That should lead you to http://register.vmware.com/content/registration.html, where you can pick up your new serial number.

As to why vmware-server-console can't be started, please do ensure that you've configured it.  I know the configuration doesn't look like it actually does anything, but the console will simply fail to start (silently if done from the desktop icon) unless you configure it.  If you're having difficulty connecting to the server rather than starting the console itself, please double check your xinetd config and ensure it's set to allow from 127.0.0.1, for some reason it doesn't do hostname resolution very well, and won't figure out what localhost means, so best to put it in as 127.0.0.1...

Hopefully this will solve most of your problems, please let me know if any of them are still hanging around, and we'll see what we can do to fix them...  5:)
Comment 32 Mike Auty gentoo-dev 2006-07-17 11:46:50 UTC
Nameless, whilst we have managed to remove most of the X dependencies, unfortunately the main server executable (the bit which actually emulates the virtual machines) is still linked against several X libraries as you can see:

ikelos bin # ldd /opt/vmware/server/lib/bin/vmware-vmx
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/libm.so.6 (0xb7f10000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7f0c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7ef9000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e0d000)
        libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb7e07000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7df9000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0xb7da8000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb7d92000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb7d89000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7d81000)
        libz.so.1 => /lib/libz.so.1 (0xb7d6e000)
        libc.so.6 => /lib/libc.so.6 (0xb7c52000)
        /lib/ld-linux.so.2 (0xb7f4a000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7c4f000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7c4a000)

Whilst many of these are provided as part of the binary package, the general policy on these matters is to take the system compiled files over the binary shipped versions (not least to allow for rapid security patching of such libraries).  Since X is now modular, this should have a very small impact on your system, installing just the necessary libraries, and not the whole of X.  This is as close to a headless system as we can manage.

As it turns out, the full dependencies necessary to run the local console have not been included, and in the future we hope to strip out the local console completely.  Until then, this is the smallest set of dependencies we can provide.  I hope this answers your question...
Comment 33 Jakub Moc (RETIRED) gentoo-dev 2006-07-17 13:19:13 UTC
*** Bug 140819 has been marked as a duplicate of this bug. ***
Comment 34 Mike Auty gentoo-dev 2006-07-17 14:06:28 UTC
Just a quick note for myself, and anyone else who might happen to run into this.  Cardoe just discovered that vmware doesn't seem to bridge very will with an aliased interface, so bridging against eth0:1 will fail, whereas bridging directly against eth0 will succeed.
Comment 35 Peter Humphrey 2006-07-23 05:14:19 UTC
Hi Mike, and thanks for all the help.

I now have another problem: when I invoke vmware-server-console I find these entries in the log:

-- 
# grep "Jul 23 12:46:" /var/log/messages
Jul 23 12:46:57 wstn xinetd[8555]: START: vmware-authd pid=14046 from=192.168.129.25
Jul 23 12:46:57 wstn vmware-authd[14046]: PAM unable to dlopen(/lib/security/pam_deny.so)
Jul 23 12:46:57 wstn vmware-authd[14046]: PAM [error: /lib/security/pam_deny.so: wrong ELF class: ELFCLASS64]
Jul 23 12:46:57 wstn vmware-authd[14046]: PAM adding faulty module: /lib/security/pam_deny.so
Jul 23 12:46:57 wstn vmware-authd[14046]: login from 192.168.129.25 as prh
Jul 23 12:46:57 wstn xinetd[8555]: EXIT: vmware-authd status=0 pid=14046 duration=0(sec)
Jul 23 12:46:57 wstn xinetd[8555]: START: vmware-authd pid=14047 from=192.168.129.25
Jul 23 12:46:57 wstn vmware-authd[14047]: PAM unable to dlopen(/lib/security/pam_deny.so)
Jul 23 12:46:57 wstn vmware-authd[14047]: PAM [error: /lib/security/pam_deny.so: wrong ELF class: ELFCLASS64]
Jul 23 12:46:57 wstn vmware-authd[14047]: PAM adding faulty module: /lib/security/pam_deny.so
Jul 23 12:46:57 wstn vmware-authd[14047]: login from 192.168.129.25 as prh
Jul 23 12:46:57 wstn xinetd[8555]: EXIT: vmware-authd status=0 pid=14047 duration=0(sec)
-- 

I find myself logged-in ok, and the WinXP client runs happily from localhost, but when I try to get Win to see the host's samba shares it always either can't see the SMB network or tells me I'm not authorised to connnect to it. I'm not an expert in samba config, but any plausible set of parameters results in these failures, and I wonder if the wrong-ELF-class errors above are at the root of it. As I said last time, I'm unsure these days of the state of auth in vmware-server. I checked the things you said last time, and the only only_from lines I can see are:

-- 
# grep -r only_from /etc/* | grep -v "#"
/etc/xinetd.conf:       only_from       = 192.168.0.0/16
/etc/xinetd.d/swat:     only_from       = localhost
-- 


(Reminder: this is a dual-Opteron box running ~amd64.)

PS: I changed the swat line to read the same as the one above and reloaded samba, but it made no difference.
Comment 36 Mike Auty gentoo-dev 2006-07-23 05:26:24 UTC
Hi Peter, I'm not certain about the samba configuration.  I don't think the vmware configuration will be affecting samba between the two hosts.

The wrong ELF class issues are a bit worrying, however.  I'd suggest posting your /etc/pam.d/vmware-authd file here (it should be very short) and we can try and see what the problem is.  My guess is that one of the lines still points to /lib/security/ rather than /lib/emul-somethingorother/someotherstuff/security.  Since vmware is all 32-bit, it will have to use the 32 bit version of PAM.  We've tried to set this up automatically for you, but it's possible we haven't got it quite right yet...

That module shouldn't be causing you networking problems between the two, however.  The best suggestion I have is to check how it's networked and ensure you can ping the other machine, then ensure you can see the samba ports, then check the samba logs etc.  If you really think it's a vmware problem, check the permissions on /dev/vmnet* and ensure that the vmware group can read and write to those (which allows for raw/promiscuous mode on the network interface, which the internal samba may require?).  Sorry I can't be of more help, but I doubt vmware is the root of this problem...
Comment 37 shimi 2006-07-23 08:25:14 UTC
When trying to emerge vmware-server, I get a SECURITY VIOLATION. See example:

# layman -s vmware
* Running command "/usr/bin/svn update /usr/portage/local/layman/vmware"...
At revision 86.
* Successfully synchronized overlay "vmware".
# emerge vmware-server vmware-modules
Calculating dependencies ...done!
>>> emerge (1 of 2) app-emulation/vmware-modules-1.0.0.15 to /
!!! Security Violation: A file exists that is not in the manifest.
!!! File: files/digest-vmware-modules-1.0.0.14


# emerge --info
Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.17-gentoo x86_64)
=================================================================
System uname: 2.6.17-gentoo x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.14
dev-lang/python:     2.4.2
dev-python/pycrypto: [Not Present]
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
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
sys-devel/gcc-config: 1.3.12-r6
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/vmware"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X a52 aac acpi alsa apache2 arts audiofile avi berkdb bidi bitmap-fonts borbis bzip2 calendar cdparanoia cdr cli cups curl dga directfb divx4linux dri dv dvb dvd dvdr dvdread eds emboss encode esd ethereal evo exif expat fam fbcon ffmpeg flash foomaticdb fortran ftp gd gdbm geoip gif glut gmp gpm gps gstreamer gtk gtk2 iconv icq idn imagemagick imap imlib innodb ipv6 isdnlog jpeg kde kdeenabelfinal kerberos lcms logitech-mouse lzw lzw-tiff mad memlimit mng mono motif mp3 mpeg msn mysql ncurses nls nptl ogg opengl pam pcre pdflib perl php png posix ppds pppd pri python qt quicktime readline reflection ruby samba scanner sdl session snmp sockets spell spl sqlite ssl svg symlink tcltk tcpd theora tidy tiff tokenizer truetype truetype-fonts type1-fonts udev unicode usb v4l vcd vhosts videos vorbis xine xinerama xml2 xorg xpm xv xvid zlib video_cards_nv video_cards_nvidia video_cards_vesa input_devices_keyboard input_devices_mouse userland_GNU kernel_linux elibc_glibc"
Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Comment 38 Mike Auty gentoo-dev 2006-07-23 08:30:56 UTC
Thanks for the report Shimi, it was an old file that isn't necessary and should now be fixed in the overlay...  5:)
Comment 39 shimi 2006-07-23 08:35:11 UTC
Thanks - Now works! :)
Comment 40 Peter Humphrey 2006-07-23 08:56:22 UTC
Hi Mike,

-- 
$ cat /etc/pam.d/vmware-authd
#%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    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
-- 

So that isn't it. On looking at samba more closely, I find from its emerge log that the module rpctorture fails to build. I can easily imagine that that could be a problem for SMB networking, so I'd better follow it up there.
Comment 41 Mike Auty gentoo-dev 2006-07-23 09:09:47 UTC
Ok Peter, it looks as though one of the default is leaking through, and hence the 64-bit library is trying to be invoked, rather than the 32-bit one.  Either way that doesn't seem to be causing you trouble.  Good luck trying to track down your samba problems, and gimme a shout if I can help at all...  5:)
Comment 42 shimi 2006-07-23 09:13:07 UTC
Not sure if it's related to this bug, but...

Now I am having a trouble accessing the installed VMware server with my VMWare Server Console (which works against other computers...). I see the following in /var/log/everything/current:

Jul 23 18:57:43 [xinetd] START: vmware-authd pid=24957 from=127.0.0.1
Jul 23 18:57:43 [xinetd] FAIL: vmware-authd address from=127.0.0.1
Jul 23 18:57:43 [xinetd] EXIT: vmware-authd status=0 pid=24957 duration=0(sec)

And the VMWare Server Console just hangs (and consumes 99.9% CPU) and has to be manually killed (I waited a few minutes to no avail...). strace on the console pid says that it does the following two calls in a loop:
time(NULL)                              = 1153671080
read(17, "", 1)                         = 0

I already tried various tips on the net (the xinetd file doesn't have only_from localhost and I am using localhost anyways, trying symlinking the files suggested at http://gentoo-wiki.com/HOWTO_Install_VMWare_Server as I am an AMD64 user, to no avail...)

My emerge --info is at Comment #37.

help? :)
Comment 43 Mike Auty gentoo-dev 2006-07-23 09:18:24 UTC
Shimi, please try using 127.0.0.1 rather than localhost, and be sure to add a line to your /etc/xinetd.d/vmware-authd file saying "only_from 127.0.0.1".  This will override any possible entries in xinetd.conf, and also uses direct IP addresses which should avoid any problems associated with name lookups.  Don't forget to restart xinetd to ensure it picks up the new settings.

If this still fails, please test your console against another server if possible, and test another console against your server.  If it succeeds, then it is in fact an xinetd problem (which is what I'm betting on) and you'll have to double check your settings to get them the way you want them.

If you get confusing results at all, post them here and we'll try and figure them out (or you can ask me on #gentoo-dev and we can try and sort it out in real time if you'd like)...
Comment 44 shimi 2006-07-24 02:52:59 UTC
Surprisingly, adding that line helped (how can limiting something help removing a limit - is beyond me).

It's important to note that I did _not_ have xinetd before that VMWare installation, which means that I'm probably using stock options of xinetd (didn't change anything), which I guess means that you must add that line to the stock ebuild of VMWare?

Up to you... :)

Thanks!
Comment 45 Mike Auty gentoo-dev 2006-07-24 04:43:50 UTC
Hi Shimi, yep xinetd is a pain.  It defaults to the outer xinetd.conf settings, and then individual files override it.  Also, it's caught other people out that it doesn't handle localhost very well.  There is an einfo at the end of the vmware-server installation mentioning that users should set an appropriate only_from line in /etc/init.d/vmware-authd.  It's unfortunately about the best we can do.  Sorry!
Comment 46 Mike Auty gentoo-dev 2006-08-01 13:21:45 UTC
Well, not 10 seconds ago I finally unmasked the ~x86 and ~amd64 versions of vmware-server and vmware-server-console in the main portage tree!  Hurray!  5:)

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 47 Alon Bar-Lev gentoo-dev 2006-08-05 00:46:32 UTC
Please consider adding the following to /etc/services at baselayout:
---
vmware-authd 902/tcp
---

So that vmware-config.pl will not modify this file by-itself.
The script will not change the /etc/services if it find a correct line there.
Comment 48 Mike Auty gentoo-dev 2006-08-05 05:38:32 UTC
Alon, hopefully in the future we'll be able to eliminate the perl configuration and init scripts, and do everything in a much more gentoo-ish type way.  Unfortunately that isn't possible at the moment, and the perl configuration script has always modified /etc/services.  It's unfortunate, but there's little that we can easily do about it at the moment, and it's quite low on our list of priorities at the moment.

Simply adding it to baselayout isn't a solution, since I believe it's required by xinetd to perform lookups, and if the user decides to set a different port for vmware-authd, the service file will still need to be edited.  Sorry we can't fix it at the moment, hopefully it's not too much of an inconvenience.
Comment 49 Alon Bar-Lev gentoo-dev 2006-08-05 05:50:09 UTC
(In reply to comment #48)
> Alon, hopefully in the future we'll be able to eliminate the perl configuration
> and init scripts, and do everything in a much more gentoo-ish type way. 

Yes, I hope so too.

> Unfortunately that isn't possible at the moment, and the perl configuration
> script has always modified /etc/services. 

No... The vmware-workstation did not have /etc/services entry... So it is a new issue (as far as I know).

I don't know there is a gentoo-ish type of handling /etc/services... The current approach is to add all known services into baselayout...

I can imagine the solution... Putting /etc/services.d, and using update-services script in order to build /etc/services... But it was not implemented so far.

> Simply adding it to baselayout isn't a solution, since I believe it's required
> by xinetd to perform lookups, and if the user decides to set a different port
> for vmware-authd, the service file will still need to be edited. 

That's true... For vmware AND other services listed at /etc/services.
Current approach is to put the default into baselayout. If the user touches the file by him-self he will install the prober mechanism (such as remarks) in order to merge it into new versions of baselayout.

> Sorry we can't fix it at the moment, hopefully it's not too much of an inconvenience.

It is not too much of inconvenience... But I thought you may want to fix this... As done with many other known services in the system.

Regards.
Comment 50 M. Edward Borasky 2006-08-05 09:03:59 UTC
Something's not quite right with the latest vmware-server ebuild:

DreamSong ~ # emerge -pv vmware-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-emulation/vmware-server-1.0.0.28343  0 kB 

Total size of downloads: 0 kB

It installed with no complaints, however:

***
 * Updating /etc/vmware/locations

 * You need to run 
 *     /opt/vmware/server/bin/vmware-config.pl
 * to complete the install.

DreamSong ~ # /opt/vmware/server/bin/vmware-config.pl
-su: /opt/vmware/server/bin/vmware-config.pl: No such file or directory
DreamSong ~ # 
Comment 51 Mike Auty gentoo-dev 2006-08-05 09:21:10 UTC
Hrmmmm, that is a bit strange, could you please make sure you have portage-utils installed, and then attach the output of "qlist vmware-server"?  That should tell us what files were installed by vmware-server, and we can start working from there...
Comment 52 M. Edward Borasky 2006-08-05 09:49:47 UTC
(In reply to comment #51)
> Hrmmmm, that is a bit strange, could you please make sure you have
> portage-utils installed, and then attach the output of "qlist vmware-server"? 
> That should tell us what files were installed by vmware-server, and we can
> start working from there...
> 

DreamSong ~ # emerge -pv portage-utils

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-portage/portage-utils-0.1.18  USE="python" 0 kB 

Total size of downloads: 0 kB
DreamSong ~ # qlist vmware-server
/etc/vmware/init.d
/etc/vmware/locations
/usr/bin/vmware
/usr/share/applications/vmware-server-console-vmware-server-console.desktop
/usr/bin/vmware-server-console
DreamSong ~ # 
Comment 53 Mike Auty gentoo-dev 2006-08-05 09:53:53 UTC
Ok, that means something went badly, *badly* wrong with the install.  5:(  Could you please attach the complete output of "emerge vmware-server" and post the output of  "emerge --info"...
Comment 54 M. Edward Borasky 2006-08-05 10:22:38 UTC
Created attachment 93520 [details]
Log file from the emerge
Comment 55 M. Edward Borasky 2006-08-05 10:23:17 UTC
Created attachment 93521 [details]
emerge --info output
Comment 56 M. Edward Borasky 2006-08-05 10:24:49 UTC
Bad ebuild??
Comment 57 Mike Auty gentoo-dev 2006-08-05 10:32:05 UTC
Ok, it looks as though you're missing the vmware.eclass file.  Please check that it's present in /usr/portage/eclass/, and that you're not using any overlays that may overwrite it (ie. double check that your vmware overlay is up to date).  vmware_src_install was previously called something else, so if you've been updating you vmware ebuilds manually and haven't updated the eclass, that could cause this problem.  Note also that eclasses in overlays take precedence over eclasses in portage, so my best suggestion is either to remove the vmware overlay, or ensure it's fully up-to-date.  If that solves it, then just drop a short note here so we know that was the problem.  Thanks...  5:)
Comment 58 M. Edward Borasky 2006-08-05 11:17:19 UTC
Well ...

Step 1: Removed the vmware overlay from /usr/portage/local/layman/make.conf
Step 2: emerge --sync
Step 3: emerge -v vmware-server
Step 4: stand back

Comment 59 M. Edward Borasky 2006-08-05 11:18:05 UTC
Created attachment 93527 [details]
log of emerge after removing the vmware overlay
Comment 60 Mike Auty gentoo-dev 2006-08-05 11:26:22 UTC
Ok, believe it or not, it's looking much healthier now, all the files are being put in place (as you can see), so now all we have to do is deal with that pesky error at the end.  Please move your /etc/vmware directory to some place else, just in case portage is trying to make a directory on top of a file or something like that.  Then give it another go.  If you get the same error, then perhaps it might be worth filing a separate bug with the portage people (since all the parts relating to the ebuild seemed to complete successfully this time)...
Comment 61 M. Edward Borasky 2006-08-05 12:26:59 UTC
(In reply to comment #60)
> Ok, believe it or not, it's looking much healthier now, all the files are being
> put in place (as you can see), so now all we have to do is deal with that pesky
> error at the end.  Please move your /etc/vmware directory to some place else,
> just in case portage is trying to make a directory on top of a file or
> something like that.  Then give it another go.  If you get the same error, then
> perhaps it might be worth filing a separate bug with the portage people (since
> all the parts relating to the ebuild seemed to complete successfully this
> time)...
> 


It's now up and running! I need to clean up my virtual machine now, but the server is OK.
Comment 62 bugz.ads 2006-08-08 20:53:23 UTC
# emerge --search vmware-server
Searching...
[ Results for search key : vmware-server ]
[ Applications found : 0 ]

this is an amd64 box i have with 2.6.x gentoo.  do i need to do anything else to get to this ebuild ?
Comment 63 Mike Auty gentoo-dev 2006-08-09 02:38:15 UTC
Not that I can think of.  Give it an emerge --sync, ensure you've added ~amd64 to your accepted keywords (either globally or just for app-emulation/vmware-server using /etc/portage/package.keywords).  Then it should emerge.  I dunno whether the search function ignores packages that can't be installed (and hence the ~amd64 is causing it to be hidden).  You can check if the files are there by going into /usr/portage/app-emulation/vmware-server and see if you can see the ebuild...
Comment 64 bugz.ads 2006-08-09 12:15:36 UTC
Yup, that seems to work with emerge.

However here is a problem which i get while configuring vmnet using vmware-config.pl

# /opt/vmware/server/bin/vmware-config.pl
Making sure services for VMware Server are stopped.

 * Stopping VMware Server ...
   Virtual machine monitor                                             done
   Bridged networking on /dev/vmnet0                                   done
   DHCP server on /dev/vmnet1                                          done
   Host-only networking on /dev/vmnet1                                 done
   Virtual ethernet                                                    d  [ ok ]
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?
(yes/no) [no] no

Do you want networking for your virtual machines? (yes/no/help) [yes]

Would you prefer to modify your existing networking configuration using the
wizard or the editor? (wizard/editor/help) [wizard]

The following bridged networks have been defined:

Do you wish to configure another bridged network? (yes/no) [no]

Do you want to be able to use NAT networking in your virtual machines? (yes/no)
[yes] no

Do you want to be able to use host-only networking in your virtual machines?
[no] yes

Configuring a host-only network for vmnet1.

The host-only network is currently configured to use the private subnet
172.16.249.0/255.255.255.0.  Do you want to keep these settings? [yes]

The following host-only networks have been defined:

Do you wish to configure another host-only network? (yes/no) [no]

Please specify a port for remote console connections to use [902]

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.

Do you want this program to set up permissions for your registered virtual
machines?  This will be done by setting new permissions on all files found in
the "/etc/vmware/vm-list" file. [no]

Generating SSL Server Certificate

In which directory do you want to keep your virtual machine files?
[/home/vmware/vmachines]

Do you want to enter a serial number now? (yes/no/help) [no]

 * Starting VMware Server ...
   Virtual machine monitor                                             done
   Virtual ethernet                                                    done
Module vmnet is not loaded.  Please verify that it is loaded before
running this script.
                                                                          [ ok ]
The configuration of VMware Server 1.0.0 build-28343 for Linux for this running
kernel completed successfully.


any insight ?



(In reply to comment #63)
> Not that I can think of.  Give it an emerge --sync, ensure you've added ~amd64
> to your accepted keywords (either globally or just for
> app-emulation/vmware-server using /etc/portage/package.keywords).  Then it
> should emerge.  I dunno whether the search function ignores packages that can't
> be installed (and hence the ~amd64 is causing it to be hidden).  You can check
> if the files are there by going into /usr/portage/app-emulation/vmware-server
> and see if you can see the ebuild...
> 

Comment 65 Mike Auty gentoo-dev 2006-08-09 12:50:24 UTC
Ok, please double check that your vmware-modules is installed, and that the running kernel is also the whose source directory you've symlinked to /usr/src/linux.  If you've symlinked in a different kernel, it will have built the modules for that one, and hence not been able to load them for the current kernel.  If all that's ok, then get back to me and we'll investigate it some more...  5:)
Comment 66 bugz.ads 2006-08-09 13:00:35 UTC
Hmmm.... seems like the things you mention are in place...

# uname -a
Linux tyan-e 2.6.15-gentoo-r4 #8 SMP Thu Mar 30 18:20:47 PST 2006 x86_64 Dual Core AMD Opteron(tm) Processor 265 AuthenticAMD GNU/Linux

# ls -l /usr/src
total 50836
lrwxrwxrwx   1 root root       22 Mar  9 15:16 linux -> linux-2.6.15-gentoo-r4
drwxr-xr-x  20 root root     4096 Apr 28 18:18 linux-2.6.15-gentoo-r4
drwxr-xr-x  20 root root     4096 Aug  3 15:15 linux-2.6.16-gentoo-r12
-rw-r--r--   1 root root 51985790 Aug  3 13:55 linux-sources-2.6.16-r12.tar.gz
drwxr-xr-x   7 root root     4096 Apr 21 22:19 pc

# emerge --search vmware-modules
Searching...
[ Results for search key : vmware-modules ]
[ Applications found : 1 ]

*  app-emulation/vmware-modules
      Latest version available: 1.0.0.15
      Latest version installed: 1.0.0.15
      Size of downloaded files: 308,490 kB
      Homepage:    http://www.vmware.com/
      Description: Modules for Vmware Programs
      License:     vmware


(In reply to comment #65)
> Ok, please double check that your vmware-modules is installed, and that the
> running kernel is also the whose source directory you've symlinked to
> /usr/src/linux.  If you've symlinked in a different kernel, it will have built
> the modules for that one, and hence not been able to load them for the current
> kernel.  If all that's ok, then get back to me and we'll investigate it some
> more...  5:)
> 

Comment 67 Mike Auty gentoo-dev 2006-08-09 13:04:51 UTC
Ok, please stop the vmware service, ensure that no vmnat/dhcp/whatever services are running and then lsmod and ensure that both vmmon and vmnet are unloaded.  Then please try to manually load vmmon and vmnet using modprobe.  If they fail please report the error message here, if they don't please unload the modules and attempt to start the service, if it fails again stop the service, kill off all the vmwhatever processes, manually modprobe the two modules in and start the service again.  This will help determine whether the modules can be loaded ok, and whether the service is having difficulty loading them, or fails even once they've been loaded already... 
Comment 68 bugz.ads 2006-08-09 14:14:43 UTC
ok, so i can finally get it to start (with some similar to steps to an earlier comment about vmmon and vmnet)

1) /etc/init.d/vmware stop
2) rm /etc/vmware/not_configured
3) modprobe vmnet
4) modprobe vmmon
5) /etc/init.d/vmware start

It seems that without 3 and 4 the service is unable to start.

However, now I am into the (oft-reported) console and server hangs issue

strace on the vmware-serverd (with ~99% usage) shows innumerable
read(29, "", 1)                         = 0
time(NULL)                              = 1155157971

i am using IP addresses in vmware_authd - only_from tag
any ideas ?
Comment 69 Mike Auty gentoo-dev 2006-08-09 14:18:23 UTC
Ok, it'd be interesting to find out why steps 3 and 4 aren't working, the service should be running modprobe for you when it starts.  Please double check that you've run etc-update, and then please grep /etc/vmware/init.d/vmware for modprobe.  If it's not in there then one of the patches failed to apply.  If it is, then something even weirder is going on...

As to the hang, if you're definitely using IP addresses in the only_from line, and the only_from line is in /etc/xinetd.d/vmware-authd and not just the global /etc/xinetd.conf, and you're attemping to connect to the server from that valid IP address, and asking it for it using the valid IP of the server, then I've got *no* idea I'm afraid...  5:(
Comment 70 bugz.ads 2006-08-09 14:38:33 UTC
1)

# grep -inR modprobe /etc/init.d/vmware
572:      /sbin/modprobe parport || eend 1
576:      /sbin/modprobe parport_pc || eend 1
588:   /sbin/modprobe -r parport_pc
589:   /sbin/modprobe -r parport
638:         /sbin/modprobe parport_pc >/dev/null 2>&1
713:         /sbin/modprobe -r parport_pc >/dev/null 2>&1


2)

hmm - then i will just wait for another update and try this one on another a different server.

Thanks for the help.


(In reply to comment #69)
> Ok, it'd be interesting to find out why steps 3 and 4 aren't working, the
> service should be running modprobe for you when it starts.  Please double check
> that you've run etc-update, and then please grep /etc/vmware/init.d/vmware for
> modprobe.  If it's not in there then one of the patches failed to apply.  If it
> is, then something even weirder is going on...
> 
> As to the hang, if you're definitely using IP addresses in the only_from line,
> and the only_from line is in /etc/xinetd.d/vmware-authd and not just the global
> /etc/xinetd.conf, and you're attemping to connect to the server from that valid
> IP address, and asking it for it using the valid IP of the server, then I've
> got *no* idea I'm afraid...  5:(
> 

Comment 71 Mike Auty gentoo-dev 2006-08-09 15:02:47 UTC
Ok, from part 1, it looks as though you're using an old vmware init script.  The current one should give you the following results:

$ grep -inR modprobe /etc/vmware/init.d/vmware
578:   /sbin/modprobe -s -f "$1" || exit 1
603:      /sbin/modprobe parport || exit 1
607:      /sbin/modprobe parport_pc || exit 1
619:   /sbin/modprobe -r parport_pc
620:   /sbin/modprobe -r parport
891:         /sbin/modprobe parport_pc >/dev/null 2>&1
989:         /sbin/modprobe -r parport_pc >/dev/null 2>&1

So please double check your installation, ensure you're not getting it from any unusual overlays, etc or even try a re-install (also remember to etc-update or dispatch-conf to update the init file)...  5:)
Comment 72 Peter Humphrey 2006-08-23 05:15:42 UTC
Hello Mike,

Today I sync'ed and was offered upgrades for vmware-server and the console, but on attempting the server upgrade I got:

-- 
!!! Missing digest for 'vmware-any-any-update101.tar.gz'
-- 
Comment 73 Mike Auty gentoo-dev 2006-08-23 10:44:38 UTC
Hiya Peter,

Yeah, that's a known problem (see bug 139134), that Zac Medico's very kindly working on as we speak!  5:)  I had thought I'd been through and updated all of the ebuilds to force the cache to fix itself, but seemingly that didn't help.  This was also originally reported as bug 143289, but that's since been marked as a duplicate of 139134, so I'd suggest you follow that one for now.  Sorry it's not been quite as smooth as we'd hoped...
Comment 74 devsk 2006-08-24 10:41:11 UTC
I am not sure why but everytime I install the vmware-server and run config.pl, my /etc/vmware/locations file keeps expanding with duplicate entries. Does anybody knwo why?

$ wc -l /etc/vmware/locations
1157 /etc/vmware/locations

$ cat /etc/vmware/locations |sort |uniq | wc -l
1122
Comment 75 Mike Auty gentoo-dev 2006-08-24 10:53:35 UTC
Yes, although it's a bit of legacy code and I'm going to be explaining this from memory so it might not be *quite* right...  Since /etc/vmware/locations is technically in the CONFIG_PROTECTED part of the system, if we try to put the new locations file in there, we risk someone not updating it, and then vmware getting confused about starting etc.

So we rather dirtily read all the entries out of the new locations file and tack them onto the end of the old locations file.  This shouldn't have too much of a detrimental effect (since it should only grow by one install list each time) and it ensures that all your previous settings are saved.  If we completely overwrote the file, you'd lose certain network configuration settings and other bits and pieces you'd miss.

This is unfortunately a problem that's going to have to wait until we manage to completely remove all the perl scripts from our vmware setup, and that could take a while.  Hope that explains it a bit better...
Comment 76 Peter Humphrey 2006-09-27 09:16:48 UTC
In comment 30 I said my GCC had been upgraded. I was mistaken - the new version had been installed, but the system was still using the older 3.4.4. Today, however, I /am/ upgrading GCC. The ABI has changed, I understand, so the entire system has to be rebuilt with emerge -e system and emerge -e world. I've finished the first and started the second, and I'm recompiling the kernel too at the same version (2.6.18).

Am I going to run into problems when I remerge vmware-server? I thought I'd seen some discussion of gcc-4.1.1 and vmware, but if so I can't find it now.
Comment 77 Mike Auty gentoo-dev 2006-09-27 09:44:28 UTC
Hiya Peter,

The short answer is No, you should be fine.

The longer answer is that since vmware's all precompiled anyway you shouldn't run into any problems with that.  The main issue is with the kernel modules (which are compiled).  The kernel modules require that they're built with the same compiler as the kernel was (which is easy to do), but they also feature a couple of tests to determine how to build the system on linux.  They basically have small programs that they try to compile for each feature, and if the feature isn't present they provide a warning.  The vmware tests upgrade the warning to a build error and then check to see if the small program compiled.  Unfortunately gcc-4.1 feature much stricter checking of some issues and reports *more* warnings than just those expected by vmware.  These also get turned into build errors and hence mess up the tests.

The newer kernels (>=2.6.17) seem to have been checked to ensure they don't throw any additional errors under gcc-4.1, and the newer modules (vmware-any-any104 and vmware-server's modules) don't have an issue with them.  Unfortunately older kernels still cause gcc to throw some additional errors, and there's an extra patch I need to add into vmware-modules-1.0.0.13 that I've been particularly slow about dealing with unfortunately...  5:(

In summary, if you're with a newer (>=2.6.17) kernel, and using gcc-4.1, everything should work perfectly.  Hope that helps (in a long winded kind of a way)...  5:)
Comment 78 Peter Humphrey 2006-09-27 15:14:59 UTC
Ok, thanks Mike. Sorry to have disturbed you. For some reason I thought I'd run into problems, but so far I haven't. I'm on kernel 2.6.18-gentoo and the emerge -e world is under way. I'll go back to sleep now...

Comment 79 Mike Auty gentoo-dev 2006-09-27 15:43:39 UTC
Anytime Peter!  I particularly enjoy the comments where all I have to do is write back, you make my job easy!  5:)
Comment 80 Peter Humphrey 2007-02-08 16:20:40 UTC
Hello Mike,
   I've stumbled over another problem. After some hardware failures recently I had to rebuild my Gentoo box. I had a copy of the virtual machines, so I copied it into place for the new vmware-server to pick up. Now the XP client runs just fine except for one thing: it can't download Windows updates. Other network traffic works as it should, just the one operation fails: fetching the updates to install. It wants to fetch 26 updates, but it can't get them.
   Watching network traffic in gkrellm, I don't see anything on any connection while this is going on, and the route out through my firewall box has not changed as far as I know. The blockage seems to be in the bridged connection between the virtual XP machine and the external eth0 of its Gentoo host.
   I have reinstalled VMware tools, and that helped with some things but not this one. Any ideas?
Comment 81 Mike Auty gentoo-dev 2007-03-04 20:40:09 UTC
Ok, I'm going to close this bug, since the overlay is now only for testing.