Description of problem: After the latest update non-wayland-native applications fail to start. Tested with mailspring, vscode & telegram. Telegram works if started with QT_QPA_PLATFORM=wayland. I checked the dnf transaction and everything else seems unrelated (quemu, snap, bluez, pipewire, etc). Upgrade xorg-x11-server-Xwayland-21.1.3-1.fc35.x86_64 @updates Upgraded xorg-x11-server-Xwayland-21.1.2.901-1.fc35.x86_64 @@System I tried downgrading to xorg-x11-server-Xwayland-21.1.2-2.fc35.x86_64 as 21.1.2.901-1 was not available anymore: without success. I tried loggin into the "Gnome on X11" session. But after a black flash of the screen I'm thrown back to GDM. Version-Release number of selected component (if applicable): xorg-x11-server-Xwayland-21.1.3-1.fc35.x86_64 How reproducible: 100% on my system Steps to Reproduce: 1. update 2. restart 3. try to start non-wayland application Actual results: No window visible & no error message in terminal Expected results: Application window visible Additional info: I would append the output of glxinfo here, but not even that is working anymore. But the GPU is a radeon RX580 with default amdgpu/radeonSI driver.
I hope there is some useful information in here. Especially "glamor: No eglstream capable devices found" seems fishy to me. If I can provide any more information please tell me what to do :) Nov 11 11:04:13 localhost.localdomain gnome-shell[2111]: Running GNOME Shell (using mutter 41.1) as a Wayland display server Nov 11 11:04:13 localhost.localdomain gnome-shell[2111]: Device '/dev/dri/card0' prefers shadow buffer Nov 11 11:04:13 localhost.localdomain gnome-shell[2111]: Added device '/dev/dri/card0' (amdgpu) using atomic mode setting. Nov 11 11:04:13 localhost.localdomain gnome-shell[2111]: Boot VGA GPU /dev/dri/card0 selected as primary Nov 11 11:04:14 localhost.localdomain gnome-shell[2111]: Disabling DMA buffer screen sharing for driver 'amdgpu'. Nov 11 11:04:14 localhost.localdomain /usr/libexec/gdm-wayland-session[2100]: dbus-daemon[2100]: [session uid=42 pid=2100] Activating service name='org.a11y.Bus' requested by ':1.4' (uid=42 pid=2111 comm="/usr/bin/gnome-shell " label="system_u:system_r:xdm_t:s0-s0:c0.c1023") Nov 11 11:04:14 localhost.localdomain /usr/libexec/gdm-wayland-session[2100]: dbus-daemon[2100]: [session uid=42 pid=2100] Successfully activated service 'org.a11y.Bus' Nov 11 11:04:14 localhost.localdomain gnome-shell[2111]: Using public X11 display :1024, (using :1025 for managed services) Nov 11 11:04:14 localhost.localdomain gnome-shell[2111]: Using Wayland display name 'wayland-0' Nov 11 11:04:14 localhost.localdomain org.gnome.Shell.desktop[2177]: glamor: No eglstream capable devices found Nov 11 11:05:07 localhost.localdomain systemd[3290]: Reached target GNOME Session Manager is ready. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Starting GNOME Shell on Wayland... Nov 11 11:05:07 localhost.localdomain systemd[3290]: Starting GNOME Shell on X11... Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Skipped due to 'exec-condition'. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Condition check resulted in GNOME Shell on X11 being skipped. Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Scheduled restart job, restart counter is at 1. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Failed to start Application launched by gnome-session-binary. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Stopped GNOME Shell on X11. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Starting GNOME Shell on X11... Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Skipped due to 'exec-condition'. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Condition check resulted in GNOME Shell on X11 being skipped. Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Scheduled restart job, restart counter is at 2. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Stopped GNOME Shell on X11. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Starting GNOME Shell on X11... Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Skipped due to 'exec-condition'. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Condition check resulted in GNOME Shell on X11 being skipped. Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Scheduled restart job, restart counter is at 3. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Stopped GNOME Shell on X11. Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Start request repeated too quickly. Nov 11 11:05:07 localhost.localdomain systemd[3290]: org.gnome.Shell: Skipped due to 'exec-condition'. Nov 11 11:05:07 localhost.localdomain systemd[3290]: Started GNOME Shell on X11. Nov 11 11:05:07 localhost.localdomain gnome-shell[3458]: Running GNOME Shell (using mutter 41.1) as a Wayland display server Nov 11 11:05:07 localhost.localdomain gnome-shell[3458]: Device '/dev/dri/card0' prefers shadow buffer Nov 11 11:05:07 localhost.localdomain gnome-shell[3458]: Added device '/dev/dri/card0' (amdgpu) using atomic mode setting. Nov 11 11:05:07 localhost.localdomain gnome-shell[3458]: Boot VGA GPU /dev/dri/card0 selected as primary Nov 11 11:05:08 localhost.localdomain systemd[3290]: Starting Virtual filesystem service... Nov 11 11:05:08 localhost.localdomain systemd[3290]: Started Virtual filesystem service. Nov 11 11:05:08 localhost.localdomain gnome-shell[3458]: Disabling DMA buffer screen sharing for driver 'amdgpu'. Nov 11 11:05:10 localhost.localdomain systemd[3290]: org.gnome.SettingsDaemon.XSettings.service: Scheduled restart job, restart counter is at 2. Nov 11 11:05:10 localhost.localdomain systemd[3290]: Stopped GNOME XSettings service. Nov 11 11:05:10 localhost.localdomain systemd[3290]: Starting GNOME XSettings service... Nov 11 11:05:10 localhost.localdomain gsd-xsettings[4327]: Cannot open display: Nov 11 11:05:10 localhost.localdomain systemd[3290]: org.gnome.SettingsDaemon.XSettings.service: Main process exited, code=exited, status=1/FAILURE Nov 11 11:05:10 localhost.localdomain systemd[3290]: org.gnome.SettingsDaemon.XSettings.service: Failed with result 'exit-code'. Nov 11 11:05:10 localhost.localdomain systemd[3290]: Failed to start GNOME XSettings service. Nov 11 11:05:11 localhost.localdomain PackageKit[2244]: uid 1000 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0) Nov 11 11:05:11 localhost.localdomain PackageKit[2244]: uid 1000 obtained auth for org.freedesktop.packagekit.system-sources-refresh Nov 11 11:05:11 localhost.localdomain systemd[3290]: org.gnome.SettingsDaemon.XSettings.service: Scheduled restart job, restart counter is at 3.
I did a fresh install of fedora 35. No problems in the live environment or after install. But as soon as I updated & restarted my system was unable to launch X11 applications or log into the X11 session again.
Created attachment 1841530 [details] Xorg log
(In reply to Jan Lukas Gernert from comment #0) > […] > I tried downgrading to xorg-x11-server-Xwayland-21.1.2-2.fc35.x86_64 as 21.1.2.901-1 > was not available anymore: without success. All builds should still be available from koji: * xorg-x11-server-Xwayland-21.1.0-1.fc35: https://koji.fedoraproject.org/koji/buildinfo?buildID=1725086 * xorg-x11-server-Xwayland-21.1.1-1.fc35 https://koji.fedoraproject.org/koji/buildinfo?buildID=1735946 * xorg-x11-server-Xwayland-21.1.1-2.fc35 https://koji.fedoraproject.org/koji/buildinfo?buildID=1767667 * xorg-x11-server-Xwayland-21.1.1-3.fc35 https://koji.fedoraproject.org/koji/buildinfo?buildID=1774264 * xorg-x11-server-Xwayland-21.1.2-1.fc35 https://koji.fedoraproject.org/koji/buildinfo?buildID=1779170 * xorg-x11-server-Xwayland-21.1.2.901-1.fc35 https://koji.fedoraproject.org/koji/buildinfo?buildID=1847520 * xorg-x11-server-Xwayland-21.1.3-1.fc35 https://koji.fedoraproject.org/koji/buildinfo?buildID=1853462 Would be interesting to check which version was the last known working package and which one first introduced the issue. (In reply to Jan Lukas Gernert from comment #1) > I hope there is some useful information in here. Especially "glamor: No > eglstream capable devices found" seems fishy to me. No, that's perfectly fine if you do not have a NVIDIA card with the NVIDIA proprietary driver which is the only one out there implementing EGLstream, to the best of my knowledge. (In reply to Jan Lukas Gernert from comment #3) > Created attachment 1841530 [details] > Xorg log Unfortunately, the Xorg logs are of no use with Xwayland.
(In reply to Olivier Fourdan from comment #4) > > Would be interesting to check which version was the last known working > package and which one first introduced the issue. > Please note, you need to restart your Wayland session after installing Xwayland to be sure.
Sadly I wasn't able to find a working version. (I tried 21.1.2.901-1 and 21.1.0-1 and did a restart after downgrading each time) So I am probably wrong and it's not "xorg-x11-server-Xwayland" that causes the issue. This would also explain why the "Gnome on Xorg" session isn't working as well. (In reply to Olivier Fourdan from comment #4) > Unfortunately, the Xorg logs are of no use with Xwayland. Are there any other logs/infos I should provide? Probably unrelated, but just to be sure. I'm seeing these warnings in the logs during "Gnome systemd[2301]: Reached target GNOME session X11 services. systemd[2301]: Starting GNOME XSettings service... gnome-shell[5999]: The XKEYBOARD keymap compiler (xkbcomp) reports: gnome-shell[5999]: > Warning: Unsupported maximum keycode 708, clipping. gnome-shell[5999]: > X11 cannot support keycodes above 255. gnome-shell[5999]: Errors from xkbcomp are not fatal to the X server
Created attachment 1841817 [details] journalctl -b
(In reply to Jan Lukas Gernert from comment #0) > I checked the dnf transaction and everything else seems unrelated (quemu, snap, bluez, pipewire, etc). Can you share the full transaction?
Sadly I can't because I reinstalled the system. Also I can not 100% exclude the possibility that I updated via dnf at some point before and only suspended the machine for a few days. So it would be hard to pin-point the exact moment the system broke. Sorry.
Can't see anything obviously wrong with attachment 1841817 [details] - Just to be sure, have you tried to run some simple X11 client such as xterm or even xclock in your Wayland session?
Yes, I used xterm to verify that X11 applications were working in the live boot environment. And I tried running xterm after installing & updating Fedora: not working anymore. I didn't check the logs after running xterm. I will do that and report back if there is anything interesting to see.
So you installed F35 GA then updated all packages, not just Xwayland? And you mentioned Xorg fails to start as well? You also mentioned that downgrading Xwayland did not fix the issue. There've been no update to xorg-x11-server-Xorg since GA, so if we assume that the root cause is the same (Xwayland and Xorg not working) it could be another package used by both. Maybe you could try downgrading Mesa to the version from GA? $ sudo dnf downgrade mesa-\*21.2.3-6.fc35\* You'll need to reboot your system after downgrading to be sure. (beware, downgrading packages may cause your installation to be unstable or even unusable, make sure to have backups up to date!)
(In reply to Olivier Fourdan from comment #12) > So you installed F35 GA then updated all packages, not just Xwayland? And > you mentioned Xorg fails to start as well? 1. Yes, xterm was working in the live environment. 2. Then I installed fedora 35 as usual 3. Then I updated everything with "dnf update" and restarted I don't think I tested xterm directly after the install before I did the update. But if it would help to track the issue down I can do a new clean install on another disk to check. (In reply to Olivier Fourdan from comment #12) > You also mentioned that downgrading Xwayland did not fix the issue. Yes, it did not fix the issue. Sadly I was wrong with my initial guess. (In reply to Olivier Fourdan from comment #12) > Maybe you could try downgrading Mesa to the version from GA? > > $ sudo dnf downgrade mesa-\*21.2.3-6.fc35\* > > You'll need to reboot your system after downgrading to be sure. > > (beware, downgrading packages may cause your installation to be unstable or > even unusable, make sure to have backups up to date!) I did downgrade mesa and saw no change after a restart Transaction ID : 73 Begin time : Tue 16 Nov 2021 11:41:54 AM CET Begin rpmdb : 2076:b057c9c798a9e38537f43b746c1fa126a1d9473a End time : Tue 16 Nov 2021 11:41:56 AM CET (2 seconds) End rpmdb : 2076:a5f3f5b2dab7152799fc5d0faebcf8aa0a8114d1 User : JeanLuc <jeanluc> Return-Code : Success Releasever : 35 Command Line : downgrade mesa-*21.2.3-6.fc35* Comment : Packages Altered: Downgrade mesa-dri-drivers-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-dri-drivers-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-filesystem-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-filesystem-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-libEGL-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-libEGL-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-libEGL-devel-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-libEGL-devel-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-libGL-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-libGL-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-libgbm-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-libgbm-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-libglapi-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-libglapi-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-libxatracker-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-libxatracker-21.2.5-1.fc35.x86_64 @@System Downgrade mesa-vulkan-drivers-21.2.3-6.fc35.x86_64 @fedora Downgraded mesa-vulkan-drivers-21.2.5-1.fc35.x86_64 @@System
Thanks for testing! So it seems it's neither Xwayland nor mesa… So, let me rephrase (just lemme know if I am wrong in my understanding), when you chose the GNOME (regular Wayland session) in the GDM login screen, you get a working GNOME desktop but launching any X11 cleint gives no window at all, but the rest of the desktop is fine? If you open up gnome-terminal (Wayland native application) and run `xterm` from that terminal, do you see any error? Can you please also check whether Xwayland gets started by looking for the Xwayland process with `ps aux ps aux | grep Xwayland` and paste the result here?
(In reply to Olivier Fourdan from comment #14) > Can you please also check whether Xwayland gets started by looking for the > Xwayland process with `ps aux ps aux | grep Xwayland` and paste the result > here? Copy/pasta failed, it should read `ps aux | grep Xwayland` obviously.
(In reply to Olivier Fourdan from comment #14) > So, let me rephrase (just lemme know if I am wrong in my understanding), > when you chose the GNOME (regular Wayland session) in the GDM login screen, > you get a working GNOME desktop but launching any X11 cleint gives no window > at all, but the rest of the desktop is fine? correct (In reply to Olivier Fourdan from comment #14) > If you open up gnome-terminal (Wayland native application) and run `xterm` > from that terminal, do you see any error? No it just blocks, but the xterm window does not come up > Can you please also check whether Xwayland gets started by looking for the > Xwayland process with `ps aux ps aux | grep Xwayland` and paste the result > here? Yes, Xwayland is running. jeanluc 11846 0.0 0.2 1646004 76028 ? Sl 05:30 0:00 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.RXLTC1 -listenfd 4 -listenfd 5 -displayfd 6 -initfd 7 jeanluc 12631 0.0 0.0 221792 2352 pts/1 S+ 05:32 0:00 grep --color=auto Xwayland As soon as I can spend some time on it I will install a new instance of fedora 35 to see if the issue is already present after installing without updating. And if not I'll try to update only small grups of packages at a time to see if I can narrow it down.
Created attachment 1842250 [details] launching xterm from gnome terminal
One thing you may try for testing, is to run Xwayland non-rootless from that gnome-terminal and post the exact same output, e.g.: $ Xwayland :12 |& tee xwayland.log To see if a large black (Xwayland) window appears on screen (I bet not) and then copy or attach the content of xwayland.log here.
(In reply to Olivier Fourdan from comment #18) > One thing you may try for testing, is to run Xwayland non-rootless from that > gnome-terminal and post the exact same output, e.g.: > > $ Xwayland :12 |& tee xwayland.log > > To see if a large black (Xwayland) window appears on screen (I bet not) and > then copy or attach the content of xwayland.log here. It actually does glamor: No eglstream capable devices found The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Unsupported maximum keycode 708, clipping. > X11 cannot support keycodes above 255. Errors from xkbcomp are not fatal to the X server
Created attachment 1842263 [details] Black XWayland window
Alright, that's actually great new, it means that Xwayland works fine :) Bad news though is the problem is elsewhere then…
Maybe a stoopid idea, but have you tried to wait for some time (like more than a minute) to see if the X11 window eventually appear? You may also try to run the X11 client with strace to see what it's actually doing, e.g.: $ strace -Tvvvvs4096 -oxterm.log xterm (That will log to the file xterm.log)
Created attachment 1842269 [details] strace xterm log
Does `xdpyinfo` work?
(In reply to Olivier Fourdan from comment #24) > Does `xdpyinfo` work? Same behavior as xterm in the screenshot above. Same for `glxinfo`.
(In reply to Jan Lukas Gernert from comment #25) > Same behavior as xterm in the screenshot above. Same for `glxinfo`. You mean it does not return anything and just hang? That would possibly mean the X11 clients hang trying to connect to the Xserver, maybe an xauth issue…?
(In reply to Olivier Fourdan from comment #26) > (In reply to Jan Lukas Gernert from comment #25) > > Same behavior as xterm in the screenshot above. Same for `glxinfo`. > > You mean it does not return anything and just hang? That would possibly mean > the X11 clients hang trying to connect to the Xserver, maybe an xauth issue…? Yes xauth list fedora-jeanluc/unix: MIT-MAGIC-COOKIE-1 205f5ef9b4453537a46e014aa92a499b #ffff#6665646f72612d6a65616e6c7563#: MIT-MAGIC-COOKIE-1 205f5ef9b4453537a46e014aa92a499b Like I promised earlier I installed Fedora 35 again on my second SSD and updated all the packages in small transactions with a reboot after each one to figure out at what point the system was broken. But xterm was still able to launch after all the updates were installed. So I thought I could simply switch over to this installation. Trying to install systemd-boot I noticed the partition table was not gpt so I whiped the SSD and reinstalled Fedora 35 again with a gpt table this time. Updated the system in one transaction and tested xterm: still working. Then I started to set the system up for regular usage: - install some applications (evolution etc), configure firefox etc - set up fancontrol - switch to systemd-boot After doing just these three things I was experiencing the original bug again. I can't imagine that installing applications or enabling fancontrol could cause this. So the only thing left would be systemd-boot. But even that I don't understand. Could this be the cause?
On my first installation X11 applications started working again after a reboot because of software updates (wireplumber & firefox). So I did the exact same update on the second installation and there the issue is still present. Is this witchcraft, voodoo, cosmic rays? I don't see any correlation between anything anymore.
I have no experience with systemd-boot so I don't know for sure whether that could play a role in all this, but that seems unlikely. One simple thing you may want to try to rule out a specific issue with the current user account is to create a fresh new user and try to log with that new user and see if things work as expected.
Update: first Fedora 35 installation is also back to not being able to launch X11 applications after a reboot (rebooted several times before without the issue returning). I tried adding a second user account and indeed: that user can open xterm just fine. I switched back and forth between the two user accounts 2x and the behavior seems consistent.
The only gnome extension installed is "dash to dock" which I also temporarily deactivated. And my .bashrc additions are nothing spectacular as well. Just rust and dotnet development: parse_git_branch() { git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/' } export PS1="\u@\h \[\e[32m\]\w \[\e[91m\]\$(parse_git_branch)\[\e[00m\]$ " export GDK_BACKEND=wayland export AVALONIA_GLOBAL_SCALE_FACTOR=2.0 export DOTNET_ROOT=$HOME/Projects/dotnet export PATH=$PATH:$HOME/Projects/dotnet export DOTNET_CLI_TELEMETRY_OPTOUT=1 . "$HOME/.cargo/env"
I am running into the exact same Issue. My user can't start any Xorg applications under Wayland (they just hang). My user also can't login to the a Xorg Session (the Screen blinks and i am back to Login). I have disabled all my gnome Extensions. Everything was Working fine last week. A newly Created User works just fine. Any way I can debug this further?
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2496 may fix this.
(In reply to Jan Lukas Gernert from comment #31) > […] > export GDK_BACKEND=wayland For the record, this is what is causing the problem for this bug, as it forces *all* applications to run on Wayland while some such as gsd-xsettings can work only on X11. GDK (and hence GTK applications) will always try Wayland first and X11 second so forcing `GDK_BACKEND=wayland` in the environment is not only a terrible idea, it is also useless. comment 32 might be a different issue though, as not even Xorg work, but certainly also related to something in the user environment as well considering a newly created user works.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.