Created attachment 794390 [details] Logs including backtrace Description of problem: After entering the correct password on F20 Alpha TC4 KDE installation on ARM or x86_64 I am returned to the login screen. Version-Release number of selected component (if applicable): sddm-0.2.0-0.4.20130821gite707e229.fc20 How reproducible: everytime Steps to Reproduce: 1. Install F20 Alpha TC4 KDE with defaults 2. Attempt to log in. Actual results: Returned to login screen. Expected results: working KDE desktop Additional info: Logs attached
Proposed Alpha blocker under this criterion: "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." [1] [1] - https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
I see this as well, but only when the session “Custom” is selected in sddm. “Failsafe”, “KDE Plasma workspace (Failsafe session)”, and “KDE Plasma workspace” work, but the selected default “Custom” does *not* work.
Based on the post on mailing list, it's not related only to ARM (and I'd say probably for Mike too). At least for now fixing the "Custom" selected as default would be a good fix for Alpha. And it's possible to workaround it by selecting the right option. Pinging mbriza to take a look.
sddm-0.2.0-0.5.20130821gite707e229.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/sddm-0.2.0-0.5.20130821gite707e229.fc20
Package sddm-0.2.0-0.5.20130821gite707e229.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sddm-0.2.0-0.5.20130821gite707e229.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16155/sddm-0.2.0-0.5.20130821gite707e229.fc20 then log in and leave karma (feedback).
Discussed at 2013-09-09 blocker review meeting [1]. This has been accepted as an Alpha blocker. While not a 100% clear-cut violation of the criteria for KDE, this was deemed close enough to a violation to take as a release blocking bug for F20 alpha: "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." [2] [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-09/ [2] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
sddm-0.2.0-0.5.20130821gite707e229.fc20 fixes the issue for me.
Just noticed that "KDE Plasma Workspace (Failsafe Session)" is now selected as default instead of "KDE Plasma Workspace", is this expected?
Martin, thanks for testing! SDDM now lists the sessions in the same order QDir::entryList() returns them from /usr/share/xsessions . It would indeed be better if the regular session was first (and I'll address it in the future by pre-selecting it by default) but it isn't really a big problem right now.
Does sddm support accountsservice and/or ~/.dmrc yet?
I also thought it was fixed, then I realized I tested an already installed system. Of course the right session was picked after upgrade, it was remembered from the last attempt. So I installed a clean TC5 DVD KDE system, booted into runlevel 3 on the first boot, upgraded sddm and rebooted. Unfortunately this is not fixed. "Custom" is still present and selected as the default. sddm-0.2.0-0.5.20130821gite707e229.fc20.x86_64
It's fixed in sddm-0.2.0-0.6.20130821gite707e229.fc20.x86_64 , not .5 (didn't notice that at Martin's comment), the update system didn't inform about the change of the update: https://admin.fedoraproject.org/updates/FEDORA-2013-16155/
(In reply to Rex Dieter from comment #10) > Does sddm support accountsservice and/or ~/.dmrc yet? Rex, not yet, AccountsService support is planned but for some reason it's listed as "Qt5 only" on https://github.com/sddm/sddm/wiki/TODO . Will ask aavci about it when he comes to IRC.
*** Bug 1006318 has been marked as a duplicate of this bug. ***
Problem fixed with .6, KDE failsafe pre-selected as default. "Custom" is gone.
(In reply to Martin Bříza from comment #12) > It's fixed in sddm-0.2.0-0.6.20130821gite707e229.fc20.x86_64 , not .5 > (didn't notice that at Martin's comment), the update system didn't inform > about the change of the update: > https://admin.fedoraproject.org/updates/FEDORA-2013-16155/ Sorry, it was a typo, I tested sddm-0.2.0-0.6.20130821gite707e229.fc20.x86_64 (and I didn't log in using .5 after clean install so the choice wasn't saved from the last login in) ;)
(In reply to Martin Bříza from comment #13) > (In reply to Rex Dieter from comment #10) > > Does sddm support accountsservice and/or ~/.dmrc yet? > > Rex, not yet, AccountsService support is planned but for some reason it's > listed as "Qt5 only" on https://github.com/sddm/sddm/wiki/TODO . Will ask > aavci about it when he comes to IRC. The plan was to use this https://github.com/hawaii-desktop/qt-accountsservice-addon which is done for Qt 5 since I'm not using Qt 4 anymore but I don't think there are problems adding Qt 4 support. I'll see if I have time on this weekend to add Qt 4 support, that will make it usable on SDDM.
sddm-0.2.0-0.6.20130821gite707e229.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.