You are not logged in.
Pages: 1
I run Ceres with no DE or display mgr. It's a console login and xinit starts a Fluxbox desktop.
Did aptitude update/upgrade yesterday. For maybe 6/8 months, an elogind upgrade killed the desktop. Elogind was to be upgraded so I dropped to the console to install the upgrades. When complete, entered xinit and got no screen, no desktop.
Used the Excalibur repo, downgraded the upgrades and the desktop worked. A process of elimination found these interdependent pkgs were the problem:
[DOWNGRADE] elogind:amd64 255.17-4 -> 255.17-2
[DOWNGRADE] libelogind0:amd64 255.17-4 -> 255.17-2
[DOWNGRADE] libpam-elogind:amd64 255.17-4 -> 255.17-2
Upgraded them again this morning and booted with different kernel, no desktop. Downgraded again and now on hold.
Xorg logs in ~/.local and parts 1 and 2 in /var
https://secureshare.in/local-Xorg.0.log
https://secureshare.in/var-Xorg.0.log-1
https://secureshare.in/var-Xorg.0.log-2
Would appreciate any insight into what those upgrades changed to cause this problem.
Thanks!
Last edited by fanderal (2026-01-23 21:56:55)
Offline
I don't know how much help this will be, but I am currently running ceres in a qemu vm with all three of the 255,17-4 pkgs with xfce4 desktop and the 6.18.5+deb14-amd64 kernel without any problems.
Offline
with xfce4 desktop
Thanks for replying. My guess ATM is the 255-17.4 upgrades were built with display mgrs in mind and haven't gotten around to OSs without one. An Xfce DE uses slim or lightdm, so no problem.
It's unstable
and not the first time holding back upgrades for while has been necessary.
Log example:
Before upgrade and after downgrade, when xinit brings up the desktop, the local Xorg log shows:
[ 76525.071] _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
The /tmp/.X11-unix owner/group are my user name. If owner/group changed to root, no display, which suggests a permissions issue.
No Xorg log msg like above with upgrade and xinit failed, because owner/group of /tmp/.X11-unix had been changed to root. As root, I changed owner/group to my user name. Went back to my user acct but xinit failed because /tmp/.X11-unix owner/group had been auto-changed in a few seconds back to root. Tried # chmod 1777 /tmp but that also failed.
Anyone with wiser eyes than mine see something in the logs that stands out?
Last edited by fanderal (2026-01-24 02:00:28)
Offline
I'm running ceres in qemu with openbox and no display manager. I use startx to get a graphical session. It's working normally with elogind 255.17-4 and friends. I notice you didn't list libelogind-compat. That also got upgraded with the others here. I also have seatd and libseat1 installed. If you're missing any of those, maybe adding them would fix it. That's a guess.
Offline
Appreciate what you posted, fsmithred. Neither xinit nor startx worked with the upgrade. I didn't list libelogind-compat because it was already installed and upgraded to 255.17-4. When I downgraded the three pkgs above there was no dependency issue, so libelogind-compat remains upgraded and the desktop works.
Been a long time since using openbox. If after month or so and an update doesn't resolve anything with fluxbox, openbox may well be a good replacement.
Seatd is not installed but libseat1 is a dependency of xserver-xorg-core. Tried seatd last year thinking it would use less memory. For whatever reason, it used more memory. Other than trying seatd for a a few days, been using elogind + dependencies + the two recommends (libpam-elogind and polkitd) for a long while in Ceres without issues.
I upgraded the three pkgs and tried users, staff and operator as owner/group, but all were changed back to root when starting the desktop. One of those three 255.17-4 pkgs will not allow any owner/group for /tmp/.X11-unix other than root, and immediately changes it to root when another owner/group is used.
Not ideal but is there a way to prevent or override the change to root as owner/group for /tmp/.X11-unix?
Offline
This looks like https://bugs.devuan.org/cgi/bugreport.cgi?bug=937 - for which I must take blame as it was an enactment of my suggestion, but it is really not clear how it can be causing these problems. If anyone is handy with dbus logs there are some to decode there.
Online
Thanks, abower, good to know. Until I understand something of the changes made in one or more of those elogind 255.17-4 pkgs, your bug report (thanks for the link) and how our issues may or may not relate, you're absolved of any blame. ![]()
Offline
@fsmithred I did what's below to see if the openbox desktop worked for me as it does for you.
[REMOVE, NOT USED] menu:amd64 2.1.51
[INSTALL, DEPENDENCIES] libobrender32v5:amd64 3.6.1-12+b4
[INSTALL, DEPENDENCIES] libobt2v5:amd64 3.6.1-12+b4
[INSTALL, DEPENDENCIES] libstartup-notification0:amd64 0.12-8+b1
[INSTALL, DEPENDENCIES] linux-base-6.18.5+deb14-amd64:amd64 6.18.5-1
[INSTALL] linux-image-6.18.5+deb14-amd64:amd64 6.18.5-1
[INSTALL] obconf:amd64 1:2.0.4+git20150213-3+b1
[INSTALL] openbox:amd64 3.6.1-12+b4
[REMOVE (PURGE)] fluxbox:amd64 1.3.7-1+b1
[UPGRADE] elogind:amd64 255.17-2 -> 255.17-4
[UPGRADE] libelogind0:amd64 255.17-2 -> 255.17-4
[UPGRADE] libpam-elogind:amd64 255.17-2 -> 255.17-4
Although it slows the OS considerably, I installed and rebooted to the latest kernel and edited .xinitrc for openbox. Neither xinit nor startx started the openbox desktop.
I downgraded the elogind pkgs to 255.17-2 and openbox started the desktop with xinit and startx.
Curious that with the 255.17-4 elogind pkgs installed, seatd allows a window mgr desktop to start from the console, but not elogind.
Offline
Good news: we've worked out (on the bug) why this happens and are discussing the most appropriate patch to the elogind source which lets us benefit from the intended changes in the latest package.
Online
Pages: 1