You know what? Why don't we just do this in anaconda?

as I explained in this mail:

https://lists.fedoraproject.org/pipermail/devel/2013-May/183114.html

Now I've spent a couple of days examining all the possible scenarios here, I'm about 99% sure there's no good reason to run initial-setup at all for anything but OEM installs.

In F18 and earlier, we had a simple split: anaconda set the root password, firstboot did user creation. firstboot would let you skip user creation, though, after you clicked through a warning.

In F19 anaconda can now do user creation. So far as I can figure, if we simply have anaconda try and encourage user creation but allow it to be skipped by a determined user, we have covered all the use cases from earlier releases with no need to run initial-setup at all.

To me, that seems much better than the unnecessary complexity of having anaconda let you skip user creation without a warning, then popping up initial-setup and having *it* encourage you to create a user. That just seems unwieldy. And as the initial incarnation of this bug report said, initial-setup doesn't even _do_ that at present. It's basically doing nothing useful whatsoever. So instead of 'fixing' initial-setup - but still having an overly complex flow - why not just get rid of it?

So I think anaconda should do this:

On the 'during install' hub, the 'user creation' spoke should be mandatory. You should be required to visit it before leaving the installer. But once you are in it, it should allow you to exit again without creating a user, but warn you using the standard anaconda mechanism if you try to do so: pop up the orange warning bar, with a message similar to the old firstboot one, and require you to click again to confirm. If you do that, it would let you out without creating a user.

If anaconda does that, I don't see that we need initial-setup at all, except for what we've been referring to as the "OEM case" (some kind of pre-deployed Fedora, so we need something to run to let the final user of the system set up a root password and user account and time zone). We could have it only run in that case, and never show in a 'normal' install.

*** Bug 949779 has been marked as a duplicate of this bug. ***

Forcing the user to enter the spoke just so they can exit it is silly.

The initial experience apps simple need to check for an existing user and let people continue with booting their system.

I don't think you quite got the idea.

Yes, we can fix initial-setup. That's what this bug started out as: a request to fix initial-setup.

But look, run both scenarios through your head.

Imagine a world where we fix initial-setup. What does it look like?

1. You run anaconda. You create a user account. You boot your installed system; because you created a user, it boots straight to the login prompt, no need for i-s.

2. You run anaconda. You don't create a user account. initial-setup runs, and offers you solely the option to create a user account (because the other stuff it has at present is pointless and should be killed). But it lets you quit without creating one, if you want.

Now imagine a world where we make this change to anaconda, and dump initial-setup entirely. What does it look like?

1. You run anaconda. You create a user account. You boot your installed system, it boots straight to the login prompt.

2. You run anaconda. You don't create a user account. Anaconda alerts you that you shouldn't do that unless you really know what you're doing. You tell it "it's fine, I know what I'm doing". You boot your installed system, and it boots to the login prompt.

How is World 1 better than World 2, exactly? They are both eons better than the world we have right now, but the point I'm driving at here is that once you think through all the scenarios, a "fixed" initial-setup is just pointless complexity and we might as well just do it in anaconda.

Note that the "no user account" case is the minority case, and the amount of inconvenience to the minority case is identical in both scenarios. Whether we kill i-s or not, we really should add some hoops you have to jump through to proceed without creating a user *somewhere*. (In F18, it was in firstboot, obviously; you had to click through a warning to proceed without creating a user account). It's just a question of whether we add them to initial-setup or to anaconda.

viteslav, could we have your opinion on this?

I think we need Initial Setup not only for OEM installations but also for addons and other screens that may appear there in future (I myself am working on one such addon). On the other hand I believe i-s should warn if no user is created in the installation nor in the i-s itself as this was the behaviour of the Firstboot. In the same time the i-s shouldn't show up if everything was set in the installation. But these are just bugs that should be fixed, not by killing the i-s nor by enforcing user creation in the installation or anything like that.

Sure, after we chatted about it, I can see your point. So let's just make this into the bug for 'i-s should warn if user creation is not done'. When I get a minute, I'll file a new bug to track the work of not displaying spokes (or i-s at all) unless it's necessary. Thanks.

Patches posted to anaconda-patches.

Somehow we must assume that people installing Fedora have common senses. If it is a kid on a desktop at home, he will figure something out. Have no fear about that.

For an admin, he would probably do what I do.

