Bug 515419

Summary: firstboot GUI crashes when launched
Product: [Fedora] Fedora Reporter: Joachim Frieben <jfrieben>
Component: firstbootAssignee: Chris Lumens <clumens>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: clumens, dcantrell, fedora, jlaska, lili, smaitra, zcerza
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: 2009-08-11 22:46:25 UTC Type: ---
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: 507676    

Description Joachim Frieben 2009-08-04 07:43:24 UTC
Description of problem:
After a fresh install from the "rawhide" tree, application "firstboot" does not get launched successfully. Instead, the boot log issues an error message indicating that no display could be opened:

  Traceback (most recent call last):
    File "/usr/sbin/firstboot", line 121, in <module>
      meh.makeRHHandler("firstboot", "@VERSION@", config)
    File "/usr/lib/python2.6/site-packages/meh/__init__.py", line 95, in makeRHHandler
      from meh.ui.gui import GraphicalIntf
    File "/usr/lib/python2.6/site-packages/meh/ui/gui.py", line 21, in <module>
      import gtk
    File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
      _init()
    File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
      _gtk.init_check()
  RuntimeError: could not open display

Version-Release number of selected component (if applicable):
firstboot-1.107-1.fc12.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Reboot system.
  
Actual results:
Service "firstboot" reports that it isn't able to open a display.

Expected results:
Service "firstboot" gets run successfully at least once in order to provide basic configuration information.

Additional info:
This used to work for the current release F11.

Comment 1 Zack Cerza 2009-08-07 17:55:20 UTC
Seeing this here inside a KVM install. At first I thought it was because X was crashing on startup, but new packages fix that and I'm still seeing the problem.

Comment 2 Zack Cerza 2009-08-07 17:57:27 UTC
I decided to try and run firstboot from runlevel 3, but I'm getting exactly the same traceback. Was text-mode support removed? I see a way to force graphical mode, but not text mode...

Comment 3 Zack Cerza 2009-08-07 18:04:19 UTC
Okay... seems like part (or all) of the problem is that /usr/sbin/firstboot calls meh.makeRHHandler before it's tried to figure out if it can even use graphical mode. That method imports a method from the meh.ui.gui module, which immediately imports gtk, which of course fails with no usable X display. Since gtk's RuntimeError isn't caught... firstboot dies.

Comment 4 Zack Cerza 2009-08-07 18:17:33 UTC
Luckily for me, once I looked at what makeRHHandler actually does - ironically, sets up an exception handler presumably to allow the user to file bugs in case firstboot crashes - I tried simply commenting out that line, and was able to use firstboot.

Comment 5 Sebastian Vahl 2009-08-10 08:14:13 UTC
I'm seeing this after an installation from a live image as well. Shouldn't this be a blocker for F12Alpha then?

Comment 6 Chris Lumens 2009-08-10 21:39:18 UTC
Yeah I'm aware of this problem and I have a potential fix for it.  However, first I need a tree that installs, and that hasn't been very easy to come by lately.  I don't see this going in for the alpha, but I should have it fixed very shortly after.

Comment 7 Sebastian Vahl 2009-08-11 07:28:42 UTC
The KDE live images are ready for installation and I think the Gnome ones are ready, too (at least my test build from saturday boots, I haven't tried the installation).
But if this isn't going into the alpha, the release notes should clearly state that adding users is broken atm (and so nobody could login after installation) and provide a workaround for that.

Comment 8 Joachim Frieben 2009-08-11 10:54:36 UTC
(In reply to comment #7)
As a workaround, I have booted into into runlevel 3, logged in as "root" and executed 'startx'. Then 'system-config-users' is available in the system menu, and a user can be added doing all necessary modifications.

Comment 9 Chris Lumens 2009-08-11 14:34:37 UTC
*** Bug 516730 has been marked as a duplicate of this bug. ***

Comment 10 Zack Cerza 2009-08-11 14:55:27 UTC
(In reply to comment #6)
> Yeah I'm aware of this problem and I have a potential fix for it.  However,
> first I need a tree that installs, and that hasn't been very easy to come by
> lately.  I don't see this going in for the alpha, but I should have it fixed
> very shortly after.  

Would it be out of the question to just push a build with the meh.makeRHHandler call either commented out, or wrapped in a try... except block, so that Alpha users don't have to do what's described in comment #8?

Comment 11 Chris Lumens 2009-08-11 18:03:43 UTC
This should be fixed in the next build of firstboot, which I'm going to do right now...

Comment 12 James Laska 2009-08-11 19:37:30 UTC
VERIFIED this fix using firstboot-1.108-1.fc12

Will move to CLOSED RAWHIDE once this build is tagged and included in rawhide/F-12-Alpha

Comment 13 Jesse Keating 2009-08-11 22:46:25 UTC
It has been tagged.

Comment 14 James Laska 2009-08-13 11:45:25 UTC
*** Bug 515466 has been marked as a duplicate of this bug. ***

Comment 15 Satyabrata Maitra 2009-08-14 05:04:21 UTC
Hi James

This is nice. Can you inform me which installation tree contains this fix version of firstboot please? The latest rawhide one? I will also try that one!

Comment 16 Jesse Keating 2009-08-14 05:33:37 UTC
Yes, this should be fixed in the rawhide from 20090813