Description of problem: Both the 3.13.92 and 3.14.0 upgrades forced me to rerun gnome-initial-setup without an option to skip it. This is a real pain, as it essentially mandates creating a new user that I then have to delete later. Version-Release number of selected component (if applicable): gnome-initial-setup-3.14.0-1.fc21.x86_64 How reproducible: Happened on the 3.13.92 upgrade and the 3.14.0 upgrade. Steps to Reproduce: 1. Install Fedora 21 alpha 2. Enroll in one or more network domains (such as enterprise logins). This step may not be necessary, but I had no local human users on the system and that seemed likely relevant. 3. Upgrade to the latest 3.14.0 bits. Actual results: After a reboot, the user is forced to go through gnome-initial-setup again, despite having usable accounts already on the system. Expected results: g-i-s should not be rerun unless it is needed. Additional info:
Raising the severity to "high". I discovered this morning that if I don't leave the created local user in place on the system, it will re-run G-I-S on every boot. This needs to be fixed.
Proposed as a Blocker for 21-beta by Fedora user sgallagh using the blocker tracking app because: "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention" "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." Neither of these is a *perfect* fit, but I'm arguing that the intent of these criteria is violated, rather than the letter.
I'm removing my blocker proposal. It's looking likely that this will not be hit in common operation and is likely related to my use of SSSD without a full AD or FreeIPA domain behind it.
accountsservice-0.6.39-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/accountsservice-0.6.39-1.fc21
Created attachment 947895 [details] Patch: don't start accounts-daemon until after nss-user-lookup.target This update did not make the problem go away. However I did figure out (finally) what the issue actually is (and why I can only consistently reproduce it in the morning or on updates). It turns out we just didn't wait long enough between reboots. The reason I could reproduce it after updates or on first morning boot is because the SSSD fast-cache (the one that still answers requests before SSSD is fully up and running) has a 300s timeout. So the only way to guarantee that the users can always be answered properly is to add After=nss-user-lookup.target to the Accounts Service systemd service file. I'm not certain if this is completely sufficient, since it's still theoretically possible for the Accounts Service to be D-BUS activated before this. Can you check on that?
thanks for tracking this down. I actually don't think it's a problem in practice since accountsservice has WantedBy=graphical.target in it, so it will get started before it gets activated. Still, I think we can fix the problem by adding a Wants line by the After line
accountsservice-0.6.39-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/accountsservice-0.6.39-2.fc21
Package accountsservice-0.6.39-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing accountsservice-0.6.39-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13123/accountsservice-0.6.39-2.fc21 then log in and leave karma (feedback).
accountsservice-0.6.39-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.