+++ This bug was initially created as a clone of Bug #1067653 +++

Description of problem:
After installing from kickstart file, firstboot comes up in spite of having specified "firstboot --disable" in kickstart. Using services --disabled=initial-setup-graphical" does not help either.


Version-Release number of selected component (if applicable):
anaconda/kickstart included with official F20 release


How reproducible:
install from kickstart file similar to attached. Specify "firstboot --disable"
and/or "services --disabled=initial-setup-graphical"

Actual results:
firstboot comes up anyway after installation is finished and the system reboots.

Expected results:
firstboot should NOT come up, login screen should be the first thing I see.

Additional info:
tried to troubleshoot by starting in rescue mode and looking for what services
are enabled. Tried "service initial-setup-graphical status" and "systemctl list-units", but got "Running in chroot, ignoring request." instead of useful information. Gee, thanks, systemd !!!

--- Additional comment from David Shea on 2014-02-20 22:07:18 EET ---

What exactly are you seeing? firstboot no longer exists. initial-setup, even if enabled, would only run if you did not create a user during installation (or if you installed an addon that uses initial-setup). What program is running and what is it asking you to configure?

--- Additional comment from Gabriel Somlo on 2014-02-20 22:24:02 EET ---

I think it's gnome-initial-setup. It's asking for a keyboard, language, timezone, etc. It forces me to create a user.

Everything except the user was already specified in the .ks file. I left out user creation ON PURPOSE.

What's the new kickstart-speak for "yes, initial-setup dear, I know what I'm doing, please stop trying to help me" ? :) Kinda what "firstboot --disable" used to convey ? Is there anything more polite than just forcing the package(s) to not get installed ? 

Thanks !

--- Additional comment from David Shea on 2014-02-20 22:33:24 EET ---

Yeah, that's gnome-initial-setup, and that's outside of our control. firstboot --disable does disable initial-setup, but gnome-initial-setup is a separate program and we can't do anything through kickstart to stop it, I'm afraid. Not installing the gnome-initial-setup is probably your best bet.

Moving the bug to gnome-initial-setup for the problem of forcing you to create a user.

--- Additional comment from Alexander Todorov on 2014-03-06 15:33:11 EET ---

Hi guys,
I'm hitting the same issue (issues) and see a trail of bugs related to whether user creation should be forced or not: 

bug #474007. bug #543008, bug #958189, bug #965797 and this one.

And it looks like we were switching this on and off. 


I have two questions: 

1) Has anyone tested that 'firstboot --disable' will actually disable initial-setup and friends, regardless of which packages are installed ? What is the expected or desired behavior here anyway ?

My expectation is if I wanted to explicitly disable it then all i-s programs will be disabled. Sounds like this is not the case. 


2) Wrt gnome-initial-setup and user creation - are we sure we want to force it ? 
I think if we use a file like /etc/sysconfig/firstboot to indicate whether g-i-s has run it should be relative easy to login as root, remove this file and reboot if the user skipped account creation by mistake ?

--- Additional comment from Gabriel Somlo on 2014-03-06 22:49:22 EET ---

(In reply to Alexander Todorov from comment #4)
> 1) Has anyone tested that 'firstboot --disable' will actually disable
> initial-setup and friends, regardless of which packages are installed ? What
> is the expected or desired behavior here anyway ?

firstboot --disable does indeed disable initial-setup. I was confusing that with g-i-s, which gets pulled in automatically when installing @gnome-desktop, and which then runs on first boot and, among other things, insists on having a user created no matter what.

> 
> My expectation is if I wanted to explicitly disable it then all i-s programs
> will be disabled. Sounds like this is not the case.

Right, is there any way to get g-i-s to notice "firstboot --disable" in a way similar to how the "regular" initial-setup obeys it ?

> 
> 
> 2) Wrt gnome-initial-setup and user creation - are we sure we want to force
> it ? 
> I think if we use a file like /etc/sysconfig/firstboot to indicate whether
> g-i-s has run it should be relative easy to login as root, remove this file
> and reboot if the user skipped account creation by mistake ?

No particular feeling for this from me -- I'd probably want it to create users for me, I'd like to be able to tell it I don't want to (on general principle, allow me to know what I'm doing, even if there's a chance I'll hang myself with all the rope :), but being able to simply bypass (firstboot --disable) it altogether is what I'm after in the first place; that would make your question #2 moot for me...

