excalibur/KDE non-root X11 session is broken

grunchy · 2025-10-11 23:15:00

using devuan_excalibur_6.0.0-rc1_amd64_desktop.iso i just created an excalibur+kde+sddm qemu vm.

one of the nice things about this update is that X11 can be run as non-root.

with kde/sddm it is as simple as adding "DisplayServer=x11-user" to a sddm config file.

i tested this with a debian trixie qemu vm and it works as advertised, but it does not work with excalibur.
something in the hand-off from sddm to X goes badly and all i get is a black screen with a blinking cursor.

if "DisplayServer=x11" is used, then VT number 2 is used and X starts up without issue.

in contrast, the debian vm log file shows the hand-off using VT number 1 and systemd-logind taking over.

the "X11-user" log shows VT number 7 being used. here is a snippet from that Xorg.0.log:

[     8.128] (++) using VT number 7

[     8.128] (II) seatd_libseat init
[     8.128] (II) [libseat/libseat.c:73] Seat opened with backend 'seatd'
[     8.128] (II) [libseat/backend/seatd.c:212] Enabling seat
[     8.128] (II) seatd_libseat enable
[     8.128] (II) seatd_libseat handled 2 events
[     8.228] (II) seatd_libseat client activated
[     8.228] (II) xfree86: Adding drm device (/dev/dri/card0)
[     8.228] (II) Platform probe for /sys/devices/pci0000:00/0000:00:01.0/drm/card0
[     8.228] (II) seatd_libseat try open graphics /dev/dri/card0
[     8.228] (II) seatd_libseat opened graphics: /dev/dri/card0 (1:14)
[     8.230] (--) PCI:*(0@0:1:0) 1af4:1050:1af4:1100 rev 1, Mem @ 0xfa800000/8388608, 0xfcc00000/16384, 0xfea14000/4096, BIOS @ 0x????????/131072
[     8.231] (II) LoadModule: "glx"
[     8.231] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[     8.231] (II) Module glx: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.16, module version = 1.0.0
[     8.231]    ABI class: X.Org Server Extension, version 10.0
[     8.231] (==) Matched modesetting as autoconfigured driver 0
[     8.231] (==) Matched fbdev as autoconfigured driver 1
[     8.231] (==) Matched vesa as autoconfigured driver 2
[     8.231] (==) Assigned the driver to the xf86ConfigLayout
[     8.231] (II) LoadModule: "modesetting"
[     8.231] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[     8.231] (II) Module modesetting: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.16, module version = 1.21.1
[     8.231]    Module class: X.Org Video Driver
[     8.231]    ABI class: X.Org Video Driver, version 25.2
[     8.231] (II) LoadModule: "fbdev"
[     8.231] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[     8.231] (II) Module fbdev: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.3, module version = 0.5.0
[     8.231]    Module class: X.Org Video Driver
[     8.231]    ABI class: X.Org Video Driver, version 25.2
[     8.231] (II) LoadModule: "vesa"
[     8.231] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     8.231] (II) Module vesa: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.15, module version = 2.6.0
[     8.231]    Module class: X.Org Video Driver
[     8.231]    ABI class: X.Org Video Driver, version 25.2
[     8.231] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     8.231] (II) FBDEV: driver for framebuffer: fbdev
[     8.231] (II) VESA: driver for VESA chipsets: vesa
[     8.231] (EE)
Fatal server error:
[     8.231] (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
[     8.231] (EE)
[     8.231] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[     8.231] (EE) Please also check the log file at "/home/xyz/.local/share/xorg/Xorg.1.log" for additional information.
[     8.231] (EE)
[     8.231] (II) seatd_libseat finish
[     8.232] (EE) Server terminated with error (1). Closing log file.

as you can see there is a permission problem with VT number 7. it is not clear to me if the problem is due
to using VT7 instead of VT2 or if VT7 is the correct choice but permissions are such that non-root user cannot
access VT7.

how can i debug this further?

ralph.ronnquist · 2025-10-12 00:22:04

It used to be that the user running Xorg has to be owner of the associated tty, i.e. /dev/tty7 in your case. How does it compare with /dev/tty2 permissions in the working use case?

Though I don't know anything about sddm or KDE.

stargate-sg1-cheyenne-mtn · 2025-10-12 06:05:25

i try to read all the new posts in an attempt to continue my education

and so i did a search and figured i might as well include it here for the future addicted autodidacts

https://start.duckduckgo.com/lite/?q=excalibur+kde+sddm+qemu+vm

also since i did it...

https://start.duckduckgo.com/lite/?q="sddm"

https://linuxconfig.org/how-to-customize-the-sddm-display-manager-on-linux

another intriguing thought occurred regarding vt handoffs since just yesterday i was reviewing grub entries on a dual boot machine with windows eleven and xubuntu 24.04.3 and saw something similar(that i don't believe i had ever witnessed before iirc)...anywho, enjoy!

more since i just experienced it(again, ha!)...

i get significantly different search results by using/not-using quotation-marks(double quote marks actually as seen above with "sddm") as well as searching with/without browser add-ons such as noscript, privacy badger, ublock origin, etc. activated(just thought i would add that as it seems to be relevant to the encouragement of others regarding current-day internet searches/searching/etc), as always - ymmv.

Last edited by stargate-sg1-cheyenne-mtn (2025-10-12 06:20:15)

grunchy · 2025-10-16 21:29:09

after a couple of days chasing this problem and not finding anything, i gave up and destroyed the vm.

re-creating the vm from the same iso worked as designed and sddm was able to create a non-root X11 session.

just to be sure, i went thu the install six more times, varying the steps to move from the default Xwayland session to the x11-user session. in all cases the non-root X11 session was created.

so i am at a loss to explain what happened on that first, buggy install

¯\_(ツ)_/¯

my apologies for the noise

on a side note, i did go down the sddm rabbit-hole looking for possible clues to this error, but could not find anything like what i encountered. but, there are multiple bug reports of 'black screen, blinking cursor'. this must be what happens when X11 fails at startup.

sddm is quite the mess and the maintainers are moving to wayland-only, no X11, as well as deprecating sysv init support to better align with systemd behavior. this is despite pleas from multiple people, both linux and bsd camps. as an old fart and an outsider to coding these days, i cannot fathom how a "simple" display manager has become such a bloated, tangled mess. geez

so excalibur may well be the last version of devuan to support KDE desktop

EDX-0 · 2025-10-16 21:48:53

so more reason to get lightdm rootless x11 working, mind you it is not an easy task even if it looks like so...

https://github.com/canonical/lightdm/pull/127

if anyone figures the code to get the displayfd method working or is able to at least find which display managers works in that manner to be able to port the code onto lightdm that would be the ideal solution as it is always easier to just yank existing code from someone else than writing it up from nothing...

another idea would be to build a display manager from the ground up that can just be "lazy" and try to route the x11 starting through the xserver-command from the xserver-xorg-legacy package to force the xorg server into starting with dropped priviledges.

Last edited by EDX-0 (2025-10-16 21:49:48)

The officially official Devuan Forum!

#1 2025-10-11 23:15:00

excalibur/KDE non-root X11 session is broken

#2 2025-10-12 00:22:04

Re: excalibur/KDE non-root X11 session is broken

#3 2025-10-12 06:05:25

Re: excalibur/KDE non-root X11 session is broken

#4 2025-10-16 21:29:09

Re: excalibur/KDE non-root X11 session is broken

#5 2025-10-16 21:48:53

Re: excalibur/KDE non-root X11 session is broken

Board footer