black screen and cursor, and nothing more

[Duncan]

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

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

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