Hm. I have a tendency to suspect NVIDIA (partially due to my own biases from recent experiences), but if iGPUs are experiencing the same issue then I doubt it’s an NVIDIA problem. The next guess would be package interactions. Has anyone posted journalctl output yet?
In order to fix the issue, the patch in question should either be reworked to preserve ABI compatibility or removed entirely.
Rebuilding layer-shell-qt from source caused the issue to stop reproducing, confirming suspicions of ABI breakage.
However, the tickets where fcitx5 is involved don’t seem to go through that same binary and class, so the interaction might be different there. (Will try to find a stack trace illustrating that.)
Sorry - I realised I had a brain freeze in my earlier post - edited it, and will expand further here.
The machine that I saw the issue on was my laptop (Intel iGPU and no dGPU), not my machine with NVidia.
I had held off updating to 6.9.1-2 on my desktop (AMD CPU, NVidia GPU), but I gave it a try.
With the proprietary NVidia drivers and 6.9.1-2, there was no apparent problem with the lockscreen - locking and unlocking appeared as normal. Despite that though, in journalctl, a segfault did appear related to libLayerShellQtInterface:
kernel: kscreenlocker_g[3185]: segfault at 9a ip 00007f1f3648419d sp 00007ffcd646f150 error 4 in libLayerShellQtInterface.so.6.4.1[319d,7f1f36481000+7000] likely on CPU 7 (core 7, socket 0)
With nouveau and 6.9.1-2, I couldn’t even start a Plasma session because SDDM blackscreened. Excerpt of a stack trace
With nouveau and 6.9.1-1, there was no such problem and the system worked as normal.
So in fact, it seems like systems with the proprietary NVidia drivers may be one case where the problem with libLayerShellQtInterface can be recovered from without user-visible consequences.
If that’s not possible, my understanding is that it’s possible to use rpm-ostree override replace to override the package to the previous good version, something like:
I’m also having this issue with kscreenlocker complaining about a segfault from libLayerShellQtInterface.so
I can temporarily fix it by removing kscreenlocker_greet’s cache folder, but it’s pretty short lived and a few minutes later goes back to being broken.
Running on an Intel i9-14900K, using the iGPU. I do have a Nvidia card, but it’s dedicated to vfio/gpu passthrough for a vm and isn’t used by the host.
Jul 02 09:30:11 fedora kscreenlocker_greet[16195]: qml: The backend got an unknown wallpaper provider type. The wallpaper will now fall back to the default. Please check your wallpaper configuration!
Jul 02 09:30:11 fedora audit[16195]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=16195 comm="kscreenlocker_g" exe="/usr/libexec/kscreenlocker_greet" sig=11 res=1
Jul 02 09:30:11 fedora kernel: kscreenlocker_g[16195]: segfault at b8 ip 00007fb2a5d5919d sp 00007ffeef99cd00 error 4 in libLayerShellQtInterface.so.6.4.1[319d,7fb2a5d56000+7000] likely on CPU 11 (core 20, socket 0)
Gonna try downgrading and see what happens I guess
Edit: downgrading qt6-qtwayland fixed it
Edit2: Realized I just replied to the last message rather than the thread. Woops.
To me it doesn’t look related to the issue in this thread.
My (not very confident) guess would be some kind of filesystem corruption when power was lost. But other folks with more BTRFS knowledge can hopefully tell you more about this.
If you’ve got Timeshift or similar set up, you could boot into a Live USB and then run it from there to restore to a known good restore point. Not saying this would fix it, but probably the first thing I would try.
A fixed version 6.9.1-3 has now been released to stable Fedora 42. This version reverts the problematic change in 6.9.1-2 and restores the behaviour of 6.9.1-1.
In that case it sounds like something is probably corrupted, so I guess my next step would be to try reinstalling the OS while leaving the home directory in place. I’d also strongly recommend getting a backup solution in place, Timeshift is good: How to Setup Timeshift with BTRFS in Fedora? - GeeksforGeeks
You might want to open another thread looking for help before doing anything that has the potential to erase your data, as your issue is likely not related to the one in this thread.
At first I’ve got the black screen. After a little while I tried another sudo dnf update and it updates mesa to 25.0.7-2. A reboot made things running again.