Bug 1213114 - initial-setup ignores "firstboot --disable" in kickstart
Summary: initial-setup ignores "firstboot --disable" in kickstart
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: initial-setup
Version: 21
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Martin Kolman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-19 00:19 UTC by Edgar Hoch
Modified: 2017-01-04 19:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-09 14:17:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Screenshot of initial setup gui scren (75.18 KB, image/png)
2015-04-19 00:19 UTC, Edgar Hoch
no flags Details

Description Edgar Hoch 2015-04-19 00:19:57 UTC
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.

Comment 1 Vratislav Podzimek 2015-04-20 08:58:05 UTC
'firstboot --disable' should be handled by anaconda so this may need to be reassigned.

Comment 2 Edgar Hoch 2015-04-20 09:13:24 UTC
(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).

Comment 3 Martin Kolman 2015-04-20 09:36:56 UTC
(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.

Comment 4 Martin Kolman 2015-10-09 14:17:40 UTC
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.


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