Wolfgang Bauer [23.11.2015 16:40]:
Am Montag, 23. November 2015, 09:46:31 schrieb Werner Flamme:
startx takes the command to run from the environment variable $WINDOWMANAGER (if you run it without arguments). To what is this set?
In /etc/sysconfig/windowmanager, KDE is configured.
"KDE" is not valid there. It should either be "kde-plasma" or "plasma5".
I did not put "KDE" there. I'm not a complete idiot, though it may seem so. Since I can't see into the file right then, I only wanted to give the impression that there is no "gnome" or whatever.
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? On my 13.2 office pc it is set to "/usr/bin/startkde".
But startx cannot be run as user at all with the default setup.
That's right, but I wrote a file to /etc/permissions.d, which causes /usr/bin/Xorg set 4755, so I can start X as a user.
Good, then it should work as user too.
It does. I *can* start X as a user :)
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.
But not being able to login seems to be related to PAM, not to KDE. The Logon window appears, but the Login is rejected. Now, there was not even that Login Screen.
A broken PAM setup can definitely break login too, yes.
I know. I fought with pam_mount for years. You'll find my posts on various openSUSE lists, or even before (SUSE mailing lists). SUSE was the recommended Linux distro in our company before our boss decided we had to support Ubuntu instead.
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. 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.
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.
If krandrstartup would still be required, *all* fresh Leap and Tumbleweed installations would be broken as I already mentioned, and this would definitely be caught by openQA too.
I do and did none of that, and though I have that problem. So, for me it is obvious that there are other circumstances possible.
I don't know what you do or did. But this is not possible with Plasma5 in *any* circumstance.
If your startkde script runs krandrstartup (and fails because of that not existing), you are not using Plasma5's startkde script.
I repeat: A Plasma5 installation doesn't contain krandrstartup, and nothing in the Xorg or Plasma5 startup process runs krandrstartup
Plasma5's startkde does *not* (and never did) use or need krandrstartup. If it would, all fresh Tumbleweed and Leap installations would be broken, as krandrstartup doesn't exist there.
The output of "rpm -qf $(which startkde)" showed you that there is Plama5 installed.
Yes, it did. But the startkde script in the package plasma5-workspace does not even mention the word "krandr".
If your Plasma5 session doesn't start without krandrstartup, something is broken with your installation. Try reinstalling plasma5-workspace to make sure you use the original, unmodified, Plasma5 startkde script.
sudo zypper in -f plasma5-workspace
Although your grep below seems to indicate that startkde is ok anyway.
Thanks for noticing. And please do not believe that I did not reinstall plasma5-workspace and plasma5-session and plasma5-desktop and whatnot.
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.
If your startkde tries to run krandrstartup, you somehow use the KDE4 version, i.e. your installation is/was broken.
Obviously, though a "grep -i randr $(which startkde)" shows no output. The same is valid for "grep -i randr $(which startx)".
So startkde does not run krandrstartup obviously. And it's clear that startx doesn't, because startx is independent of KDE.
Well then, if it's really a missing krandrstartup that causes your desktop failing to start, if must be run by some other script in the startup process (which is not done on a standard installation). Check the xinit scripts in /etc/X11/xinit/ and the .xinitrc in your home folder (if it exists).
grep -R randr /etc/X11/xinit/ ~/.xinitrc
Btw, does it work without krandrstartup on a fresh user account? Then the problem would rather have to be looked for in your home folder, not your installation.
However, I have a line in .xsession-errors stating that the session ends (before any graphic mode was reached) because /usr/bin/krandrstartup wasn't found.
And what's the timestamp of the file?
It was the current timestamp, and the file was very short.
.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). Regards, Werner --