Bug 929289 - only start gnome-initial-setup if no user account already exists
Summary: only start gnome-initial-setup if no user account already exists
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jasper St. Pierre
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
: 929439 949353 950020 950621 951958 952618 953138 953333 (view as bug list)
Depends On:
Blocks: F19Alpha-accepted, F19AlphaFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-03-29 16:04 UTC by satellitgo
Modified: 2013-05-29 13:41 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-03 22:36:03 UTC


Attachments (Terms of Use)
screenshot during default (GNOME) 19 Alpha TC3 install showing that both root and user accounts can be created (27.28 KB, image/png)
2013-03-30 19:49 UTC, Andre Robatino
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 697292 None None None Never

Description satellitgo 2013-03-29 16:04:15 UTC
Description of problem:
user created in anaconda is ignored in gnome-initial-setup. on startup user is required to setup a 2nd user before proceding. Boot into gnome is to 2nd user. Anaconda user is only avalable after log-out/log-in in GDM

Version-Release number of selected component (if applicable):
Fedora-19-Alpha-TC3-x86_64-Live-Desktop.iso

How reproducible:
only on first startup after install

Steps to Reproduce:
1.
2.
3.
  
Actual results:
2 users created (required)

Expected results:
anaconda user created should be used

Additional info:

Comment 1 Francis Earl 2013-03-30 18:59:37 UTC
This description isn't actually correct as pertains the situation I am seeing, however I was asked to comment here.

My understanding is that gnome-initial-setup replaces firstboot. In this use case there is no problem, it is great in this capacity.

Where the initial report is inaccurate is that firstly anaconda doesn't actually create users, it only sets the root password. What actually happens is if the user has installed without GNOME, then installs the group 'GNOME Desktop', it is unaware of any users currently on the system and still goes through the process of creating a user.

I don't know if currently firstboot and gnome-initial-setup both run during an install of Rawhide/Fedora 19 Alpha, if they do then I can confirm this bug.

Comment 2 satellitgo 2013-03-30 19:39:37 UTC
I did not see this in a VirtualBox netinstall of xfce_x86_64 where "yum groupinstall gnome-desktop" is run then logout/login to gnome  No gnome-initial-setup started. This appears to be only related to an anaconda install where the user is configured.
see screenshots here:
 http://wiki.sugarlabs.org/go/Fedora_19_gnome-initial-setup

Comment 3 Andre Robatino 2013-03-30 19:49:18 UTC
Created attachment 718352 [details]
screenshot during default (GNOME) 19 Alpha TC3 install showing that both root and user accounts can be created

Comment 4 Andre Robatino 2013-03-30 19:57:25 UTC
Anaconda currently offers the option of creating root and/or regular user during *any* installation, in either graphical or text mode (so you can even do it in a minimal install). This is nice, as long as gnome-initial-setup doesn't insist on creating another user even when one already exists.

Comment 5 satellitgo 2013-03-30 21:01:08 UTC
there should be a warning in anaconda to not create a user in anconda if installing gnome-desktop. This will avoid gnome-initial-setup creating a 2nd user

Comment 6 Jasper St. Pierre 2013-03-30 21:05:27 UTC
Anaconda / gnome-initial-setup interaction to prevent duplicate steps is planned.

Comment 7 Shawn Starr 2013-04-01 18:15:17 UTC
I noticed if I set a user with anaconda during install; after installation, once gnome-initial-setup starts, Go though screens, create a bogus user (which never gets created on disk) proceed to end of screens, click the 'Start using GNOME 3' button at end, it wont proceed past this.

If I Reboot VM, then I am able to use anaconda user and is listed in gdm login screen. I can then login to GNOME 3 fine.

Comment 8 Jens Petersen 2013-04-02 10:22:56 UTC
*** Bug 929439 has been marked as a duplicate of this bug. ***

Comment 9 Martin Sivák 2013-04-03 11:59:15 UTC
Francis: GIE does not replace firstboot as KDE and others still need users. It merely has one feature in common (but not all!).

There is a new incarnation of firstboot called initial-setup (and the name was chosen while Gnome still used gnome-initial-experience in their marketing..) which shares some screens with Anaconda and supports 3rd party plugins.

The only interaction we wanted here was to prevent displaying initial-setup's user creation screen iff (if and only if) Gnome was the only environment installed.

Anaconda does not care about Gnome being installed or not, because it can't determine what is going to be executed. The user can be created while the packages are still being copied. Moreover, users can be also created using a kickstart file or (under development - see realmd) the whole login system can use networked (NIS/kerberos) logins.

