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>
File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
File "/usr/lib64/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
RuntimeError: could not open display
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Reboot system.
Service "firstboot" reports that it isn't able to open a display.
Service "firstboot" gets run successfully at least once in order to provide basic configuration information.
This used to work for the current release F11.
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.
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...
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.
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.
I'm seeing this after an installation from a live image as well. Shouldn't this be a blocker for F12Alpha then?
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.
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.
(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.
*** Bug 516730 has been marked as a duplicate of this bug. ***
(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?
This should be fixed in the next build of firstboot, which I'm going to do right now...
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
It has been tagged.
*** Bug 515466 has been marked as a duplicate of this bug. ***
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!
Yes, this should be fixed in the rawhide from 20090813