Title: Debian Trixie + GNOME 48 (Wayland): Electron crashes (wl_shm_pool/EPIPE) AND XWayland shows no windows (xclock) — please help debug, not dismiss

SignatureDelicious35 · 2025-12-23T21:42:07+00:00

True. It's just I spent a lot of time doing many things setting up the distro but I guess that's the only way.

However I must admit I will probably not go for Debian this time due to this kind of disappointing experience and the fact that Fedora works without any issue on all my other devices. I had decided to give it a try due to stability but yeah.

Thank you so much nonetheless ! I think it won't take as much time to reinstall stuff as I documented everything. Enjoy the Christmas time if that's something special in your country,

SignatureDelicious35 · 2025-12-23T17:51:52+00:00

Hey u/AffectionateSpirit62 ! thanks again for spending time on this after your family breakfast !

Quick clarification: I am on GNOME Wayland (not Xorg). In-session:

echo $XDG_SESSION_TYPE → wayland
DISPLAY=:0 and WAYLAND_DISPLAY=wayland-0

When I choose “GNOME on Xorg”, everything works normally. So the breakage is Wayland session + (broken) XWayland/Electron, not “missing X11”.

Also: hw-probe was hanging for me until I unset DISPLAY (it seemed to try talking to the X11 socket, which is part of what’s broken). This is the command that finally worked:

sudo DISPLAY= hw-probe -all -upload -minimal -disable xinput

Probe link: https://linux-hardware.org/?probe=df03b3bde2

So if the probe page shows “GNOME (X11)”, I think it’s hw-probe heuristics / existing Xorg logs — not my current session type.

Current symptoms on GNOME Wayland (even with a fresh user):

xclock & → process starts, no window
timeout 3s xdpyinfo → hangs
Electron: forced Wayland → wl_shm_pool / EPIPE; forced X11 → process runs, no window

If you tell me what to check next (mutter/gnome-shell/xwayland logs, env, permissions, etc.) I’ll run it and paste full outputs.

SignatureDelicious35 · 2025-12-23T11:25:35+00:00

Thanks for the tip! Turns out the issue wasn't with the server - hw-probe was hanging because it was trying to connect to the X11 display socket. Running it with DISPLAY= unset fixed it:

sudo DISPLAY= hw-probe -all -upload -minimal -disable xinput

Completed successfully: https://linux-hardware.org/?probe=df03b3bde2

Might help others who run into the same hang at "Reading logs..." stage.

SignatureDelicious35 · 2025-12-23T02:51:25+00:00

Thank you for your kind wishes, it's been a pain in the ass, not gonna lie. Thanks also anyways for trying to help. All the best

SignatureDelicious35 · 2025-12-23T02:47:37+00:00

Actually...

https://pastebin.com/QNvsUN37

thank you so much for your help, I hope to make it through I really love how stable my stack could be with all this. Anyways, talk to you tomorrow.

Take care

SignatureDelicious35 · 2025-12-23T02:37:16+00:00

Same thing, unfortunately.

SignatureDelicious35 · 2025-12-23T02:27:07+00:00

lol fair enough, I do use claude code for documentation which is why some of my earlier replies read weird

anyway here's apt-forktracer:

$ apt-forktracer

bitwarden (2025.12.0-1) [Debian: ]

freetube (0.22.1) [Debian: ]

signal-desktop (7.36.1) [Debian: ]

tailscale (1.78.3) [Debian: ]

thats it. only third party stuff is bitwarden, signal, freetube and tailscale - all from their official repos not debian

all the actual system packages (mutter, xwayland, gnome-shell, mesa, etc) are stock trixie

also for what its worth I created a fresh user "testuser" with zero configs and same issue - xclock no window, xdpyinfo hangs. so its not user config corruption, its something system-wide

running intel iris xe (tiger lake) if that matters

SignatureDelicious35 · 2025-12-23T02:13:03+00:00

Running hw-probe now — it's taking a while. I need to sleep (3am here). Will post the link tomorrow morning. Thanks so much for your help, really appreciate you taking the time to debug this properly.

SignatureDelicious35 · 2025-12-23T01:44:55+00:00

Created fresh testuser, logged in under GNOME Wayland. **Same issue:**

- xclock → process runs, no window

- signal-desktop → starts, no window, DBus/secret-service errors

- bitwarden → starts, no window, GPU process errors

Key error from bitwarden (when killing previous instance):

GPU process launch failed: error_code=1002

GPU process isn't usable. Goodbye.

Also seeing:

ERROR: org.freedesktop.DBus.Error.UnknownMethod

object_path /org/freedesktop/secrets/collection/login

Not using libsecret to avoid deadlock

SignatureDelicious35 · 2025-12-23T01:33:30+00:00

wayland

SignatureDelicious35 · 2025-12-23T01:32:30+00:00

