VMware – 14.0.0 ‘Fail to open Executable’ – More Info..

Posted on by October 15, 2017
Reply

When running VMware 14 (14.0.0) from the command line, I noticed the following message:

$ vmware
Fail to open executable: No such file or directory

Further research suggested that this ‘missing’ item was in fact /usr/lib/vmware/lib/libvmware-unity-helper.so/libvmware-unity-helper.so, which is indeed not included with VMware 14.0.0..

I found a copy of this in an old backup, and tried to restore it to the current VMware library tree, and discovered that it had further VMware library dependencies – which were also in the old backup:

libvmwarebase.so.0
libvmwareui.so.0
libgvmomi.so.0
libview.so.3
libgcrypt.so.11
libgcr.so.0
libgck.so.0

This was OK, so far, but the last dependency was

[AppLoader] Fail to load the library. /usr/lib/vmware/lib/libstdc++.so.6/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /lib64/libgdkmm-2.4.so.1)

– which was a show-stopper, as this would cause a conflict with the existing VMware 14 version of that file…

So, I backed out all the file/library moves, and will never know if any of this would have made a real difference to any of the performance issues being reported.      I had taken a complete backup of all my VMs before the upgrade, and have considered reverting to 12.5.7 (even with all the ‘workarounds’ needed), but – so far – have only experienced some sluggishness in the Windows 7 VM operation, so I am staying with 14.0.0, and hoping that 14.0.1 is released soon!

Robert Gadsdon   October 15, 2017..

Kernel – ‘Urgent’? 4.13 Update Released – 4.13.7..

Posted on by October 14, 2017
Reply

Kernel 4.13.6 has only been out for two days, but there has just been another update – 4.13.7 – with the following changes:  https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.13.7

If you are running 4.13.6, then update is – presumably – recommended ASAP!

Robert Gadsdon.   October 14, 2017.

NVIDIA – 387.12 released – OK with Kernel 4.14/Intel, and AMD with SME Disabled..

Posted on by October 3, 2017
Reply

NVIDIA driver 387.12 is out, and details are here:  http://www.nvidia.com/Download/driverResults.aspx/125399/en-us

