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