black screen and cursor, and nothing more
1i5t5.duncan at cox.net
Sat Aug 18 00:27:19 BST 2018
dep posted on Fri, 17 Aug 2018 15:28:22 +0000 as excerpted:
> i'm making an attempt to switch from trinity desktop environment to
> whatever version of plasma is installed when one installs
> kubuntu-desktop in ubuntu 16.04. window manager is kwin.
> when i select plasma at the login screen, all seems to go well but for
> the appearance not of plasma but of a black screen with a mouse cursor.
> no clicking of either button produces anything, and the only escape is
> ant-f1, login, and rebooting from there.
Gentoo here, so no knowledge of (k)ubuntu specifics, and I don't use a *DM
graphical login manager, preferring instead a text-based login and
running (effectively) startx from the CLI, with plasma set as my session,
so little knowledge of DM specifics either.
But that said, I've seen and trouble-shot similar issues with plasma
session only giving me a blackscreen here, and from my experience at
least, it's not entirely uncommon when first switching to plasma5 from
something else (I had the problem some time ago when first trying to
switch from kde/plasma4, tho obviously plasma5 was less mature and still
buggy at that point, so it might have been expected, tho the 16.04
version suggests you're running 2+ years outdated so it could well have
similar bugs long since fixed in anything current) so perhaps I can
1) As RJVB suggested, try logging in at the CLI (command-line interface)
login prompt and starting plasma (startx, etc, you may have to put "exec
startkde" as a line in your user's ~/.xinit so it knows to start a kde/
plasma session instead of something else). As I said above, that's what
I use here, so even if it doesn't work (and apart from any help RJVB may
be with it as well), it'll give us something closer to an equivalent
starting basis to compare notes on.
2) The unresponsive black screen, but with a mouse cursor, indicates that
X is starting, thus the mouse cursor, but that at least the plasmashell
component of plasma, which provides the desktop GUI "shell", is not
starting. However, plasma is several components, and other components
may be starting... or not. What we need to debug now is exactly how far
it's getting in the startup process and where it stops, and then, once we
know that, why whatever component is crashing.
3) If we're lucky, krunner will at least be running, and you can run
stuff from it. The default hotkeys to invoke it should be (IIRC, I've
customized mine) either alt-F2 (the older one) or alt-space (newer, may
not be in early 2016-vintage plasma5 yet). See if that brings up at
least a run dialog. If it does, you can run konsole or the like from
there, and use it for further troubleshooting. And note whether anything
started has a titlebar; if not, kwin's probably not running, if so, it,
or at least /some/ window manager, must be running.
4) Either from konsole, if krunner was working so you could start konsole,
or by switching VTs and doing a CLI login, with X still running in the
Try getting a list of running programs. htop is my preferred tool for
this, but you may have to install it. Else use top (hint: to quit either
top or htop, just hit "q"), or just a bare "ps aux", but htop makes
things easier so I'll assume you installed it if necessary.
In htop, you can hit F1 to get a list of the keyboard shortcuts. We want
a tree view, so (back in regular mode) use F5 or t to get that. Then use
the arrows or search for each of a number of X and plasma components, to
see what children they have (thus using htop's tree mode, which makes
this *much* easier) and thus how far the sessions startup got.
* kdeinit5: running...
kdeinit5 is a kde/plasma component that (normally) starts a bunch of
others. On a "normal" session, children should include ksmserver (which
should in turn start kwin, kwin_x11 in current), kded5, klauncher, and
likely others. kded5 and ksmserver in particular are critical core
plasma components that if they aren't running will severely cripple a
plasma session, with ksmserver starting kwin as the window manager as
well, so if it doesn't run, you probably won't have kwin running either.
And while we're talking kwin, early in the plasma5 cycle and again later
when there were opengl problems, kwin crashing was in fact what was
stopping me from a plasma session, but in those cases, it would crash and
respawn a few times before popping up a dialog (naturally without a
titlebar since now window manager was running) saying it was crashing and
asking me if I wanted to try a different window manager. But I don't
have any other WMs installed here, so I couldn't. You aren't getting
that popup so this isn't likely to be your problem, but just saying it
/can/ be a problem.
* krunner (or with a path, /usr/bin/krunner or similar, depending on
where your distro puts it).
As mentioned this is a separate component, deliberately, to provide some
hope of at least being able to launch something to fix the problem if
plasmashell crashes. If you start things from krunner and they don't
detach themselves, they'll be listed as children of krunner.
* plasmashell (with a path, /usr/bin/plasmashell or similar)
This is unlikely to be listed, as if it's running you should get a
desktop. But it could have been started and then locked up such that
it's still listed, which would definitely point the finger directly at
plasmashell as being if not the problem, at least a big part of it.
* /bin/sh /bin/startx (or more likely for you /usr/bin/startx)
Only if you're launching startx/plasma from the CLI; AFAIK this won't
appear if you're running from a *DM graphical login.
Here (current kde-frameworks and kde-plasma from live-git using the
gentoo/kde overlay live-git build packages, a 2016-vintage version of
another distro's kde/plasma may differ slightly), startx has xinit as a
child, which has /usr/libexec/Xorg (with various parameters) and /bin/sh /
bin/startkde (likely /usr/bin/startkde for you) as children, and startkde
in turn has kwrapper5 /usr/bin/ksmserver as a child.
To the extent that you have those processes and children running, you
should have a reasonably normal plasma session. To the extent they're
/not/ running, they either weren't started, or started and crashed. So
this should help quite a bit with debugging.
* You should also have, either as a child of systemd --user, if ubuntu
had adopted systemd by then, or launched by something else if not,
/usr/bin/dbus-daemon --session ... other parameters. Actually, IIRC the
user's dbus session not starting was the problem for me at some point, so
that might be it.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde