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:
Can you please attach the output of the 'journalctl -u initial-setup-graphical.service' command?
Created attachment 814547 [details] initial setup log
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?
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.
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?
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
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
satellit, thanks for testing, I don't understand why it doesn't work for me, on two different machines!? :(
Created attachment 818693 [details] journalctl output for initial-setup-graphical.service Log from latest install, probably the same as old one?
(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!
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.
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?
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')
sorry about .target, it is .service, I don't know what happened to me :(
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!
Created attachment 823825 [details] anaconda-ks.cfg I already have latest initial-setup installed ( initial-setup-0.3.10-1.fc20.noarch )
Created attachment 823826 [details] boot log
(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.
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?
Oh, I meant 'journalctl -b', sorry about that.
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?
Created attachment 823922 [details] initial_setup traceback
Oh, wonderful, now we finally know what happens. It seems like an anaconda bug to me, because it produces an invalid kickstart file.
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
# 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>
Actually, I believe python-blivet produces those kickstart lines.
Pushed a fix out for this, will do a new pykickstart build eventually.
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
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).
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.