Service
OpenRC
Set SDDM as the default display manager:
FILE /etc/conf.d/xdm
DISPLAYMANAGER="sddm"
To start SDDM on boot, add xdm to the default runlevel:
Note
The dbus service gets pulled in dynamically.
root #rc-update add xdm default
To start SDDM now:
root #/etc/init.d/xdm start
After logging in to the X session via sddm, it is a good idea to verify that ConsoleKit is working as intended. By typing ck-list-sessions all active sessions can be listed. The list should include your session, typically running on x11-display-device = '/dev/tty7'. This session should also read active = TRUE. Active being FALSE indicates an issue [1][2].
Anyway If you want to keep SDDM and elogind try
apt install openrc
I think the parallel loading of openrc solved any init order issues that may be causing the problem.
]]>The laptop got a new HDD and a clean install of Devuan Jessie yesterday, then upgraded to Ascii but somehow it had pulled in the -systemd variants. I followed the instructions in the lurker link you provided and replaced them with -elogind variants. Now logout, reboot, shutdown from the KDE menu all work as expected.
I still have SDDM as the login manager...
Again, thanks for the quick response. :-)
]]>Here's what was in the dead link.
Author: Irrwahn
Date: 2018-02-14 07:37 -500
To: dng
Subject: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.PLEASE NOTE:
The following only applies to already existing ASCII systems that got
upgraded to the newest package versions as present in the repositories.
Fresh installations of Devuan ASCII 2.0.0 Beta should not be affected.TL;DR
-----
Make sure you got the correct libpolkit-backend installed!Background
----------
It would appear that under certain circumstances an unsuitable flavor
of libpolkit-backend-1-0-XXXX gets pulled in upon upgrade. This can lead
to a temporary loss of desktop session related functionality, namely the
ability to user-mount removable drives or to shutdown/restart the system
using the GUI controls provided by the respective desktop environment. The
issue was ultimately caused by the recent addition of elogind to the
repositories, or rather the repackaging of policykit-1 that followed suit.Resolution
----------
1. Make sure you have at least one of (traditional) consolekit or (new)
elogind installed. (Note: You can have both installed and active; which
one is actually used however is decided by which libpolkit-backend you
choose to install, see 4.)2. Make sure (at least one of) the above is activated. You may do so by
interactively running the 'pam-auth-update' command as root.3. Ensure the following packages got installed:
policykit-1 0.105-18+devuan2.4
libpolkit-agent-1-0 0.105-18+devuan2.44. Install one of the mutually exclusive policykit backend libs, i.e.
- EITHER -
libpolkit-backend-1-0-elogind 0.105-18+devuan2.4 and
libpolkit-gobject-1-0-elogind 0.105-18+devuan2.4- OR -
libpolkit-backend-1-0-consolekit 0.105-18+devuan2.4 and
libpolkit-gobject-1-0-consolekit 0.105-18+devuan2.4depending on which session manager backend you intend to use, see 1.
In case you find you have a backend with -systemd in the name installed:
that one will _not_ work, and is most likely the cause why things went
sideways in the first place.5. After making changes to the session management you should either reboot
the system or at least cycle through runlevel 1.Note: Depending on what login manager you use in conjunction with which
desktop environment you might have to experiment a bit to find out which
of consolekit or elogind works best for you (or works[TM] at all).Bottom line: As always in life, keep your backends covered. ;-)
HTH, HANVD, and enjoy the ASCII Beta!
Best regards
Urban
I have had to add the option "reboot=pci" to the Linux command line in grub, otherwise reboots or shutdowns hang the machine after kernel exits, but I wouldn't expect that to affect this. It seems more like KDE is always doing a "logout" rather than a "reboot" or "shutdown", since SDDM works correctly.
I've checked and I have both eudev and elogind installed... but I don't know how to check if they are working correctly.
Anyone have any suggestions?
]]>steve_v has long since left the building.
steve_v is waiting for a Devuan release that isn't 2+ years behind Debian, and he still gets mail alerts.
Meanwhile, he's running a systemd-free rolling release, one with a modern desktop that works properly now.
He's running Devuan on servers though, where appallingly ancient software isn't such a problem.
]]>@Miyo . . . steve_v has long since left the building. But he did test after I asked him to see if elogind fixed things and he said:
Yes, power management in KDE now works, if eudev & elogind are installed.
Ahhh...okay. Hey...I might give it another go too then!
]]>Yes, power management in KDE now works, if eudev & elogind are installed.
I eventually had to replace Plasma, because it was running one of my CPUs at 100% all of the time. Again, that was months ago, so I can't speak for how things are now.
]]>I'm not (yet) familiar with the changes in Devuan, is plasma's power management functionality completely broken sans systemd or am I just doing it wrong?
Everything else appears to work, and the various blah-kits are doing their thing, at least as far as I can tell. There's some other layer between plasma and console-kit / upower etc. yeah?
Anyone had better luck here?
Off topic, what's the plan for the release cycle after stretch / ascii? Aiming for parallel with debian's stable releases or one behind? I'm guessing the former, as I hear rumors of tracking testing as well...
]]>