Created attachment 1588739 [details] journalctl output Xwayland-1.20.5 Description of problem: No video output after Plymouth boot screen after upgrading to xorg-x11-server-Xwayland-1.20.5. Version-Release number of selected component (if applicable): 1.20.5 How reproducible: Upgrade from xorg-x11-server-Xwayland-1.20.4 to org-x11-server-Xwayland-1.20.5. Steps to Reproduce: 1. dnf upgrade Actual results: The video output is lost after the Plymouth boot screen. Expected results: I can see the GNOME display manager and use my system. Additional info: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390] (rev 80). Using mesa-19.1.1 Other xorg-server components: xorg-x11-server-Xorg-1.20.5, xorg-x11-server-Xephyr-1.20.5 and xorg-x11-server-common-1.20.5
Created attachment 1588740 [details] journalctl output Xwayland-1.20.4
Created attachment 1588741 [details] Xorg log
Created attachment 1588742 [details] xrandr output
From xranrd, you're not running Xwayland but plain Xorg. Can you please state what exact version of the package you're using? (“1.20.5” is the upstream version, the package version is something like “xorg-x11-server-Xorg-1.20.5-4.fc30.x86_64”)
I am sorry, I have this problem when using xorg-x11-server-Xwayland-1.20.5-3.fc30.x86_64, and it resolves if I downgrade to xorg-x11-server-Xwayland-1.20.4-3.fc30.x86_64.
Please try with xorg-x11-server-Xwayland-1.20.5-4.fc30 from updates-testing + xorg-x11-drv-ati-19.0.1-1.1test.fc30 from https://koji.fedoraproject.org/koji/taskinfo?taskID=36052571
Sorry I mean xorg-x11-server-Xorg-1.20.5-4.fc30 + xorg-x11-server-common-1.20.5-4.fc30 from updates-testing + xorg-x11-drv-ati-19.0.1-1.1test.fc30 from https://koji.fedoraproject.org/koji/taskinfo?taskID=36052571
Unfortunately the problem persists.
Humm, the logs show a wayland protocol error between Xwayland and GNOME shell and then GDM switches to X: lug 09 15:22:26 localhost.localdomain gnome-shell[1891]: WL: error in client communication (pid 1891) lug 09 15:22:26 localhost.localdomain gnome-shell[1891]: WL: error in client communication (pid 1891) lug 09 15:22:26 localhost.localdomain audit[1959]: ANOM_ABEND auid=4294967295 uid=42 gid=42 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=1959 comm="Xwayland" exe="/usr/bin/Xwayland" sig=6 res=1 lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: (EE) lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: Fatal server error: lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: (EE) wl_drm@4: error 0: authenicate failed lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: (EE)
So the best candidate would be: https://gitlab.freedesktop.org/xorg/xserver/commit/bb74db6b which was backported from master to the stable branch between xserver-1.20.4 and xserver-1.20.5, but that commit was to use render nodes and thus avoid the DRM authentication, in other words, that commit is to avoid that DRM authentication error... Which is odd. Can you please install drm-utils and post the output of the command “drmdevice” ran on your system?
Created attachment 1589011 [details] drmdevice output
OK, I think I start to understand... the confusion here :) 1. “journalctl output Xwayland-1.20.5” (attachment 1588739 [details], ie the one said to *fail*) shows a *working* Wayland session, the wl_drm authentication error is not there and gnome-shell starts a a Wayland compositor. But that that log shows that gnome-shell fails to access the DRI devices: ``` lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to set power save mode for output DVI-D-1: Permission denied lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to set power save mode for output HDMI-1: Permission denied lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to set CRTC mode 1920x1080: Permission denied lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to set CRTC mode 1920x1080: Permission denied lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to disable CRTC lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to disable CRTC lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to disable CRTC lug 09 13:24:41 localhost.localdomain gnome-shell[1926]: Failed to disable CRTC ``` 2. “journalctl output Xwayland-1.20.4” (attachment 1588740 [details], i.e. the one said to *work*) shows a failed Wayland session because of the wl_drm authentication issue. As a result, GDM fallbacks to Xorg whic hgives you a working session: ``` lug 09 15:22:26 localhost.localdomain gnome-shell[1891]: WL: error in client communication (pid 1891) lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: (EE) lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: Fatal server error: lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: (EE) wl_drm@4: error 0: authenicate failed lug 09 15:22:26 localhost.localdomain org.gnome.Shell.desktop[1891]: (EE) [...] lug 09 15:22:27 localhost.localdomain /usr/libexec/gdm-x-session[2043]: X.Org X Server 1.20.5 lug 09 15:22:27 localhost.localdomain /usr/libexec/gdm-x-session[2043]: X Protocol Version 11, Revision 0 lug 09 15:22:27 localhost.localdomain /usr/libexec/gdm-x-session[2043]: Build Operating System: 5.1.11-200.fc29.x86_64 lug 09 15:22:27 localhost.localdomain /usr/libexec/gdm-x-session[2043]: Current Operating System: Linux localhost.localdomain 5.1.16-300.fc30.x86_64 #1 SMP Wed Jul 3 15:06:51 UTC 2019 x86_64 ``` The funny thing there is that Xorg is 1.20.5. So here is what I think happens: *BEFORE* the update of Xwayland to 1.20.5 1. Xwayland failed to start because if could not open /dev/dri/card0 causing the wl_drm authentication error 2. Since Xwayland fails to start, Wayland is unusable and GDM fallbaks to Xorg/X11 which starts successfully 3. You get a working Xorg/X11 session *AFTER* the update of Xwayland to 1.20.5 4. Xwayland 1,20,5 has a fix to use render nodes and therefore does not fail anymore trying to use /dev/dri/card0 5. There is no more failure and GDM reckons the Wayland session works, and uses gnome-shell on Wayland 6. But gnome-shell/mutter still fail to use the /dev/dri/card0 and you have a black screen under Wayland So I think the problem is not with the update but rather with something wrong on the system preventing either Xwayland or gnome-shell mutter to use the DRM device.
Out of curiosity, what gives “ls -la /dev/dri/“ on your system? Have you tried starting without selinux, does it make any difference? You may want to try a relabelling.
> Out of curiosity, what gives “ls -la /dev/dri/“ on your system? total 0 drwxr-xr-x. 3 root root 100 10 lug 11.22 . drwxr-xr-x. 23 root root 4860 10 lug 11.23 .. drwxr-xr-x. 2 root root 80 10 lug 11.22 by-path crw-rw----+ 1 root video 226, 0 10 lug 11.22 card0 crw-rw-rw-. 1 root render 226, 128 10 lug 11.22 renderD128 > Have you tried starting without selinux, does it make any difference? I tried and it did not change anything, but switching to LightDM and upgrading Xwayland works fine. > You may want to try a relabelling. I am sorry, what do you mean?
Created attachment 1589049 [details] journal lightdm
(In reply to cappellorosso from comment #14) > I tried and it did not change anything, but switching to LightDM and > upgrading Xwayland works fine. I do not know which session lightdm spawns, but lightdm itself is unlikely to know about Wayland so I guess it starts a plain Xorg session which works (see comment 12). But again, the problem here is that with an updated Xwayland, it starts fine and therefore GDM uses Wayland, but gnome-shell fails to set the modes and outputs and hence you get a black screen. > > You may want to try a relabelling. > > I am sorry, what do you mean? I mean "touch /.autorelabel" then reboot so that that the boot process will relabel all files for selinux at next boot (that can take an awful lot of time though!). Another thing you may want to try is to boot without “rhgb” from the kernel command line (that can be done in grub for a quick on-shot test, just edit the kernel boot line in grub, erase “rhgb” and boot).
> You may want to try a relabelling. I did it and it did not change anything. > Another thing you may want to try is to boot without “rhgb” from the kernel > command line (that can be done in grub for a quick on-shot test, just edit > the kernel boot line in grub, erase “rhgb” and boot). This did the trick! What does it mean?
(In reply to cappellorosso from comment #17) > > > Another thing you may want to try is to boot without “rhgb” from the kernel > > command line (that can be done in grub for a quick on-shot test, just edit > > the kernel boot line in grub, erase “rhgb” and boot). > > This did the trick! What does it mean? Oh, that's a breakthrough! It means that the problem possibly lies in between plymouth or systemd
Do you mind if we run some more tests?... Can you please boot with changing your kernel command line, keep "rhgb" but remove "quiet" and replace it with "plymouth.debug=stream:/dev/kmsg" (that will instruct plymouth to log to /dev/kmsg so that we can capture the entire log including plymouth traces, all in one place). Once boot has complete (and the original issue reproduced), capture and attach the content of "journalctl -b -a -l"
Created attachment 1589113 [details] journalctl output
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. 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 Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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 please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.