Version-Release number of selected component: sddm-0.10.0-2.fc22 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: sddm-greeter crash_function: qt_message_fatal executable: /usr/bin/sddm-greeter kernel: 3.18.0-0.rc3.git4.1.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #2 qt_message_fatal at global/qlogging.cpp:1411 #3 QMessageLogger::fatal at global/qlogging.cpp:639 #4 QXcbConnection::QXcbConnection at qxcbconnection.cpp:346 #5 QXcbIntegration::QXcbIntegration at qxcbintegration.cpp:155 #6 QXcbIntegrationPlugin::create at qxcbmain.cpp:50 #7 loadIntegration at kernel/qplatformintegrationfactory.cpp:56 #8 QPlatformIntegrationFactory::create at kernel/qplatformintegrationfactory.cpp:73 #9 init_platform at kernel/qguiapplication.cpp:1011 #10 QGuiApplicationPrivate::createPlatformIntegration at kernel/qguiapplication.cpp:1166 #11 QGuiApplicationPrivate::createEventDispatcher at kernel/qguiapplication.cpp:1183
Created attachment 955578 [details] File: backtrace
Created attachment 955579 [details] File: cgroup
Created attachment 955580 [details] File: core_backtrace
Created attachment 955581 [details] File: dso_list
Created attachment 955582 [details] File: environ
Created attachment 955583 [details] File: limits
Created attachment 955584 [details] File: maps
Created attachment 955585 [details] File: open_fds
Created attachment 955586 [details] File: proc_pid_status
Created attachment 955587 [details] File: var_log_messages
Qt bug, sddm can't do anything about this
if (!m_connection || xcb_connection_has_error(m_connection)) qFatal("QXcbConnection: Could not connect to display %s", m_displayName.constData()); I don't think it's fair to blame Qt for failing to bring up a GUI if it can't connect to the X server. The problem must be somewhere else.
Apparently, the DISPLAY= environment variable is not set. It's no wonder Qt cannot connect to the display "". This is not a Qt bug. Either the issue lies in SDDM, or lower in the stack.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Another user experienced a similar problem: Clean install Fedora 22 (KDE Spin) on a Dell Optiplex 745 w: * Intel(R) Core(TM)2 CPU * 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300] Boot completes successfully, but instead of the greeter, a black screen is displayed, and dmesg reports: > [ 45.496872] sddm-greeter[1349]: segfault at 8 ip 00007f1f48aa3eb8 sp 00007ffdf373b930 error 4 in r300_dri.so[7f1f485b9000+7b7000] So presumably a driver issue. Switching to another TTY, logging in and running `startx` works as expected. Thanks reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: sddm-greeter --test-mode crash_function: qt_message_fatal executable: /usr/bin/sddm-greeter global_pid: 20034 kernel: 4.0.4-301.fc22.x86_64 package: sddm-0.10.0-4.fc22 reason: sddm-greeter killed by SIGABRT runlevel: N 5 type: CCpp uid: 0
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.
*** This bug has been marked as a duplicate of bug 1403340 ***
*** Bug 1415326 has been marked as a duplicate of this bug. ***
*** Bug 1403340 has been marked as a duplicate of this bug. ***
Closing as duplicate for private bug is not best idea ;)
Created attachment 1255347 [details] kernel-4.9.8 journal entries with sddm-greeter
I started seeing this problem in F25 when kernel-4.9.9 arrived. Relevant journal entries: Feb 18 18:12:53 lucy-001 sddm-greeter[1156]: High-DPI autoscaling Not Enabled Feb 18 18:12:53 lucy-001 audit[1156]: ANOM_ABEND auid=4294967295 uid=997 gid=994 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=1156 comm="sddm-greeter" exe="/usr/bin/sddm-greeter" sig=6 Feb 18 18:12:53 lucy-001 sddm-greeter[1156]: QXcbConnection: Could not connect to display :0 Feb 18 18:12:53 lucy-001 abrt-hook-ccpp[1179]: Process 1156 (sddm-greeter) of user 997 killed by SIGABRT - dumping core For a successful boot with 4.9.8, see attachment -- although those sddm-greeter messages are interesting by themselves.
Likely a dup of bug #1370222 Tracks one case where xauth gets invalidated due to hostname changes *** This bug has been marked as a duplicate of bug 1370222 ***
Rex, that might be interesting except for the fact that my machine has a statically allocated IP address/hostname. It never changes. So why would this problem be a duplicate of 1370222?
OK, I only said likely. So, we're back to wondering why X connections are being refused. :(
Actually, Rex -- you are on the right track. Turns out my /etc/hostname was set to localhost.localdomain, whereas my systems hostname is lucy-001. Changing them both to lucy-001 means sddm-greeter on 4.9.9 doesn't crash anymore, and therefore I can log into the desktop again. Why this mismatch between /etc/hostname and NetworkManager's notion of hostname didn't cause a problem for me until 4.9.9 is unknown. Shrug. ;)
ok, let's go back to considering it a dup *** This bug has been marked as a duplicate of bug 1370222 ***
Can confirm that changing /etc/hostname from localhost resolved the issue for me.
*** Bug 1430938 has been marked as a duplicate of this bug. ***