Bug 515419 - firstboot GUI crashes when launched
firstboot GUI crashes when launched
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
: 515466 516730 (view as bug list)
Depends On:
Blocks: F12Alpha/F12AlphaBlocker
  Show dependency treegraph
 
Reported: 2009-08-04 03:43 EDT by Joachim Frieben
Modified: 2013-01-10 00:19 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-11 18:46:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joachim Frieben 2009-08-04 03:43:24 EDT
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 13:55:20 EDT
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 13:57:27 EDT
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 14:04:19 EDT
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 14:17:33 EDT
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 04:14:13 EDT
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 17:39:18 EDT
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 03:28:42 EDT
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 06:54:36 EDT
(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 10:34:37 EDT
*** Bug 516730 has been marked as a duplicate of this bug. ***
Comment 10 Zack Cerza 2009-08-11 10:55:27 EDT
(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 14:03:43 EDT
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 15:37:30 EDT
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 18:46:25 EDT
It has been tagged.
Comment 14 James Laska 2009-08-13 07:45:25 EDT
*** Bug 515466 has been marked as a duplicate of this bug. ***
Comment 15 Satyabrata Maitra 2009-08-14 01:04:21 EDT
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 01:33:37 EDT
Yes, this should be fixed in the rawhide from 20090813

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