New Fedora, new VMplayer startup problems

With older machines we have the risk of unsupported software hitting compatib ility problems with each OS upgrade. A recent example of this is running vmplayer 12.5.9 on Fedora 30 which ran fine on Fedo ra 26 .. 28 albiet needing a couple of tweaks

But what's the new problems on Fedora 30 and what are the workarounds?


As noted sometimes we simply can't upgrade your legacy software because of dr opped hardware support - in this case VMware stopped supporting older SandyBr idge Intel CPUs after VMplayer 12.5.9 together with a forced Fed ora upgrade (harddisk head crash) meant it now we are now forced to use VMplayer on the latest Fedora release.

After grabbing the 12.5.9 bundle from VMware (see link above) we follow the w orkaround instructions for getting the VMplayer kernel modules t o compile and starting the relevant service:

$ git clone https://github.com/mkubecek/vmware-host-modules
$ cd vmware-host-modules
$ git checkout workstation-12.5.9
$ sudo make install
$ sudo systemctl restart vmware
$ sudo systemctl status vmware
● vmware.service - SYSV: This service starts and stops VMware services
Loaded: loaded (/etc/rc.d/init.d/vmware; generated)
Active: active (running) since Sat 2019-07-27 18:26:43 BST; 5min ago
Docs: man:systemd-sysv-generator(8)
Process: 22490 ExecStart=/etc/rc.d/init.d/vmware start (code=exited, st atus=0/SUCCESS)
Tasks: 10 (limit: 4915)
Memory: 22.9M
CGroup: /system.slice/vmware.service
├─22581 /usr/lib/vmware/bin/vmware-vmblock-fuse -o subtype=vmwa re-vmblock,default_permissions,allow_other /var/run/vmblock-fuse
├─22611 /usr/bin/vmnet-bridge -s 6 -d /var/run/vmnet-bridge-0.p id -n 0
├─22619 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-v mnet1.pid /dev/vmnet1 vmnet1
├─22625 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/ dhcpd.conf -lf /etc/vmware/vmnet1/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhc>
├─22628 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vmnet8/nat/nat.conf
├─22630 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-v mnet8.pid /dev/vmnet8 vmnet8
├─22636 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/ dhcpd.conf -lf /etc/vmware/vmnet8/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhc>
└─22664 /usr/sbin/vmware-authdlauncher
$ sudo systemctl enable vmware

right now, this looks fine so to start the player:

$ vmplayer
/usr/lib/vmware/bin/vmware-modconfig: Relink `/lib64/libssh.so.4' with `/lib6 4/librt.so.1' for IFUNC symbol `clock_gettime'

This is less good.

However, this error is actually misleading as the underlying problem has NOTH ING to do with libssl - some bug reports/references online refer to incorrect installation of the kernel modules but that isn't the culprit e ither.

The solution for me was actually another previously documented 12.4 (version ??) fix related to the shared libraries shipped with vmplayer. We can verify that the VMware utils are failing to find the correct libraries (and then core dumping with Bad RIP code as shown in the system logs which is also unhelpful) by running LD_DEBUG=libs vmplayer and observing which libraries the linker fails to resolve or find.

The real fix is to replace the following vmplayer libraries with the system equivalents:

$ cd /usr/lib/vmware/lib
$ for i in \
libz.so.1 libexpat.so.1 libfontconfig.so.1 libfreetype.so.6 \
do
( cd $i && mv $i $i.orig && ln -s /lib64/$i )
done

Following this we should be able to start vmplayer as before.