Bug 1147504

Summary: Upgrading to GNOME 3.14.0 reruns g-i-s
Product: [Fedora] Fedora Reporter: Stephen Gallagher <sgallagh>
Component: gnome-initial-setupAssignee: Rui Matos <tiagomatos>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 21CC: jstpierr, pnemade, rstrode, sgallagh, tiagomatos
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: accountsservice-0.6.39-2.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-10 06:28:52 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:
Attachments:
Description Flags
Patch: don't start accounts-daemon until after nss-user-lookup.target none

Description Stephen Gallagher 2014-09-29 12:35:30 UTC
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:

Comment 1 Stephen Gallagher 2014-09-30 13:35:34 UTC
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.

Comment 2 Fedora Blocker Bugs Application 2014-09-30 13:39:29 UTC
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.

Comment 3 Stephen Gallagher 2014-09-30 15:56:45 UTC
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.

Comment 4 Fedora Update System 2014-10-16 18:23:51 UTC
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

Comment 5 Stephen Gallagher 2014-10-17 13:19:51 UTC
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?

Comment 6 Ray Strode [halfline] 2014-10-17 15:38:01 UTC
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

Comment 7 Fedora Update System 2014-10-17 16:31:38 UTC
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

Comment 8 Fedora Update System 2014-10-17 19:45:27 UTC
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).

Comment 9 Fedora Update System 2014-11-10 06:28:52 UTC
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.