VMware Workstation 12.5.6 doesn't start on Ubuntu 17.10

[Loboar]

I upgraded to VMware Workstation 12.5.6 this morning but It does not start anymore. VMware's icon blinks in the unity launcher but vmware never starts.

I reinstalled it, reboot the computer, etc. Also, I installed kernel 4.11 but the issue was not solved.

If anyone of you can help me troubleshoot this issue I would appreciate it.

Now, I uninstalled that kernel and returned to previous 4.10.0-21-generic kernel. I will try to install the previous build of VMware Workstation which was running fine in the same computer but I would like to use 12.5.6 and know why that is not starting. Thanks.

Kind regards,

Hugo Javier Sanoguera

[Loboar]

FYI, I reinstalled VMware Workstation 12.5.5 and it is working fine. Anyway, I would like to make running VMware Workstation 12.5.6. Thanks.

[fenris]

I've facing the same problem with you.

Do u mean that VMware Workstation work again after u revert to kernel 4.10 with version 12.5.5 ? or version 12.5.6 works with kernel 4.10 not 4.11 ?

[Loboar]

Hi fenris,

Workstation 12.5.6 did not work with neighter of these kernel versions. So I uninstalled kernel 4.11, I reinstalled 12.5.5 and I skipped version 12.5.6. Basically I rolled back to my initial scenario which was working fine.

[CollinChaffin]

So annoyed I just spend over 8 hrs troubleshooting this.  What the heck is the newest friggin officially supported version of Ubuntu that is supported on VMware Workstation?  I cannot find the exact build number for Ubuntu that is supported but I can confirm 17.10 FORGET IT - it simply does NOT run on either 12.5.5 or 12.5.6.

[CollinChaffin]

Found it did not realize that apparently 16.10 is only the latest even supported.  Remember the days 15+ yrs ago when VMware was always the one pulling everyone to the bleeding edge?

[mfelker]

I'm going to try this and update 17.04 to 17.10.   If WS 12..5.5 does work on Ubuntu 17.10 then there is a confirmed regression that VMware needs to address.

[mfelker]

Workstation 12.5.5 did not work for me when I upgraded

There was no apparent change to the kernel  which remained the latest 4.10.0-21-generic

Looks like all processes are running. 

69 ?	00:00:00 vmstat
347 ?	00:00:00 lvmetad
1095 ?	00:00:00 vmware-usbarbit
2101 ?	00:00:00 vmware-vmblock-
2132 ?	00:00:00 vmnet-bridge
2140 ?	00:00:00 vmnet-netifup
2158 ?	00:00:00 vmnet-dhcpd
2161 ?	00:00:00 vmnet-natd
2163 ?	00:00:00 vmnet-netifup
2183 ?	00:00:00 vmnet-dhcpd
2238 ?	00:00:00 vmware-authdlau
2505 ?	00:00:01 vmware-hostd If Darius or anybody else can point me to any vmware logs which may shed light on this I'd be more than happy to help.   I can also install ws12.5.6 but the odds of that working seem almost nil. Hope VMware can fix this.

[CollinChaffin]

Well I was partially correct.  This is just flat out an issue with the newer Linux kernels running specifically on the friggin RECOMMENDED SCSI controller on a windows host

Here is yet another report of EXACTLY what I and others are experiencing repeatedly.  I am re-testing but I believe this Kali bug poster's tests are accurate, that the workaround is simply to NOT use the recommended SCSI virtual adapter, and instead change it to SATA.

0004017: Kali 2017 problem with VMware Workstation - Kali Linux Bug Tracker

[CollinChaffin]

But, when USB3 and other devices all use SCSI commands and drivers in Linux, I am not convinced that even if the boot drive is set to SATA (because we do not know exactly what part/code in the SCSI vmware drivers is causing this) I'm leery of trusting using other disks plugged in via USB3 passthru, etc.

VMware really needs to acknowledge this so we have an idea of when it will finally be fixed.  This is an entire line of OS' with the virtualized SCSI disk driver being corrupted.

[dariusd]

Hi Marty!

Please try running:

   $ find /tmp/vmware-$USER -cmin -60

to find possibly-relevant logfiles created within the last hour.  Hopefully there will be a vmware-apploader-<nnnn>.log in there.

