Bug 1021274

Summary: initial setup doesn't start on first boot after install
Product: [Fedora] Fedora Reporter: Branko Grubić <bitlord0xff>
Component: pykickstartAssignee: Chris Lumens <clumens>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: amulhern, anaconda-maint-list, bcl, bitlord0xff, dlehman, kevin, satellitgo, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-blivet-0.23.7-1.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-29 13:55:48 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:
Attachments:
Description Flags
initial setup log
none
journalctl output for initial-setup-graphical.service
none
initial-setup log
none
anaconda-ks.cfg
none
boot log
none
new_boot_log
none
initial_setup traceback none

Description Branko Grubić 2013-10-20 21:56:11 UTC
Description of problem:
I tested Fedora KDE Live image (BETA TC5 (and older)), If I skip user account setup in anaconda, and just set root account, after install system boot up to login screen, where user cannot log in. I need manually to switch to tty, and create a new user account. Initial setup doesn't run.

Version-Release number of selected component (if applicable):
Don't know which version is used on TC5

How reproducible:
Always

Steps to Reproduce:
1. Run liveinstall
2. don't set user account (I tested with root account enabled/configured, no user, maybe no_root and no_user is not possible?) 
3. restart into new system

Actual results:
Initial setup doesn't run on new live installs if no user account is created in installer

Expected results:
Initial setup runs on new installs when no user account is created in installer

Additional info:

Comment 1 Vratislav Podzimek 2013-10-21 11:07:21 UTC
Can you please attach the output of the 'journalctl -u initial-setup-graphical.service' command?

Comment 2 Branko Grubić 2013-10-21 11:19:35 UTC
Created attachment 814547 [details]
initial setup log

Comment 3 Vratislav Podzimek 2013-10-22 08:59:41 UTC
There is no error in the log. And I've just tested the installation from the F20 Beta TC5 live image and the initial-setup utility ran successfully on the first boot letting me create a user account. Can you please retest this once more?

Comment 4 Branko Grubić 2013-10-22 18:54:57 UTC
You tested BETA TC5 KDE? (maybe this is KDE live specific?), I'm now not 100% sure, but I think I tested TC5, and initial-setup didn't show up after first boot, but sddm and empty login screen. 
I cannot test it now, but tomorrow maybe.

Comment 5 Branko Grubić 2013-11-02 23:00:17 UTC
I tested F20 Beta-RC2, initial-setup doesn't start if regular user account is not created in anaconda, last time you said it works ( comment #3 ), did you tested KDE live image or not?

Comment 6 satellitgo 2013-11-03 00:10:15 UTC
f20-Beta-2 x86_64 DVD dd USB install to usb Hard Disk:
Anaconda 20.25.5-1

Use Case to test:
Root Password set but no user:

On Reboot after install: 
===========================
USER CREATION
"No user will be created" 
===========================

Click on it to get User creation Spoke:

 Full Name____
 User Name____
 [ ] Make this user administrator
 [x] Require a password to use this account

         Password________
 Confirm Password________
                [Advanced]

[Back]
 2 times
=======================
USER SETTINGS
User Creation
 * Administrator ****will be created

                                   [Finish Configuration]
=======================
Logs in to KDM? with USER and blank password box

enter password in box and KDE starts

Comment 7 satellitgo 2013-11-03 02:09:28 UTC
f20-beta-2 Live KDE x86_64 burned to DVD
Booted live DVD install to Hard Disk

Connected to wireless AP

Use Case to test:
Root Password set but no user:

Exactly the same behavior as seen in Comment 6

