Hi Marc, On Thu, Feb 26, 2026 at 09:28:29PM +0100, Helmut Grohne wrote: > Ok, I can keep trying a bit. Possibly, we can replicate this in a debvm. > Though not right now.
I looked into reproducing the problem in a defined environment. debvm-create -o greetd.debvm -r unstable -- --include=foot,greetd,libpam-systemd,linux-image-amd64,sway --hook-dir=/usr/share/mmdebstrap/hooks/useradd debvm-run -i greetd.debvm -g Some explanation: * foot is useful as sway is relatively useless without a terminal or menu. * greetd is what we are testing. * Without libpam-systemd, nothing sets up XDG_RUNTIME_DIR and sway gets unhappy. * We request linux-image-amd64 instead of the default linux-image-cloud-amd64 to get graphics drivers. * sway is our target command from greetd. * The useradd hook is quite clever. It causes a non-root user (default "user") to be added. It also attempts to configure automatic login by various means including lightdm and *drumroll* greetd. So it takes care of editing the config.toml and adding the initial_session section you mentioned earlier. * The -g option for debvm-run requests graphical mode. This test case is unreliable. Try booting the machine several times. I am storing the debvm image on tmpfs to rule out speed variance from the storage stack. I tried this both with and without dbus-broker and got similarly mixed results. Sometimes, sway starts and sometimes it fails. In the minimal example (compared to the physical system I earlier tried), I am not seeing much going on after greetd is being started. I tried adding After=basic.target, but even that did not reliably fix it. Thanks for insisting to dig deeper as my naive workaround evidently is insufficient. Ansgar pointed out that systemd-cat cant redirect a given command's output to the journal. So I attempted wrapping sway in systemd-cat and got an error: | 00:00:00.003 [ERROR] [wlr] [backend/session/session.c:331] Failed to open device '/dev/dri/card0': Resource temporarily unavailable Not sure what we can do about this. Apparently one reason for this can be that the vt is not active. However, greetd's switch defaults to true and has not been changed, so it really should be active. I'm a bit lost as to what we can do here. At least we have an (unreliable) test case now. Would you be able to independently verify my reproducer? Any further ideas for debugging? Helmut
