Display manager (login screen) issues

This is mostly commenting on what I have recently noticed.

1: Using “lightdm”

For various reasons, I switched to “lightdm”. That worked fine, and I logged into Plasma. But, shortly after login, I was prompted for the password for “kdewallet”. This was a surprise. I am using “kwallet-pam” and it is supposed to automatically open “kdewallet”. Apparently that does not work when using “lightdm”. I will probably report this as a bug, but I’ll wait a day to see if there are any comments here.

I normally use “gdm” or “sddm”, and those work fine with “kwallet-pam”. For testing, I also tried “xdm” and “kdm”. And both of those also are fine with “kwallet-pam”. Only “lightdm” is giving problems.

2: Console

When I run

update-alternatives --config default-displaymanager

to change the display manager, there is an option for “Console”. And I had no idea what that was supposed to do. So, while experimenting, I decided to give it a try. This was with Tumbleweed in a VM.

After switching, I rebooted. And it never finished booting. The messages showed a failure to start displaymanager, and a waiting (no-limit). To me, this seems like a bug. Either “Console” should not be an option, or I should at least be able to finish booting if I select that option. Again, I’ll wait a day to see if there are any responses, before I decide whether to post a bug report.

NOTE: To recover, I did a forced power-off. And then I rebooted, adding a “3” to the end of the boot command. That got me to a command line boot, where I was able to run “update-alternatives” to revert to using “sddm”.

See xdm changelog. It is intended to simply exit display manager startup script without starting any GUI.

The messages showed a failure to start displaymanager, and a waiting (no-limit).

display-manager.service is of type forking, and in case of “console” start script simply exits without going through proper daemon startup so this is indeed failure from systemd point of view. I am not sure what it is waiting indefinitely for. Looking on current TW, display-manager.service has standard 90s timeout. May be there is some other unit that depends on it, you did not say what systemd was waiting for.

Anyway, bug is definitely in order, “console” alternative does not work as intended with systemd.

P.S. I just restarted TW VM with console alternative and I do not see any waiting. It reports failure to start display manager and goes to console login prompt. I disabled plymouth (plymouth.enable=0), may be it is related.


I’ll try again tomorrow. This is in a VM, so I can easily take a screenshot of the boot screen.

As far as I know, Plymouth is active but not showing its spash screen (I removed “splash=silent” from boot command line).

I have filed bug reports for both of these issues:

Bug 1102588The “lightdm” displaymanager does not honor pam_kwallet

Bug 1102584Setting default-displaymanager to “console” makes system unbootable

Yes, “Hold until boot …” comes from plymouth which was not started in my case.

Interesting. Thanks. I may try without Plymouth.