The driver compiles/loads OK with Kernel 4.14-rc3 on Intel, without any patches, and is OK with AMD as long as its Secure Memory Encryption feature is de-selected ( see http://rglinuxtech.com/?p=2070 ).

.....................
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-modeset/nvidia-modeset-linux.o
 Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-drm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-387.12/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.14-rc3'
make[1]: Leaving directory '/usr/src/linux-4.14-rc3'

Robert Gadsdon.  October 3, 2017.

Kernel – 4.14-rc3 Released – OK with Patched VMware, Still has NVIDIA/AMD/GPL Problem..

Posted on by October 1, 2017
2

Kernel 4.13-rc3 is out, and brief details of changes from -rc2 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1710.0/00180.html

VMware 14.0.0 – with the vmmon patch – still loads/runs OK(*), and NVIDIA is OK on Intel systems, but if the new AMD ‘Secure Memory Encryption‘ feature is enabled in the kernel config, then NVIDIA (384.90) will still fail with a GPL error:

.............
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'sme_me_mask'
make[3]: *** [/usr/src/linux-4.14-rc3/scripts/Makefile.modpost:91: __modpost] Error 1
............

*  As expected, the ‘VMware 14 failing on older CPUs’  issue has produced quite a lot of ‘discussion’ on the VMware forum…

Robert Gadsdon.   October 1, 2017.

NVIDIA – Another GPL Problem, but only with AMD Systems..

Posted on by October 1, 2017
2

Thanks to Pete for finding this one…

There is another GPL-only issue with NVIDIA and Kernel 4.14-rc2, but this one only occurs if you have an AMD system, with the new ‘secure memory encryption’ feature enabled…    It may also crop up if you are using a Distro-created version of this kernel release, as these tend to have almost-everything-enabled in their kernel config.

If you have ‘AMD Secure Memory Encryption (SME) support‘ enabled in your kernel config, then the NVIDIA ( 384.90 ) compile/load will fail:

..................
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nvidia-modeset-linux.o
 Building modules, stage 2.
 MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'sme_me_mask'
make[3]: *** [/usr/src/linux-4.14-rc2/scripts/Makefile.modpost:91: __modpost] Error 1
make[2]: *** [/usr/src/linux-4.14-rc2/Makefile:1502: modules] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14-rc2'
make[1]: *** [Makefile:145: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14-rc2'
make: *** [Makefile:81: modules] Error 2

The workaround – for the time being – is to de-select this feature in the Kernel config….

Hopefully this will get fixed soon, as it has already been mentioned in one of the related mailing lists:  https://www.spinics.net/lists/linux-arch/msg41632.html

Robert Gadsdon.  October 1, 2017.

 

VMware – Workstation 14 released – with a Gotcha..

Posted on by September 27, 2017
15

VMware Workstation Pro 14.0.0 has been released – a bit earlier than expected – and it has a (potentially) nasty surprise for those with ‘older’ CPUs..   Release notes are here:  https://docs.vmware.com/en/VMware-Workstation-Pro/14.0.0/rn/workstation-14-release-notes.html

I installed this on my test system without any problems, and was able to confirm that it compiles and loads/runs OK with Kernels 4.13.x, and that the vmmon patch for 12.5.x still applies, and this enables it to load/run with Kernel 4.14-rc2..   The runtime # vmware also works correctly, with Fedora 26..

However…  As soon as I tried to run a VM, I was presented with the following error message:

“This host does not support “Intel EPT” hardware assisted MMU virtualization.
This host does not support virtualizing real mode. The Intel “VMX Unrestricted Guest” feature
is necessary to run this virtual machine on an Intel processor.
Module ‘CPUIDEarly’ power on failed.
Failed to start the virtual machine.“

# cpuinfo reports the CPU in my test system as  ‘Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz’..

The Intel site reports that this CPU supports:  Intel® Virtualization Technology (VT-x) and Intel® Virtualization Technology for Directed I/O (VT-d)..

According to the VMware release notes:

“Systems using Processors (CPUs) launched in 2011 or later are supported except:
Intel Atom processors based on the 2011 “Bonnell”  micro-architecture (e.g. Atom Z670/Z650; Atom N570)
Systems using Intel Atom processors based on the 2012 “Saltwell” micro-architecture (e.g. Atom S1200, Atom D2700/D2500, Atom N2800/N2600.
Systems using AMD processors based on the “Llano” and “Bobcat” micro-architectures (e.g. code-named “Hondo”, “Ontario”, “Zacate”, “Llano”)
In addition the following are supported:
Systems using Intel processors based on the 2010 “Westmere” micro-architecture (e.g. Xeon 5600, Xeon 3600, Core i7-970, Core i7-980, Core i7-990)”

The VMware documentation for W/S 14 is more vague, and states:

“For supported processors to run 64-bit guest operating systems, the host system must use one of the following processors.
          *  An AMD CPU with AMD-V support
          *  An Intel CPU with VT-x support
If you have an Intel CPU that has VT-x support, you must verify that VT-x support is enabled in the host system BIOS. The BIOS settings that must be enabled for VT-x support vary depending on the system vendor.“

I did try adding the monitor.allowLegacyCPU = “true” parameter in the VMware config file, but this still did not work, and left the “…The Intel “VMX Unrestricted Guest” feature is necessary … error..

So… more testing is necessary, and it seems – at least – as if the VMware documentation is somewhat lacking in clarity or consistency…    I have a feeling that this new ‘feature’ is going to cause quite a lot of discussion….

Robert Gadsdon.   September 27, 2017.

Kernel – 4.14-rc2 Released – Includes NVIDIA/GPL Fix..

Posted on by September 24, 2017
2

Kernel 4.14-rc2 is out, and brief details of changes since -rc1 are here: http://lkml.iu.edu/hypermail/linux/kernel/1709.3/00498.html

This includes:
John Hubbard (1):
ACPI / bus: Make ACPI_HANDLE() work for non-GPL code again
– which fixes the GPL problem for NVIDIA drivers, so that the latest version – 384.90 – with just the first patch found here: http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/ – now compiles and loads OK:

..................
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nvidia-modeset-linux.o
 Building modules, stage 2.
 MODPOST 4 modules
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-uvm.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia-uvm.ko
 CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia.mod.o
 LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.90/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.14-rc2'
make[1]: Leaving directory '/usr/src/linux-4.14-rc2'

VMware 12.5.7 – with the 4.13 vmnet patch, and the 4.14 vmmon patch, as mentioned in a previous article ( http://rglinuxtech.com/?p=2054 ) also compiles and loads/runs OK.

Robert Gadsdon.   September 24, 2017.

NVIDIA – New Driver – Same Problems..

Posted on by September 21, 2017
Reply

NVIDIA have just released a new driver version – 384.90 – and brief details are here:  http://www.nvidia.com/Download/driverResults.aspx/123918/en-us

This version appears to be runtime bug-fixes only, and still fails to compile with Kernel 4.1.-rc1 without the patch mentioned in a previous article ( http://rglinuxtech.com/?p=2056 ), and still suffers from the GPL issue:

 .........
Building modules, stage 2.
 MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'acpi_device_fwnode_ops'
make[3]: *** [/usr/src/linux-4.14-rc1/scripts/Makefile.modpost:91: __modpost] Error 1
make[2]: *** [/usr/src/linux-4.14-rc1/Makefile:1502: modules] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14-rc1'
make[1]: *** [Makefile:145: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14-rc1'
make: *** [Makefile:81: modules] Error 2

There was some mention of a ‘completely new’ driver from NVIDIA some time ago, but this seems to have been forgotten, now..?

Robert Gadsdon.   September 21, 2017.

ARM64 – 4.14-rc1 Problems..?

Posted on by September 18, 2017
Reply

Kernel 4.14-rc1 has been stable on the x86_64 test system, but when I tried updating the Odroid C2 (ARM64) I saw a lot of mmc and other errors reported..

..........
[ OK ] Started File System Check on Root Device.
 Starting Remount Root and Kernel File Systems...
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
mmcblk0: response CRC error sending r/w cmd command, card status 0xd00
print_req_error: I/O error, dev mmcblk0, sector 2048
Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write
EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
...................
[ OK ] Started udev Coldplug all Devices.
[FAILED] Failed to start Load/Save Random Seed.
See 'systemctl status systemd-random-seed.service' for details.
...............
phy phy-c0000000.phy.0: USB ID detect failed!
phy phy-c0000000.phy.0: phy poweron failed --> -22
dwc2: probe of c9000000.usb failed with error -22
..............

Once the system was up, I found that the old Ethernet link problem seemed to have reappeared, and although eth0 seemed to be up, network traffic would cease after a short time..       The system had also switched to a ‘read-only filesystem’…..

So.. I reverted to 4.13.2, and everything was OK, again..     I did not even get a chance to test if hdmi etc. worked at all, this time..

Robert Gadsdon.   September 18, 2017.

NVIDIA – More Details on Kernel 4.14-rc1 Problems..

Posted on by September 17, 2017
Reply

I have found more comprehensive info on the problems with NVIDIA driver 384.69 and Kernel 4.14-rc1 – here:  http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/

The code changes needed are clearly set out, but there is no ‘legal’ solution yet, due to the unresolved GPL licence issues..

Robert Gadsdon.  September 17, 2017.