I installed Fedora 24 Alpha 1.5 KDE x86_64 live: https://kojipkgs.fedoraproject.org/compose/24/Fedora-24-20160316.3/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-24_Alpha-5.iso . It installed fine, I was able to create a user in initial-setup and log in. I then left the VM running. After a while the session auto-locked. When I tried to unlock it, I could not. If I enter an invalid password and click Unlock, I see an "Unlocking failed" error message, OK. If I enter the correct password and click Unlock, the screen goes blank briefly then cycles back to the lock screen. If I do this several times, instead of going back to the lock screen, I see an error in large white type on a black background, slightly cut off at the edges: (?)creen locker is broken and unlocking is not possible any(?) (?)rder to unlock switch to a virtual terminal (e.g. Ctrl+Alt+(?) log in and execute the command: loginctl unlock-sessions (?)terwards switch back to the running session (Ctrl+Alt+F(?) Proposing as an Alpha blocker - I'm gonna cite "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.", on the basis that the 'working' desktop becomes 'not working' rather easily just by being left alone for a few minutes. https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
the error message's recommendation does work, FWIW (logging into a tty as root and running 'loginctl unlock-sessions' gets me back to the desktop).
Discussed at 2016-03-17 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot.fedoraproject.org/fedora-meeting/2016-03-17/f24-alpha-go_no_go-meeting.2016-03-17-17.00.html . We agreed that this looks pretty worrying, but we'd like a bit more data before making a definite decision (e.g. we should get some tracebacks, and why can I reproduce it reliably but Rex could not?)
Created attachment 1137667 [details] kscreenlocker_greet crash backtrace Generated manually with gdb.
To my untrained eye, this appears to be some sort of mesa/llvmpipe crash? #1 0x00007f76d16bbc3f in KCrash::defaultCrashHandler (sig=8) at /usr/src/debug/kcrash-5.19.0/src/kcrash.cpp:431 argv = {0x7f76d1afa880 <QQmlVMEVariantQObjectPtr::~QQmlVMEVariantQObjectPtr()> "H\215\005\361r\032", 0x0, 0x7ffedf04fbd0 "\320.\210\314v\177", 0x55fd3ef0b590 "J\350\257", <incomplete sequence \313>, 0x55fd3ef07c80 "P^\357>\375U", 0x55fd3eefb4b8 "", 0x7f76cc882ed0 <_q_ObjectMutexPool+848> "", 0x7f76cb7bcedc <__GI___libc_free+76> "H\203\304([]A\\A]\303f\017\037\204", 0x7f769c156ec8 "", 0x7f769c1909a0 " \301\022\234v\177", 0x1 <error: Cannot access memory at address 0x1>, 0x0, 0x7f76cc882ed0 <_q_ObjectMutexPool+848> "", 0x0, 0x7ffedf04fbd0 "\320.\210\314v\177", 0x55fd3ef0b5f0 "", 0x55fd3ee4fcb8 " ;p\314v\177", 0x55fd3ef0b590 "J\350\257", <incomplete sequence \313>, 0x55fd3ef07c80 "P^\357>\375U", 0x55fd3eefb4b8 "", 0x7f76cc882ed0 <_q_ObjectMutexPool+848> "", 0x7f76cb7bcedc <__GI___libc_free+76> "H\203\304([]A\\A]\303f\017\037\204", 0x1 <error: Cannot access memory at address 0x1>, 0x98ce988ae9a9a600 <error: Cannot access memory at address 0x98ce988ae9a9a600>, 0x7f769c1909a0 " \301\022\234v\177", 0x0, 0x55fd3ee4fcb8 " ;p\314v\177", 0x0, 0x7f769c056218 "p2\027\234v\177"} i = <optimized out> platformName = {d = 0x7f769c0f3370} about = <optimized out> sigtxt = "\001\000\000\000\000\000\000\000\000" pidtxt = "\320.\210\314v\177\000\000\334\316{\313v\177\000\000p\262\357>" startupId = {d = 0x400} crashRecursionCounter = 2 #2 <signal handler called> No locals. #3 0x00007f76ca61e789 in pthread_barrier_destroy (barrier=barrier@entry=0x55fd3ea337e0) at pthread_barrier_destroy.c:40 bar = 0x55fd3ea337e0 count = 0 max_in_before_reset = <optimized out> in = <optimized out> #4 0x00007f76b228a07f in pipe_barrier_destroy (barrier=0x55fd3ea337e0) at ../../../../src/gallium/auxiliary/os/os_thread.h:155 No locals. #5 lp_rast_destroy (rast=0x55fd3ea320c0) at lp_rast.c:970 i = 1 #6 0x00007f76b2293f71 in llvmpipe_destroy_screen (_screen=0x55fd3ea31b50) at lp_screen.c:528 screen = 0x55fd3ea31b50 winsys = 0x55fd3ea31af0 #7 0x00007f76b1edce7f in dri_destroy_screen_helper (screen=screen@entry=0x55fd3ea319b0) at dri_screen.c:380 No locals. #8 0x00007f76b1edcf25 in dri_destroy_screen (sPriv=0x55fd3ea31910) at dri_screen.c:391 screen = 0x55fd3ea319b0 #9 0x00007f76b1edb272 in driDestroyScreen (psp=0x55fd3ea31910) at dri_util.c:228 No locals. #10 0x00007f76ca1aa1c5 in driswDestroyScreen (base=0x55fd3e9e77e0) at drisw_glx.c:587 psc = 0x55fd3e9e77e0 #11 0x00007f76ca185f8c in FreeScreenConfigs (priv=<optimized out>, priv=<optimized out>) at glxext.c:217 psc = 0x55fd3e9e77e0 i = <optimized out> screens = <optimized out> #12 0x00007f76ca186009 in glx_display_free (priv=priv@entry=0x55fd3e9e92d0) at glxext.c:240 gc = <optimized out> #13 0x00007f76ca18615e in __glXCloseDisplay (dpy=0x55fd3e9a09d0, codes=<optimized out>) at glxext.c:288 priv = 0x55fd3e9e92d0 prev = <optimized out> #14 0x00007f76d3041a42 in XCloseDisplay (dpy=0x55fd3e9a09d0) at ClDisplay.c:65 ext = 0x55fd3e9e9350 i = <optimized out>
Believe me, your eye is more trained than mine when it comes to C backtraces... that would explain why you couldn't reproduce on bare metal too, I guess? I'll try with bare metal and a few variations on video config in the KVM today.
CCing the usual graphics suspects for now.
OK yeah, so confirmed that it works for me on bare metal (Intel graphics). Let's tentatively assign this to mesa for now, I'll try and narrow it down a bit more.
I tried testing a VM with graphics set to vga / VNC; it doesn't even make it to the desktop. Booting with 'quiet' removed shows sddm segfaulting with a general protection fault in Qt, will attach a screenshot.
Created attachment 1137863 [details] screenshot of sddm segfault with vga/vnc graphics
KVM with the graphics set to vmvga / VNC shows the same problem as qxl / SPICE, kscreenlocker_greet crashes.
updating summary (for incoming dups)
*** Bug 1319722 has been marked as a duplicate of this bug. ***
*** Bug 1319321 has been marked as a duplicate of this bug. ***
*** Bug 1302423 has been marked as a duplicate of this bug. ***
*** Bug 1299167 has been marked as a duplicate of this bug. ***
(In reply to Adam Williamson from comment #0) > Proposing as an Alpha blocker - I'm gonna cite "A system installed with a > release-blocking desktop must boot to a log in screen where it is possible > to log in to a working desktop using a user account created during > installation or a 'first boot' utility.", on the basis that the 'working' > desktop becomes 'not working' rather easily just by being left alone for a > few minutes. > https://fedoraproject.org/wiki/ > Fedora_24_Alpha_Release_Criteria#Expected_installed_system_boot_behavior Personally, I think this is a little iffy; I don't think it's so horrible if the alpha release doesn't work after a screen lock. (But I agree it should be a blocker for the final release.)
Discussed at today's blocker review meeting [1]. Voted as RejectedBlocker AcceptedFreezeException (Alpha) - it's a close call, but we feel the overall impact of this conditional violation is not quite sufficient enough to constitute an Alpha blocker. It's clearly worth a freeze exception, however [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-21
mesa-11.2.0-0.devel.12.24ea81a.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8e27c369d3
mesa-11.2.0-0.devel.12.24ea81a.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8e27c369d3
Fix looks good in Alpha-1.7, thanks.
mesa-11.2.0-0.devel.12.24ea81a.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.