Cheers,

--

Darius

[mfelker]

Thank you, Darius:

        It will be awhile before I can get to this.   VMware WS 12.5.5 is working great on Ubuntu 17.04 with the latest 4.10 Ubuntu kernel.    I can restore the Ubuntu 17.10 anytime I want to and then can look into this problem.  It's always a bit frustrating when this happens.    Virtualbox has no problem.   I'm running the latest test build.  

Regards,

Marty

[mfelker]

Hi Darius:

      Hope you had a good holiday.    I'm attaching an vmware-apploader log which I captured using your handy command.    This was created when I had upgraded Ubuntu 17.04 with a working (very nicely I might add) build of WS 12..5.5.   I hadn't upgraded to WS 12.5.6 because somebody posted that his WS 12.5.5 was working on Ubuntu 17.10.

     This was run before even rebooting into Ubuntu 17.10.    There was a shared VM of ESXi 6.5 running happily during the upgrade but obvious not after.

     Attaching 2 compressed archives.

1)  Just the most recent vmware-apploader log.

2)   All vmwarelogs in /tmp/vmware-marty.

I hope this may be of some assistance to you.

Looking forward to your reply.

[mfelker]

Hi again Darius:

      Just to complete this task attached is the archive of vmware-apploaderlog after rebooting into Ubuntu 17.10 and running vmware.

      I'm going to completely remove vmwarefrom linux - I still have it working on windows server 2016.

[mfelker]

Hi again Darius

      I'd really like to see vmwareworkstation work on Ubuntu 17.10 so I've attached an archive containing the logs from running vmware as root.

The kernel is  4.11.3-041103-generic   (kernel 4.12rc3 won't boot on my system).

Using vmwareworkstation 12.5.6 this time

[CollinChaffin]

I agree but all my tests have been on workstation on Windows, specifically.  I'm trying to capture better debug info, but the corruption continues and it's only new(er) kernels, when I boot very old Kali 1.09 vm's that are even still using SCSI (at least on 12.5.4) I don't think I'm seeing any corruption in the guest linux logs or fs errors.  The newer kernels, instant corruption after the first power off and back on and every subsequent after that.

[dariusd]

Please keep discussion related to the disk corruption in the other thread, Ubuntu 17.10 does not run in VMware Workstation 12.5.6​.

The issue mfelker is encountering (unable to launch WS 12.5.6 at all when installed on top of an Ubuntu 17.10 host) is entirely unrelated to the disk corruption issue when running some Linux guests on a Windows host.  Entangling the two discussions will only confuse both issues and make it more difficult to resolve either of them.

Thanks,

--

Darius

[dariusd]

Thanks for the update, Marty!

Unfortunately, it doesn't look like this library compatibility issue will be easy to fix or work around -- it seems we're crashing while initializing libXrandr.  I can't yet tell whether this is an issue with Workstation/apploader or with the Ubuntu 17.10 libraries or maybe I'm even misinterpreting the crash... it's an odd one.  I'll let you know when I find a solution.

Cheers,

--

Darius

[sfabpix]

Hi all.

I have exactly the same issue with OpenSuSE Tumbleweed, with kernel 4.11.3. Anyway, the issue seems to be related to xrandr, also.

Hope it helps,

Sylvain

EDIT : Fixed, by doing the following commands, inspired by the Archlinux page :

# cd /usr/lib/vmware/lib/libz.so.1

# mv libz.so.1 libz.so.1.old

# ln -s /usr/lib64/libz.so .

[mfelker]

Hi Darius:

     I've found a distro that works best in regards to VMware Workstation Pro 12.5.6.    It is Siduction 17.1.0 which as the name sorta implies is based on Debian 9 (Stretch) also referred to as Debian Sid.

      Immediately after installing SiductionI updated to the latest version which features a custom 4.11 kernel ( 4.11.3-towo.3-siduction-amd64).   WS installed and ran flawlessly including the Workstation Server which was having problems. 

       Siduction may not be everybodies cup but it is working great -  especially using the lightning fast lxde desktop.    Of course I am limiited to whenever the devs get around to kernel 4.12 but I can live with that for awhile at least.

    Cheers,

     Marty

PS FWIW I've never encountered corruption using the VMware SCSI drives.