In the Workstation forum the top 1 question is: why does Workstation XY fails to install on Ubuntu YZ.
Can we please get an announcement or a sticky posts that explains this in some depth.
Do you really want us volunteers to repeat this rant over and over again:
VMware does not care wether the latest Workstation installs on latest Ubuntu.
Instead monitor the Ubuntu scene - sooner or later some freak from the Ubuntu scene will post a script that fixes the defects of the official installer.
This is advertisement of the worst kind - do you think we are enjoying posting "VMware just does not care ...." over and over again ?
Rob - do you have an old boxes logo - preferable one that was used with GSX 3 ?
I remember running 30 VMs with that version on a 2GB machine with win2003 32bit as host.OS
That one had shared VMs, seamless intergration with the ESXi branch - and best of all a guy named Petr was part of the forum inventar and he would answef all our questions - wether it was supported or not.
I wonder what the results would be if we asked currect developers wether they know anything about an old WS-version named GSX.
I've only got that one which you used at the moment. I don't believe I ever downloaded GSX (which, if I remember correctly, was actually more of the precursor to VMware Server 1). I've got versions of WS from 3.x onward on an external drive somewhere, if not burned to DVD.
Ahh, yes, the days when Petr was around and extremely helpful....
Sorry - the attach image function in the forum is apprently broken or limited to young iphone users only ???
In early VMware years the version that were running on the hosted platforms were called GSX and Workstation.
After the complete GSX branch was shreddered to Nirwana the versions for hosted platforms were relabelled to
Workstation (same as before)
VMserver ( an extremly crippled GSX )
VMplayer ( an extremly crippled WS )
Apparently VMware management made an obscure decision when they suddently had to deal with competetion on the hosted market.
The results was that perfect working features like
- use the WS-GUI interface to run VM on ESXi or other GSX hosts
- manageabiltity of ESXi VMs from a hosted platform
were radically thrown under the bus and later attempts to revive those features ended up as just lame attempts to reach previous matureness again.
The VMserver products 1 and 2 were so dumbedd down that they died with nobody sharing a tear on their loss.
So IMHO WS was shot in the foot three times:
1. by discontinuing GSX which was without doubt the far better product than WS
2. firing the developers team once in late 12.0
3. firing the team again years later.
No wonder the result is : "Sadly, the folks who intimately knew how it works have been long gone."
We have not been to gentle in this post - but believe us. We are a tired of what your company does.
While you are aware that the free Virtualbox is way way easyier to install you still behave as if it would be normal that the latest build of Workstation just does not install on so many hosts.
You still behave like your are the top dog in the room.
I still find it anoying that even me - the oldest and over the year busiest member of this community has no way to report bugs or report serious issues.
Well nobody expects that you fix your issues from one day to another - but honestly it would be time that you show at least some empathy.
Just look at the screenshot from the forum - taken a few minutes ago - slightly altered.
It should not been asked to much - you can hire one of your documentation writer and have it done.
This would set a sign like : we are aware that the linux installer and documentation is a mess, we are aware that we are not a geat help when a new user wants to setup Workstation on a HyperV host. But now we will start trying.
Those users that just download the latest stuff and realize that they wasted their time.
A Windows 11 user that just firgured out that the download he paid severalhundred bugs for would have done some good when invested in a nice Steak instead.
Your companys behaviour just shows this type of users the finger - and we then are supposed to win them back wile being friendly.
Help us !
Do something useful like this:
If you supply those texts you can sugar coat them as you like.
For the users this will mean that the data is availble when it is needed.
When we have to post the same stuff you will get rants, unfriendly wording and what have you.
If you do it yourself and if you provide good contents you will make points for comunnication.
If you would even start leaking occasionally tips and tricks by folks like the unnamed EFI-freak you will even make new friends.
And right now - the communication between user scene and Workstation team is not existing at all.
I guess that many of us simply expect a silent fade out if it goes on like this.
And that is not our fault - but management decision made by VMware Inc dont give us any long term expectations.
Sorry for the plaintext ...
We do have a fix internally for this issue, and we'll be shipping it next week via Workstation 16.2.4.
Sorry for being blunt but I'm afraid you - meaning rather VMware in general than just you in person - are still missing the point here. The core problem is not version X of Workstation not working correctly with version Y of Ubuntu (or Fedora or openSUSE or whatever). It's the very fact that you still think in the terms of "supported host/guest systems", i.e. you have a fixed list of versions of a very short list of distributions and completely disregard the rest.
The Linux world does not work like this. There are not 3 or 4 distributions, there are hundreds. And, worse, more and more people move to rolling style distributions where you don't have discrete sequence of versions, unless you consider every daily snapshot a "version". Corporate people often say that they cannot test all of those but that's exactly where they are missing the point. For instance, when the init script does not get started because some distributions stopped shipping chkconfig by default (and some even not at all) in order to force people to migrate to native systemd units, it's not a problem "with Tumbleweed" (or Fedora), it's a generic problem with a generic solution. The same can be said for necessary updates of the kernel modules: if an upstream change in 5.18 kernel breaks the module, it's not a problem of a specific Fedora or Tumbleweed snapshot, it's a generic problem that is inevitably going to affect more and more systems as they move to 5.18 kernel. And it should be addressed as soon as 5.18 is released (the fix can be usually prepared as soon as rc1 is out). Sure, there are also specific issues with specific versions of specific distributions but those are rare, vast majority of the problems is generic and should be treated as such.
An example: Workstation/Player 16.2.4 has been just released and it fixes (on kernel module front) one specific issue with the hack in the definition ASSERT_ON_COMPILE_SELECTOR_SIZE() macro which is going to "fix the problem on Ubuntu 22.04". More precisely, it fixes the problem on any distribution building its kernel with -fsanitize=shift. It does not, however, address any of the issues with build against 5.19 kernel (going to be released at the end of this week). Sadly, it does not address even known problems with 5.18 kernel (dropped HAVE_GET_KERNEL_NOFAULT and netif_rx_ni()) or 5.17 (net_device::dev_addr now const and accessors should be used), and AFAICS not even the include issues known since 5.15 and 5.16 (need to use kernel versions of stdarg.h and stddef.h rather than userspace ones). This is a result of thinking in the terms of fixed list of "supported releases": as long as it does not break completely (warnings are ignored, mostly) on one of them, you don't care. BtW, a fix for the "Ubuntu 22.04 issue" (exactly the same as yours, except for a comment and whitespace formatting) was known in public since January 2nd, i.e. more than half a year before 16.2.4 was released and more than 2 months before 16.2.3 was released.
To sum up: as long as you don't change your understanding of the Linux world, this is going to be a recurring issue and people are inevitably going to be annoyed.
I have POP OS 22.04 running kernel 5.18 and I have gone from Workstation pro 16.2 working with 5.15, then to not working again in 5.18. Tried to upgrade to 16.4 but no Bueno. I love my system 76 Oryx but they are aggressive updating their kernels. Very frustrating. have had to settle running Gnome Boxes in the interim until VMware spends more time on updating their software for updated kernels.
For those of you running kernel 5.18, I would suggest taking a look at the Arch AUR package https://aur.archlinux.org/packages/vmware-workstation and see what the package maintainer has done; maybe it would help getting your system working again. For me, this package has always built without fail, going back to kernel 5.15.
To @Mikero, since these problems affect all of us, I believe it would be in VMware's best interest to communicate with the aforementioned packager maintainer; at least it would give the impression that the company is actively seeking a fix.
Speaking of fixes...is there an easy way to get on the beta test team? I'm retired, so I can spend as much time as you need to troubleshoot bugs or test fixes.