Created attachment 1015957 [details] Screenshot of initial setup gui scren Description of problem: initial-setup is started even if kickstart file contains a line firstboot --disable According to Fedora 21 Installation Guide section A.7.1 https://docs.fedoraproject.org/en-US/Fedora/21/html/Installation_Guide/sect-kickstart-commands-after.html#sect-kickstart-commands-firstboot initial setup should not start when the kickstart file contains the option as listed above. Also note that the default of this option is disabled, as declared on the same page of the installation guide: "If not specified, this option is disabled by default." I looked about the files of the package and found that in /usr/lib/python2.7/site-packages/initial_setup/__main__.py the file /root/anaconda-ks.cfg is parsed. But I found nothing that checks for the existence of the "firstboot" option. Version-Release number of selected component (if applicable): initial-setup-0.3.25-1.fc21.x86_64 initial-setup-gui-0.3.25-1.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. Install Fedora 21 non-product with a kickstart file that contains at least the lines firstboot --disable xconfig --defaultdesktop=GNOME --startxonboot and other options that would be asked by initial-setup, but does not create a non-root user auth --useshadow --passalgo=sha512 rootpw ... network ... and installs packages initial-setup and initial-setup-gui. 2. Check the graphical console after kickstart installation has finished. Actual results: initial-setup is running. root 875 1 0 00:15 ? 00:00:00 /bin/xinit /bin/firstboot-windowmanager /bin/initial-setup -- /bin/Xorg :9 -ac -nolisten tcp root 1138 875 0 00:15 ? 00:00:00 /bin/sh /bin/firstboot-windowmanager /bin/initial-setup root 1155 1138 0 00:15 ? 00:00:00 /bin/sh /bin/initial-setup root 1160 1155 0 00:15 ? 00:00:13 python -m initial_setup # systemctl status initial-setup-graphical.service ● initial-setup-graphical.service - Initial Setup configuration program Loaded: loaded (/usr/lib/systemd/system/initial-setup-graphical.service; enabled) Active: activating (start) since So 2015-04-19 00:15:10 CEST; 1h 59min ago Process: 718 ExecStartPre=/bin/plymouth quit (code=exited, status=0/SUCCESS) Main PID: 875 (xinit) CGroup: /system.slice/initial-setup-graphical.service ├─ 875 /bin/xinit /bin/firstboot-windowmanager /bin/initial-setup -- /bin/Xorg :9 -ac -nolisten tcp ├─ 881 /usr/libexec/Xorg.bin :9 -ac -nolisten tcp ├─1138 /bin/sh /bin/firstboot-windowmanager /bin/initial-setup ├─1151 /usr/bin/xfwm4 ├─1155 /bin/sh /bin/initial-setup ├─1160 python -m initial_setup ├─1222 /bin/dbus-launch --autolaunch c82bbcaee24c3e457894dcf3f5167366 --binary-syntax --close-stderr ├─1239 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session ├─1243 /usr/lib64/xfce4/xfconf/xfconfd ├─1361 /usr/libexec/at-spi-bus-launcher ├─1365 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 └─1369 /usr/libexec/at-spi2-registryd --use-gnome-session Apr 19 00:15:15 myhost.example.com org.a11y.Bus[1239]: Activating service name='org.a11y.atspi.Registry' Apr 19 00:15:15 myhost.example.com org.a11y.Bus[1239]: Successfully activated service 'org.a11y.atspi.Registry' Apr 19 00:15:15 myhost.example.com org.a11y.atspi.Registry[1365]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Apr 19 00:15:15 myhost.example.com org.a11y.atspi.Registry[1365]: Xlib: extension "XEVIE" missing on display ":9". Apr 19 00:15:15 myhost.example.com initial-setup[1160]: initializing GUI Apr 19 00:15:15 myhost.example.com initial-setup[1160]: setting up the UI Apr 19 00:15:15 myhost.example.com initial-setup[1160]: starting the UI Apr 19 00:15:15 myhost.example.com anaconda[1160]: Entered hub: InitialSetupMainHub Expected results: Initial setup was not started.
'firstboot --disable' should be handled by anaconda so this may need to be reassigned.
(In reply to Vratislav Podzimek from comment #1) > 'firstboot --disable' should be handled by anaconda so this may need to be > reassigned. When initial-setup starts, it parses the file /root/anaconda-ks.cfg . This is independent of anaconda, because /root/anaconda-ks.cfg was already created and (for example) initial-setup-gui may be installed later, after anaconda has finished. In my case I added the package group xfce, with installed initial-setup-gui. At this time (package installed on an already running system) anaconda can do nothing at all. initial-setup should be aware if it should really ask the user or not (because it was prohibited by kickstart option, or it has already asked).
(In reply to Edgar Hoch from comment #2) > (In reply to Vratislav Podzimek from comment #1) > > 'firstboot --disable' should be handled by anaconda so this may need to be > > reassigned. > > When initial-setup starts, it parses the file /root/anaconda-ks.cfg . > This is independent of anaconda, because /root/anaconda-ks.cfg was already > created and (for example) initial-setup-gui may be installed later, after > anaconda has finished. In my case I added the package group xfce, with > installed initial-setup-gui. > > At this time (package installed on an already running system) anaconda can > do nothing at all. initial-setup should be aware if it should really ask the > user or not (because it was prohibited by kickstart option, or it has > already asked). This is caused by the Initial Setup systemd unit being marked as enabled in the systemd service preset file. So even if initial-setup is not installed during the installation, it will be enabled once it is installed at some later time (even if it is dragged in by a package group. This is being tracked as RHEL bug 1183042, but it will of course be also implemented in Fedora. But I guess we should probably also check the if the kickstart file contains firstboot --disable and quit Initial Setup if it does, with an appropriate message sent to Journal.
So the problematic service preset has been removed and I have just confirmed that the initial-setup services are indeed disabled by Anaconda if firstboot --disable is present in kickstart. So I think we can close this bug as fixed.