Comment 8 Branko Grubić 2013-11-03 06:28:24 UTC
satellit, thanks for testing, I don't understand why it doesn't work for me, on two different machines!? :(

Comment 9 Branko Grubić 2013-11-03 06:50:41 UTC
Created attachment 818693 [details]
journalctl output for initial-setup-graphical.service

Log from latest install, probably the same as old one?

Comment 10 Vratislav Podzimek 2013-11-04 07:32:39 UTC
(In reply to (bitlord) from comment #9)
> Created attachment 818693 [details]
> journalctl output for initial-setup-graphical.service
> 
> Log from latest install, probably the same as old one?
Nothing that bugs me in that log.

Could you please try running 'initial-setup' from a shell as root when logged in the KDE session of the newly installed system? If you hit Quit instead of Finish Configuration it won't do any changes to the system. That should tell us if it runs, skips itself or what. Thanks!

Comment 11 Branko Grubić 2013-11-12 17:18:38 UTC
Now I tested Beta-RC5 xfce live, same problem, initial-setup doesn't start. I tried starting it from a tty also from X (as root), doesn't show up. (I have user created already, (with useradd))

In anaconda, as before I just configured 'root' account, no user account.

Comment 12 Vratislav Podzimek 2013-11-13 13:39:55 UTC
What was the output and return code when you tried to run Initial Setup on a tty and X server?

Could you please attach 'journalctl -u initial-setup-graphical.service' from that machine?

Comment 13 Branko Grubić 2013-11-13 15:05:51 UTC
Created attachment 823476 [details]
initial-setup log

There is no output when I try to run it, it always return 0. (using "echo $?") 
And when I try to run it (with or without X running) from a tty, it starts new X session I think, shows mouse cursor and a black screen, and after few seconds it dissapers. (I think this also happens on every boot?) (systemctl is-enabled initial-setup-graphical.target, says 'enabled')

Comment 14 Branko Grubić 2013-11-13 15:09:23 UTC
sorry about .target, it is .service, I don't know what happened to me :(

Comment 15 Vratislav Podzimek 2013-11-14 07:22:35 UTC
Sorry for bothering you again, but I cannot reproduce the issues you describe so I'd need a bit more information from you.

Could you please try to run:
'sudo yum update initial-setup --enablerepo=updates-testing'

and then reboot? That should install a new version if the initial-setup which has better logging. The please attach the output of 'journalctl -b1' (all logs from the last boot).

Also, could you please attach the /root/anaconda-ks.cfg file from that system?

Thanks!

Comment 16 Branko Grubić 2013-11-14 09:19:11 UTC
Created attachment 823825 [details]
anaconda-ks.cfg

I already have latest initial-setup installed ( initial-setup-0.3.10-1.fc20.noarch )

Comment 17 Branko Grubić 2013-11-14 09:24:42 UTC
Created attachment 823826 [details]
boot log

Comment 18 Vratislav Podzimek 2013-11-14 10:21:27 UTC
(In reply to (bitlord) from comment #17)
> Created attachment 823826 [details]
> boot log
Are you really sure this boot log is with the latest initial-setup installed? It is from 'Nov 12' and I cannot see the debugging messages in it.

Comment 19 Branko Grubić 2013-11-14 11:37:02 UTC
Created attachment 823894 [details]
new_boot_log

initial-setup is upgraded after install (from yum history, transaction ID 2,  2013-11-12 17:39 | I, U           |  227 EE )
   Updated     initial-setup-0.3.7-1.fc20.noarch                           @koji-override-0/$releasever
    Update                    0.3.10-1.fc20.noarch                          @updates-testing


I booted the machine today and rebooted again, and then did 'journalctl -b1' then saved that to a file. 

...
Oh, I see,  -b1  will get first log file, so that is the problem I think? 


from man journactl  (searching for '-b')
"If the boot ID is omitted, a positive offset will look up the boots starting from the beginning of the journal,
           and a equal-or-less-than zero offset will look up boots starting from the end of the journal. Thus, 1 means the
           first boot found in the journal in the chronological order, 2 the second and so on;"  

new log file with 'journalctl --since=today'  maybe that helps?

Comment 20 Vratislav Podzimek 2013-11-14 12:12:20 UTC
Oh, I meant 'journalctl -b', sorry about that.

Comment 21 Vratislav Podzimek 2013-11-14 12:16:58 UTC
Could you please try replacing the /usr/lib/python2.7/site-packages/initial_setup/__main__.py file with the following one: http://paste.fedoraproject.org/54003/31340138 and try running it from a terminal or console?

Comment 22 Branko Grubić 2013-11-14 12:32:17 UTC
Created attachment 823922 [details]
initial_setup traceback

Comment 23 Vratislav Podzimek 2013-11-14 14:28:18 UTC
Oh, wonderful, now we finally know what happens. It seems like an anaconda bug to me, because it produces an invalid kickstart file.

Comment 24 Vratislav Podzimek 2013-11-14 14:28:45 UTC
Traceback (most recent call last):
  File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.7/site-packages/initial_setup/__main__.py", line 71, in <module>
    parser.readKickstart("/root/anaconda-ks.cfg")
  File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 717, in readKickstart
    self.readKickstartFromString(s, reset=False)
  File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 690, in readKickstartFromString
    self._stateMachine (i)
  File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 673, in _stateMachine
    self._tryFunc(lambda: self.handleCommand(lineno, args))
  File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 593, in _tryFunc
    fn()
  File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 673, in <lambda>
    self._tryFunc(lambda: self.handleCommand(lineno, args))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/kickstart.py", line 1631, in handleCommand
    return KickstartParser.handleCommand(self, lineno, args)
  File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 483, in handleCommand
    retval = self.handler.dispatcher(args, lineno)
  File "/usr/lib/python2.7/site-packages/pykickstart/base.py", line 433, in dispatcher
    obj = self.commands[cmd].parse(args[1:])
  File "/usr/lib/python2.7/site-packages/pykickstart/commands/volgroup.py", line 182, in parse
    retval = FC16_VolGroup.parse(self, args)
  File "/usr/lib/python2.7/site-packages/pykickstart/commands/volgroup.py", line 127, in parse
    raise KickstartValueError(formatErrorMsg(self.lineno, msg=_("Members may not be specified for preexisting volgroup")))
pykickstart.errors.KickstartValueError: The following problem occurred on line 33 of the kickstart file:

Members may not be specified for preexisting volgroup

Comment 25 Vratislav Podzimek 2013-11-14 14:30:06 UTC
# Partition clearing information
clearpart --none --initlabel 
# Disk partitioning information
part luks --fstype="luks" --noformat --onpart=sda2
part /boot --fstype="ext4" --onpart=sda1
volgroup <my_vg> --noformat --pesize=32768 --useexisting pv.19
logvol /  --fstype="ext4" --useexisting --name=root --vgname=<my_vg>
logvol swap  --fstype="swap" --useexisting --name=swap --vgname=<my_vg>
logvol /home  --fstype="ext4" --noformat --useexisting --name=home --vgname=<my_vg>

Comment 26 Vratislav Podzimek 2013-11-14 14:37:48 UTC
Actually, I believe python-blivet produces those kickstart lines.

Comment 27 Chris Lumens 2013-11-22 19:29:12 UTC
Pushed a fix out for this, will do a new pykickstart build eventually.

Comment 28 Fedora Update System 2013-11-26 03:55:54 UTC
python-blivet-0.23.6-1.fc20, anaconda-20.25.11-1.fc20, pykickstart-1.99.48-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2013-21928/pykickstart-1.99.48-1.fc20,python-blivet-0.23.6-1.fc20,anaconda-20.25.11-1.fc20

Comment 29 Fedora Update System 2013-11-26 17:57:01 UTC
Package python-blivet-0.23.6-1.fc20, anaconda-20.25.11-1.fc20, pykickstart-1.99.48-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-blivet-0.23.6-1.fc20 anaconda-20.25.11-1.fc20 pykickstart-1.99.48-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21928/pykickstart-1.99.48-1.fc20,python-blivet-0.23.6-1.fc20,anaconda-20.25.11-1.fc20
then log in and leave karma (feedback).

Comment 30 Fedora Update System 2013-11-29 13:55:48 UTC
python-blivet-0.23.7-1.fc20, anaconda-20.25.12-1.fc20, pykickstart-1.99.48-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.