I tested an KDE Neon LTS 5.8 (based on Ubuntu xenial) and KDE Neon 5.9 (based on Ubuntu zesty) on my system. With both distributions, nouveau and mesa glx is running fine. Also connecting with x2go to an x2goserver installed is no problem. After compiling and installing the mentioned latest NVIDIA driver, x2go fails again to launch KDE plasma.
Klaus
On 08/28/2017 03:46 PM, Klaus Fuerstberger wrote:
I tested an KDE Neon LTS 5.8 (based on Ubuntu xenial) and KDE Neon 5.9 (based on Ubuntu zesty) on my system. With both distributions, nouveau and mesa glx is running fine. Also connecting with x2go to an x2goserver installed is no problem. After compiling and installing the mentioned latest NVIDIA driver, x2go fails again to launch KDE plasma.
This is likely the cause because the nVidia driver installs its own libGL version.
This is fine as long you only ever use the machine locally, but fails badly in use cases such as X2Go.
Typically it might be possible to ignore the directory in which the package installs this special libGL version and thus making sure that the MESA-gl version is being used. Not a trivial task to do from X2Go's viewpoint, since the libGL directory is hardcoded within the system's ld.so.conf file.
Mihai
Am 01.09.2017 um 07:18 schrieb Mihai Moldovan:
On 08/28/2017 03:46 PM, Klaus Fuerstberger wrote:
I tested an KDE Neon LTS 5.8 (based on Ubuntu xenial) and KDE Neon 5.9 (based on Ubuntu zesty) on my system. With both distributions, nouveau and mesa glx is running fine. Also connecting with x2go to an x2goserver installed is no problem. After compiling and installing the mentioned latest NVIDIA driver, x2go fails again to launch KDE plasma.
This is likely the cause because the nVidia driver installs its own libGL version.
This is fine as long you only ever use the machine locally, but fails badly in use cases such as X2Go.
Typically it might be possible to ignore the directory in which the package installs this special libGL version and thus making sure that the MESA-gl version is being used. Not a trivial task to do from X2Go's viewpoint, since the libGL directory is hardcoded within the system's ld.so.conf file.
The nvidia driver installer removes the conflicting mesa drivers and especially /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
If I backup this library bevor installing the nvidia driver and change one symbolic link pointing to the systems library then x2go works fine.
# cd /usr/lib/x86_64-linux-gnu # ls -l libGL.so lrwxrwxrwx 1 root root 10 Sep 1 10:46 libGL.so -> libGL.so.1
The nvidia one #ls -l libGL.so.1 lrwxrwxrwx 1 root root 14 Sep 1 11:09 libGL.so.1 -> libGL.so.1.0.0
rm libGL.so.1 # The original library of the system ln -s libGL.so.1.2.0 libGL.so.1
Of course this workaround does not function, when started with the x2go Xsession, because the user has no write permissions in /usr/lib/x86_64-linux-gnu.
I wonder why x2go worked bevor with KDE4 and the nvidia drivers.
Klaus
On 09/01/2017 12:42 PM, Klaus Fuerstberger wrote:
The nvidia driver installer removes the conflicting mesa drivers and especially /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
If I backup this library bevor installing the nvidia driver and change one symbolic link pointing to the systems library then x2go works fine.
Are you really using the nVidia installer package? You shouldn't do that. Instead, use the packages your distribution provides. They do things differently and more importantly correct from a distribution viewpoint.
For instance, they won't be removing MESA's libGL version.
Debian (and probably thus also Ubuntu) uses its alternatives system to select the libraries provided by different implementations, one of which is nVidia.
I don't know how it's done on other systems, but they probably do something like that as well.
Of course this workaround does not function, when started with the x2go Xsession, because the user has no write permissions in /usr/lib/x86_64-linux-gnu.
I wonder why x2go worked bevor with KDE4 and the nvidia drivers.
No idea, but software changes. Maybe nVidia's libGL was just compatible enough to work previously, but now isn't.
In any case, we never intended to use anything but MESA's libGL.
Just today I've had a report of a user that all Qt5-based applications didn't work any longer on his system (Debian Buster). Turned out that the nvidia drivers were installed and that this was the culprit.
When we switched to MESA's implementation via sudo update-alternatives --set glx /usr/lib/mesa-diverted, things started to work again.
Sadly, while this might fix X2Go sessions, it's not a viable option for users who also want to use their machines directly.
Also, sadly, I didn't yet come up with any means of overriding libGL and whatever other library is being switched from X2Go Server's scripts. I'd like to just always force the MESA libraries for X2Go sessions only, but this stuff is rooted deep into the system.
Mihai
-
Klaus Fuerstberger -
Mihai Moldovan