Red Hat Bugzilla – Bug 965883
"Use network login..." button in user creation spoke entirely broken
Last modified: 2013-06-11 23:37:59 EDT
So far as I can tell, clicking "Use network login..." in the user creation spoke of anaconda or initial-setup in F19 Beta RC2 does precisely nothing at all. Well, the button click animation happens. That's about it. No window opens. Nothing is appended to any of the logs that I can see.
This is obviously a pretty significant issue as it'll prevent network auth configuration on non-GNOME installs entirely (GNOME uses gnome-initial-setup, which gives us another bite at the cherry, but I don't know if its network auth code actually works either, yet).
Proposing as a final blocker:
"A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."
OK, we (still) need to tweak that criterion, but basically, we require that account creation works at some point before you get to the login screen. This is effectively broken for the KDE path (GNOME path is complicated as g-i-s gives us a second bite at the cherry; KDE path is clearer since it uses anaconda then initial-setup) with any non-local user account at present. It's arguable whether that's a wide enough impact to block release for, but we should at least discuss it. And it should clearly be an FE bug, IMHO.
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . This is definitely accepted as a freeze exception issue, but we did not feel that we had the necessary experience at the meeting to make a call as to whether remote auth config ought to be release critical or not - we just don't know how important it is to those who use remote auth that it be configurable interactively before first login (or whether they'd be fine with creating a local account first and then configuring remote auth from there). Please, if you have input on whether this should be a blocker issue, post a comment.
Discussed at 2013-06-05 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-05/f19final-blocker-review-3.2013-06-05-16.05.log.txt . Based on the feedback received on devel@ so far we're rejecting this as a blocker: overall the impression we're getting is that people who use remote auth already didn't find firstboot reliable for it and are already used to working around getting it set up outside of anaconda/'firstboot' stages.
We are accepted the bug as a freeze exception issue, though. Obviously if this can be 'fixed' - as in, useful remote auth code put in in time for Final - that would be good. The other option, if there's no chance of any usable remote auth setup code going in before Final, would be to suppress the button so it doesn't confuse/disappoint people.
May as well just remove it for now.
anaconda-19.30.3-1.fc19 has been submitted as an update for Fedora 19.
* 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 anaconda-19.30.3-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
For release notes: we should note that there's no remote auth configuration in the anaconda/i-s path and only FreeIPA and AD support in the anaconda/g-i-s path; all other cases require kickstart (in %post, I guess) or post-install configuration.
I've added a Release Note for this. Thanks for flagging, Adam!
anaconda-19.30.3-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.