Bug 1955894

Summary: SDDM does not start after F33->F34 upgrade
Product: [Fedora] Fedora Reporter: Will Springer <skirmisher>
Component: sddmAssignee: Martin Bříza <m>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 34CC: jgrulich, kde-sig, me, m, pierluigi.fiorini, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-08 00:07:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Will Springer 2021-05-01 10:28:04 UTC
Description of problem:
Upon upgrading from Fedora 33 to 34, SDDM will no longer start, instead leaving VT1 displaying the startup log indefinitely.

Version-Release number of selected component (if applicable): 0.19.0-13.fc34.x86_64

How reproducible: Always

Steps to Reproduce:
1. Upgrade SDDM to the latest version on F33
2. Upgrade F33 to F34
3. Boot system configured with SDDM as display manager

Actual results:
SDDM does not start

Expected results:
SDDM starts and shows the login screen

Additional info:
Here is the entirety of the log present in journalctl for sddm.service:

May 01 00:22:35 sheen systemd[1]: Started Simple Desktop Display Manager.
May 01 00:22:35 sheen sddm[7825]: Failed to read display number from pipe
May 01 00:22:35 sheen sddm[7825]: Attempt 1 starting the Display server on vt 1 failed
May 01 00:22:37 sheen sddm[7825]: Failed to read display number from pipe
May 01 00:22:37 sheen sddm[7825]: Attempt 2 starting the Display server on vt 1 failed
May 01 00:22:39 sheen sddm[7825]: Failed to read display number from pipe
May 01 00:22:39 sheen sddm[7825]: Attempt 3 starting the Display server on vt 1 failed
May 01 00:22:39 sheen sddm[7825]: Could not start Display server on vt 1

It seems the display server is not starting. I have no insight into why this is; I have found no traces of a log produced by SDDM anywhere else, nor do I know how SDDM's startup process works. I know SDDM is supposed to use Wayland now, but I have no idea how that is configured, considering it isn't documented on the change page[1] despite it alluding to the ability to switch back to X11. Thus, I can't tell whether SDDM is attempting to use Wayland or X11.

I noticed that SDDM also failed to relaunch when logging out of my Plasma session in F33, prior to preparing for the upgrade. At the time, I dismissed it as a fluke. The journal from that boot is cut off, but "Failed to read display number from pipe" and "Could not start Display server on vt 1" are present. Note that I had not yet upgraded SDDM from its previously installed version at all. (The last package upgrade on this system was over a month ago, while being logged into Plasma for two months straight; it's possible that the SDDM package was upgraded that previous time, but I'm not familiar with its update history.)

Plasma starts and functions normally using both X11 and Wayland. However, selecting "log out" in the Wayland session does not terminate the remaining Wayland clients (or at least the KDE background processes) gracefully, and they start to consume massive amounts of CPU, forcing a `loginctl terminate-session` or a game of htop whack-a-mole. I don't know what's up with that, but it's probably unrelated. Fortunately, getting all aspects of Wayland working is not a goal for me.

[1]: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma

Comment 1 Ben Cotton 2022-05-12 16:16:02 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
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 '34'.

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 34 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.

Comment 2 Ben Cotton 2022-06-08 00:07:07 UTC
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 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.

Thank you for reporting this bug and we are sorry it could not be fixed.