Bug 1226819 - gnome-initial-setup cannot be disabled, forces user creation
Summary: gnome-initial-setup cannot be disabled, forces user creation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-initial-setup
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Rui Matos
QA Contact: Desktop QE
Marie Dolezelova
URL:
Whiteboard:
: 1144623 (view as bug list)
Depends On: 1067653
Blocks: 1298243 1422867
TreeView+ depends on / blocked
 
Reported: 2015-06-01 08:38 UTC by Alexander Todorov
Modified: 2017-08-01 10:06 UTC (History)
25 users (show)

Fixed In Version: gnome-initial-setup-3.22.1-2.el7
Doc Type: Release Note
Doc Text:
Gnome Initial Setup can now be disabled by the "firstboot --disable" command in kickstart With this update, the _gnome-initial-setup_ package has been fixed to respect the "firstboot --disable" kickstart command. As a result, Gnome Initial Setup can be robustly turned off during a kickstart installation and users are no longer forced to create user account on the first boot under the described circumstances as long as the installation kickstart contains the "firstboot --disable" command.
Clone Of: 1067653
: 1422867 1428471 (view as bug list)
Environment:
Last Closed: 2017-08-01 10:06:04 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2318 normal SHIPPED_LIVE gnome-initial-setup bug fix and enhancement update 2017-08-01 12:44:07 UTC

Description Alexander Todorov 2015-06-01 08:38:52 UTC
+++ 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.

Comment 1 ralacroix 2016-03-17 20:16:32 UTC
This problem also affects RHEL 7.2

My setup:

- using "text" install rather than "graphical" in kickstart.
- kickstart file satisfies all items that would generate prompts.
- no users are created locally (using Enterprise logins).
- users will have a graphical environment (%packages section contains the environment group @^graphical-server-environment).

My requirements:

A) Do not run gnome-initial-setup on first boot, which prompts for user creation.

B) Do not run gnome-initial-setup on a user's first login, which localizes the user's desktop. The desktop is already customized globally for all users.

My findings:

- "firstboot --disable" in kickstart doesn't prevent gnome-initial-setup from running, so not using this as it might affect something else.

- allowing gnome-initial-setup on first boot to create a local user localizes only that user. Additional users still run gnome-initial-setup on first login.

- My requirements are met in varying degrees by the following 4 methods which have been documented elsewhere, which I tested with these results.

1) Add "InitialSetupEnable=False" under [daemon] in /etc/gdm/custom.conf

This method satisfies requirement A, but not requirement B.

2) Exclude the gnome-initial-setup package in kickstart and blacklist it from the gnome-desktop package group so that it is not reinstalled by an update of gnome-desktop.

%packages
-gnome-initial-setup
%end
%post
yum group mark blacklist gnome-desktop
%end

This method satisfies both requirements A and B. It's an unusual package setup and might affect future dependencies unless it becomes the de-facto standard way.

3) Remove gnome-initial-setup-*.desktop items from XDG autostart.

%post
rm /etc/xdg/autostart/gnome-initial-setup-{copy-worker,first-login}.desktop
%end

This method does nothing for requirement A, and only temporarily satisfies requirement B (the files might be reinstalled by an update of the gnome-initial-setup package). This is unacceptable.

4) Set up a template for new user home directories in /etc/skel that stops gnome-initial-setup from running. This affects only locally created users and may do nothing for an enterprise setup, which likely has remote home directories that are mounted on-the-fly; the same file needs to be created in pre-existing remote home directories. The contents of the file do not matter. This example template uses an empty file, which works.

%post
mkdir -p /etc/skel/.config && touch /etc/skel/.config/gnome-initial-setup-done
%end

This method satisfies requirement B, but not requirement A. Note that root's home directory is not set up by /etc/skel so if you insist on logging into root with a GUI and don't want localization to happen you would need instead to use

%post
mkdir -p /etc/skel/.config /root/.config && touch /etc/skel/.config/gnome-initial-setup-done /root/.config/gnome-initial-setup-done
%end

Conclusion:

The choices that work are: method 2 by itself, or methods 1 and 4 together. Method 2 never allows a user to reconfigure localization, while the latter combination allows a user to reconfigure localization by removing the file ~/.config/gnome-initial-setup-done (which is noticed almost immediately by GNOME).

Using method 2 (removing the package) makes the most sense to me only for my requirements, but it's exposed to the risk of new dependencies down the road.

If I was to suggest a software solution, it would be to modify gnome-initial-setup. In InitialSetup mode allow it to modify only global configuration settings like Time Zone (but that setting is debatable for a multiuser system) and make creation of the first local user optional (but surely some novices will use the wrong workflow and fail to create a local user). Also add a new control item under [daemon] in /etc/gdm/custom.conf, say UserInitialSetupEnable, that globally controls gnome-initial-setup for individual login mode. Existing behaviour with ~/.config/gnome-initial-setup-done can be retained to override UserInitialSetupEnable=true

Comment 2 ralacroix 2016-04-13 19:16:50 UTC
"firstboot --disable" is necessary to skip the prompts for accepting the EULA and creating a local user.

Comment 3 evilc 2016-11-03 16:43:22 UTC
I think I am also seeing this issue.
Setting up RHEL 7.3, and picking the KDE Gui from the package options.

Upon startup, I get to a first use wizard that is non-dismissable.

I hit Next through to the "About You" page.

There is also a "Set Up Enterprise Login" button. If you click this button, and attempt to enter windows domain details, then it informs you that samba and sssd is not installed.
Hitting Back does not allow you to exit "Enterprise Login".

It does seem, however, that if you click "Set Up Enterprise Login" again, you go back to the "About You" page.

I then reinstalled RedHat, and checked the "File Server" option in installed packages (I do not want a file SERVER, I want to use SAMBA to access windows shares).
Repeated, and it still said that SSSD was not installed.

So I just set up the user anyway, and finished the wizard.

Yet STILL, on startup, I cannot access my windows fileshares from nautilus.
I get "Unable to access location - Failed to retrieve share list from server: No such file or directory".

Epic Fail.
I have now tried RHEL 7.1, 7.3 beta and 7.3 and spent numerous days trying to get RHEL installed with working SAMBA. I have spent DAYS trying to do this.
Exactly how many years do you need to fix this? Beyond a joke.

Comment 4 ralacroix 2016-11-03 17:06:57 UTC
Not a joke. Management has officially cancelled our RHEL 7 deployment for taking too long. Maybe we will skip to RHEL 8, but seriously looking at porting our application to Windows. We are a Windows and Active Directory shop and this application was an outlier, originally running on Apollo workstations, then HP PA-RISC, and finally RHEL 4 and 6 for the last 10+ years. RHEL 7 is OK as a server O/S but too much stuff is broken in a desktop deployment.

Comment 7 Martin Kolman 2017-03-10 17:00:10 UTC
The Anaconda-side functionality needed for this is ready to be merged:
https://github.com/rhinstaller/anaconda/pull/973

Once that's in, everything should be in place.

Comment 8 Rui Matos 2017-03-13 13:26:09 UTC
*** Bug 1144623 has been marked as a duplicate of this bug. ***

Comment 20 Tomas Pelka 2017-06-21 09:48:06 UTC
Verified with gnome-initial-setup-3.22.1-4.el7

Comment 22 errata-xmlrpc 2017-08-01 10:06:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2318


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