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.
I confirm this error with Fedora 19 RC2 .
Please attach the logs from /tmp/*log to this bug as individual text/plain attachments. program.log should show systemctl being run.
Created attachment 765862 [details] anaconda.ifcfg.log
Created attachment 765863 [details] anaconda.log
Created attachment 765864 [details] anaconda.packaging.log
Created attachment 765865 [details] anaconda.program.log
Created attachment 765866 [details] anaconda.storage.log
Created attachment 765867 [details] anaconda.xlog
Created attachment 765868 [details] syslog
Created attachment 765869 [details] anaconda-ks.cfg - the generated kickstart file from the installation 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.
(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
I looks like we're expecting /lib/systemd/system/firstboot-graphical.service to exist, but initial-setup isn't providing that.
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
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
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.
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.
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?
(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.
(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.
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
Closing per comment 20