Hello, Im trying to activate Remote administration in 42.1 but when I click “Allow remote administration” in settings - progress bar appear than got somewhere about 66% and than “crash” - crash mean that Plasma 5 turn off and only terminal appear with prompt to login:
Is here somebody with same issue or can you help me somehow? I dont know which way to investigate…
and exactly what you clicked on to select “Remote Administration.”
I suppose the corresponding module in YaST.
Is there a proprietary graphics driver involved? (nvidia, fglrx)
Plasma5 won’t work then, as those drivers break Mesa and its software OpenGL renderer, and hardware acceleration won’t work via VNC…
Also, make sure that the same user is not already logged in locally.
You cannot run Plasma twice for the same user at the same time. That was a “problem” in KDE4 already.
I’m having exactly the same issue (well not only plasma, but whole X server crashes at “restarting service” step). I’m using integrated Intel gpu HD4000. After crash and reboot VNC is activated according to YaST, but when I’m trying to connect to it I’m getting just black screen. nmap shows open vnc ports though. If i remember well, on Factory it was caused by some specific tigerVNC version, but it never happened to me before with tigerVNC installed from DVD
Is installation of openSUSE 13.2 the only way to get VNC working with Nvidia and KDE/Plasma? Leap 42.1 open source Nvidia drivers do not work at all (total hang in about two minutes, known problem) and if VNC does not work any more with closed source Nvidia drivers -> no hope?
I had no problem with VNC and closed source Nvidia drivers in openSUSE 13.1 but with Leap 42.1 it does not work any more…
Ha ha and too bad! I installed openSUSE 13.2 and now all my problems are solved. Support for openSUSE 13.2 should continue at least one year. Maybe then it is time for Leap.
Ok so I needed something more up to date than OpenSUSE 13.2, Factory is also bugged as hell especially when you try to update packages, so decided to try to set it up on Arch. And actually I did not manage to make it work on Arch with similar result to one on Leap. But I think I might found out why it crashes on Leap.
So I’ve read through how to actually create setup like one made by YaST manually and it’s done via xinetd with some rules. IBM website mentions that it also requires XDMCP support to be enabled in login manager in order to work BUT… Actually when I googled how to enable XDMCP support in SDDM (which is default KDE5 login manager) and it seems that SDDM does NOT support XDMCP, not yet, and in fact it may even never implement it as it’s “meant to” work with waland. So I think it may be not possible at all to make it work the “old way” with SDDM and KDE5. I haven’t tried with GDM or some other display manager but I guess it’s worth trying. Right now I’m installing Factory 13.2 it should work for at least half a year till I’ll have some time to deal with this problem for a while.
If someone would try with other manager I’d be graceful for info if it works so I could move back to Leap.
Did you know that SDDM means “Simple Desktop Display Manager”? It is evidently designed by clever people, since simplicity is the highest intellectual achievement, as distinct, say, from X Window System.
SDDM doesn’t even allow user selection from list at login (why bother who the other users are; just type in your name). Now, with simplicity in mind, do you need to add complexity to your life and look into remote desktops?
When the leaped VNC server runs in Gnome, it is still impossible to log in via VNC, but the message on crash screen is different. It is the famous “Oh no! Something went wrong!” message. Here is an example:
Gnome message is usually do to incorrect or broken video drivers. Gnome requires openGL to be available if not it displays that message. NVIDIA driver mods the X stack which breaks things for other drivers.
Yes, it is quite new, and it is intended to be “simple” when it was first designed.
So what?
If you don’t agree with those “clever people”, design your own. Or use a different one that exists already.
SDDM doesn’t even allow user selection from list at login (why bother who the other users are; just type in your name). Now, with simplicity in mind, do you need to add complexity to your life and look into remote desktops?
Then you are not using the default theme.
But you know what?
The theme is configurable. Most of them do show a user list, even the default ones. Some don’t.
So it is not a sddm or KDE problem.
More likely an OpenGL problem as already mentioned by me in this thread.
I am not sure how to check whether openGL is available in Gnome, but glxgears works in Gnome and in KDE.
Yeah, but you are not using OpenGL directly, but rather over VNC.
Nvidia breaks the Mesa installation, and in particular Mesa’s software renderer.
GDM, GNOME, SDDM, and Plasma5 require a working OpenGL implementation.
nvidia’s hardware accelerated OpenGL support obviously doesn’t work over VNC…
You basically have those options:
remove nvidia and use nouveau
don’t use a desktop over VNC that requires OpenGL, which is probably a better idea anyway with VNC
I agree, login manager must be simple. And it is good that the product matches its description. Reminded me even simpler login managers of some twenty years ago.
And there is some reason in not showing user names. Like, for example, some pots and cups, that are manufactured without handles. Sure, there is a reason for that.
The more complex login manager - I think it was the default one from opensuse - didn’t work correctly. Needed debugging, some knowledge of Linux, and help in this forum. Perhaps because it had one level of complexity more - tried to show user names! - but unsuccessfully before debugging.
After debugging, correcting errors, editing configuration files, I selected that one.
However, previous KDE and opensuse were far better in this regard.
However, all this software and the same nvidia card with the same driver work good in opensuse 13.2.
Most of crash debugging output showed crashes in Qt5 libraries. I don’t remember if I have seen a crash report indicating a segfault in an openGL function of nvidia’s libraries. I am not 100% percent convinced that nvidia is at fault here, by diverging from openGL standards. There is a chance that Qt5 calls functions wrong way.
So you think it is the nvidia driver causing crashes?
Good to know that there is a chance they will correct. For new graphic cards, there is release of driver once in several months, with 50 bugfixes. For old cards, there may be a release once in a few years.
But will they change their “overwrite the OpenGL files and links, or don’t install” policy?
It is interesting that competitors of Nvidia are sponsors of Mesa (which provides libraries), while Nvidia is a member of Khronos group that develops the OpenGL standards.
There is this sentence in Wikipedia:
“At XDC2014, Nvidia employee Andy Ritger proposed to enhance EGL in order to replace GBM.”