Bug 961140 - g-i-s lets you create a user with no password, but if you do, transition from g-i-s to user session fails and g-i-s re-runs on reboot
Summary: g-i-s lets you create a user with no password, but if you do, transition from...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 19
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jasper St. Pierre
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-08 21:56 UTC by Adam Williamson
Modified: 2013-05-28 00:31 UTC (History)
4 users (show)

Fixed In Version: gnome-initial-setup-0.10-3.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-24 20:43:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2013-05-08 21:56:26 UTC
g-i-s's user creation page will happily accept a user account with no password. If you just enter a name, no password, then the "Next" button is active and you can click it and proceed through the rest of g-i-s with no trouble.

However, doing so breaks the world: after you finish g-i-s, GNOME doesn't come up. The system just gets stuck, still in the g-i-s session.

If you reboot, g-i-s runs again. If, at this point, you create a new user account, with a password, then that will work and you will wind up in a user session for the new account. However, GNOME acts as if the first user account does not exist. It doesn't show up in GDM, and there is no Log Out option for the second user account.

At a console, you cannot log in as the first user account; it seems like it's created as a locked account, not an account you can log into without entering a password.

If, after creating the 'empty password' user, you do 'yum remove gnome-initial-setup' and reboot (instead of letting g-i-s run and creating a new account), then GDM fails to start up properly.

Not sure if the intent here is for you to be able to create a password-less account - in which case the mechanism needs to be fixed - or for it not to be possible - in which case Next needs to be greyed out if no password is entered.

Comment 1 Adam Williamson 2013-05-17 17:57:37 UTC
Nominating as a potential Beta FE - this behaviour makes a pretty bad impression and if whatever desktop team decides to do to fix it is quite simple/safe, we might want to pull it in for Beta (if not, we might prefer to leave it for Final).

Comment 2 Fedora Update System 2013-05-17 19:52:42 UTC
gnome-initial-setup-0.10-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gnome-initial-setup-0.10-3.fc19

Comment 3 Fedora Update System 2013-05-17 22:22:30 UTC
Package gnome-initial-setup-0.10-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-initial-setup-0.10-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8488/gnome-initial-setup-0.10-3.fc19
then log in and leave karma (feedback).

Comment 4 Adam Williamson 2013-05-20 17:45:43 UTC
Discussed at 2013-05-20 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-20/f19beta-blocker-review-7.2013-05-20-16.07.log.txt . Accepted as a freeze exception bug: this behaviour is pretty nasty if you hit it, and worth making sure is fixed for Beta.

Comment 5 Adam Williamson 2013-05-22 22:03:34 UTC
Verified fixed with 0.10-3.fc19.

Comment 6 Fedora Update System 2013-05-24 20:43:06 UTC
gnome-initial-setup-0.10-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Adam Williamson 2013-05-28 00:31:21 UTC
this was fixed prior to beta release, no need for commonbugs / FE.


Note You need to log in before you can comment on or make changes to this bug.