Thanks,
--G

--- Additional comment from Edgar Hoch on 2014-03-10 19:52:20 EET ---

Today I had three Fedora 19 system that was fresh installed some time ago, used by regular users (all user accounts are available only via nis), they run yum-updatesd and was rebooted today. But after reboot gnome-initial-setup was started unexpectedly instead of the usual gdm login screen.

The hosts have no ordinary local non-system user (only system users in /etc/passwd).
All ordinary non-system users are imported by nis (ypbind), home partitions are stored in nfs partitions. Login manager is gdm.

I have not found the reason why gnome-initial-setup was called after a long time of use while gnome-initial-setup was never started. I have used kickstart for the installation.

Currently I don't know how to stop starting gnome-initial-setup instead of gdm login screen. I tried to reboot but this was no help - gnome-initial-setup was started each time again.

I found that the file /var/lib/AccountsService/users/gnome-initial-setup exists on those systems that has started gnome-initial-setup. I have removed the file and rebootet the system, but I'm not sure if this had any effect on starting gnome-initial-setup. On one system regular gdm login screen was started after removing the file and rebooting, on another system gnome-initial-setup was started again after reboot, but not anymore after the second reboot.

I use NetworkManager to start the network interfaces, the ip configuration is configured static. Maybe that there is an unpredictable (?) timing problem if gdm was started before network and nis (ypbind) are available and then gdm (gnome-shell?) found no non-system user on the system (because it needs nis to find them)?

This is the first time the kernel 3.13.x (3.13.5) was booted on this F19 systems (because available updates are installed by yum-updatesd). I don't think that there is a relation between the new kernel and the problem, but I want to note it.

I know that this bug is against F20, but possibly this problem may be related to the problem of this bug report?

Is there a explanation what may have happend here? Have anyone other seen this behavior?
Is there a reliable methode to prevent gnome-initial-setup starting again and again (if that would happen)?

Thanks in advance.

--- Additional comment from Rui Matos on 2014-03-11 12:18:45 EET ---

If you wish to completely disable gnome-initial-setup being spawned by GDM, add the following to your /etc/gdm/custom.conf:

[daemon]
InitialSetupEnable=false

--- Additional comment from Francis Pinteric on 2014-03-19 17:08:28 EET ---

