Bug 998083

Summary: gnome-initial-setup runs on live image boot in current Rawhide
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: spin-kickstartsAssignee: Jeroen van Meeuwen <vanmeeuwen+fedora>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: adam.stokes, admiller, bcl, bruno, dhuff, Jasper.Hartline, jstpierr, katzj, kevin, mclasen, robatino, stephent98, systemd-maint, tiagomatos, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-20 16:26:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 980649    

Description Adam Williamson 2013-08-17 07:10:33 UTC
I just built and booted a live image from current Rawhide repositories. On boot, gnome-initial-setup kicks in, including the user creation phase, and logs me in as the created user. This means the 'Welcome to Fedora' window doesn't appear and there is no installer link in the Dash.

Nominating as an Alpha blocker: the Alpha release criteria state "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop.", i.e., they should not boot to a firstboot utility.

Comment 1 Adam Williamson 2013-08-17 07:11:19 UTC
I can see that it might make sense for g-i-s to run on live boot to customize liveuser's environment, but in that case, user creation must be skipped. If you want to do that, we can adjust the release criteria for it.

Comment 2 Steve Tyler 2013-08-17 11:33:39 UTC
Confirmed with a nightly.[1]

The problem appears to be that most of the Live image init script did not run:[2]
/etc/rc.d/init.d/livesys

Most notably, the code to create /home/liveuser/ did not run:
# add fedora user with no passwd
action "Adding live user" useradd \$USERADDARGS -c "Live System User" liveuser
passwd -d liveuser > /dev/null
usermod -aG wheel liveuser > /dev/null

And evidently this did not run:
# don't run gnome-initial-setup
mkdir ~liveuser/.config
touch ~liveuser/.config/gnome-initial-setup-done

[1] $ qemu-kvm -m 4096 -hda f20-test-1.img -cdrom ~/xfr/fedora/nightly-composes/Fedora-20-Nightly-x86_64-Live-desktop-20130816.11-1.iso -vga std -boot menu=on

[2] Written in the kickstart "%post" section:
http://kojipkgs.fedoraproject.org//work/tasks/3176/5823176/fedora-livecd-desktop-168dcbf.ks

Comment 3 Steve Tyler 2013-08-17 11:59:06 UTC
See also:
Bug 991466 - No user created in live image

