Bug 1067653

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?

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 !

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.

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 ?

(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

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.

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

(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?

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?

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'.

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*.

(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!

"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.

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.

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.

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.

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

See bug #1226819 for the RHEL 7.1 part.

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.

I don't believe we ever did anything to address this, so re-opening.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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 23 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.

still don't think this has been done.

I've got a kickstart that installs a user, accepts the eula, and disables firstboot

And I've still got this goddamned initial-setup running.

FOUR GODDAMNED YEARS YOU'VE KNOWN ABOUT THIS, AND YOU'VE DONE NOTHING.

Just look at this garbage:

root       752     1  0 17:33 tty1     00:00:00 /bin/bash /usr/libexec/initial-setup/run-initial-setup
root       765   752  0 17:33 tty1     00:00:00 /bin/xinit /usr/libexec/initial-setup/firstboot-windowmanager /usr/libexec/initial-setup/
root       768   765  0 17:33 tty2     00:00:00 /bin/Xorg :9 -ac -nolisten tcp
root       786   716  0 17:33 ?        00:00:00 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /
root       967   765  0 17:33 ?        00:00:00 /bin/sh /usr/libexec/initial-setup/firstboot-windowmanager /usr/libexec/initial-setup/ini
root       975   967  0 17:33 ?        00:00:00 /usr/bin/metacity
root       980   967  0 17:33 ?        00:00:01 /usr/bin/python /usr/libexec/initial-setup/initial-setup-graphical --no-stdout-log

FIX IT.

I don't particularly care about the gnome initial setup. But this initial-setup garbage is a problem. 

So, it turns out, to stop the initial-setup garbage from running, you need this in your kickstart:

eula --agreed
firstboot --disable
#AND 
services --disabled="initial-setup-graphical"


UPDATE YOUR DOCUMENTATION

gnome-initial-setup and initial-setup are separate things. This bug has nothing to do with initial-setup; it is specific to g-i-s.

(also, if you have a kickstart, why don't you just leave the packages out entirely?)

Yes, this bug is mainly about g-i-s, but it contains references to initial-setup and initial-setup-graphical as well. 

I ended up here because this bug is the closest thing to accurate documentation on the mess that is firstboot, initial-setup, initial-setup-graphical, and gnome-initial-setup.

This bug is now the clearest piece of documentation on the web regarding the behaviour of initial-setup, ie, that it is *NOT* disabled by "firstboot --disable", because initial-setup-graphical still runs unless the initial-setup-graphical service is also disabled.

That's not what it's for, though. It's a bug report, and the actual bug that it relates to still actually exists, and it's not useful to have discussion of an entirely different problem clogging up the bug report. This report contains references to initial-setup only for the purpose of comparing the behaviour when g-i-s is involved to the behaviour when i-s is involved, with the assumption that the behaviour when i-s is involved is the 'intended' behaviour, with a view to having things behave the same when g-i-s is involved.

If you think there's a bug related to initial-setup behaviour, the best thing to do is to file a different bug report.

I'm not going to read through the whole bug, but suffice to say we will not be making user creation optional in gnome-initial-setup. If you don't want to create an initial user, then you need to make sure not run gnome-initial-setup in the first place.

If you have a problem with your kickstart, it's not going to be fixed by reporting a bug against gnome-initial-setup.

Re-opening with a better description for the outstanding valid issue. See comment #9 and follow-ups. This would require co-ordination between anaconda and g-i-s teams to implement and not break going forward.

Given that gnome-initial-setup is not a Fedora project, are you proposing to add in Fedora-specific patches to prevent gnome-initial-setup from running? If so, gdm would be the right place, because it's gdm that starts the g-i-s session and nothing g-i-s does will be able to avoid that. But really, you just need to be sure an initial user exists before gdm is launched, because gdm doesn't have anything plausible to do other than launch g-i-s if there are no users.

So I'm really not sure what the requested behavior is, but something not GNOME would need to create the initial user if you want to avoid g-i-s. E.g. the kickstart file. Is anaconda responsible for kickstarts?

Please reassign this bug to another component if you want to keep it open.

It's about allowing g-i-s to be disabled *without a user necessarily having been created* - this is something that people want, or at least did back in 2014. :P

There don't need to be any Fedora-specific packages, there just needs to be a mechanism for telling g-i-s not to run which works for anaconda folks to interface with, I guess. Some file or setting anaconda can drop into place to tell g-i-s not to run. Something like the setting mentioned in comment #7, I guess, but that's not an ideal thing for anaconda to have to set by the looks of it.

Frankly, I must say this is a huge surprise to me - I though this has been long fixed on both RHEL7 *and* Fedora! 

Basically what we did for RHEL 7.4 (Anaconda bug 1422867 and GIS bug 1226819) was for Anaconda to forward the "firstboot --disable" kickstart command to the user interaction config file[0] in /sysconfig/anaconda, setting the "post_install_tools_disabled" key to "1". Gnome Initial Setup then learned to parse /sysconfig/anaconda (which is a simple ini-style config file, that is trivial to parse from C compared to kickstart file) and to terminate if it finds "post_install_tools_disabled" set to "1".

This mechanism seem to be working fine since RHEL 7.4 & makes it possible to trivially disable *both* Initial Setup and Gnome Initial Setup from kickstart.

The same code that takes care of writing the "post_install_tools_disabled" key to /sysconfig/anaconda is present not only on the RHEL 7 branch but also in Anaconda upstream. I was expecting the same for Gnome Initial Setup, but apparently that's not the case - looks like support for parsing /sysconfig/anaconda still lives only in a RHEL/CentOS 7 downstream patch:

https://git.centos.org/blob/rpms!gnome-initial-setup.git/c7/SOURCES!honor-firstboot-disabled.patch

The patch does not look like it found it's way to the Gnome Initial Setup upstream - at least git grep has not found anything for "post_install_tools_disabled", "sysconfig" or "anaconda" in the Gnome Initial Setup source code repository.

As for a way forward I see one of these 3 options:

* using the RHEL/CentOS 7 patch as a Fedora downstream patch for GIS
- this is the fastest option (if the patch applies) but least future proof

* getting the patch upstream it it's current form
- no downstream patch is needed in Fedora
- other distros can make use of it
- the name of the file has "anaconda" in it, so it's not completely generic

* getting the patch upstream with generic config name
- a generic not yet used config name would have to be found
- backwards compatibility needs to be taken into account (Anaconda writes /sysconfig/anaconda + the new file, or possibly just does a symlink)

Looking forward to your feedback on these options! :)

[0] https://anaconda-installer.readthedocs.io/en/latest/user-interaction-config-file-spec.html

(In reply to Adam Williamson from comment #33)
> It's about allowing g-i-s to be disabled *without a user necessarily having
> been created* - this is something that people want, or at least did back in
> 2014. :P

Yes, we don't want and need local users on systems that are part of a nis or ldap domain. Users are defined by the central name service - it is not useful to have local users in this case.

I have solved the problem for me by explicit excluding package gnome-initial-setup in our kickstart files ("-gnome-initial-setup" in %package section - thanks there is no other dependency that requires it!). But of course, it would be better if g-i-s execution can be disabled even if the package is installed.

Martin, I think any of the three options are fine, but I *don't* think that patch would work in its current form, per the comment:

+  /* We only do this in existing-user mode, because if gdm launches us
+   * in new-user mode and we just exit, gdm's special g-i-s session
+   * never terminates. */
+  if (initial_setup_disabled_by_anaconda () &&
+      mode == GIS_DRIVER_MODE_EXISTING_USER) {
+    gis_ensure_stamp_files ();
+    exit (EXIT_SUCCESS);
+  }

On firstboot, Fedora runs g-i-s in new user mode, whereas RHEL uses existing user mode. So that brings us back to gdm. You also need changes in gdm to get the behavior you desire.

FWIW, enterprise login in g-i-s is already broken in Fedora, because you wind up with disabled root account and no local administrator user, so just making it possible to skip user creation will not actually result in a usable system. We need to figure out how to solve that too.

Michael: with a kickstart install, root is not necessarily locked. They do not want to get g-i-s to run but skip user creation. They just don't want it to run at all because they are doing the stuff they need for their site in the kickstart and g-i-s has nothing to contribute (AIUI).

OK, I understand.

Summary: need a way to tell gdm not to run the gnome-initial-setup session.