On a slightly better note. The beta 4 seems to address the issues I had while configuring and running vmware. It still doesn't like the compiler but it will let you continue to use it. At least this time the 'bug' in the compiler test is gone (or dormant.) There is still the RedHat centric setup but that is easy to get around. I still haven't found out yet if it's devfsd friendlier either. My setup still saves the old devfs entries. The only real problem for me is justifying the upgrade.
]]>IMHO, the big problem with vmware 3.x (and perhaps 4) is it's RedHat centric. Even the install and daemon scripts don't like other environments. The configuration doesn't support gcc 3.x but it has a bug so the modules still compile on AL (mine defaults to 486 code though.) The other problem I have is it's not really devfsd friendly. Unless you plan on creating the device entries every boot or use the devfsd save option vmware thinks it's not properly configured.
]]>You might try re-installing from the tarball although I don't know how much difference this will make. Unfortunately, there is no uninstall option for the non-rpm install method.
Yes. I try it but no success.
FWIW, the init hacks mentioned in the other vmware install text are simply to fool the installer. IIRC, the config never touches them at any later date. All vmware needs for proper operation is the daemon run at startup and properly compiled modules. With this in mind, it might be possible to create a pacman PKGBUILD file than can install the program. This is simply an excercise in logic as they are developing version 4 which is in beta release right now.
Ok. to wait the v.4.
I solved the problem compiling the "q.c" (previus post) and work fine.
Tanks and sorry for my orrible english.
You might try re-installing from the tarball although I don't know how much difference this will make. Unfortunately, there is no uninstall option for the non-rpm install method.
FWIW, the init hacks mentioned in the other vmware install text are simply to fool the installer. IIRC, the config never touches them at any later date. All vmware needs for proper operation is the daemon run at startup and properly compiled modules. With this in mind, it might be possible to create a pacman PKGBUILD file than can install the program. This is simply an excercise in logic as they are developing version 4 which is in beta release right now.
]]>I haven't played with my vmware much on a running AL system although I use it for running tests with AL on another system. Anyhow, did you try re-running the vmware-config program just to see if rebuilding the modules helps?
Yes. re-running the vmware-config.
vmware start "for little moments" and crash.
But i have found this doc:
http://groups.google.com/groups?hl=it&l … schman.org
I do not know like compiling. Need help.
Try re-installing gtk2 and pango again.
# pacman -Sy pango gtk2
Yes!!! Now work fine, only "vmware" not work.
]]># pacman -Sy pango gtk2
try upgrading again - make sure you get xfree86 4.3 with the upgrade; the latest gtk2.2 and pango packages should play with that.
Yes is ok.
Also, try running fc-cache -f -v as root, and deleting ~/.fc-cache as your user.
No the problem remain.
The "~/.fc-cache" is not present.
tanks.
Also, try running fc-cache -f -v as root, and deleting ~/.fc-cache as your user.
]]>2. The vmware start error:
$ vmware
XIO: fatal IO error 0 (Success) on X server ":0.0"
after 3797 requests (3796 known processed) with 27 events remaining.
someone has some idea. Tanks for help
]]>