Your log doesn’t say that lightdm didn’t start, it actually started successfully…
But, it also says that you had an existing remote session already running on the display you attempted to connect to (:1) which is why your connection attempt failed.
So,
Be sure you log out of all your sessions before disconnecting.
You may need to figure out why you have an already running session. I also noticed that you seem to have two authorized User accounts, could your “other” authorized User be logged in already?
I guess I wasn’t explicit about this. This happens straight after I power up the machine as part of the boot sequence, so there is certainly no remote session running. At the end of this there is no X environment at all (only a tty), so I wouldn’t count that as a successful start of lightdm…
I’ll just add a quick note (or reference point) that I am not having this problem. I do use “lightdm” and it is still starting reliably. I most recently updated yesterday (20160816). I see there’s another update there, but I’ll probably wait till tomorrow before updating.
I guess I still wasn’t clear enough. There are no remote apps of any kind, no VNC, nothing. Just me working on the console.
Since this morning things have changed though. No idea why, but lightdm now starts automatically. However, X has significant problems getting my mouse to work correctly. I had to to restart X something like 6 times before the mouse worked normally, before that it was completely non-functional. Unplugging it and plugging back in didn’t help either (only tried that once though). It is a wireless Logitech mouse connected to the docking station. I have seen this problem before, it seems to pop up randomly, but never this extreme. Lately it seemed to have become even less and I hadn’t seen it for weeks. But now it seems to be back more extreme than ever… I will see how this develops, but any ideas what could be causing this would be welcome.
Docking station? External monitor attached? Have you tried comparing the behaviour when connected and when not connected to the docking station? Just in case it is impacting with the graphical environment. I can only speculate about the mouse, and I assume the batteries are good, and that it behaves ok with other machines (assuming you have other hardware available to test with).
It is rather inconvenient to test the mouse directly on the laptop, but not impossible, so I will try that if it reoccurs. The NiMH battery in the mouse is quite old, but still gets me through the day without problems. What I do know is the following. I did “grep -i mouse” on /var/log/Xorg.0.log. The result of that looked identical (apart from the timestamps) when the mouse was either working or not working. So the basic detection of the hardware seems to work OK.
OK, yes I see now that the problem is your your local graphical session (VT7)
These are the critical log entries you posted which indicate that for whatever reason VT7 was unavailable because it’s already being used
+1.11s] DEBUG: Activating VT 7+1.11s] DEBUG: Activating login1 session 1
+1.11s] DEBUG: Seat seat0 changes active session to 1
+1.11s] DEBUG: Session 1 is already active
+1.17s] DEBUG: Session pid=1489: Greeter closed communication channel
+1.17s] DEBUG: Session pid=1489: Exited with return value 0
+1.17s] DEBUG: Seat seat0: Session stopped
Can’t imagine why something/someone else is already logged in to VT7 when it becomes time for <you> to log in…
Maybe you’d have to inspect the preceding few hundred (or more) entries to see if there are entries for a prior login.
Am considering whether the error in your log is misleading…
Maybe the system <assumed> that VT7 was unavailable because of a prior login when maybe that might not be the actual reason… that the graphical interface just wasn’t initiated yet (in other words a timing issue which shouldn’t have happened. Reason might be a missing or incorrect dependency).
Without trying to dig into exactly how your boot sequence might be off,
You might simply do a complete and thorough re-install (more than the usual that happens in a normal “zypper dup”)
You can try running the following, and then go do something else because it will probably run well over an hour…
“zypper dup” does not reinstall the system, it just upgrades it.
If there are no updates/upgrades, nothing will happen.
And the --replacefiles option only tells it to ignore file conflicts, i.e. if a file is contained in more than one package at the same time.
From “zypper dup --help”:
--replacefiles
Install the packages even if they replace files from other,
already installed, packages. Default is to treat file conflicts
as an error. --download-as-needed disables the fileconflict check.
Agreed,
After some testing, verified that although I didn’t interpret the helpfile explanation the same way, Wolfi’s interpretation/description is accurate.
After doing some more investigation, I’d throw out a wild guess, you can re-install the base packages which would be a no-risk shotgun try…
You can try the following which only fix your problem
zypper in -f aaa_base aaa_base-extras
You can inspect the contents of these two packages to see what is being re-installed, for example
The problems with starting lightdm haven’t disappeared completely. It now seems that I have roughly a 50-50 chance of hitting the problem or just have a normal boot. So a timing issue sounds quite plausible where vt7 is not ready in time for lightdm to start. How could this be investigated further?
The lightdm.log was current.
I am not prepared to do a full reinstall of my system. That seems to be a really desperate measure. I have reinstalled the aaa_base rpms. Let’s see if that works, but I am not holding my breath…