(In reply to Edgar Hoch from comment #6)
> Today I had three Fedora 19 system that was fresh installed some time ago,
> used by regular users (all user accounts are available only via nis), they
> run yum-updatesd and was rebooted today. But after reboot
> gnome-initial-setup was started unexpectedly instead of the usual gdm login
> screen.
> 

I've just experienced the same thing. The system has been running since F19 initial release. Then, after updated today (including kernel 3.13.6-100.fc19.x86_64) gnome-initial-setup started rather than normal gnome login. After creating a dummy account, gnome standard login does come up however my normal userid was unavailable in the list of userids. I was able to log in using the 'Not lists?' option. Is something getting corrupted perhaps?

--- Additional comment from Adam Williamson on 2014-03-20 19:48:18 EET ---

francis: what you're seeing is not "the same thing". This bug is about what is effectively a behaviour change at initial deployment time - some people want to bypass the (intended, 'correct') running of gnome-initial-setup on first boot of an installed system. What you're seeing appears to be some kind of bug where g-i-s suddenly starts running on an already-long-deployed-and-correctly-functioning system. It's not the same thing that's under discussion here.

Getting back to the actual issue here: rtcm: the thing is that people have an expectation that putting 'firstboot --disable' in their kickstarts will prevent the execution of a 'firstboot'-ish tool on first boot of an installed system, and initial-setup honors that just as firstboot did, but gnome-initial-setup does not. It seems like perhaps we ought to set things up so g-i-s does honor it, somehow or other - either by having g-i-s respect whatever it is anaconda actually does when 'firstboot --disable' is in the kickstart, or having anaconda do something g-i-s will notice in that case (like writing to /etc/gdm/custom.conf).

For now, I guess I'd simply suggest people explicitly drop gnome-initial-setup in their kickstarts, or if that doesn't work, write /etc/gdm/custom.conf in %post. Would that work for you, Edgar &c?

--- Additional comment from Matthias Clasen on 2014-03-20 19:52:26 EET ---

We've had a long, unsuccessful history of trying to agree with the anaconda team on a protocol for signalling whether initial-setup needs to run certain steps (or at all). In the end, the only thing we got was 'if a user exists, don't run it'.

--- Additional comment from Adam Williamson on 2014-03-20 19:55:38 EET ---

Huh, doesn't seem like it should be so hard.

What it actually does right now is quite tied into the initial-setup service. See https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/kickstart.py#n594 . But it doesn't seem like it should be beyond our capabilities to have that little function and g-i-s hook up with each other *somehow*.

--- Additional comment from Edgar Hoch on 2014-03-20 20:34:59 EET ---

(In reply to Adam Williamson from comment #9)
> For now, I guess I'd simply suggest people explicitly drop
> gnome-initial-setup in their kickstarts, or if that doesn't work, write
> /etc/gdm/custom.conf in %post. Would that work for you, Edgar &c?

After Fedora 20 was released, I had added the entries

[daemon]
InitialSetupEnable=False

to /etc/gdm/custom.conf in a kickstart postinstall script, and this works as expected. This was previously not neccessary on Fedora 19, but last week I did it for all our Fedora 19 hosts, too. I haven't really tested if the config file works on Fedora 19 because I have removed the package gnome-initial-setup as a precaution.

I have also removed package gnome-initial-setup from all our Fedora 19 and 20 hosts, this was successful.

I have made an exclude entry in the kickstart file for gnome-initial-setup, but I have not tested if it really prevents installation of gnome-initial-setup until now. I thought gnome-initial-setup was installed automatically on behave of a depencency, or it may be part of a yum / rpm group which I have installed, but I am unsure. I will do a test installation in some time and report the result.

Thanks for the hints!

--- Additional comment from Adam Williamson on 2014-03-20 20:53:12 EET ---

"I have made an exclude entry in the kickstart file for gnome-initial-setup, but I have not tested if it really prevents installation of gnome-initial-setup until now. I thought gnome-initial-setup was installed automatically on behave of a depencency, or it may be part of a yum / rpm group which I have installed, but I am unsure. I will do a test installation in some time and report the result."

Yeah, that's exactly what I meant by "if it works" - I haven't checked it either.

--- Additional comment from Edgar Hoch on 2014-05-16 05:05:13 EEST ---

Sorry for the delay.

Now I have installed F20 machines with an explicit exclude entry for package gnome-initial-setup in the kickstart file ("-gnome-initial-setup" in %package section).

This works for me, after installation package gnome-initial-setup is not installed, and the machine boots normally without waiting for user configuration. gdm is started normally.


So I see two different workarounds for the problem described in this bugreport:

1. Prohibite the installation of the package gnome-initial-setup in the kickstart configuration file.

2. Add the following entries to file /etc/gdm/custom.conf in a kickstart postinstall script:

[daemon]
InitialSetupEnable=False


A solution should make manual workarounds unneccessary.
A solution should recognize "firstboot --disable" option in the kickstart file and prevent starting gnome-initial-setup on boot. I think it would be best if something is done like described in workaround 2, because this will work even if package gnome-initial-setup is installed later.

--- Additional comment from Bryan Burke on 2014-10-02 21:49:21 EEST ---

Just a couple of items to add to this:

1. This issue affect RHEL7 as well.

2. It would be nice if anaconda could edit the /etc/gdm/custom.conf, on the assumption that you started with a graphical installation (i.e. chose the "Server with GUI Environment"). However, since that is not the case with my systems -- we do all minimal installs, then our configuration management adds the appropriate package[groups] -- I don't feel strongly about it.

3. I would, however, appreciate if a fix/note about this was more easily found. It took several hours of searching, testing, etc before I finally came across this bug report. Especially for the enterprise case, it would be really nice if there were a note that mentioned how one might disable this (the file edit), since I suspect this is a common issue for RHEL deployments. Places where this note would make sense to me:

  a. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/sect-trouble-after-x86.html#sect-trouble-after-graphical-login-x86

  b. http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/sn-switching-to-gui-login.html

Thanks for your consideration.

--- Additional comment from Fedora End Of Life on 2015-05-29 13:59:51 EEST ---

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.

--- Additional comment from Ben Stanley on 2015-05-29 17:06:56 EEST ---

This problem also affects RHEL 7.1, and needs to be dealt with there.