Comment 4 Steve Tyler 2013-08-17 12:26:28 UTC
(In reply to Steve Tyler from comment #3)
> See also:
> Bug 991466 - No user created in live image

I think this commit did not accomplish what was intended:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/fedora-live-base.ks?id=a47186bb673789cb3ba6bae8af26bf0a86b7dcac

Specifically, these lines got moved outside of the section that writes the livesys init script:
# Mark things as configured
touch /.liveimg-configured

Those will be written as part of the install, which will permanently disable any code in /etc/rc.d/init.d/livesys that follows the test below:

%post
# FIXME: it'd be better to get this installed from a package
cat > /etc/rc.d/init.d/livesys << EOF
#!/bin/bash
...
if [ -n "\$configdone" ]; then
  exit 0
fi

# add fedora user with no passwd
action "Adding live user" useradd \$USERADDARGS -c "Live System User" liveuser
passwd -d liveuser > /dev/null
usermod -aG wheel liveuser > /dev/null
...

Comment 5 Steve Tyler 2013-08-17 12:42:30 UTC
The fedora-live-base.ks kickstart script actually writes two scripts:
/etc/rc.d/init.d/livesys
/etc/rc.d/init.d/livesys-late

And they are both using flag-files:
touch /.liveimg-configured
touch /.liveimg-late-configured

This would all be better done with systemd services ...

CCing: systemd-maint

Comment 6 Steve Tyler 2013-08-17 12:53:00 UTC
CCing Kevin: This looks related to Bug 991466 - No user created in live image.

Comment 7 Adam Williamson 2013-08-17 13:39:53 UTC
Nice catch, Steve, it was too late for me to look into it in much detail last night.

I once wrote a giant patch to turn livesys and livesys-late into systemd-fired scripts and obsolete chunks of them. It was rejected on the grounds it wasn't radical enough (they wanted to turn all of what they do into separate systemd services, not keep the big scripts). I'm not sure I want to go through that pain again.

https://bugzilla.redhat.com/show_bug.cgi?id=739446

Comment 8 Steve Tyler 2013-08-17 15:43:24 UTC
(In reply to Adam Williamson from comment #7)
...
Component: gnome-initial-setup → livecd-tools
Assignee: jstpierr → bcl

spin-kickstarts? (Bug 991466, Comment 2)

Comment 9 Steve Tyler 2013-08-17 16:22:13 UTC
(In reply to Adam Williamson from comment #7)
...
> I once wrote a giant patch to turn livesys and livesys-late into
> systemd-fired scripts and obsolete chunks of them. It was rejected on the
> grounds it wasn't radical enough (they wanted to turn all of what they do
> into separate systemd services, not keep the big scripts). I'm not sure I
> want to go through that pain again.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=739446

That looks like an excellent approach.

I just skimmed spin-kickstarts and found this:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/log/fedora-arm-xfce.ks

Kickstart files are completely unsuited to managing this level of complexity ...

== fedora-arm-xfce.ks ==
%include fedora-arm-base.ks
%include fedora-arm-xbase.ks
%include fedora-xfce-packages.ks
%include fedora-arm-partitioning.ks

%post
echo -n "Enabling initial-setup gui mode on startup"
ln -s /usr/lib/systemd/system/initial-setup-graphical.service /etc/systemd/system/graphical.target.wants/initial-setup-graphical.service
echo .

%end
==

Comment 10 Steve Tyler 2013-08-17 16:46:22 UTC
(In reply to Steve Tyler from comment #9)
...
> I just skimmed spin-kickstarts and found this:
> https://git.fedorahosted.org/cgit/spin-kickstarts.git/log/fedora-arm-xfce.ks
> 
> Kickstart files are completely unsuited to managing this level of complexity
> ...

It gets worse:  :-)

https://git.fedorahosted.org/cgit/spin-kickstarts.git/log/fedora-arm-xfce-vfat.ks

Comment 11 Adam Williamson 2013-08-20 16:26:47 UTC
I went ahead and fixed this and tested the fix. Works fine.

Comment 12 Steve Tyler 2013-08-20 18:21:15 UTC
Thanks, Adam.[1]

That code is very hard to read. A terminating comment might help:
...
%post
# FIXME: it'd be better to get this installed from a package
cat > /etc/rc.d/init.d/livesys << EOF
#!/bin/bash
...
# Mark things as configured
touch /.liveimg-configured

EOF # === end of livesys is here ===

...

==
[1] move the 'livesys is done' block back up so it's at least inside livesys
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=11631d64815c3f0174e37f7a16f8702221099fb5

Comment 13 Steve Tyler 2013-08-20 18:38:41 UTC
(In reply to Steve Tyler from comment #12)
...
> EOF # === end of livesys is here ===
...

Wow is that ever fragile. The here-document delimiter must match exactly:
EOF
# === end of livesys is here ===

Test case that fails:

$ cat x1.sh
#!/bin/bash

cat << EOF
bar1
bar2
bar3
EOF # === end of here-document ===

echo foo

$ ./x1.sh
./x1.sh: line 10: warning: here-document at line 3 delimited by end-of-file (wanted `EOF')
bar1
bar2
bar3
EOF # === end of here-document ===

echo foo

$

Comment 14 Adam Williamson 2013-08-20 18:45:25 UTC
yeah, we're aware of that. If you check some of the kickstarts, there are cases where this kind of structure is nested, and the nested ones use CAT > /blah << FOE ... FOE ("EOF" is just a random label, you can use whatever you like). We are all painfully aware that the whole live image definition / creation process is a fragile ball of duct tape, believe me...