Am Dienstag, 24. November 2015, 08:24:43 schrieb Werner Flamme:
But my actual question was what $WINDOWMANAGER is set to.
startx only takes DEFAULT_WM from /etc/sysconfig/windowmanager when $WINDOWMANAGER is not defined, but even in this case it would set $WINDOWMANAGER appropriately. So posting the value of $WINDOWMANAGER would show what startx *really* runs. I'll do when I'm starting this Laptop next time. The WINDOWMANAGER variable is set in non-GUI mode also, right?
Yes. /etc/profile.d/profile.sh sets it too (by evaluating /etc/sysconfig/displaymanager)..
I started the thread on November 19, so that was the day I did the last updates.
And since then you cannot login to KDE?
Long ago. First time I wrote about that on this list was 2015-03-31 in posting <551A7866.7020405@ufz.de>, Subject "Re: [opensuse-factory] [TW-20150328]".
Back then, KDE4 was the default KDE desktop in Tumbleweed, and yes, this needs (needed) krandrstartup. But back then this problem didn't exist as the KDE4 desktop was still officially supported, and it required kscreen which of course still existed as well and did contain (a dummy) krandrstartup.
The problem with the missing krandrstartup only started about a month ago, because kscreen and the dependency on it was removed..
My problem back then had absolutely nothing to do with krandrstartup.
Obviously, that's what I wrote. But you mentioned that you had similar problems back then...
But a missing login screen is a completely different problem again. The login screen doesn't use krandrstartup either.
Maybe you should start afresh and actually explain your exact problems.
Ahem... I did.
The problem was the non-appearnace of any Icon or applet or plasmoid or anything for NetWorkManager. That's why this thread got the Subject line it still has. This problem is solved.
Yes, but we are talking about your desktop not starting without krandrstartup now. (probably the subject line should be changed...) And then you suddenly mentioned that you don't get a login screen either. So I'm not completely sure any more what your actual problems are in this regard. In particular: is this also related to krandrstartup missing, or does this happen even if it's there?
Only a "BTW" at the end of the OP referred to the file /usr/bin/krandrstartup. I never knew it existed until I found in my .~/xsession-errors file that it was missing, and thus my GUI did not start.
But a last time: krandrstartup is only used by the KDE4 desktop. Nothing in a standard Plasma5 installation uses it. If Plasma5 doesn't start without it, something is wrong on your system. Or, in other words, if
I installed krandr. Felix Miata proposed that in <56332B7A.2060802@earthlink.net> on October, 30.
AFAIK Felix Miata uses/used KDE4. And for that you do need krandrstartup.
However, his reply was about a user having "Plasma".
"Plasma" is the name of KDE's desktop since version 4.0 eight years ago. So yes, somebody who runs the KDE4 desktop *is* a user having "Plasma".
Plasma5 is the latest generation of KDE's desktop, it is based on Qt5 (instead of Qt4), KDE Frameworks 5 (instead of kdelibs4), and again, it doesn't use nor need krandrstartup because krandr has been removed completely.
startkde, started on tty6, gives me $DISPLAY is not set or cannot connect to the X server.
As written before, you can only run startkde inside an already existing X session.
So the setting 'DISPLAYMANAGER_STARTS_XSERVER="yes"' in /etc/sysconfig/displaymanager is just there to raise confusion?
Don't mix up things, please. This option is completely irrelevant here.
If you are in text mode, there is no display manager running, obviously.
And startkde is no display manager either, it's a shell script that starts all necessary components of a KDE desktop. And as mentioned, it needs to have an Xserver already running.
Just in case you don't know, the display manager is the Login Screen.
The problem you described can only happen if you locked kdebase4-workspace and actively blocked the installation of Plasma5.
Obviously, it can occur under other circumstances too.
No.
Why do you say that it cannot occur under other circumstances than locking kdebase4-workspace and actively blocking the installation of Plasma5?
Again, because Plasma5 doesn't use nor need krandrstartup, krandrstartup is not even available any more.
Well, after installing the krandr package I found a file /usr/bin/krandrstartup on my disk, and the GUI started again.
Of course. krandr contains krandrstartup, as krandrstartup is the tool to apply krandr's settings. But a last time: krandrstartup is only used by the KDE4 desktop. Nothing in a standard Plasma5 installation (or even in the whole distribution, except for kdebase4-workspace, of which krandr is actually a part of) uses it, because krandr doesn't exist any more (it was unmaintained since years already anyway, and replaced by kscreen). If Plasma5 doesn't start without it, something is wrong on your system. Or, in other words, if something on your system needs krandrstartup, it cannot come from a current openSUSE package. So, you should find out *what* exactly wants to run krandrstartup, and remove/fix that. E.g. the grep line I suggested would be a first start. Installing krandr is the wrong workaround. It might even break/override your Plasma5/kscreen5 display settings...
And I never copied another startkde from elsewhere to replace that startkde script that is in the system. Nor did I edit this file.
Well, you might have restored it from an older backup or snapshot by mistake. How should I know?
You know by me telling you. You have no other way. I never had to restore a backup to a system partition.
Yeah, but you didn't tell that until now. Just because you didn't mention it, doesn't rule it out. It would have been one possibility why you would have an outdated startkde on your system. And krandrstartup is (only) being called by KDE4's startkde to apply the display settings on login. So having an outdated (KDE4) startkde was the most obvious reason IMHO. But meanwhile it is clear that your startkde is ok, anyway...
.xsession-errors is not used any more, it should rather be called .xsession- errors-:0, or depending on which displaymanager you use, the logs might (only) go to systemd's journal.
Ah - those were symlinked, I remember. And sysstemd's jornal will hopefully reach it through to the standard syslog, won't it? Many messages are passed by, so I hope I find display messages in /var/log/messages too (/var/log/Xorg.0.log and /var/log/Xorg.1.log do not show errors, just a clean shutdown).
If you have a syslog daemon running, it should get forwarded to /var/log/messages, yes. But there's not much difference whether you browse the huge messages file or the systemd log I suppose. Hint: run journalctl -b to only get the entries from the current boot. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org