Description of problem: Firstboot doesn't start after a fresh manual install of rawhide. It appears to be failing inside the XFrontEnd().start() method, but I'm not sure how to further debug around those signal methods. Version-Release number of selected component (if applicable): firstboot-1.110-1.fc13.x86_64 How reproducible: Steps to Reproduce: 1. Perform a manual install of rawhide (http://serverbeach1.fedoraproject.org/pub/alt/stage/rawhide-testing/) 2. Perform an installation, accepting all defaults and using updates=http://jlaska.fedorapeople.org/updates/613623.img 3. Reboot into installed system Actual results: Firstboot never starts ... the user is taken directly to the GDM login Expected results: Firstboot configuration Additional info: * Firstboot appears to be configured to start at runlevel 3 and 5 # chkconfig --list firstboot firstboot 0:off 1:off 2:off 3:on 4:off 5:on 6:off * There is no /etc/sysconfig/firstboot file that disables firstboot # cat /etc/sysconfig/firstboot cat: /etc/sysconfig/firstboot: No such file or directory * It emits the following traceback when attempting to start firstboot manually # /etc/init.d/firstboot start firstboot ERROR: X server failed to start Traceback (most recent call last): File "/usr/sbin/firstboot", line 167, in <module> config.frontend.start() File "/usr/lib64/python2.6/site-packages/firstboot/xfrontend.py", line 87, in start raise RuntimeError, "X server failed to start" RuntimeError: X server failed to start [FAILED]
Firstboot is not run because python-meh was changed, and the actual version of firstboot is not updated to these changes. I have a new version with the needed patch, but seems like I can't do the fedora builds. I need to get the permissions first, then I will make the new build, and it should work. I tried it with the new version, and it worked OK.
I couldn't reproduce the X server failed to start problem, so I guess that was some temporary problem.
Martin - apply for the firstboot group in pkgdb and I'll approve you for it.
Discussed at 2010/07/16 blocker meeting. We accept this as a blocker under the criterion "In most cases, the installed system must boot to a functional graphical environment (see Blocker_Bug_FAQ)": user account creation is done in firstboot, so if firstboot is skipped, you have no user accounts, and hence no way to log into a 'functional graphical environment' when you hit gdm (which won't let you log in as root). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Confirmed this is fixed using firstboot-1.111-1.fc14