Devuan bug report logs -
#937
elogind: SwayWM fails to launch from vTTY: Could not take device: No such file or directory
Full log
🔗
View this message in rfc822 format
Hi Nathan,
On Fri, Jan 23, 2026 at 01:24:02PM -0600, Nathan Schulte wrote:
> Upon upgrading to elogind packages version 255.17-4, SwayWM
> fell/"crashed" back to vTTY, and is no longer able to be started,
> producing the log attached. The log is produced with the command:
>
> > sway --debug --verbose &> sway-$(date -u -Im).log
>
> elogind service is running with this upgrade, and the system is
> practically virgin (a fresh install). However, the only way I've managed
> to launch Sway is by downgrading elogind packages to version 255.17-3.
> Reboots, both warm and cold, do not resolve the issue, nor does any
> amount of waiting.
The change between these two versions of elogind is a new initscript,
for two purposes:
1) To simplify the script using init-d-script(5).
2) To enable use of the sd_notify(3) protocol during elogind startup so
that the service is not deemed to have started until it is actually
ready to service requests. This is to prevent problems with other
services assuming elogind is ready when it is not just because those
services had expressed a startup dependency on elogind.
The scenario that (2) is trying to fix is:
LSB header for service A expresses dependency on elogind
T
|
+ elogind service started
|
+ service A started
|
+ service A tries unsuccessfully to use elogind functionality
|
+ elogind is ready to service clients
The new ordering should be:
T
|
+ elogind service started
|
+ elogind notifies start-stop-daemon that it is ready
|
+ service A started
|
+ service A successfully uses elogind functionality
So in theory this should be an improvement, but it will change timings
and could have adverse side effects if not everything else is correct.
Take this situation:
LSB header for service A expresses dependency on elogind
Service B relies on service A but does not express this dependency.
T
|
+ elogind service started
|
+ service A started
|
+ service B started
|
+ elogind is ready to service clients
|
+ service A successfully uses elogind functionality
|
+ service B successfully uses service A functionality
... everything is fine - by chance.
But with the new behaviour, timings could change things to be like this:
T
|
+ elogind service started
|
+ service B started
|
+ service B tries unsuccessfully to use service A functionality
|
+ elogind is ready to service clients
|
+ service A started
|
+ service A is ready to service clients
Now it is far from clear that this is what is actually happening but it
is a possible cause.
Would you mind sharing the file /etc/init.d/.depend.start, please, so we
can see what the dependency chain is on your system? That might reveal
if there is an issue similar to the Service A/Service B interactions
I've described above.
Another possibility other than that is that a service gets in which sets
some system features up incorrectly as a fallback which elogind would
have set up correctly. We sometimes see that sort of thing with cgroups
mounts, for example.
Another user has also suggested something to eliminate (1) as a cause of
this regression. You could reinstall version -4 of the package and edit
the following variable as such:
DAEMON_ARGS="-D"
START_ARGS=""
i.e. putting the behaviour back how it was but with the structure of the
new version of the initscript.
> Thank you for your attention.
>
> -- System Information:
> Distributor ID: Devuan
> Description: Devuan GNU/Linux 7 (freia/ceres)
> Release: 7
> Codename: freia ceres
> Architecture: x86_64
>
> Kernel: Linux 6.18.5+deb14-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
>
> -- no debconf information
> 00:00:00.000 [INFO] [sway/main.c:321] Sway version 1.11
> 00:00:00.000 [INFO] [sway/main.c:322] wlroots version 0.19.1
> 00:00:00.001 [INFO] [sway/main.c:78] Linux desmas-l-fa617xt 6.18.5+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.5-1 (2026-01-16) x86_64 GNU/Linux
> 00:00:00.001 [INFO] [sway/main.c:94] Contents of /etc/os-release:
> 00:00:00.001 [INFO] [sway/main.c:78] PRETTY_NAME="Devuan GNU/Linux 7 (freia/ceres)"
> 00:00:00.001 [INFO] [sway/main.c:78] NAME="Devuan GNU/Linux"
> 00:00:00.001 [INFO] [sway/main.c:78] VERSION_ID="7"
> 00:00:00.001 [INFO] [sway/main.c:78] VERSION="7 (freia/ceres)"
> 00:00:00.001 [INFO] [sway/main.c:78] VERSION_CODENAME="freia ceres"
> 00:00:00.001 [INFO] [sway/main.c:78] ID=devuan
> 00:00:00.001 [INFO] [sway/main.c:78] ID_LIKE=debian
> 00:00:00.001 [INFO] [sway/main.c:78] HOME_URL="https://www.devuan.org/"
> 00:00:00.001 [INFO] [sway/main.c:78] SUPPORT_URL="https://devuan.org/os/community"
> 00:00:00.001 [INFO] [sway/main.c:78] BUG_REPORT_URL="https://bugs.devuan.org/"
> 00:00:00.001 [INFO] [sway/main.c:94] Contents of /etc/debian_version:
> 00:00:00.001 [INFO] [sway/main.c:78] forky/sid
> 00:00:00.001 [INFO] [sway/main.c:66] LD_LIBRARY_PATH=
> 00:00:00.001 [INFO] [sway/main.c:66] LD_PRELOAD=
> 00:00:00.001 [INFO] [sway/main.c:66] PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> 00:00:00.001 [INFO] [sway/main.c:66] SWAYSOCK=
> 00:00:00.001 [INFO] [sway/main.c:351] Starting sway version 1.11
> 00:00:00.001 [DEBUG] [sway/server.c:236] Initializing Wayland server
> 00:00:00.001 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:64] Could not connect to socket /run/seatd.sock: No such file or directory
> 00:00:00.001 [INFO] [wlr] [libseat] [libseat/libseat.c:76] Backend 'seatd' failed to open seat, skipping
> 00:00:00.004 [INFO] [wlr] [libseat] [libseat/libseat.c:73] Seat opened with backend 'logind'
elogind does seem to be operational here and has opened a session or
whatever.
> 00:00:00.004 [INFO] [wlr] [backend/session/session.c:108] Successfully loaded libseat session
> 00:00:02.439 [ERROR] [wlr] [libseat] [libseat/backend/logind.c:124] Could not take device: No such file or directory
> 00:00:02.439 [ERROR] [wlr] [backend/session/session.c:331] Failed to open device: '/dev/dri/card0': Resource temporarily unavailable
This is the failing call:
ret = sd_bus_call_method(session->bus, "org.freedesktop.login1", session->path,
"org.freedesktop.login1.Session", "TakeDevice", &error, &msg, "uu",
major(st.st_rdev), minor(st.st_rdev));
> 00:00:02.444 [ERROR] [wlr] [libseat] [libseat/backend/logind.c:124] Could not take device: No such file or directory
> 00:00:02.445 [ERROR] [wlr] [backend/session/session.c:331] Failed to open device: '/dev/dri/card1': Resource temporarily unavailable
> 00:00:02.446 [ERROR] [wlr] [backend/backend.c:245] Found 0 GPUs, cannot create backend
> 00:00:02.446 [ERROR] [wlr] [backend/backend.c:420] Failed to open any DRM device
> 00:00:02.460 [ERROR] [sway/server.c:247] Unable to create backend
Thanks!
Andrew
Send a report that this bug log contains spam.