VMware – 12.5.5. released – Another ‘Security Fix’..

VMware 12.5.5 is out, and the release notes are here:  http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-1255-release-notes.html

As with 12.5.4, this is another security/fix release, and still supports Kernels 4.10 and earlier.    (see http://rglinuxtech.com/?p=1937 )

12.5.5 runs OK on Kernel 4.10.6, and the 4.11 vmmon and vmnet patches still apply (tested on 4.11-rc4)….

Robert Gadsdon.   March 29, 2017.

VMware – 12.5.4 Released – Security Fix Only..

Hot on the heel of VMware 12.5.3 comes 12.5.4, and the release notes are here: http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-1254-release-notes.html

As can be seen from these notes, this is an urgent-security-fix release only, and the compatibility with Linux kernel versions, and patch applicability, is the same as for 12.5.3 (see http://rglinuxtech.com/?p=1937 ) .      I can confirm that 12.5.4 runs OK on Kernel 4.10.3, and the 4.11 patchset still applies..

Robert Gadsdon.   March 15, 2017.

Kernel – 4.11-rc1 and BTRFS – a Warning..?

I encountered a catastrophic problem with btrfs formatted system disk partition corruption, shortly after updating a test system to Kernel 4.11-rc1.

To put this in context, this may be an isolated incident, and I have not seen problems – so far – mentioned elsewhere..    But.. there a quite a lot of BTRFS changes on 4.11, and – after the usual tests – I confirmed that system memory was OK (running memtest86+ several times..) and the disk was OK (running smartmontools utilities etc. several times).    The disk is only one year old, in any case (WD – 2GB)..

Unfortunately, I did not have a serial console attached to this particular system  at the time, and so had to photograph the screen at various times, and then re-type the details below from those photos (!)..

The scenario:

System disk (/dev/sda2) is formatted btrfs..
Updated to Kernel 4.11-rc1.
Within 24 hours, the system froze, and on rebooting, got a critical btrfs error:

...................
 Mounting /sysroot....
BTRFS critical (device sda2): corrupt node, bad key order: block=368346054656, root=1, slot=192
BTRFS critical (device sda2): corrupt node, bad key order: block=368346054656, root=1, slot=192
BTRFS error (device sda2): failed to read block groups: -5
BTRFS error (device sda2): open_ctree failed
[FAILED] Failed to mount /sysroot
See 'systemctl status sysroon.mount' for details
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
......................
 Starting Emergency Shell...

Ran:

:/# btrfs check /dev/sda2
Checking filesystem on /dev/sda2
UUID xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx
checking extents
bad block 33488896
Errors found in extent allocation tree or chunk allocation
^C
:/# btrfs rescue chunk-recover /dev/sda2
Scanning: 66126696448 in dev0

Then got scrolling screens full of:

...........
Deleting bad dir index [537997,96,160] root 5
Deleting bad dir index [537997,96,168] root 5
Deleting bad dir index [537997,96,170] root 5
Deleting bad dir index [537997,96,180] root 5
Deleting bad dir index [537997,96,186] root 5
Deleting bad dir index [537997,96,190] root 5
Deleting bad dir index [537997,96,198] root 5
................ continuing...

Then more scrolling screens full of:

...............
Trying to rebuild inode:1658592
root 5 inode 1658592 error 2001, no inode item, link count wrong
 unresolved ref dir 198531 index 0 namelen 18 name gtk-indent-ltr.png filetype 7 errors 6, no dir index, no inode ref
Trying to rebuild inode:1658593
root 5 inode 1658593 error 2001, no inode item, link count wrong
 unresolved ref dir 198531 index 0 namelen 18 name gtk-indent-rtl.png filetype 7 errors 6, no dir index, no inode ref
............... continuing....

Then more scrolling screens full of:

..............
repairing missing dir index item for inode 30734433
repairing missing dir index item for inode 30734434
repairing missing dir index item for inode 30734435
repairing missing dir index item for inode 30734436
repairing missing dir index item for inode 30734437
repairing missing dir index item for inode 30734438
repairing missing dir index item for inode 30734439
............ continuing...

Then more scrolling screens full of:

..............
Deleting bad dir index [363308,96,63443] root 5
Deleting bad dir index [363396,96,12025] root 5
The following tree block(s) is corrupted in tree 5:
 tree block bytenr: 44061900800, level: 1, node key: (365821249776, 168, 45056)
Try to repair the btree for root 5
Btree for root 5 is fixed
Deleting bad dir index [364225,96,3382] root 5
Deleting bad dir index [363308,96,63425] root 5
Deleting bad dir index [363308,96,63427] root 5
Deleting bad dir index [363308,96,63427] root 5
........... continuing ...........

The ‘recovery’ kept running, although appearing to stall, several times, but I just left it and it ran for almost three days in total, and finally ended:

..............
Btree for root 5 is fixed
root 5 root dir 256 error
root 5 inode 256 errors 200, dir isize wrong
reset isize for dir 2139040 root 5
reset isize for dir 2139040 root 5
..................
Trying to rebuild inode:33318043
moving file 'lost+found' to 'lost+found' dir since it has no valid backref
Fixed the nlink of inode 33318043
found 583909376 bytes used err is 1
total csum bytes: 0
total tree bytes: 1884160
total fs tree bytes: 0
total extent tree bytes: 1474560
btree space waste bytes: 758524
file data blocks allocated: 201064448
 referenced 201064448
:/#
:/#

After all that, I rebooted:

...................
 Mounting /sysroot....
BTRFS critical (device sda2): corrupt node, bad key order: block=44061900800, root=1, slot=192
BTRFS critical (device sda2): corrupt node, bad key order: block=44061900800, root=1, slot=192
BTRFS error (device sda2): failed to read block groups: -5
BTRFS error (device sda2): open_ctree failed
[FAILED] Failed to mount /sysroot
See 'systemctl status sysroon.mount' for details
[DEPEND] Dependency failed for Initrd Root File System.
[DEPEND] Dependency failed for Reload Configuration from the Real Root.
....................
Entering emergency mode..............

So… The btrfs recovery was a waste of three days, and did not fix the problem.. I will now have to re-create the data from another source.. Fortunately this was ‘just’ the system disk partition and no irreplaceable recent user data was lost, apart from /root

I should mention as well, that all other btrfs-formatted partitions on other systems, running 4.10.x and earlier, have been error-free, and reliable.   And… I have not tried 4.11-rc2 with BTRFS, yet..

Robert Gadsdon.   March 14, 2017.

VMware – Not Working with Fedora 26 – GCC 7, and Workarounds..

I have recently updated one crash-and-burn system to Fedora 26 (alpha/testing) and have encountered two problems with VMware and the ‘bleeding edge’ version of GCC included..

The first problem sounded very familiar, and it is a repeat of one from 2015, where the vmware runtime would simply not start, with no output..   (see http://rglinuxtech.com/?p=1601 )..  The second problem was with the ‘automated’ compilation of the VMware modules, and none of the usual methods worked.   Both problems can be traced to Fedora 26’s use of GCC version 7 (currently 7.0.1)

To get the vmware runtime to execute, force it to use the Fedora 26 versions of various glib2 libraries:

As root, cd to /usr/lib/vmware/lib , then:

# cp -afv /usr/lib64/libgio-2.0.so.0.5104.0 libgio-2.0.so.0/libgio-2.0.so.0
# cp -afv /usr/lib64/libglib-2.0.so.0.5104.0 libglib-2.0.so.0/libglib-2.0.so.0
# cp -afv /usr/lib64/libgmodule-2.0.so.0.5104.0 libgmodule-2.0.so.0/libgmodule-2.0.so.0
# cp -afv /usr/lib64/libgobject-2.0.so.0.5104.0 libgobject-2.0.so.0/libgobject-2.0.so.0
# cp -afv /usr/lib64/libgthread-2.0.so.0.5104.0 libgthread-2.0.so.0/libgthread-2.0.so.0

The VMware libraries are each in their own individual directory, with the same name as that library.. Of course, the Fedora 26 library version numbers may change over time..

After that, run vmware, forcing the use of the copied libraries:

# VMWARE_USE_SHIPPED_LIBS=force vmware

The application will run, but will immediately encounter the second problem…   VMware does not ‘recognise’ GCC version 7..

The vmware runtime graphical module compiler/installer will complain that ‘GNU C Compiler (gcc) version 6.3.1 was not found’, and then ‘A compatible version of gcc was not found’..

The command-line installer fails, but with less detail:

# vmware-modconfig --console --install-all
Failed to get gcc information.

The fix is a bit messy, but does work..

The VMware 12.5.3 vmmon and vmnet modules will actually both compile OK with GCC 7.0.1, and the trick is to manually install these, and then run the vmware runtime application directly, instead of via the normal ‘complaining’ scripts..

In the /usr/lib/vmware/modules/source directory, unTAR vmmon.tar and vmnet.tar, and then enter the resulting vmmon-only and vmnet-only directories and just type # make in each. Then create a /lib/modules/<kernel version>/misc directory, and copy vmmon.ko and vmnet.ko there, then #depmod -a.

To run the vmware runtime directly, instead of /usr/bin/vmware, run /usr/lib/vmware/bin/vmware, and the runtime application should execute without any gcc checks etc….

Combining the two workarounds, the runtime command is now:

# VMWARE_USE_SHIPPED_LIBS=force /usr/lib/vmware/bin/vmware

I have tested this with Fedora 26 – with GCC 7.0.1, and VMware 12.5.3, and it works..     The current release schedule shows this version of Fedora will be released around June 2017, but – of course – this may well slip..

Robert Gadsdon.  March 12, 2017.

Thanks to Vincent Cojot for the original glib2 fix info, in 2015..

VMware – 12.5.3 released – OK with Kernel 4.10. 4.11 Patch Still Works..

VMware 12.5.3 has been released, and release notes are here:  http://pubs.vmware.com/Release_Notes/en/workstation/12pro/workstation-1253-release-notes.html

Although these notes only mention Kernel 4.9.0, I can confirm that it also supports 4.10.x Kernels (tested on 4.10.1).

I applied the vmmon and vmnet patches for Kernel 4.11, mentioned in a previous article, and these still worked, and VMware compiled OK, and ran, on 4.11-rc1..

Robert Gadsdon.   March 11, 2017.

 

NVIDIA – Kernel 4.11 Fix Available, but not ‘Legal’..

There is a fix/patch available now, for NVIDIA driver 378.13 on Kernel 4.11, but it involves modifying the licence on NVIDIA code, and so is not legal..

Details – and links to discussions – here:  https://devtalk.nvidia.com/default/topic/995636/?comment=5101210

Some previous changes to Kernel code enforcing GPL-only licensing had been reverted, but looking at the correspondence on the Linux Kernel Mailing List, it seems that this may not happen, in this case…     So.. it would be up to NVIDIA themselves to make the necessary changes to their code..

The LKML discussion includes the comment that NVIDIA are currently ‘designing …… new open-source drivers‘, but more details are not given..

Robert Gadsdon.   March 8, 2017.

VMware – Patch for Kernel 4.11 Support..

Thanks to Virgo, there are now patches for vmnet and vmmon with Kernel 4.11 (see his comments under the earlier article).    These are incremental patches, for application to VMware 12.5.2 code already patched for Kernel 4.9/4.10 support..

Links are here:   http://pastebin.com/McqmUf0u     and    http://pastebin.com/yjbDHiSX

I have modified these (adding appropriate #if LINUX_VERSION_CODE…… #endif statements) to be backward-compatible with 4.10 and earlier, and applied them to 4.9/4.10-patched VMware 12.5.2, and can confirm that it now compiles and runs on 4.11-rc1..

Robert Gadsdon.   March 6, 2017.

Kernel – 4.11-rc1 Released – Breaks (Patched) VMware and NVIDIA..

Kernel 4.11-rc1 has been released, and brief details are here: http://lkml.iu.edu/hypermail/linux/kernel/1703.0/03031.html

Updated the test system, and 4.10-patched versions of VMware 12.5.2 and NVIDIA 378.13 fail to compile..

VMware (12.5.2 – patched for 4.9/4.10):

.............
/tmp/modconfig-rRcJiJ/vmmon-only/linux/hostif.c: In function ‘HostIFFastClockThread’:
/tmp/modconfig-rRcJiJ/vmmon-only/linux/hostif.c:3267:4: error: implicit declaration of function ‘allow_signal’ [-Werror=implicit-function-declaration]
 allow_signal(SIGKILL);
 ^~~~~~~~~~~~
/tmp/modconfig-rRcJiJ/vmmon-only/linux/hostif.c: In function ‘HostIF_SetFastClockRate’:
/tmp/modconfig-rRcJiJ/vmmon-only/linux/hostif.c:3421:10: error: implicit declaration of function ‘force_sig’ [-Werror=implicit-function-declaration]
 force_sig(SIGKILL, linuxState.fastClockThread);
 ^~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:294: recipe for target '/tmp/modconfig-rRcJiJ/vmmon-only/linux/hostif.o' failed
make[2]: *** [/tmp/modconfig-rRcJiJ/vmmon-only/linux/hostif.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/tmp/modconfig-rRcJiJ/vmmon-only/linux/driver.c:121:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
 .fault = LinuxDriverFault
 ^~~~~~~~~~~~~~~~
/tmp/modconfig-rRcJiJ/vmmon-only/linux/driver.c:121:19: note: (near initialization for ‘vmuser_mops.fault’)
/tmp/modconfig-rRcJiJ/vmmon-only/linux/driver.c:1283:1: warning: always_inline function might not be inlinable [-Wattributes]
 LinuxDriverSyncReadTSCs(uint64 *delta) // OUT: TSC max - TSC min
 ^~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:294: recipe for target '/tmp/modconfig-rRcJiJ/vmmon-only/linux/driver.o' failed
make[2]: *** [/tmp/modconfig-rRcJiJ/vmmon-only/linux/driver.o] Error 1
Makefile:1492: recipe for target '_module_/tmp/modconfig-rRcJiJ/vmmon-only' failed
make[1]: *** [_module_/tmp/modconfig-rRcJiJ/vmmon-only] Error 2
make[1]: Leaving directory '/usr/src/linux-4.11-rc1'
Makefile:120: recipe for target 'vmmon.ko' failed
make: *** [vmmon.ko] Error 2
make: Leaving directory '/tmp/modconfig-rRcJiJ/vmmon-only'
....................................
 CC [M] /tmp/modconfig-rRcJiJ/vmnet-only/bridge.o
/tmp/modconfig-rRcJiJ/vmnet-only/userif.c: In function ‘VNetUserIfRead’:
/tmp/modconfig-rRcJiJ/vmnet-only/userif.c:748:11: error: implicit declaration of function ‘signal_pending’ [-Werror=implicit-function-declaration]
 if (signal_pending(current)) {
 ^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:294: recipe for target '/tmp/modconfig-rRcJiJ/vmnet-only/userif.o' failed
make[2]: *** [/tmp/modconfig-rRcJiJ/vmnet-only/userif.o] Error 1
make[2]: *** Waiting for unfinished jobs....

NVIDIA (378.13 with 4.10 patch):

...............................
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_linux.h: In function ‘__fatal_signal_pending’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_linux.h:212:25: error: implicit declaration of function ‘sigismember’ [-Werror=implicit-function-declaration]
 return unlikely(sigismember(&p->pending.signal, SIGKILL));
 ^
/usr/src/linux-4.11-rc1/include/linux/compiler.h:179:42: note: in definition of macro ‘unlikely’
 # define unlikely(x) __builtin_expect(!!(x), 0)
 ^
In file included from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_utils.c:25:0:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_linux.h: In function ‘fatal_signal_pending’:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_linux.h:217:16: error: implicit declaration of function ‘signal_pending’ [-Werror=implicit-function-declaration]
 return signal_pending(p) && __fatal_signal_pending(p);
 ^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
/usr/src/linux-4.11-rc1/scripts/Makefile.build:294: recipe for target '/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_utils.o' failed
make[3]: *** [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel/nvidia-uvm/uvm_utils.o] Error 1
/usr/src/linux-4.11-rc1/Makefile:1492: recipe for target '_module_/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel' failed
make[2]: *** [_module_/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-378.13-custom/kernel] Error 2
make[2]: Leaving directory '/usr/src/linux-4.11-rc1'
Makefile:152: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.11-rc1'
Makefile:81: recipe for target 'modules' failed
make: *** [modules] Error 2
........................................

Robert Gadsdon.  March 5, 2017

NVIDIA – New 410 Patch – With Hotplug Support..

Thanks to Alberto Milone, there is now a patch for the latest NVIDIA driver, which is reported to include ‘hotplug’ support :https://pkgs.rpmfusion.org/cgit/nonfree/nvidia-kmod.git/plain/kernel_4.10.patch

I can confirm that this compiles OK when applied to driver 378.13, with kernel 4.10.   I am not able to test hotplug functionality, as I do not have a suitable system..   So..  YMMV…

Thanks to Tomas Pruzina for the info, and link..

Robert Gadsdon.   February 22, 2017.

Kernel – 4.10 Released – OK with Patched NVIDIA and VMware..

Kernel 4.10 is out, and brief details of changes from -rc8 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1702.2/02069.html

I have installed this, and the patched versions of VMware 12.5.2 and NVIDIA 378.13 compile and load/run OK.   See previous articles for patch details..    It is worth repeating here, that the NVIDIA patches do not currently include hotplug support..

$ uname -a
Linux rglinux-i7 4.10.0 #1 SMP Sun Feb 19 20:45:44 PST 2017 x86_64 x86_64 x86_64 GNU/Linux

Robert Gadsdon.   February 19, 2017.