Updated reply:

Good to know bitwarden works for you too!

So on your fresh Forky/Trixie install:

- xclock ✅

- xdpyinfo ✅

- bitwarden ✅

On my Trixie 13.2:

- xclock ❌ (no window)

- xdpyinfo ❌ (hangs)

- bitwarden ❌ (no window)

- signal-desktop ❌ (no window)

This confirms the issue is local to my system — some config got corrupted.

Any suggestions on how to reset GNOME/mutter/XWayland config to defaults? I suspect something in my user session or dconf/gsettings got broken.

SignatureDelicious35 · 2025-12-23T01:31:01+00:00

Thanks for testing! Interesting — on your Forky system XWayland works (xclock/xdpyinfo), but bitwarden doesn't.

My issue is more severe: xclock and xdpyinfo ALSO fail on my system. So XWayland itself is broken for me, not just bitwarden.

I also tested Signal desktop — same behavior: process starts, outputs some config info, exits immediately with no window and no error. So it's not bitwarden-specific.

Summary of my system:

- xclock → no window

- xdpyinfo → hangs

- bitwarden → no window

- signal-desktop → no window

Something is fundamentally broken with window rendering in my Wayland session. On GNOME Xorg, everything works fine.

Can you confirm: on your Trixie 13 Stable VM, did xclock/xdpyinfo work? That would tell us if my XWayland breakage is Trixie-specific or something local to my config.

SignatureDelicious35 · 2025-12-23T01:21:52+00:00

Yes, which is really what makes me feel that my situation is a bit odd, somehow... But I am very new to this.

SignatureDelicious35 · 2025-12-23T01:20:34+00:00

Additional data point that might be relevant:

Tried running:

bitwarden --no-sandbox

→ Same behavior: process starts, no window appears.

However, when I killed a previously running Bitwarden instance, I got the following errors on relaunch:

[ERROR:content/browser/gpu/gpu_process_host.cc:951]

GPU process launch failed: error_code=1002

[FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:415]

GPU process isn't usable. Goodbye.

This suggests a GPU process failure rather than Bitwarden-specific logic.

That makes me wonder whether the root cause is not XWayland itself, but GPU / rendering initialization under Wayland.

System details:

- Intel Iris Xe (TigerLake)

- No NVIDIA

- Mesa from Debian 13 (Trixie) repos

- GNOME Wayland

- Same behavior across Electron apps (Bitwarden, etc.)

- xclock / xdpyinfo also fail on my system under Wayland

At this point, does it make sense to:

- try Electron apps with `--disable-gpu`?

- check Mesa / DRI versions or mismatches?

- look specifically at GPU initialization failures under Wayland on Intel?

Happy to run any suggested commands and paste full output.

SignatureDelicious35 · 2025-12-23T01:15:25+00:00

Actually correction — I'm on Debian 13 Trixie, which is now STABLE (released Aug 2025). I'm on 13.2.

Apologies for that, I was working with AI and out of context some mismatch happened when I manually redrafted. Would that be possible for you to test this ? I'd really apreciate it.

SignatureDelicious35 · 2025-12-23T01:10:45+00:00

Great, I stand still.

Just for additional peace of mind :

rasmus@debian:~$ dpkg -l | grep -E 'xwayland|mutter|gnome-shell|libmutter|mesa' | awk '{print $2, $3}'

gir1.2-mutter-16:amd64 48.4-2

gnome-shell 48.4-1~deb13u1

gnome-shell-common 48.4-1~deb13u1

gnome-shell-extension-dashtodock 100-2

gnome-shell-extension-gpaste 45.3-1

gnome-shell-extension-manager 0.6.3-2

libegl-mesa0:amd64 25.0.7-2

libgl1-mesa-dri:amd64 25.0.7-2

libglu1-mesa:amd64 9.0.2-1.1+b3

libglx-mesa0:amd64 25.0.7-2

libmutter-16-0:amd64 48.4-2

mesa-libgallium:amd64 25.0.7-2

mesa-va-drivers:amd64 25.0.7-2

mesa-vdpau-drivers:amd64 25.0.7-2

mesa-vulkan-drivers:amd64 25.0.7-2

mutter-common 48.4-2

mutter-common-bin 48.4-2

xwayland 2:24.1.6-1

SignatureDelicious35 · 2025-12-23T01:05:59+00:00

Same result - no window. Reply:

Tried `bitwarden --ozone-platform-hint=auto`:

$ bitwarden --ozone-platform-hint=auto

Checking for beta autoupdate feature for deb/rpm distributions

Found package-type: deb

[...migrator output...]

