From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
On boot, X appears to start and gives blue screen (bluecurve default)
but fedora fails to load. Problem started occuring after recent
up2date. Killing X from command line and manually starting it (startx)
allows GUI to load as expected. May be duplicate of Bug 123356, but
I'm not sure.
The blue background is as expected and usually loads just prior to the
Fedora splash screen.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot fedora
Actual Results: X GUI appears to start but splash screen then login
screen do not appear as expected. I left it overnight to see if it was
just slow, but still "hung" hours later".
Expected Results: GUI loads as normal
Please let me know what information is needed to diagnose and fix this
Created attachment 101339 [details]
Created attachment 101340 [details]
Created attachment 101341 [details]
Created attachment 101342 [details]
Created attachment 101526 [details]
Appears to be a GDM issue. Running KDM from command line brings a
login screen, as does XDM.
I reported this bug almost a month ago and have yet to receive even an
initial response- it's quite frustrating. I've found a couple other
sites reporting the same problem, but no one has a solution yet.
You don't seem to be using the latest official Fedora Core 2 kernel
update or xorg release. Are you using builds from rawhide? If
so, this should be reassigned as a "Fedora devel" bug, as it isn't just
a stock FC2 system. All sorts of instabilities could result from
using devel packages on a stable OS. If you need stability in the
mean time, I strongly recommend using stock Fedora Core 2 with
all updates applied and not using any Fedora devel/rawhide packages
as Fedora development packages can break at any time and remain
broken for quite some time until they're fixed.
I don't notice any X server related problems in the log files you've
provided, but that isn't conclusive.
Are you sure you're attaching the logs from a failed session, and
not the logs from the new session that is running when you aquire
the log file to attach to the bug report? It is important if
there's an X server failure to get the log file from the X server
invocation that's failing. You need to copy the file prior to
starting the X server up again, otherwise the new invocation
will overwrite the old log file, and the log will appear as if
nothing is wrong (which the attached log file shows).
Please also attach your complete /var/log/messages file from boot
time onward to the problem timeframe and slightly beyond, as this
could also be a kernel related issue, although I wouldn't make
that conclusion this early.
I'll have a look again, once you've attached the new files.
Hope this helps, TIA
I ended up fixing it by reinstalling. I was using a stock system. The
problem ended up being that up2date settings were changed during an
upgrade so that it was getting development/unstable packages (which I
didn't realize). Which consequently resulted in problems like this
one. After I reinstalled, I changed the up2date settings to get only
stable packages, and everything has been fine since then.
Okay, closing then. Thanks Michael.