Bug 474007

gdm no longer allows logging in as root, so we really do need a non-root user created for the typical installation case.  If we provide people the option to skip user creation, some significant portion of people are going to take it, then be stuck not being able to login through X.  Anyway it's just good policy to have a regular user on the system.

firstboot shouldn't even be enabled in the system recovery case, either.

Please read the mail and part of the discussion at the link. I was going to perform a system recovery and had a broken /home partition. In this case I must have one of the two options:

1. Ether skip user creation.
2. Or have full control on the user creation process, i.e. manually specify at least uid, group/gid and home path.

If I'm performing system recovery I do not need that "user" after the recovery process, because I restore the users/groups/etc from the passwd/shadow/group/gshadow backup. Creating a user without full control on the process will make in many cases a user with settings which overlap with what you are going to recover. If I have a full control on user creation I can later easily get rid of the temporary user account created during installation for recovery purposes.

(In reply to comment #1)
> firstboot shouldn't even be enabled in the system recovery case, either.

Why not? It still tries to do some useful things like setting up clock/timezone for example.

Also consider you are setting up a server and do not want to create any user accounts except root. Yes, you will not be able to perform a graphical login with default settings, but in this case you are not going to. But in many cases you still need to do the rest of the firstboot configuration.

After I did a text-based clean install of F10, the default runlevel was set at 3 instead of 5, and the text-based version of firstboot didn't even ask me if I wanted to create an ordinary user account (which is probably another bug).  See bug #472687.  If that can be run instead of the GUI version, that would be another workaround for your problem (at least until that bug is fixed).

If you're setting up a server and won't be performing graphical logins, you still probably want an extra non-administrative user that you can use to do administrative tasks through sudo (which reminds me - I need to add support for that to firstboot).  Anyway there are way more simple tools for setting up clocks and timezones in rescue cases than having to deal with the rest of firstboot.

firstboot is, by and large, designed for the initial boot of interactive systems to perform a few final tasks.  It also provides a framework for people to add all sorts of crazy extra screens, but that's beside the point.  As such, as long as the login manager enforces that a non-root user must be present to login, firstboot is going to have to play along.  I don't want users in a situation where they cannot login on their first boot because they failed to make a new user account.

I understand the concern about users who can't login because they failed to make a new user account, but there's a real need to be able to create a system without an extra non-administrative user.  For example, I have a little script that I run after I do an install.  This script creates all of the users and groups and performs other miscellaneous configuration.  Unfortunately, there doesn't seem to be any way to get around firstboot to run the script.  If I create an extra user in firstboot, then I have to manually delete it after the other users are created.

If firstboot won't provide an option to bypass user creation, could you at least enable virtual terminals.  I would be so happy if I could just do Ctrl-Alt-F2, log in as root on a terminal, and run my script.  Unfortunately, when I do Ctrl-Alt-F2, I get a blank screen, and there's no way to log in.  I can't think of any reason not to enable virtual terminals, and they would really help for the situation where a user really knows what they're doing and wants to bypass firstboot.

Should I create a separate bug report, since this one is closed?  Thanks.

(In reply to comment #5)
> If you're setting up a server and won't be performing graphical logins, you
> still probably want an extra non-administrative user that you can use to do

If you want me to force to create some 'useful' user at the firstboot then at least give me the full control of the process. I must be able assign UIDs, groups, home directories; without this user will not be useful for me. What the heck, add the 'advanced' button where I can specify these options. Should I open a separate bug for this? Regular useradd takes quite a number of options, you know, why are you insisting that any user created only with name, login and password is useful?

I still think that either the whole firstboot process must have an option to be skipped, or at least the user creation part.

There's already a bug saying firstboot should use something like system-config-users, which I do agree with as it'll reduce the amount of special code I have to deal with, so don't worry about that.

firstboot can be skipped if you use kickstart or if you chroot /mnt/sysimage and chkconfig it off after an install is done.

Kickstart is a great tool, but there are tons of situations where it's not the right tool for the job.  Doing a chroot & chkconfig is a really roundabout solution, and it doesn't really help after the system is already installed.

Anyway, I just created bug #494130.  When it is fixed, this problem should be much easier to work around.  I still think that there should be a more direct solution provided, though.

I just reinstalled my machine with Fedora 12, and now I can't even do CTRL-ALT-BACKSPACE to get out of firstboot.  I used to be able to force the stupid thing to go away, but now I'm completely stuck.  Firstboot completely takes over the system, not allowing any other terminals to run and providing no way to quit it.  If there were a quit button, firstboot would go away at least temporarily (and if a misguided newbie accidentally quit it, the worst thing that could happen is that they'd have to reboot to get firstboot again).

No, X no longer lets you do ctrl-alt-backspace.  firstboot's doing nothing special there.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 WONTFIX if it remains open with a Fedora 
'version' of '12'.

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 prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This is still a problem for me in Fedora 13 and 14.

Actually, in Fedora 14, it looks like Ctrl-alt-backspace works during firstboot, so I'm now able to quit out of it.  I'm not sure if this helps the original requester, though.

It is possible to skip the user creation using a trick described in bug #543008 (select Configure network login, and then Cancel). Also in F14, there is an Advanced button now, where the administrator can create users using system-config-users, with full control over UIDs, GIDs, etc.

However: after creating users with s-c-u (clicking Advanced in firstboot), firstboot still thinks no user has been created yet, and does not allow to get out of this step, unless the trick described above is used.

Fixed by 890cb3b91334014bfc318752b03c79292db38989

Now, if you have no suitable user account, you just get a warning, but you can continue if you wish so, and you know what you're doing.