Bug 1021274 - initial setup doesn't start on first boot after install
initial setup doesn't start on first boot after install
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: pykickstart (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-20 17:56 EDT by Branko Grubić
Modified: 2013-11-29 08:55 EST (History)
8 users (show)

See Also:
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 08:55:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
initial setup log (41.34 KB, text/plain)
2013-10-21 07:19 EDT, Branko Grubić
no flags Details
journalctl output for initial-setup-graphical.service (28.63 KB, text/plain)
2013-11-03 01:50 EST, Branko Grubić
no flags Details
initial-setup log (89.44 KB, text/plain)
2013-11-13 10:05 EST, Branko Grubić
no flags Details
anaconda-ks.cfg (1.23 KB, text/plain)
2013-11-14 04:19 EST, Branko Grubić
no flags Details
boot log (182.76 KB, text/plain)
2013-11-14 04:24 EST, Branko Grubić
no flags Details
new_boot_log (350.74 KB, text/plain)
2013-11-14 06:37 EST, Branko Grubić
no flags Details
initial_setup traceback (2.03 KB, text/plain)
2013-11-14 07:32 EST, Branko Grubić
no flags Details

  None (edit)
Description Branko Grubić 2013-10-20 17:56:11 EDT
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 07:07:21 EDT
Can you please attach the output of the 'journalctl -u initial-setup-graphical.service' command?
Comment 2 Branko Grubić 2013-10-21 07:19:35 EDT
Created attachment 814547 [details]
initial setup log
Comment 3 Vratislav Podzimek 2013-10-22 04:59:41 EDT
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 14:54:57 EDT
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 19:00:17 EDT
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-02 20:10:15 EDT
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-02 22:09:28 EDT
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 01:28:24 EST
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 01:50:41 EST
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 02:32:39 EST
(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 12:18:38 EST
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 08:39:55 EST
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 10:05:51 EST
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 10:09:23 EST
sorry about .target, it is .service, I don't know what happened to me :(
Comment 15 Vratislav Podzimek 2013-11-14 02:22:35 EST
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 04:19:11 EST
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 04:24:42 EST
Created attachment 823826 [details]
boot log
Comment 18 Vratislav Podzimek 2013-11-14 05:21:27 EST
(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 06:37:02 EST
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 07:12:20 EST
Oh, I meant 'journalctl -b', sorry about that.
Comment 21 Vratislav Podzimek 2013-11-14 07:16:58 EST
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 07:32:17 EST
Created attachment 823922 [details]
initial_setup traceback
Comment 23 Vratislav Podzimek 2013-11-14 09:28:18 EST
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 09:28:45 EST
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 09:30:06 EST
# 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 09:37:48 EST
Actually, I believe python-blivet produces those kickstart lines.
Comment 27 Chris Lumens 2013-11-22 14:29:12 EST
Pushed a fix out for this, will do a new pykickstart build eventually.
Comment 28 Fedora Update System 2013-11-25 22:55:54 EST
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 12:57:01 EST
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 08:55:48 EST
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.

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