So the plan was:
- Anaconda installer will always show user creation screen
- initial-setup will show the user creation screen unless it was configured already or unless GIE asked for it (this interaction needs to be defined as GIE runs after initial-setup)

sattelit:

Even if we decide to make this work your way in Anaconda, you still have to deal with the kickstart case where many users (not just one..) can be created before the first reboot.

From my point of view, this is definitely a bug in GIE as it is making assumptions about the installed system instead of reading the actual config files.

I will be available for consultations if needed, but vpodzime is now the maintainer of initial-setup. I have moved to a different team.

Comment 10 Adam Williamson 2013-04-03 17:43:59 UTC
Discussed at 2013-04-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt .

This isn't ultimately fatal; worst case you end up with multiple user accounts, really. You can basically do a successful install with a user account. So we agreed it's not a blocker issue.

We accept it as a freeze exception issue, though. The general principle here is that we're favourable to pulling in fixes to anaconda / initial-setup / gnome-initial-setup interaction at least this week (we'll get tighter next week as we get close to release). We really need the anaconda, i-s and g-i-s folks to get together and agree on how this is supposed to work. It REALLY should have been thrashed out before we ever got this far. The current situation is a mess that I'm not sure anyone understands; has anyone even figured out the interactions between the two initial-setup packages when both are installed?

Comment 11 Jens Petersen 2013-04-04 01:50:32 UTC
I think a simple solution would be to allow skipping gnome-initial-setup
if a user account already exists in the system with a [Skip] button say.

