Bug 176782 - firstboot fails to start when RHGB is not installed
firstboot fails to start when RHGB is not installed
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-02 11:31 EST by G.Wolfe Woodbury
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-05 13:02:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Firstboot crash log (301 bytes, text/plain)
2006-01-03 16:42 EST, G.Wolfe Woodbury
no flags Details

  None (edit)
Description G.Wolfe Woodbury 2006-01-02 11:31:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
Firstboot fails to run automatically or manually when RHGB is not installed.  The autorun fails with a failure to connect to :1 error.  Attempting to run from a root login after X starts results in a "Could not start any firstboot interface" RuntimeError.

Version-Release number of selected component (if applicable):
firstboot-1.3.55-1.1.noarch.rpm

How reproducible:
Always

Steps to Reproduce:
1. install rawhide of 2006-01-01 deselecting RHGB in the base options
2. watch firstboot fail on firstboot
3. login as root user (init runlevel 5)
4. open terminal and type firstboot
5. watch it fail again
  

Actual Results:  During the autorun phase, X actually starts and and goes to an arror mouse pointer but the firstboot process reports that it could not attach to screen :1, claiming that the X session failed or was killed.

letting the system go ahead, then logging in as "root" to xdm and opening a terminal window, typing "firstboot" fails with:

  File "/usr/sbin/firstboot", line 93, in ?
    raise RuntimeError, "Could not start any firstboot interface"

Expected Results:  firstboot should run normally

Additional info:

this is an older problem that is rearing its ugly head again. Reported first in FC3, it went away for most of FC4, and is now back in hte FC5/rawhide series.

If RHGB is enabled, then firstboot does fine, since it can find the screen from RHGB and connect.  Otherwise, it cannot properly find the screen.
Comment 1 Chris Lumens 2006-01-03 13:07:52 EST
After it tries to run automatically the first time and fails, does it leave a
/tmp/firstboot-crash.log file?  Could you attach it if it exists?

This problem is coming back up because I reorganized some code and removed a
bunch of duplicated stuff in favor of using rhpxl.
Comment 2 G.Wolfe Woodbury 2006-01-03 16:40:39 EST
Darndest thing, I re-installed 2006-01-02 rawhide, leaving out RHGB, and this
time it worked (sort of)  It did make a crash log (attached)
Comment 3 G.Wolfe Woodbury 2006-01-03 16:42:20 EST
Created attachment 122727 [details]
Firstboot crash log
Comment 4 Chris Lumens 2006-01-04 11:35:06 EST
Do you have pygtk and all the gtk packages installed?  It looks to me like you
should only be running into that exception if there's a problem reading from a
pipe or if you hit the timeout.  What sort of hardware do you have?
Comment 5 G.Wolfe Woodbury 2006-01-04 23:35:54 EST
Default rawhide install except for unchecking RHGB in BASE|X WINDOWS option list.

Hardware: Celeron (Coppermine)@500MHz 256Mo RAW  VIA Chipset  Trident
Cyberblade/i1 GPU, DVD-ROM, CDRW, etc.

Will be doing another test install late tonight
Comment 6 G.Wolfe Woodbury 2006-01-05 09:39:53 EST
test install of rawhide 2006-01-04 still fails with all the same symptoms and
the same crash.log.

The only difference I can think of between this run and the one that succeeded
is that I moved the mouse pointer as soon as X came up in the successful try.

Trying again and moving the mouse still failed.

It does take a long time for the Trident CYberblade to start X.  Do you want me
to attach the X log? (Xorg.0.log.old)
Comment 7 Chris Lumens 2006-01-05 11:17:14 EST
Yes, having that log file might be helpful.  If you're feeling a little crazy,
you can try modifying /usr/share/firstboot/firstboot.py line 130 and see if
changing the 10 to a higher number of seconds does anything for you.  That's
just an arbitrary amount of time to wait for X to start up.  If it takes longer
for your hardware, we need to increase that timeout.
Comment 8 G.Wolfe Woodbury 2006-01-05 12:36:14 EST
That did it.  I set it to 15 and it came up correctly.
Date and Time failed for other reasons, but everything else worked fine.
Comment 9 Chris Lumens 2006-01-05 13:02:28 EST
Well, this will be an exciting bug to have to deal with from time to time as we
run across hardware that needs longer.  Fixed in Rawhide.

The Date and Time import problem should be fixed now, though.  Refer to bug 175999.

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