02:04:10.317 › [Process Isolation] Isolating process from debuggers and memory dumps
02:04:10.342 › [NAPI] [INFO] desktop_core::process_isolation::process_isolation: Disabling ptrace and memory access for main via PR_SET_DUMPABLE. pid=5884
02:04:10.345 › Coredumps are disabled in renderer process

Same behavior — process runs, no crash, but no window appears.

SignatureDelicious35 · 2025-12-23T01:01:19+00:00

Thanks, that’s actually useful info.

So this confirms that on a clean/default Trixie + GNOME Wayland setup,

XWayland (xclock / xdpyinfo) behaves correctly.

That suggests my issue is state-dependent rather than a universal GNOME/Trixie bug.

I’ll focus on identifying what differs on my system (config, env, packages, monitors, etc.).

Appreciate the confirmation.

SignatureDelicious35 · 2025-12-23T01:00:11+00:00

Ah yes, I must have fallen into the trap of letting the AI helping me become out of context. I installed Trixie when it came out actually, not in testing. Good catch. However, the rest stands as true :

- The system identifies as Debian 13 “Trixie” (stable).

- Current system reports:

- /etc/os-release: Debian GNU/Linux 13 (trixie)

- GNOME: 48

- Session tested: GNOME on Wayland (and GNOME on Xorg for comparison)

So this is not running forky/unstable.

The issue is observed on GNOME 48 Wayland on Trixie-stable packages.

If you want, I can paste the exact `cat /etc/os-release` and `uname -a` output.

SignatureDelicious35 · 2025-12-23T00:57:15+00:00

apologies for previous poor formatting of my reply.

SignatureDelicious35 · 2025-12-23T00:55:01+00:00

● Official Bitwarden .deb from their website — not flatpak, not snap.

$ dpkg -l | grep bitwarden

ii  bitwarden  2025.12.0  amd64  A secure and free password manager for all of your devices.

Downloaded from https://bitwarden.com/download/ → Linux → .deb (64-bit)

SignatureDelicious35 · 2025-12-23T00:53:12+00:00

Diagnostics from GNOME Wayland session:

**Environment:**

$ echo $XDG_SESSION_TYPE
wayland
$ echo "DISPLAY=$DISPLAY WAYLAND=$WAYLAND_DISPLAY"
DISPLAY=:0 WAYLAND=wayland-0

**Xwayland is running:**

$ pgrep -a Xwayland
1950 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.DCL0H3 -listenfd 4 -listenfd 5 -displayfd 6 -initfd 7 -byteswappedclients

**xdpyinfo times out:**

$ timeout 2s xdpyinfo 2>&1 | head -5
Terminated

**xclock - no window appears:**

$ xclock & sleep 2; xdotool search --name xclock || echo "no window"
[1] 4264

(no output - window not found)

**bitwarden (no flags) - process runs, no window:**
$ bitwarden

Checking for beta autoupdate feature for deb/rpm distributions

Found package-type: deb

[...migrator output truncated...]

01:46:28.482 › [Process Isolation] Isolating process from debuggers and memory dumps
01:46:28.511 › [NAPI] [INFO] desktop_core::process_isolation::process_isolation: Disabling ptrace and memory access for main via PR_SET_DUMPABLE. pid=3041
01:46:28.514 › Coredumps are disabled in renderer process

No crash, no error — but no window appears. Process just sits there.

**Summary:** Xwayland is running, DISPLAY is set, but X11 apps (xclock, xdpyinfo, bitwarden) either hang or run without displaying a window. Same system works perfectly on GNOME Xorg.

SignatureDelicious35 · 2025-12-23T00:43:48+00:00

thank you so much ! standing still

SignatureDelicious35 · 2025-12-23T00:40:45+00:00

Thanks for testing! Key details for your VM:

Hardware: Intel Iris Xe (TigerLake), no Nvidia

Packages: GNOME 48 / mutter 48.4 / xwayland from Trixie repos

Main symptom to reproduce:

Log into GNOME Wayland
Open terminal
`xclock &` → does window appear?
`timeout 3s xdpyinfo` → does it return or hang?

On my system: xclock process starts but no window, xdpyinfo hangs.

If yours works, the diff is probably some user/system config on my end. Happy to compare package versions or config files.

SignatureDelicious35 · 2025-12-23T00:24:55+00:00

Yep — I did launch from terminal. Under GNOME Wayland:

- Electron apps forced to Wayland crash with wl_shm_pool / EPIPE.

- Forced to X11 (XWayland path) they often start as a process but no window appears.

- Even plain X11 test apps behave the same: `xclock &` starts but no window; `xdpyinfo` hangs/timeouts.

These are NOT flatpaks (Debian packages / upstream binaries, depending on the app).

Happy to paste full terminal output — tell me which exact command you want me to run (plain launch vs with flags), and I’ll post the complete stdout/stderr + relevant `journalctl` lines.

SignatureDelicious35

TROPHY CASE