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.
Err... vmware-server, that is...
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?
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}"
Quick update, build 27828 is now in the overlay... 5:)
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:)
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.
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:)
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...
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.
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:)
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?
emerge layman layman -f layman -a vmware
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'
Nevermind.. I have my svn in /usr/local/portage not in the same layman tree. I copied it over and all started compiling. :) Thanks!
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:)
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
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
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:(
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
are there any ebuilds available for the rc2 (Build 27828)?
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:)
Ok, VMWare released it out of Beta, am I the first to ask what timeline Gentoo e-build's are on? :)
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
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:)
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.
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'
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...
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:)
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:)
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.
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:)
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...
*** Bug 140819 has been marked as a duplicate of this bug. ***
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.
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.
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...
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
Thanks for the report Shimi, it was an old file that isn't necessary and should now be fixed in the overlay... 5:)
Thanks - Now works! :)
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.
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:)
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? :)
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)...
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!
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!
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:)
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.
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.
(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.
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 ~ #
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...
(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 ~ #
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"...
Created attachment 93520 [details] Log file from the emerge
Created attachment 93521 [details] emerge --info output
Bad ebuild??
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:)
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
Created attachment 93527 [details] log of emerge after removing the vmware overlay
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)...
(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.
# 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 ?
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...
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... >
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:)
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:) >
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...
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 ?
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:(
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:( >
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:)
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' --
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...
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
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...
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.
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:)
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...
Anytime Peter! I particularly enjoy the comments where all I have to do is write back, you make my job easy! 5:)
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?
Ok, I'm going to close this bug, since the overlay is now only for testing.
