If you do a clean install of current Fedora Rawhide KDE - e.g. from https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220725.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20220725.n.0.iso - then boot the installed system, log in, and log out, you wind up at a console on tty2, not back at SDDM as you should. As best I can tell, when the system boots, SDDM is running on tty1 and there are consoles on tty2 and tty3. After login, SDDM goes away and tty1 just shows a flashing cursor; KDE starts on tty3. tty2 still has a console. When logging out from KDE, the system puts you on tty2, with the console. tty1 still shows a flashing cursor. tty3 also now has a console again. SDDM doesn't seem to be present on any tty, though it's still *running* according to systemctl and ps. This seems similar to https://bugzilla.redhat.com/show_bug.cgi?id=2057419 , but AFAICT, sddm is no longer *crashing* at any point. It's just...not *there* after you log out.
I reported what might be the same problem with sddm on Wayland when logging out of Plasma in a F36 KDE Plasma installation https://bugzilla.redhat.com/show_bug.cgi?id=2073725 Errors like sddm[971]: Auth: sddm-helper exited with 3 were in the journal when that happened. The same problem is still happening with sddm-0.19.0^git20220321.e67307e-2.fc36.x86_64 and sddm-wayland-plasma-5.25.3.1-5.fc36.noarch in my F36 KDE Plasma installation. Since kwin_wayland is being used as the sddm compositor and kwin_wayland might be stopped during logout before sddm is shown again, this problem might be what happens. Lukas also reported this problem at https://bugzilla.redhat.com/show_bug.cgi?id=2097255
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
Confirmed bug at Fedora-KDE-Live-x86_64-37-20220813.n.0.iso
+4 in https://pagure.io/fedora-qa/blocker-review/issue/837 , marking accepted.
Since this is potentially a Wayland issue, I'm setting it to block the "Wayland by Default for SDDM" Change proposal tracker. An change for the sddm package to switch back to X11 is pending (https://src.fedoraproject.org/rpms/sddm/pull-request/5), so I'm setting this BZ to the POST status.
So, the PR was merged, and https://bodhi.fedoraproject.org/updates/FEDORA-2022-8456442870 went stable, but openQA is still showing the bug: https://openqa.fedoraproject.org/tests/1399308# the last green frame is openQA confirming logout as user Jack Sparrow, the first red frame is it winding up at a console when it expects to wind up at the login screen. Not yet sure if the change didn't take effect and we're still on Wayland, or the change took effect and we're on X but it's still broken.
Fedora-KDE-Live-x86_64-37-20220826.n.0.iso still has sddm-wayland-plasma-5.25.4-1.fc37.noarch installed with sddm-0.19.0^git20220321.e67307e-4.fc37.x86_64. sddm on Wayland was in use when I ran a QEMU/KVM VM with that image in GNOME Boxes. I could also see with ps aux | grep sddm that sddm-helper had /usr/bin/startplasma-wayland in its command line. When I logged out a black screen with just a flashing text cursor in the top left was shown. https://kojipkgs.fedoraproject.org//packages/Fedora-KDE-Live/37/20220826.n.0/data/logs/image/x86_64/livemedia-out.log has lines showing sddm-wayland-plasma is still installed like 2022-08-26 10:21:55,372 INFO pylorax: Installing sddm-wayland-plasma.noarch (1341/1870)
sddm-wayland-plasma is from the plasma-workspace source package https://src.fedoraproject.org/rpms/plasma-workspace/blob/f37/f/plasma-workspace.spec which contains a block for sddm on Wayland. # Control sddm wayland by default %if (0%{?fedora} && 0%{?fedora} < 37) || (0%{?rhel} && 0%{?rhel} < 9) %bcond_with sddm_wayland_default %else %bcond_without sddm_wayland_default %endif That part in plasma-workspace.spec might need to be changed like in sddm-0.19.0^git20220321.e67307e-4.fc37 https://src.fedoraproject.org/rpms/sddm/c/2ef9c9dc583cb99a3434cf37b5113aec61e3ac95?branch=f37 # Control SDDM Wayland by default - %if (0%{?fedora} && 0%{?fedora} < 37) || (0%{?rhel} && 0%{?rhel} <= 9) + %if (0%{?fedora} && 0%{?fedora} < 38) || (0%{?rhel} && 0%{?rhel} <= 9) %bcond_with sddm_wayland_default %else %bcond_without sddm_wayland_default
plasma-workspace-5.24.3-2.fc36 had a such a change to revert from sddm on Wayland to sddm on X at https://bodhi.fedoraproject.org/updates/FEDORA-2022-a541c359e4 and https://src.fedoraproject.org/rpms/plasma-workspace/c/c073fda73c010312e53e1d56dc7454f6d31213c9?branch=f36 # Control sddm wayland by default - %if (0%{?fedora} && 0%{?fedora} < 36) || (0%{?rhel} && 0%{?rhel} < 9) + %if (0%{?fedora} && 0%{?fedora} < 37) || (0%{?rhel} && 0%{?rhel} < 9) %bcond_with sddm_wayland_default %else %bcond_without sddm_wayland_default
Thanks, Matt, I think you're right. I'm sending a plasma-workspace build with that change now.
FEDORA-2022-6f3ca6889e has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6f3ca6889e
FEDORA-2022-6f3ca6889e has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6f3ca6889e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6f3ca6889e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I've triggered openQA tests on the update on staging; that'll get us a live ISO to test.
ISO for testing: https://openqa.stg.fedoraproject.org/tests/2007780/asset/iso/02007780-Fedora-KDE-Live-x86_64-FEDORA-2022-6f3ca6889e.iso
https://openqa.stg.fedoraproject.org/tests/2007780/file/_live_build-livemedia-out.log shows sddm-x11 installed in lines like 2022-08-27 13:34:42,374 INFO pylorax: Installing sddm-x11.noarch (1580/1870) 02007780-Fedora-KDE-Live-x86_64-FEDORA-2022-6f3ca6889e.iso has sddm-x11-0.19.0^git20220321.e67307e-4.fc37 installed when run in a QEMU/KVM VM. After I disabled Plasma autologin in System Settings through Startup and Shutdown > Login Screen (SDDM) > Behaviour > disable Automatically log in, I logged out to sddm on X normally twice. I updated to plasma-workspace-5.25.4-2.fc37 in a Fedora 37 KDE Plasma installation with sddm-wayland-plasma installed. sddm-wayland-plasma was updated to sddm-wayland-plasma-5.25.4-2.fc37. So plasma-workspace-5.25.4-2.fc37 kept sddm on Wayland if it was already installed which might be intended. That's what happened when I updated to plasma-workspace-5.24.3-2.fc36 in a F36 installation in March. Thanks.
Yeah, the way it works is that sddm-wayland-plasma gets "Supplements: (sddm and plasma-workspace-wayland)" if the build option is set, so the installed system gets sddm-wayland-plasma installed, which presumably tells sddm to use Wayland. Updating to a newer version of the the package without the Supplements won't cause it to be automatically removed, we're not that aggressive in Fedora's default config. So I think that's expected, and it's probably OK.
OK, tested the ISO locally and indeed log out does seem to work. I'll give the update karma and get it pushed stable.
FEDORA-2022-6f3ca6889e has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
So, we fixed this for F37 again by going back to X, but the bug is still there in Rawhide, where SDDM is still set to use Wayland: when you log out from KDE, you wind up on a tty, and sddm isn't running. I can't seem to find a current upstream issue for this, but it's definitely still broken. So, re-opening; as we've accepted this exact bug as a blocker twice so far, I'm just going to go ahead and mark it as an accepted blocker for F38, there doesn't seem to be any point re-debating it, it's the same bug.
This is on F36 but using the same package as in rawhide (built on COPR): restarted computer did not login switched to a tty restarted sddm via "systemctl restart sddm" logged in logged out.... sddm shows up as expected logged in again... everything works fine is this an indicator of a race condition or some environment thing not being set properly? Note: without restarting sddm, I experience the issue as described in this bug report
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Does it have to be in an installed system? I just live booted Fedora-KDE-Live-x86_64-Rawhide-20230104.n.0.iso and was able to logout of the live user and log back in without any issues.
Filed upstream bug report: https://github.com/sddm/sddm/issues/1636
(In reply to Justin Zobel from comment #22) > Does it have to be in an installed system? I just live booted > Fedora-KDE-Live-x86_64-Rawhide-20230104.n.0.iso and was able to logout of > the live user and log back in without any issues. Yes. Needs to be on an installed system.
Aleix Pol seems to be working on this. I just tried his draft: https://github.com/sddm/sddm/pull/1641 And I don't experience the problem anymore :-) Looking forward to the final implementation.
FEDORA-2023-1a365f606b has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1a365f606b
FEDORA-2023-1a365f606b has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1a365f606b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1a365f606b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-1a365f606b has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
I confirmed today this does work on Rawhide; the desktop_login test passes now.