I was previously on F39 but for unrelated reasons I decided to reinstall F40, so this is a fairly clean install except for a couple packages (including this one) I needed. After installing the x11 session and rebooting, the session selector is available. However after successful login the screen goes black and the session does not launch. Oddly enough, I am also unable to get to a TTY from that point on. Ctrl+Alt+2 just doesn't appear to do anything. I need to shutdown/reboot using the power button. It should be noted that I am able to launch an x11 session if I switch to a TTY while SDDM is shown, login, and then simply use `startx`. From that point on the session works perfectly fine and as expected. It should also be noted that on F39 I was using the x11 session just fine (for years since F28 in fact). So this might be related the the now-Wayland-default SDDM handing off to X11 somehow since SDDM was X11 before as well. The startup via `startx` was suggested during some troubleshooting on the Fedora matrix channel. It was also suggested that this is likely a modeset issue with my GPU. I am using an RX Vega 64 on the default amdgpu driver, so not exactly the latest model but it's still working fine. On the Fedora Community Discord I also asked around and at least one user was confirming the session worked just fine on their GPU (an RX 6700 XT). I will be adding a journalctl from a fresh boot, login, (failed) x11 launch, and the shutdown via power button. I can't say I'm seeing anything relevant in it though. Of course I'm also open to more testing (also on the Fedora Matrix channel if needed). Reproducible: Always Steps to Reproduce: 1. Use an RX Vega card (not sure what - if any - other cards are affected) 2. Select Plasma (X11) in SDDM 3. Login Actual Results: Login succeeds, the screen goes black and stays that way. TTY is also unavailable Expected Results: The session should launch and the user be presented with the desktop. $ uname -r 6.10.7-200.fc40.x86_64 $ lspci -vv 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c1) (prog-if 00 [VGA controller]) Subsystem: Sapphire Technology Limited Device e37f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 89 IOMMU group: 17 Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=2M] Region 4: I/O ports at e000 [size=256] Region 5: Memory at fcd00000 (32-bit, non-prefetchable) [size=512K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: amdgpu Kernel modules: amdgpu
Created attachment 2045643 [details] journalctl
> So this might be related the the now-Wayland-default SDDM handing off to X11 somehow since SDDM was X11 before as well. There is an easy way to verify that: force SDDM to use X11 too: sudo kwriteconfig6 --file /etc/sddm.conf --group General --key DisplayServer x11 (then reboot).
Yep, that made it work. Although this also cleared the content of the entire file (but from what I can tell everything as commented anyway) π Good thing I made a backup π
Comments are not significant anyway as far as SDDM's config file parser is concerned. :-) I guess they now ship the default settings commented out. They used to set them explicitly in the config file, which carries the risk of the code and the config file getting out of sync. Commenting out the defaults means that in case of conflicts, the code prevails, not the config file. But the drawback is that automated tools such as kwriteconfig6 do not understand the comments and can end up removing them.
Hm... interesting. So I recently got a new GPU, a 7700XT: 0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] (rev ff) (prog-if 00 [VGA controller]) Subsystem: Sapphire Technology Limited Device c475 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 89 IOMMU group: 17 Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=2M] Region 4: I/O ports at e000 [size=256] Region 5: Memory at fcc00000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: amdgpu Kernel modules: amdgpu And I'm still experiencing the same issue. That's... interesting because as mentioned in the initial post, someone claimed it worked just fine for them on a 6700 XT. So either the 6000 series is inexplicably not affected or something else is at play here. At the time I didn't confirm whether they were on a fresh install or if it was an upgrade, which could play into differences in their sddm.conf. Maybe they were running SDDM on X11 which as we know circumvents all this. Either way, at least my GPU isn't ancient now so it's probably easier to find testers π
OK, some more details, since I heard back from the user on Discord. It appears that indeed the 6000 series is inexplicable unaffected (unless back then they actually forgot to switch to X11 and were running Wayland)? I had them run a couple things to confirm what their SDDM config looked like: > > dnf list installed "sddm*" > Installed Packages > sddm.x86_64 0.21.0-4.fc40 @anaconda > sddm-breeze.noarch 6.2.1-1.fc40 @updates > sddm-kcm.x86_64 6.2.1-1.fc40 @updates > sddm-wayland-plasma.noarch 6.2.1.1-1.fc40 @updates So this is the same version I am running, which is a good start. > 12:00 PM | π» | aceiow @ fedora | [ ~ ] > > grep "DisplayServer" /etc/sddm.conf > 12:00 PM | π» | aceiow @ fedora | [ ~ ] > > cat /etc/sddm.conf | grep "DisplayServer" > 12:00 PM | π» | aceiow @ fedora | [ ~ ] > > cat /etc/sddm.conf | grep DisplayServer > 12:00 PM | π» | aceiow @ fedora | [ ~ ] > > ls /etc | grep sddm.conf > -rw-r--r--. 1 root root 0 Oct 14 12:25 sddm.conf > drwxr-xr-x. 1 root root 34 Oct 14 12:24 sddm.conf.d It seems their sddm.conf is empty (which seems to happen when setting an SDDM theme because it's probably using kwriteconfig6 as well), which is effectively the same as the default config that has everything commented out... > 05:13 PM | π» | aceiow @ fedora | [ ~ ] > > ls /etc | grep sddm > drwxr-xr-x. 1 root root 80 Apr 15 2024 sddm > -rw-r--r--. 1 root root 0 Oct 14 12:25 sddm.conf > drwxr-xr-x. 1 root root 34 Oct 14 12:24 sddm.conf.d > 05:13 PM | π» | aceiow @ fedora | [ ~ ] > > ls /etc/sddm > total 16K > drwxr-xr-x. 1 root root 80 Apr 15 2024 . > drwxr-xr-x. 1 root root 4.6K Oct 22 12:31 .. > -rw-r--r--. 1 root root 141 Mar 20 2024 README.scripts > -rwxr-xr-x. 1 root root 1.6K Feb 26 2024 wayland-session > -rwxr-xr-x. 1 root root 70 Feb 26 2024 Xsetup > -rwxr-xr-x. 1 root root 53 Feb 26 2024 Xstop > 05:13 PM | π» | aceiow @ fedora | [ ~ ] > > ls /etc/sddm.conf.d/ > total 4.0K > drwxr-xr-x. 1 root root 34 Oct 14 12:24 . > drwxr-xr-x. 1 root root 4.6K Oct 22 12:31 .. > -rw-r--r--. 1 root root 243 Oct 14 12:24 kde_settings.conf This also looks the same as my setup. So yeah, unless there's another variable I'm missing it seems it works on the 6000 series but not on 7000 or Vega? Not sure where to go from here.
In any case, if this is really hardware-specific, it looks like a bug in the graphics driver, not in Plasma X11.
I wonder if you want to try xorg-x11-server 21 update https://copr.fedorainfracloud.org/coprs/sergiomb/xorg-x11-server/
(In reply to Sergio Basto from comment #8) > xorg-x11-server 21 update Tested. No dice, unfortunately :( > ~ ξ° dnf list installed xorg-x11-server-common xorg-x11-server-Xorg xorg-x11-server-Xephyr > Installed Packages > xorg-x11-server-Xephyr.x86_64 21.1.13-6.fc40 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > xorg-x11-server-Xorg.x86_64 21.1.13-6.fc40 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > xorg-x11-server-common.x86_64 21.1.13-6.fc40 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server Are there any configs or debug flags I can set so the journal spits out more about what's happening? Also one thing I just realised, but IDK if that's relevant: When the session start fails, it's also not playing that session start sound that's normally playing on the splashscreen. But that might just be because Plasma never fully launches so it doesn't even get that far.
dnf copr enable sergiomb/xorg-x11-server dnf update you need update at least xorg-x11-drv-amdgpu to be compatible with xorg-x11-server 21
(In reply to Sergio Basto from comment #10) > dnf copr enable sergiomb/xorg-x11-server > dnf update That's what I ran and the 3 packages listed (+ TigerVNC stuff) were the updates: > ~ ξ° dnf history info 0 > Transaction ID : 106 > Begin time : Tue 22 Oct 2024 16:50:22 CEST > Begin rpmdb : 7d61b63e4fc82ca665874096289b449caabdebc692e55a10af3324507c9dfc61 > End time : Tue 22 Oct 2024 16:50:23 CEST (1 seconds) > End rpmdb : 07de6263e59c1f282ec90cfc21b8c4cd4f28ac0d30954b0849efbbe15d7b7fb9 > User : Tarulia <tarulia> > Return-Code : Success > Releasever : 40 > Command Line : update > Comment : > Packages Altered: > Upgrade tigervnc-license-1.14.0-8.fc40.noarch @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > Upgraded tigervnc-license-1.14.0-4.fc40.noarch @@System > Upgrade tigervnc-server-minimal-1.14.0-8.fc40.x86_64 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > Upgraded tigervnc-server-minimal-1.14.0-4.fc40.x86_64 @@System > Upgrade xorg-x11-server-Xephyr-21.1.13-6.fc40.x86_64 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > Upgraded xorg-x11-server-Xephyr-1.20.14-35.fc40.x86_64 @@System > Upgrade xorg-x11-server-Xorg-21.1.13-6.fc40.x86_64 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > Upgraded xorg-x11-server-Xorg-1.20.14-35.fc40.x86_64 @@System > Upgrade xorg-x11-server-common-21.1.13-6.fc40.x86_64 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server > Upgraded xorg-x11-server-common-1.20.14-35.fc40.x86_64 @@System (In reply to Sergio Basto from comment #10) > you need update at least xorg-x11-drv-amdgpu to be compatible with > xorg-x11-server 21 Well, well, well, that's... interesting, because that package wasn't installed π€ So yeah, quickly installed that: > ~ ξ° dnf history info 0 > Transaction ID : 107 > Begin time : Tue 22 Oct 2024 22:56:13 CEST > Begin rpmdb : 07de6263e59c1f282ec90cfc21b8c4cd4f28ac0d30954b0849efbbe15d7b7fb9 > End time : Tue 22 Oct 2024 22:56:14 CEST (1 seconds) > End rpmdb : 76d1956498df7eed9d2bbed97a5ffc374d701eb076588148de25b8d0f0b836c8 > User : Tarulia <tarulia> > Return-Code : Success > Releasever : 40 > Command Line : install xorg-x11-drv-amdgpu > Comment : > Packages Altered: > Install xorg-x11-drv-amdgpu-23.0.0-6.fc40.x86_64 @copr:copr.fedorainfracloud.org:sergiomb:xorg-x11-server Reverted the sddm.conf: > ~ ξ° grep "DisplayServer" /etc/sddm.conf > # DisplayServer=X11 Rebooted and... waddaya know, it just works. So it seems there's a dependency missing somewhere π Though it seems that package wasn't needed for anything else because I've been using the install just fine, including playing games and all that.
I guess that before, it was using the generic "modesetting" driver, which should mostly work, except when it doesn't. That must also be why some people with the hardware are seeing the bug and others are not, because it works with the specific amdgpu driver and fails with the generic modesetting one.
OK I was curious and I asked them if they have that package, and: > 07:15 PM | π» | aceiow @ fedora | [ ~ ] > > dnf list installed xorg-x11-drv-amdgpu > Error: No matching Packages to list > 07:16 PM | π» | aceiow @ fedora | [ ~ ] > > dnf history xorg-x11-drv-amdgpu > No transaction which manipulates package 'xorg-x11-drv-amdgpu' was found. So yeah IDK. Unless they actually forgot to switch to X11 at the time I don't know why it would have worked for them :D Could just be driver shenanigans with the 6000 generation I guess... IDK. Anyway, glad to at least have found the cause :D
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Looks like NOTABUG to me. Closing. Feel free to reopen with new information, but preferably open an upstream ticket at https://gitlab.freedesktop.org/drm/amd/-/issues too.
I'm not sure how this would be considered NOTABUG? This is a dependency not being installed, which would be a packaging issue. If I were to open an upstream ticket I'm not sure what I'd even describe the bug as given the fact that installing the correct driver dependency makes it work properly? They'd just (rightfully) point to an issue with the package because it isn't pulling said driver. There is no "new information" to be had. We figured out what the problem was in the conversation above and that problem was a missing package. Given that this package is part of the Xorg project I'm inclined to believe it's supposed to be there because they knew it wouldn't work with the generic driver: https://src.fedoraproject.org/rpms/xorg-x11-drv-amdgpu/blob/rawhide/f/xorg-x11-drv-amdgpu.spec#_15-16
I guess there is one piece of new information: After painfully getting F39 KDE to boot (who came up with refusing to boot after EOL... ???), I can say that even the Live ISO includes that package, even though nothing actually depends on it. That tells me that someone at some point figured this was required for something. > liveuser@localhost-live:~$ rpm -E %fedora > 39 > liveuser@localhost-live:~$ dnf list installed | grep xorg-x11-drv-amdgpu > xorg-x11-drv-amdgpu.x86_64 23.0.0-2.fc39 @anaconda > liveuser@localhost-live:~$ dnf rq --whatrequires xorg-x11-drv-amdgpu --installed > liveuser@localhost-live:~$ dnf rq --whatrequires xorg-x11-drv-amdgpu > Last metadata expiration check: 0:02:54 ago on Mon 25 Nov 2024 02:31:19 PM EST. > liveuser@localhost-live:~$ dnf rq --whatrecommends xorg-x11-drv-amdgpu > Last metadata expiration check: 0:06:35 ago on Mon 25 Nov 2024 02:31:19 PM EST. > liveuser@localhost-live:~$ dnf rq --whatsuggests xorg-x11-drv-amdgpu > Last metadata expiration check: 0:06:43 ago on Mon 25 Nov 2024 02:31:19 PM EST. I'm not going to actually install F39 obviously but the point stands. I'm pretty sure that package would end up installed anyway.
Sorry for the triple post, but actually reading back up, I forgot this issue was reassigned in #7 . You're correct in that this is not a bug with xorg-x11-drv-amdgpu, because well... that exact package makes the session work. So this bug should likely be reassigned back to plasma-workspace-x11. On F39 (and below I'd assume) xorg-x11-drv-amdgpu was part of the base installation so this issue never occurred. Since it is not anymore, it needs to be pulled in for the session to work correctly, so plasma-workspace-x11 should depend (or at minimum soft-depend) on xorg-x11-drv-amdgpu, otherwise it's unusable for AMD users unless they either install xorg-x11-drv-amdgpu manually or set SDDM to run on X11.
Looks like the correct dependency chain should be: xorg-x11-server-Xorg (Recommends) -> xorg-x11-drivers (Requires) -> xorg-x11-drv-amdgpu plasma-workspace-x11 (and the GNOME equivalent gnome-session-xsession) require xorg-x11-server-Xorg. xorg-x11-drivers meta package is missing the dependency on amdgpu driver (though it has one on the old ati driver). And the Xorg server should probably have a weak dependency on the driver metapackage. Reassigning to xorg-x11-drivers as the lack of amdgpu dependency is an obvious omission.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-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 '40'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 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 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 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.