RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1412185 - New F19 firstboot doesn't honor kickstart option "firstboot --disable"
Summary: New F19 firstboot doesn't honor kickstart option "firstboot --disable"
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-11 13:32 UTC by Tru Huynh
Modified: 2021-01-15 07:30 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 968582
Environment:
Last Closed: 2021-01-15 07:30:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CentOS 0012584 0 None None None 2017-01-11 13:32:23 UTC

Description Tru Huynh 2017-01-11 13:32:23 UTC
+++ This bug was initially created as a clone of Bug #968582 +++

Description of problem:
Specifying "firstboot --disable" in kickstart should disable firstboot, but this doesn't seem to be the case in F19 with the new firstboot.

Version-Release number of selected component (if applicable):
anaconda-19.30-1.fc19

How reproducible:
Always

Steps to Reproduce:
1. Install from kickstart that specifies "firstboot --disable"

Actual results:
Firstboot is enabled.

Expected results:
Firstboot is disabled.

--- Additional comment from Edgar Hoch on 2013-06-26 12:22:51 EDT ---

I confirm this error with Fedora 19 RC2 .

--- Additional comment from Brian Lane on 2013-06-26 20:26:22 EDT ---

Please attach the logs from /tmp/*log to this bug as individual text/plain attachments. program.log should show systemctl being run.

--- Additional comment from Edgar Hoch on 2013-06-26 21:09:16 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:09:47 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:10:40 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:11:19 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:11:48 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:12:20 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:12:53 EDT ---



--- Additional comment from Edgar Hoch on 2013-06-26 21:20:07 EDT ---

I attach the files from /var/log/anaconda/ because the files in /tmp are lost after (automatic) reboot. anaconda-ks.cfg is from /root/ .

I have used only the Fedora 19 RC2 DVD (iso image, extracted) on a nfs partition.

nfs --server=server2.example.com --dir=/fs/tmp-local/boot_dir/Fedora/19/x86_64

I normally use also the options

repo --name=fedora
repo --name=updates

but anaconda crashed some time after formatting the partitions and before starting installing the packages. I cound not get a dump because the host didn't respond and hanged.

I removed these repo options from the kickstart file for the moment until Fedora 19 is released because the reason for the crash may be (?) that these repos are not available before Fedora 19 is released?

I also use the option

firstboot --disable


I have replaced the hostnames and ip addresses for privacy reasons.

--- Additional comment from Edgar Hoch on 2013-06-26 21:23:03 EDT ---

(In reply to Brian C. Lane from comment #2)
> Please attach the logs from /tmp/*log to this bug as individual text/plain
> attachments. program.log should show systemctl being run.

In the logs no systemctl is run regarding firstboot. From file /bin/initial-setup I found that the following command should have run (but isn't):

/bin/systemctl disable initial-setup-graphical.service initial-setup-text.service

--- Additional comment from Brian Lane on 2013-06-27 15:42:26 EDT ---

I looks like we're expecting  /lib/systemd/system/firstboot-graphical.service to exist, but initial-setup isn't providing that.

--- Additional comment from Terje Røsten on 2013-07-01 13:50:55 EDT ---

To me it seems like firstboot has been replaced by initial-setup package and the services initial-setup-graphical.service and initial-setup-text.service.

So we need a new ks option:

initial-setup --disable

or let 

firstboot --disable

disable those two services as in comment #11:

/bin/systemctl disable initial-setup-graphical.service
/bin/systemctl disable initial-setup-text.service

--- Additional comment from Vratislav Podzimek on 2013-07-30 08:17:47 EDT ---

I think this should be handled correctly. The code tries to enable/disable all firstboot/i-s services [1]

[1] https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/kickstart.py?h=f19-branch#n543

--- Additional comment from Vratislav Podzimek on 2013-07-30 08:30:32 EDT ---

I think this is a systemd issue. We call 'systemctl disable' with 3 services one of which doesn't exist. The result should be the existing services disabled and some error reported, not doing nothing. systemd maintainers, if you think this is okay, reassing this bug back and I will change the code to try to disable the services one after another.

--- Additional comment from Zbigniew Jędrzejewski-Szmek on 2013-07-30 09:41:50 EDT ---

This behaviour was changed post systemd-204 (commit 02b9e969a6f), and 'systemctl disable' will now just remove all symlinks to the specified units, independent of whether the unit file exists or not. This could be backported, or anaconda could be modified to run them one by one. I don't know what's the best option here.

--- Additional comment from Andrew McNabb on 2013-08-21 14:08:24 EDT ---

I've encountered what may be a different manifestation of the same problem. I have a kickstart postinstall script that runs "systemctl disable initial-setup-graphical" (and the logs show that the command does not give any output). After reboot, running "systemctl is-enabled initial-setup-graphical" reports that it's enabled.

Is anaconda enabling the initial-setup-graphical service after the kickstart postinstall script completes? Is this the same as the problem with the kickstart option "firstboot --disable", or are they separate issues?

--- Additional comment from Edgar Hoch on 2013-08-21 16:23:01 EDT ---

(In reply to Andrew McNabb from comment #17)
> Is anaconda enabling the initial-setup-graphical service after the kickstart
> postinstall script completes? Is this the same as the problem with the
> kickstart option "firstboot --disable", or are they separate issues?

I think this is a different problem because in my case "systemctl disable ..." in the %post part works as expected (e.g. the services are disabled). I have also the option "firstboot --disable" in my kickstart file.

Do you have the option "firstboot --disable" in your kickstart file?

I don't know what the default is if the firstboot option is missing. I suppose the default is enabled.

Could you try kickstart with the option "firstboot --disable" (and systemctl disable ... in the %post part)?


I think (without looking at the anaconda code):

If "systemctl disable ..." in the %post part works works as expected if the option "firstboot --disable" in your kickstart file,
and works not as expected if the option "firstboot --disable" in your kickstart file is missing or have another option,
then the order of postprocessing in anaconda may be other as we excpect.
I think that
first the kickstart options (also implicit options, default values) and other (system) postprocessing should be processed (this includes an explicit or implicit firstboot processing),
and last the %post part (declared by the administrator) should be called (processed).
The reason is that the administrator should be able to change what anaconda have done in the kickstart stages before - usualy in the %post part.

In this case the solution for the next release should be to process the %post last (after an explicit or implicit firstboot option),
and to use "firstboot --disable" in the kickstart file for Fedora 19 (as a workaround).

In Fedora 20 and following "firstboot --disable" should disable initial-setup-graphical.service initial-setup-text.service without the need to call systemctl in the %post part.


If "systemctl disable ..." in the %post part works works not as expected if the option "firstboot --disable" is in your kickstart file,
then it is also another problem.

--- Additional comment from Andrew McNabb on 2013-08-21 17:36:19 EDT ---

(In reply to Edgar Hoch from comment #18)
> (In reply to Andrew McNabb from comment #17)
> > Is anaconda enabling the initial-setup-graphical service after the kickstart
> > postinstall script completes? Is this the same as the problem with the
> > kickstart option "firstboot --disable", or are they separate issues?
> 
> I think this is a different problem because in my case "systemctl disable
> ..." in the %post part works as expected (e.g. the services are disabled). I
> have also the option "firstboot --disable" in my kickstart file.
> 
> Do you have the option "firstboot --disable" in your kickstart file?

Yes, I do have it.

> Could you try kickstart with the option "firstboot --disable" (and systemctl
> disable ... in the %post part)?

Yes, that's how I've been running it.

> If "systemctl disable ..." in the %post part works works not as expected if
> the option "firstboot --disable" is in your kickstart file,
> then it is also another problem.

I suppose once "firstboot --disable" works, I'll be perfectly happy.

--- Additional comment from Edgar Hoch on 2014-01-08 11:36:11 EST ---

The problem is solved in Fedora 20.

"firstboot --disable" in kickstart file works as expected.
See the following excerpt from /var/log/anaconda/anaconda.program.log:

03:59:43,860 INFO program: Running... systemctl disable firstboot-graphical.service initial-setup-graphical.service initial-setup-text.service
03:59:43,882 INFO program: rm '/etc/systemd/system/multi-user.target.wants/initial-setup-text.service'
03:59:43,883 INFO program: rm '/etc/systemd/system/graphical.target.wants/initial-setup-graphical.service'
03:59:43,883 DEBUG program: Return code: 0

--- Additional comment from David Shea on 2014-01-08 15:41:56 EST ---

Closing per comment 20

Comment 1 Martin Kolman 2017-01-11 17:15:12 UTC
I think I don't really understand this bug  - cloned from a closed Fedora 19 bug. Do you mean that the same thing - "firstboot --disable" not turning off Initial Setup - is also happening in RHEL 7.3 ?

Comment 2 Tru Huynh 2017-01-11 17:27:02 UTC
right, it used to work for 7.2 but 7.3 broke it (the firstboot gui is not disabled by ks "firstboot --disabled"), afaik.

Comment 5 RHEL Program Management 2021-01-15 07:30:06 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


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