Fedora – Fix For Annoying F27 KDE/Dolphin QT Bug..

The latest version of QT5 on Fedora 27 – qt5-qtbase-5.9.6-1.fc27.x86_64 – produces a very annoying display problem in KDE’s Dolphin file manager, where the window does not resize/reformat correctly, leaving large blank areas at each side:

Dolphin window problem..

Dolphin window problem..

This has been identified as a QT5 bug/regression, and a patch is available, at https://codereview.qt-project.org/#/c/233482/

I have applied this, and Dolphin now behaves correctly, again.   QT5 5.10.1-6 on Fedora 28 does not have this problem, but that update is not – yet – available for Fedora 27.

Robert Gadsdon.   June 27, 2018.

Kernel – 4.18-rc2 is Out – Includes fix for VMware Runtime, OK with Latest Patched VMware and NVIDIA.

Kernel 4.18-rc2 has been released, and brief details of changes from -rc1 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1806.3/00112.html

This includes the cmdline fix, which enables the VMware runtimes to execute correctly.   The VMware 14.1.2 vmmon patch is still required (see http://rglinuxtech.com/?p=2322 )

NVIDIA 390.67 compiles OK, with the nvidia-drm-drv.c patch (see http://rglinuxtech.com/?p=2315 )

Robert Gadsdon.  June 24, 2018.

Fedora – Easier ‘Fix’ for F28 Wine..

Wine on Fedora 28 is still broken with some windows apps, and to avoid having to individually download and then run RPM on a series of F27 wine rpms, it is possible to use dnf to do the update/replacement with the – working – Fedora 27 versions.

# dnf update *wine* --releasever=27 --allowerasing --best

This only works with dnf update, so if the F28 version is already at the ‘latest’ version, do a # dnf downgrade wine* first, then do the dnf update… as above.     Best – of course – to run this from an empty directory…

Robert Gadsdon.  June 23, 2018

VMware – New Version of 4.18-rc1 ‘cmdline’ Patch..

As expected, there is another version of the cmdline patch for Kernel 4.18-rc1 – this time from Linus himself.. at  http://lkml.iu.edu/hypermail/linux/kernel/1806.2/03011.html

I have applied this, and – as with the previous version –  VMware now behaves correctly..

I should mention that is is not a good idea to try to copy/paste patches from a website newsgroup listing, as the formatting is usually messed up.    You can still access these messages in their original format by accessing the newsgroup the ‘old-fashioned’ way, using an email client such as Thunderbird, at news.gmane.org.   The group is ‘gmane.linux.kernel‘, but be warned – there are many thousands of messages!

Robert Gadsdon.   June 20, 2018

VMware – Problem with Kernel 4.18-rc1 Found, and a Patch..

Thanks to Michal Kubeček, the source of the VMware problem with Kernel 4.18-rc1 has been found, and a Kernel patch produced:  http://lkml.iu.edu/hypermail/linux/kernel/1806.2/02730.html

I have applied this, and can confirm that VMware (14.1.2 patched) now operates correctly..

The kernel patch now has to run the gauntlet of the LKML ‘review process’, and so may be changed over time, but this version does the job..

Robert Gadsdon.   June 19, 2018.

VMware – Possible Clues to Failure?

OPINION/SPECULATION:

After more tests, I am still encountering the odd behaviour of VMware (14.1.2 with vmmon patch) and Kernel 4.18-rc1, but did notice one possible clue..

Looking at the # systemctl status vmware.service output, it includes the following:

Jun 18 01:02:03 rgtest vmware[5663]: Blocking file system[FAILED]

I think this should not be there, as VMBlock has been obsolete for a long time now, and the functionality has been taken over by kernel code, including FUSE (File system in User Space)..     And… it turns out that there have been some changes to FUSE in 4.18-rc1:   http://lkml.iu.edu/hypermail/linux/kernel/1806.0/01405.html

So.. it may be that changes to FUSE have caused VMware – including userland functions – to be ‘confused’?

More investigation needed, of course..

Robert Gadsdon.   June 18, 2018.

VMware – Odd Behaviour with Kernel 4.18-rc1, and a Workaround?

VMware 14.1.2 worked OK with Kernel 4.17, on my Fedora 28 test system, but after updating to 4.18-rc1 the following occurred:

Modules (vmmon/vmnet) compiled OK, but – after further testing – appeared to have a runtime problem..    I applied the vmmon patches from Michal Kubeček, at https://github.com/mkubecek/vmware-host-modules/commit/3f2a6c720f68 and this also compiled cleanly.

When I ran # vmware-modconfig …. I got the following ‘error’:

# vmware-modconfig --console --install-all
..........................
Received option outside of allowed bounds. Option was -1
........................
Must use a valid mode. Use one of:
............................

So, I tried a manual compile/install of vmmon and vmnet, into /lib/modules/4.18.0-rc1/misc (after creating the ~/misc sub-directory), and then #depmod -a and # modprobe vmmon  # modprobe vmnet..

But then:

# service vmware start
Starting vmware (via systemctl): Job for vmware.service failed because the control process exited with error code.
See "systemctl status vmware.service" and "journalctl -xe" for details.
                                               [FAILED]

and:

# systemctl status vmware.service
● vmware.service - SYSV: This service starts and stops VMware services
Loaded: loaded (/etc/rc.d/init.d/vmware; generated)
Active: failed (Result: exit-code) since Mon 2018-06-18 01:02:04 PDT; 3min 7s ago
Docs: man:systemd-sysv-generator(8)
Process: 5663 ExecStart=/etc/rc.d/init.d/vmware start (code=exited, status=1/FAILURE)
CGroup: /system.slice/vmware.service
├─3879 /usr/bin/vmnet-bridge -s 6 -d /var/run/vmnet-bridge-0.pid -n 0
├─3933 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet1.pid /dev/vmnet1 vmnet1
├─3953 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet1/dhcpd/dhcpd.leases -pf /var/>
├─3964 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vmnet8/nat/nat.conf
├─3969 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet8.pid /dev/vmnet8 vmnet8
├─3985 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet8/dhcpd/dhcpd.leases -pf /var/>
└─4025 /usr/sbin/vmware-authdlauncher

Jun 18 01:02:03 rgtest vmware[5663]: Blocking file system[FAILED]
Jun 18 01:02:04 rgtest vmware[5663]: Virtual ethernet[ OK ]
Jun 18 01:02:04 rgtest vmware[5663]: VMware Authentication Daemon[ OK ]
Jun 18 01:02:04 rgtest systemd[1]: vmware.service: Control process exited, code=exited status=1
Jun 18 01:02:04 rgtest systemd[1]: vmware.service: Failed with result 'exit-code'.
Jun 18 01:02:04 rgtest systemd[1]: Failed to start SYSV: This service starts and stops VMware services.

The userland # vmware command did nothing, and just returned to a command prompt..

After more testing, I found that using the # /usr/lib/vmware/bin/vmware start command actually worked, and resulted in the normal VMware graphical window appearing, and guest o/s (WinXP, and Fedora) started OK, and guest networking seemed to work correctly..

So..  It would appear that the various error messages are somewhat confused, and VMware does actually work, although not in the normal way..

Robert Gadsdon.   June 18, 2018

Kernel – 4.18-rc1 released – Breaks NVIDIA, Fix Available.. Not OK with VMware

Kernel 4.18-rc1 has been released – earlier than expected, but Linus is in Japan, where it was already Sunday..

Brief details are here:  http://lkml.iu.edu/hypermail/linux/kernel/1806.2/00125.html

Tested with VMware 14.1.2, and vmmon/vmnet compile OK, but NVIDIA fails:

 ...............................
CC [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.67/kernel/nvidia-drm/nvidia-drm-drv.o
In file included from /usr/src/linux-4.18-rc1/include/drm/drmP.h:82,
from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.67/kernel/nvidia-drm/nvidia-drm-priv.h:30,
from /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.67/kernel/nvidia-drm/nvidia-drm-drv.c:25:
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.67/kernel/nvidia-drm/nvidia-drm-drv.c:637:23: error: ‘DRM_CONTROL_ALLOW’ undeclared here (not in a function); did you mean ‘DRM_RENDER_ALLOW’?
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
^~~~~~~~~~~~~~~~~
/usr/src/linux-4.18-rc1/include/drm/drm_ioctl.h:162:12: note: in definition of macro ‘DRM_IOCTL_DEF_DRV’
.flags = _flags, \
^~~~~~
make[3]: *** [/usr/src/linux-4.18-rc1/scripts/Makefile.build:318: /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.67/kernel/nvidia-drm/nvidia-drm-drv.o] Error 1
........................

Thanks to HERB. there is a fix for this, at http://mom.hlmjr.com/2018/06/11/nvidia-drivers-390-67-vs-kernel-4-17/

This patch is for 390.67 specifically, and would need modifying for other versions..     I have tested the patch, and it applies cleanly, and 390.67 compiles OK with 4.18-rc1..

UPDATE:  After further testing…  VMware compiles OK, but runtime fails, and even vmware-modconfig does not work:

# vmware-modconfig --console --install-all
[AppLoader] GLib does not have GSettings support.   <--this is an existing warning (non-fatal) 
Received option outside of allowed bounds. Option was -1
Must use a valid mode. Use one of: ......

See comment below, from Michal Kubeček, with more info..    More testing is needed, and the results will be in a new article..

Robert Gadsdon.   June 17, 2018.

Kernel – 4.17 Released – OK with Latest VMware and NVIDIA..

Kernel 4.17 is out, and details of changes from -rc7 are here: http://lkml.iu.edu/hypermail/linux/kernel/1806.0/01332.html

No real surprises, so far, and it is OK with VMware 14.1.2, and NVIDIA 396.24.

Apparently the major version bump to Linux 5.0 might occur at around the Kernel 4.20 mark….

Robert Gadsdon   June 3, 2018.