Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Hi,
This is a follow-up to my submitted bug report (#1110357).

Here is more context:

I am using Debian 13 RC2, fresh install with KDE.

Logging into the Plasma Wayland session fails to initialize $WAYLAND_DISPLAY. That variable is completely missing (echo $WAYLAND_DISPLAY outputs nothing), while XDG_SESSION_TYPE=wayland is set.

As a result, critical KDE daemon services like kded6 crash in a loop. Qt-based applications and KDE components log the error:

Failed to create wl_display (No such file or directory)
qt.qpa.plugin: Could not load the Qt platform plugin "wayland"

kglobalaccel never starts → global keyboard shortcuts (e.g. Fn key) are broken.

The KDE session appears half-loaded, with icons and panel, but no core functionality.

Workaround:

Logging in via Plasma X11 works properly — all daemons and shortcuts OK.

Attached log is from:

journalctl -b | grep -Ei '(wl_display)'

Let me know if you'd like me to attach that file or preview its contents.

Arthur

Hi,

thanks for your bugreport.

The interesting bit here is what greeter you use to start your KDE session.
As the greeter is responsible to start wayland and set the environment
variables.

Please share the name and logs of the greeter.

At least from my point of view everything looks working. I checked:

* I am running a KDE Wayland session started by SDDM ( the default greeter
used by task kde) and I see the environment variables. (But any other greeter
with wayland support should work. ) If you use any other greeter please try to
test with sddm.
* The live images tests are able to start session (and they use wayland
session):
https://openqa.debian.net/tests/overview?distri=debian-live&version=trixie&build=20250731&groupid=18

Regards,

hefee

Hi,

Thanks for the quick reply regarding bug #1110357.

As requested, here is some more detail:

I'm using SDDM, as installed by Debian 13 RC2 via the KDE installation ISO. I have not manually installed another greeter only thing i′ve done is to add pam_u2f to use my yubikeys for login.

Desktop starts visually but functionality is broken: keyboard shortcuts don’t work, KDE Connect fails, at first it′s not really obvious. I′ve seen because my volume shortcuts were not working, and keyboard shortcut part of the settings had an error.

Please let me know if you need other logs.

Thanks again for your help.

Arthur

Hey,

mmh the sddm logs look normal.

* Did you check with a fresh user or with a packed home from before?
* Did you checked without pam_u2f? At least pam modules are able to control
environment and maybe block some env variable to end up in the users env.

I understood that part and your analysis that the underlying issue is that the
environment is missing the needed variables sounds very plausible.
The question is why does your system do not set the env correctly.

regards,

hefee

I′m sorry because it′s far beyond my what i′m used to on linux but this is what i found.

You were right, after several tries, i find that it breaks only after making changes related to YubiKey, but only breaks on Wayland sessions. X11 sessions still works well.

The main workaround i identified is to revert pam.d config, to create a new user. And after not putting back yubikey logging not to break the new user.

Issue is existing users continue to face issues with Wayland sessions after reverting configuration about yubikey. So i dropped my idea to use yubikey for logging for now as i prefer to stay on wayland and made a new user.

Just for context, i tried on gnome with GDM and yubikey config didn′t broke session in x11 and wayland.

I forgot to add the two modified pam.d files causing the issue.

For gnome i also modified GDM the same way as SDDM.

I hope it can be useful.

Hey,

Me too. I never dived into the pam system.

I reassign to pam-u2f, as it somehow the connection between sddm and pam-u2f.
As sddm maintainers are already in the feedback loop ( because sddm is pkg-qt-
kde umbrella), I just throw it over the fence to pam-u2f.

To get hopefully some information, what may explain why sddm+pam-u2f won't set
$WAYLAND_DISPLAY. Maybe you simple need to setup pam-u2f differently with Sddm
and Wayland?

Regarding the config files - can you please share the diff you did against the
default config. So far I see, that you disabled pam_u2f in the configs you
share, correct?

Okay thanks for this data point. You can also try to use GDM to start a KDE
Wayland session? As there is no need to use SDDM ;)

Regards,

hefee

Hey,

Me too. I never dived into the pam system.

I reassign to pam-u2f, as it somehow the connection between sddm and pam-u2f.
As sddm maintainers are already in the feedback loop ( because sddm is pkg-qt-
kde umbrella), I just throw it over the fence to pam-u2f.

To get hopefully some information, what may explain why sddm+pam-u2f won't set
$WAYLAND_DISPLAY. Maybe you simple need to setup pam-u2f differently with Sddm
and Wayland?

Regarding the config files - can you please share the diff you did against the
default config. So far I see, that you disabled pam_u2f in the configs you
share, correct?

Okay thanks for this data point. You can also try to use GDM to start a KDE
Wayland session? As there is no need to use SDDM ;)

Regards,

hefee

I wanted to let you know that switching to GDM as the display manager resolves the login/session issue for me—everything works correctly now with GDM and KDE plasma 6.3.6.
On SDDM it was still unstable even without pam-u2f, as new users the first time they entered in wayland session were working fine. And the second time the same issue appeared again.
GDM feels more stable in my installation.

As requested, I have already shared my previous PAM.d configuration files.

For now, I’m reinstalling my system to have a clean and working OS. However, I plan to try to reproduce the bug in a VM if possible after official debian 13 release, and will report back if I can confirm it.

I hope this information is helpful for debugging.

Thank you for your assistance.
Arthur