When installing and not creating a user during anaconda execution this is what I do.

I create the root password as simple as possible and force it to be so. 
Example 1234567890 is forced, because I can remember it.

When the system reboots after anaconda has done its thing, I log to root
I create an administrator, I set his password, and I put him in the wheeel group.
I also create a guest account and password.

I then set root password to a confidential one, easy to verify from within the installed operating system. I this way, I am certain of the root password.

And just before I exit root, I do two actions from the console,  

yum update -y  and 
reboot.

Just document the method in the release notes and thats it. No need to go further

I was kind of expecting this to be resolved long before final crunch, but the patches got held up in review. Proposing as a final freeze exception: this looks pretty dumb, when we run i-s after you already did all the useful stuff it can do during installation.

Discussed at 2013-06-19 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . Accepted as a freeze exception issue: firstboot used to do this, and it's a bad idea to make it too easy to get to a login screen with no user account. Can't be fixed post-release.

Unfortunately this hasn't made RC1 or RC2 because a new i-s build with the fix hasn't been done since it was acked on June 19 :( Be great if we could get a new build just in case we wind up doing an RC3.

(In reply to Adam Williamson from comment #13)
> Unfortunately this hasn't made RC1 or RC2 because a new i-s build with the
> fix hasn't been done since it was acked on June 19 :( Be great if we could
> get a new build just in case we wind up doing an RC3.
It is not about a new build of the I-S. The patch for the I-S has been ACKed, but the patch for the Anaconda that is needed as well was NACKed.

How this will work during unattended installations with kickstart,
with "no user account", like in comment #10 ?
Currently with kickstart's:
firstboot --disable
i'm left with a confirmation dialog waiting to be closed.

My practical advice for such an install would just be to remove the initial-setup package from the deployed package set:

%packages
-initial-setup
%end

(In reply to Adam Williamson from comment #16)
> My practical advice for such an install would just be to remove the
> initial-setup package from the deployed package set:
> 
> %packages
> -initial-setup
> %end

I confirm this workaround works for me - no more "no user account" confirmation button to click.

This is still broken in F20 :( We really need to fix it. May need to be cloned for RHEL 7 as well.

Will try to revive the discussion about the potential solution.

For the discussion:

I want to note that having no "local user" created may be what the administrator wants to have!

Regard a scenario where you have many hosts (desktops, servers) in a network (for example at university or company) which uses ldap or nis to distribute users to the hosts. Then it is ok to have only root as a local user (which will be used only for administration, mostly remote using ssh).

I think, if the administrator uses kickstart and sets "firstboot --disable", then no question about the configuration should be asked at all, neither by initial-setup nor by gnome-initial-setup.

This bug would not affect that path. If initial-setup is disabled it is, of course, not going to print any warnings.

(In reply to Edgar Hoch from comment #20)
> For the discussion:
> 
> I want to note that having no "local user" created may be what the
> administrator wants to have!
> 
> Regard a scenario where you have many hosts (desktops, servers) in a network
> (for example at university or company) which uses ldap or nis to distribute
> users to the hosts. Then it is ok to have only root as a local user (which
> will be used only for administration, mostly remote using ssh).
> 
> I think, if the administrator uses kickstart and sets "firstboot --disable",
> then no question about the configuration should be asked at all, neither by
> initial-setup nor by gnome-initial-setup.

The subject of this bug is something different but it's useful to state
that on CentOS 7.0.1406 x86_64 in order to get the desired behaviour
(fully unattended installation) one needs:

1. firstboot --disable
2. -initial-setup
3. -gnome-initial-setup

This is consistent with https://ask.fedoraproject.org/en/question/33672/fedora-19-and-nis-issues-on-a-fresh-install/

marcin: for the record - I noticed that during RHEL 7 testing and am told it will be less silly in 7.1 :)

I can confirm that in centos 7.1 (1503) it is "less silly", but gnome-inital-setup is still alive and well unfortunately. (#1144623; Insult to injury: it creates a homedir in /home that automounter doesn't like later on when you get a chance to configure it.)

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

If the user is allowed to enroll himself on loggin into the system on first boot, what is the guarantee that this first user must be an administrator and not a normal user?

I believe that both root and administrator logons must be filled within anaconda as a safety measure.



If this solution is accepted, the installation guide will have a small correction to one paragraph to remove the text about first boot.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.