GUI doesn't show after upgrade
Is it necessary to copy the missing libraries to /usr/lib/vmware/lib/? I think it will be better to use soft links.
I just wanted to record that the workaround listed here (export LD_LIBRARY_PATH...) does actually resolve the problem for Workstation 11.1.3 (I'm running on a 4.4.1 Kernel)
I agree that the solution is not easily confirmed (I've read /usr/bin/vmware and there's nothing obvious why LD_LIBRARY_PATH is required) - but that's probably an issue to be taken to VMware, rather than reported in depth here.
This workaround is not easily found on the rest of the internet and I have been struggling to get this working for a while (on & off..), so it is definitely a good idea to keep this section here.
- Hi, I have this same issue with vmware where the GUI won't show, but If I try the trick in this section of the wiki, it tells me modules have to rebuild, but nothing happens after https://wiki.archlinux.org/index.php/VMware#GUI_doesn.27t_show_after_upgrade. I still get this output: http://slexy.org/view/s2lgjglqrN
- Professorkaos64 (talk) 20:56, 5 July 2016 (UTC)
- I'm using version WS 12.5 with kernel 4.8, searching all pages in many days, then just need add one line: "export VMWARE_USE_SHIPPED_LIBS=force" in /usr/bin/vmware. The solution comes from https://bugzilla.redhat.com/show_bug.cgi?id=1278896#c3. It works for me. Hope this help.
- User:pacman Oct 23 15:24:53 UTC 2016
Tools Download Link
If anyone facing an issue with vmware tools, like could not install component, you can manually download tools from vmware.
Just shared so someone can find it usefull ;-)
Kernel Modules Not Compiling (Again)
It seems that with the 4.9 kernel vmware is again refusing to compile modules. Just an advisory for anyone currently running testing. I'm sure that there should be another patch / workaround available soon for it. It seems like VMWare is having this issue more often with recent kernels. I think this is the third time in the past six months with only 4.8 not having any new problems. Is this a problem with the kernel changing more stuff lately than normal or is this VMWare's problem? --TheChickenMan (talk) 08:20, 30 December 2016 (UTC)
- Any out-of-tree (non-mainline) driver should get out of sync with each major release of the kernel due to the huge churns and thousands of symbol changes (there's no such thing as a stable ABI for the kernel, because you couldn't then change anything).
- VMCI and VSOCK have been mainlined since 3.9 (April 2013) and get automatic updates/syncs, but VMMON and VMnet remain bundled/maintained in the app (see this for vagueish expalantions on each).
- 4.9 should be fixed by this: http://rglinuxtech.com/?p=1863 (RGLinuxTech is always a good go-to-first resource for Nvidia/VMware breakage)
- --Dettalk 07:43, 31 December 2016 (UTC)
VMware Remote Console
- The problem is:
Unable to load libgdk_pixbuf-2.0.so.0 from /usr/lib/vmware/lib/libgdk_pixbuf-2.0.so.0/libgdk_pixbuf-2.0.so.0: /usr/lib/librsvg-2.so.2: undefined symbol: cairo_tag_begin
- As workaround, you can tell vmrc to load libraries only from
for f in /usr/lib/vmware/lib/*; do [ -d "$f" ] && ldpaths="$ldpaths:$f" done export LD_LIBRARY_PATH="$ldpaths:/usr/lib"
The 'Troubleshooting' section is ever expanding. I'd like to suggest pruning issues which definitely apply to old (minor) versions of VMware only (12.5.3 through 12.5.5 seem no longer relevant to me). Any opinions? --Thralas (talk) 15:10, 25 May 2017 (UTC)
- I agree that it could use some cleanup. On a related note, I was thinking there should be a note somewhere on StrayArch (talk) 15:42, 10 June 2017 (UTC)
, since vmware has tendency to break with every new minor version of . --
- To further expand on my previous comment --- the troubleshooting subsections for old minor versions should stay. After updating and rebooting, I am still unable to get 12.5.6 to work with StrayArch (talk) 16:56, 10 June 2017 (UTC) and . For now, I am using 12.5.4 with . tl;dr the subsections regarding old minor versions should be kept since they are relevant to lts. --
- Ehm... NO! Yes, it has a tendency to break and that's why this section is so important. Why do you want to take away from users the only real useful information in this article: Easy to follow and definitely working ways to fix their problems and get VMware working again. Besides that, v12.x is not a legacy version. It is still supported and most people can't switch to VMware 14 as it removed support for a whole bunch of CPUs. It can be fixed to run on these CPUs, but not performantly. Furthermore, why did you flag the section for removal I just added yesterday? It does not apply to old minor versions of 12.x, but the latest one. If you really can't stand a wiki page providing valuable information collected by people for a long time to help others, may I suggest to create a subpage just for VMware troubleshooting? --Bachsau (talk) 02:40, 10 February 2018 (UTC)
- This section has a link to the vmware-host-modules repo from which the patch in "your new section" is downloaded and a link to the AUR package which applies the very same patch. So we don't really need one specific section for each new kernel/vmware version. -- Lahwaacz (talk) 12:42, 10 February 2018 (UTC)
- And I don't see a problem in having thousands of these sections as long as they are of any use and look organized. Keeping information is always better than removing it. Of course there are other methods, but for me it is much easier to follow some simple instructions instead of installing another package or autopatcher from a git repository with lots of code, where I first have to inspect what exactly it will do to my system before installing it. Furthermore, the aur package has been abandoned for a long time. --Bachsau (talk) 14:14, 10 February 2018 (UTC)
- Even 5 of these sections don't look organized in any way - what's organized is the vmware-host-modules repo which is the source of all of these patches. It's perfectly fine for it to be linked just once and there is no problem with removing superfluous information. I also don't see why you're so concerned with inspecting every piece of code in the repo and not the patch you'd have downloaded otherwise. Besides, all of it is to make some proprietary shitcode working... -- Lahwaacz (talk) 23:56, 10 February 2018 (UTC)
- Of course it is proprietary shitcode. Even though I think that changing the name of kernel functions for no reason in a minor release is also a bad idea. Unfortunately, on the desktop, we are in lack of alternatives, with the only one being VirtualBox, which also has a lot of bugs, lags many features and is not nearly as fast as VMware Workstation. --Bachsau (talk) 00:43, 12 February 2018 (UTC)