Fedora – 26-27 DNF Upgrade Woes, and a Workaround..

After upgrading four Fedora systems (x86_64) from release 26 to 27, using # dnf system-upgrade download --refresh --releasever=27 --allowerasing --nogpgcheck --best -y, two of these worked OK, but two failed – with a sudden reboot, back to F26 – and no (apparent) error displayed, after # dnf system-upgrade reboot had rebooted the system, and the upgrade process had started, but before the actual rpms were processed:

dnf[914]: 7f83cc874000-7f83cca73000 ---p 00030000 08:03 7865985 /usr/lib64/libexpat.so.1.6.6
dnf[914]: 7f83cca73000-7f83cca76000 r--p 0002f000 08:03 7865985 /usr/lib64/libexpat.so.1.6.6
dnf[914]: 7f83cca76000-7f83cca77000 rw-p 00000000 00:00 0
dnf[914]: 7f83cca77000-7f83cca9c000 r-xp 00000000 08:03 7896214 /usr/lib64/librepo.so.0
dnf[914]: 7f83cca9c000-7f83ccc9c000 ---p 00025000 08:03 7896214 /usr/lib64/librepo.so.0
dnf[914]: 7f83ccc9c000-7f83ccc9d000 r--p 00025000 08:03 7896214 /usr/lib64/librepo.so.0
dnf[914]: 7f83ccc9d000-7f83ccc9e000 rw-p 00026000 08:03 7896214 /usr/lib64/librepo.so.0
dnf[914]: 7f83cccb8000-7f83cccf8000 rw-p 00000000 00:00 0
dnf[91reboot: Restarting system
..............   (system reboots, into F26 again..

I had encountered a similar problem before, and was able to work out a – rather convoluted – workaround..

In this upgrade, the F27 rpms are resident at /var/lib/dnf/system-upgrade , and each repo has its own sub-directory – the repo ID followed by a uuid-style numerical string, eg:  fedora-cba4cf65782eccda , updates-09879b494aeba108 , rpmfusion-free-093775106f01a54b etc..    In each of these, the F27 upgrade rpms – if there are any – are in the packages sub-directory..  If there are no upgrade rpms for a particular repo, then the packages sub-directory will not exist..

As root, I created a temporary directory and copied each group of F27 rpms to this, so that the update/upgrade could be done all-at-once..  Then I checked for the kernel….xxx rpms, and installed (not updated!) these by # rpm -ivh kernel*rpm --nodeps --force , and then deleted them..   After that, I updated all the remaining F27 rpms:  # rpm -Uvh *rpm --nodeps --force , and waited for this to complete (which takes some time!).      After that, I simply re-booted the system, and it came back up – correctly – as Fedora 27.

Robert Gadsdon.   November 15, 2017.                   (updated Nov 25, to clearly show double-dash in rpm commands, which normally get merged in ‘publishing’, and have to be handled in raw html!




Kernel – 4.14 Released – OK with Latest NVIDIA and – Patched – VMware

Kernel 4.14 is now out, and brief details – including updates from -rc8 – are here:  http://lkml.iu.edu/hypermail/linux/kernel/1711.1/03305.html

As expected, the latest NVIDIA drivers (384.98 and 387.22) are OK with this release, and VMware 14.0.0 – with the vmmon patch ( see http://rglinuxtech.com/?p=2090 ) – is OK as well..

Robert Gadsdon.  November 12, 2017.

Kernel – 4.14-rc8 Released, After All..

Kernel 4.14-rc8 is out, and brief details of changes since -rc7 are here: http://lkml.iu.edu/hypermail/linux/kernel/1711.0/03395.html

This might have been 4.14 ‘final’ but there were still too many changes to warrant that..    Th 4.14 ‘final’ release may be slightly delayed, as it would now clash with the US ‘Thanksgiving’ holiday..

The latest NVIDIA drivers (384.98 and 387.22 beta) both compile and load/run OK, and VMware 14.0.0 – with the vmmon patch – is OK.     On my system, I have had runtime problems (Firefox crashing, etc..) with the NVIDIA 387.xx drivers, so far, and so am still using 384.98.

Robert Gadsdon.  November 6, 2017.

Audacity – New Major Release – Compile Fix, for Portaudio..

After some considerable time, there is a new major version of Audacity – 2.2.0 – with a new-improved UI, amongst other things..

As I needed this ASAP, and did not want to wait for the (uncrippled) RPM to come out, I decided to compile it myself, with all useful options included..

I got the following error on compiling:

AudioIO.cpp:(.text+0x174): undefined reference to `PaUtil_GetTime'
audacity-AudioIO.o: In function `audacityAudioCallback(void const*, void*, unsigned long, PaStreamCallbackTimeInfo const*, unsigned long, void*)':
AudioIO.cpp:(.text+0xcb8c): undefined reference to `PaUtil_GetTime'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:2348: audacity] Error 1

I tried adding an explicit reference to the portaudio header file in AudIO.cpp, but this did not make any difference..   After more research, I found that you have to specify –with-portaudio=local in the configure options.    My configure options were then:

../configure –prefix=/usr –enable-shared –with-ffmpeg –with-lame –with-libflac –with-libid3tag –with-libmad –with-libtwolame –with-libvorbis –with-lv2 –with-portaudio=local –with-midi –with-portmidi

– and this now compiled OK, and (so far..) works just fine..    Not sure why this portaudio option was not the default

Robert Gadsdon.    November 4, 2017


VMware – Potential Fix for W/S 14 Performance/Memory Issues..

I had found that although VMware 14.0.0 installed OK with Kernel 4.13, the runtime performance was rather ‘sluggish’, and others have reported more serious memory issues…

There is a patch that may help with this – and thanks to Roke for reporting this, and to mkubecek for the actual patch..

Details are in this posting, on the VMware forum:  https://communities.vmware.com/thread/572935

I have applied this to VMware 14.0.0 running on Kernel 4.13.9, and have found – so far – that a Win7 guest appears to be more responsive than before..

Robert Gadsdon.   October 23, 2017.

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

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:


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..

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..

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..

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.