Comment 12 Jens Petersen 2013-04-04 04:58:13 UTC
(In reply to comment #5)
> there should be a warning in anaconda to not create a user in anconda if
> installing gnome-desktop. This will avoid gnome-initial-setup creating a 2nd
> user

Yes either that or disabling the user spoke when installing gnome, perhaps?

(In reply to comment #6)
> Anaconda / gnome-initial-setup interaction to prevent duplicate steps is
> planned.

Can you say more about the plan?

Comment 13 Matthias Clasen 2013-04-05 12:33:48 UTC
> Can you say more about the plan?

We are changing things in gdm upstream to only go into initial-setup if there are no user accounts. So, if you create a user account in anaconda, you will end up on the login screen (when you log in for the first time, initial setup will still run, in a reduced mode that skips steps that don't make sense in this mode.

For now, that's just the user creation step. It would be nice if there was a way to know that timezone has already been configured in anaconda, then we could skip that too.

Comment 14 Jens Petersen 2013-04-08 05:49:53 UTC
Okay thanks - sounds very good.

Comment 15 Jens Petersen 2013-04-08 07:39:03 UTC
*** Bug 949353 has been marked as a duplicate of this bug. ***

Comment 16 Jens Petersen 2013-04-08 07:42:26 UTC
(In reply to comment #13)
> It would be nice if there was a
> way to know that timezone has already been configured in anaconda, then we
> could skip that too.

It seems to pick up the system timezone so maybe it is working
or can be assumed?

Comment 17 Matthias Clasen 2013-04-08 16:55:23 UTC
Here is the upstream commit in gnome-initial-setup:

https://git.gnome.org/browse/gnome-initial-setup/commit/?id=88f61b7f92c3d31909bc62bc2ce70a6a42140f0e

and here is the bug with the required gdm changes:

https://bugzilla.gnome.org/show_bug.cgi?id=697292

Comment 18 Matthias Clasen 2013-04-08 16:59:03 UTC
These changes will be in 3.8.1 which is due next Monday.

Comment 19 Jaroslav Reznik 2013-04-10 11:25:45 UTC
(In reply to comment #13)
> It would be nice if there was a
> way to know that timezone has already been configured in anaconda, then we
> could skip that too.

With current Anaconda NewUI workflow, I think you can always assume timezone has been configured and it should be skipped in gnome-initial-setup.

User reviews current configuration in the Hub, if the correct timezone is preselected. If yes, he does not have to touch it at all and just begins installation.

Comment 20 Jens Petersen 2013-04-11 04:21:52 UTC
*** Bug 950621 has been marked as a duplicate of this bug. ***

Comment 21 Robert Lightfoot 2013-04-14 20:15:34 UTC
*** Bug 951958 has been marked as a duplicate of this bug. ***

Comment 22 Matthias Clasen 2013-04-16 15:49:59 UTC
*** Bug 952618 has been marked as a duplicate of this bug. ***

Comment 23 Ryan Lerch 2013-04-17 13:27:53 UTC
*** Bug 953138 has been marked as a duplicate of this bug. ***

Comment 24 Ryan Lerch 2013-04-17 13:32:37 UTC
*** Bug 950020 has been marked as a duplicate of this bug. ***

Comment 25 Jens Petersen 2013-05-02 06:22:39 UTC
Well it still seems to be starting in current F19 (Beta TC2)
but in the user session - maybe that is intended.

Comment 26 Matthias Clasen 2013-05-02 15:21:08 UTC
We are running gnome-initial-setup in the user session too, yes. This is only supposed to happen the very first time you log into an account. Due to the way this is implemented, you currently also get it in existing accounts after upgrades. 

When run in this mode, gnome-initial-setup skips all steps that are only relevant in firstboot scenarios (setting timezone, creating user account).

Comment 27 Adam Williamson 2013-05-03 01:03:09 UTC
That part's not a bug then. So if, in TC2, it doesn't start up prior to login, and doesn't show timezone and user creation steps, I think we can mark this as fixed. Can anyone confirm? (virt-manager is busted for me ATM so it's a bit inconvenient for me to check).

Comment 28 Robert Lightfoot 2013-05-03 22:33:45 UTC
Testing with Fedora-19-Beta-TC2 of both i386 and x86_64 on qemu/kvm and vbox hosts provided anticipated behavior of gnome-initial-setup.

Comment 29 Adam Williamson 2013-05-03 22:36:03 UTC
Bob confirms that this behaves 'as expected' in TC2, so I believe we can close this bug. The 3.8.1 mega-update which included g-i-s 0.9 is in stable. There's a g-i-s build in testing ATM, but it post-dates this fix.

Comment 30 Adam Williamson 2013-05-08 21:24:22 UTC
*** Bug 953333 has been marked as a duplicate of this bug. ***

Comment 31 Michael Ekstrand 2013-05-28 18:36:27 UTC
I just did a netinstall of Fedora 19 Beta, and encountered the problem described in this bug: I created a user during Anaconda, but still got the setup screen upon booting into the new system, create-user and all.

Relatedly, Anaconda did not do group setup at all as advertised, so it may be that the resulting user (which had the group ID of a nonexistent group) triggered it.

Comment 32 Ankur Sinha (FranciscoD) 2013-05-29 05:01:21 UTC
(In reply to Michael Ekstrand from comment #31)
> I just did a netinstall of Fedora 19 Beta, and encountered the problem
> described in this bug: I created a user during Anaconda, but still got the
> setup screen upon booting into the new system, create-user and all.
> 
> Relatedly, Anaconda did not do group setup at all as advertised, so it may
> be that the resulting user (which had the group ID of a nonexistent group)
> triggered it.

Interesting. I did a clean F19 Beta install yesterday and it worked just fine. I created a root user, and a separate user which had admin privileges. Did you create at least a root or an admin user in anaconda?

Comment 33 Adam Williamson 2013-05-29 05:40:49 UTC
Michael: *gnome*-initial-setup only runs if you install GNOME.

If you installed anything else, you saw initial-setup, and you want https://bugzilla.redhat.com/show_bug.cgi?id=963935 .

Comment 34 Michael Ekstrand 2013-05-29 13:41:43 UTC
(In reply to Ankur Sinha (FranciscoD) from comment #32)
> (In reply to Michael Ekstrand from comment #31)
> > I just did a netinstall of Fedora 19 Beta, and encountered the problem
> > described in this bug: I created a user during Anaconda, but still got the
> > setup screen upon booting into the new system, create-user and all.
> > 
> > Relatedly, Anaconda did not do group setup at all as advertised, so it may
> > be that the resulting user (which had the group ID of a nonexistent group)
> > triggered it.
> 
> Interesting. I did a clean F19 Beta install yesterday and it worked just
> fine. I created a root user, and a separate user which had admin privileges.
> Did you create at least a root or an admin user in anaconda?

I did - I created both a root password, and my normal admin user (michael). Upon boot, it asked me to create a new user in the initial setup (and wouldn't let me skip or tell it I already had one).

However, the user did not get created correctly - see <https://bugzilla.redhat.com/show_bug.cgi?id=968085>. It could be that gnome-initial-setup is behaving correctly but the incomplete user setup confused it.

My install was a Gnome Desktop install.


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