Subject: Bug#1201: Black window with KDE5 plasma

From: Klaus Fuerstberger <[email-masked]>
Date: Fri, 18 Aug 2017 12:25:58 +0200

Package: x2goserver
Version: 4.1.0.0-0x2go1.2

When starting x2goclient (linux or windows makes no difference) I only
got a blank, black screen as result when selecting KDE as desktop
environment. Starting a single application, for example xterm, works.
This happens after upgrade to Debian 9 and KDE5. The installation is
running without systemd but with sysvinit.

Some Logfile entries when starting the session:

/var/log/syslog:

###################
Aug 18 11:52:35 ork kernel: [ 2692.627128] kscreen_backend[20230]:
segfault at 8 ip 00007f9ed9c294d7 sp 00007ffd14939ee0 error 4 in
KSC_XRandR.so[7f9ed9c13000+23000]
Aug 18 11:52:35 ork kernel: [ 2692.641405] kscreen_backend[20234]:
segfault at 8 ip 00007f70844724d7 sp 00007ffddc3f71f0 error 4 in
KSC_XRandR.so[7f708445c000+23000]
###################

~/.xsession-x2go-errors:

###################
KCrash: Application Name = drkonqi path =
/usr/lib/x86_64-linux-gnu/libexec pid = 20179
KCrash: Arguments: /usr/lib/x86_64-linux-gnu/libexec/drkonqi --appname
krunner --apppath /usr/bin --signal 6 --pid 20120 --appversion 5.8.6
--programname krunner --bugaddress [email-masked] --startupid 0
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
from kdeinit
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/libexec/drkonqi' from
wrapper.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/libexec/drkonqi'
ksmserver: autostart service "/usr/bin/krunner" finished with exit code  9
failed to get the current screen resources
###################
See also https://pastebin.com/m5nJuRJ5 for the full log.

Thanks
Klaus

---

From: Klaus Fuerstberger <[email-masked]>
Date: Sat, 26 Aug 2017 16:15:30 +0200

I uninstalled the binary NVIDIA driver 384.59 and then x2go works as
before. Only VESA drivers are installed because nouveau does not
recognize my graphics card in the version provided by Debian stretch. Of
course running with the VESA drivers is not an option and only for testing.
So it has to do with the current Debian plasma-desktop 5.8.6-1 *and*
with the NVIDIA drivers.

Maybe someone with a newer plasma-desktop and a NVIDIA graphics card can
test this? Ubuntu "zesty" or "artful" do provide newer plasma packages.

Klaus

Am 18.08.2017 um 12:35 schrieb X2Go Bug Tracking System:
> Thank you for filing a new Bug report with X2Go.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  X2Go Developers <[email-masked]>
> 
> If you wish to submit further information on this problem, please
> send it to [email-masked].
> 
> Please do not send mail to [email-masked] unless you wish
> to report a problem with the Bug-tracking system.
>

---

From: Klaus Fuerstberger <[email-masked]>
Date: Mon, 28 Aug 2017 15:46:08 +0200

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

---

From: Mihai Moldovan <[email-masked]>
Date: Fri, 1 Sep 2017 07:18:27 +0200

> 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

---

From: Klaus Fuerstberger <[email-masked]>
Date: Fri, 1 Sep 2017 12:42:41 +0200

> 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

---

From: Mihai Moldovan <[email-masked]>
Date: Sun, 3 Sep 2017 08:30:07 +0200

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

> 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

---

From: E-Mail <[email-masked]>
Date: Mon, 14 Oct 2024 13:40:49 +0000

Ihr E-Mail-Konto läuft am 31. Oktober 2024 ab. Sie müssen Ihr Konto sicher
und aktiv halten, um eine vorübergehende Sperrung zu vermeiden. Befolgen
Sie die Anweisungen, um Ihr Konto zu aktivieren.

KLICKEN SIE HIER FÜR DEN AKTUALISIERUNGSVORGANG
<https://arcarupdate.weebly.com/>

Wenn Ihr Konto nicht aktualisiert werden kann, wird es nach dem
(31.10.2024) automatisch gelöscht.