Bug 116937 - graphical anaconda fails to start
graphical anaconda fails to start
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
athlon Linux
high Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
: 114576 115755 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-26 12:06 EST by raid517
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-22 15:04:52 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 raid517 2004-02-26 12:06:16 EST
Description of problem: Fedora Core 2.0 test 1 Freezes (hard locks)
before X display is launched. To start with the Amaconda graphical 
installer refused to start - so I then switched to text mode. Text 
mode sucessfully installed the OS, but on first boot the OS hung on 
inintialising the firewire Ohci1394 controller. So after editing the 
modules.conf line via Knoppix I was able to boot the OS - but this 
time only to the point where X appeard to be about to start and then 
it [the OS] froze (hard locked, became unresponsive - keyboard ctrl 
alt delete had no effect)with this message:

Firstboot. py4112: Warning GTkText SearchFlags is not an enum type:

Warning: Failed to open connection to a session manager, so windows 
will not be saved.

Session_Manager environment variable not defined.


Version-Release number of selected component (if applicable):


How reproducible: Always.


Steps to Reproduce:
1.Boot Fedora Core 2 test 1
2.Since a graphical install is not available, select text install.
3.Test media. Media has tested clean.
4. Deselect everything from the install selections and choose only 
the option to 'install everything.
  
Actual results: Fedora Core 2.0 should have booted cleanly to a 
graphical display. But it did not do this. Instead it simply hard 
locked and became unusable.


Expected results: Fedora Core 2.0 should have booted cleanly to a 
graphical display.

Additional info:

I have an Althon XP 2800 Barton processor, 512MB of Ram and a radeon 
9800 Graphics card. I have sucessfully booted several linux 
distributions using this configuration in the past.

I'm sorry but I don't know where this should go - but graphical 
display seems the most appropriate - since I was unable to boot into 
a graphical display either via the Anaconda installer - or via the 
final installed OS.

There is at least one other person who has experienced this problem.

http://www.redhat.com/archives/fedora-list/2003-November/msg01863.html

I trust this information is useful to you.

GJ
Comment 1 Mike A. Harris 2004-02-26 12:34:34 EST
There are a few bugs being reported lately of XFree86 not starting
up.  They fall into 3 general categories:

1) The 2.6.x kernel no longer has a /dev/psaux device, so if you
   have been using that in 2.4.x kernels, you must change to using
   /dev/input/mice.  In the future, our installation and
   configuration tools need to be enhanced to automatically
   reconfigure XFree86 appropriately.  This is not an XFree86 bug
   however, as it is just doing what it was told to do in the config
   file.  The bug that tracks this issue, claims it is fixed in
   rawhide:
       https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116118

2) Upon upgrading the kernel to 2.6.3 recently, a bug was introduced
   which broke SysV IPC, in particular shmat() calls now fail.  This
   breaks XFree86 which calls shmat() in the linux specific int10
   X server module.  This is a kernel bug, and not an XFree86 bug,
   and it has been fixed in a newer kernel released in rawhide:
       https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116724

3) The kernel logs some error messages from atkbd.c which claim that
   XFree86 is broken and should not be using the keyboard controller
   directly.  This problem has also been fixed:
       https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=atkbd

There are also various reports of certain keyboard and/or mice
no longer working aside from the problems above.  All of these
problems are related to the 2.6.x kernel, and are kernel bugs.

Please attach your X server log, config file, and /var/log/messages
as individual uncompressed file attachments using the bugzilla
link below, so we can determine which of the above bugs you are
experiencing, or if the problem is a new one.

The mailing list URL you've provided discusses a different unrelated
problem in "Fedora Core 1" OS release.  While the problem has many
things in common with the problem you are reporting, it is very
unlikely to be the same problem.


P.S. I should note that the release you are using is not named
"Fedora Core 2.0", as that has not been released yet.
Comment 2 raid517 2004-02-26 14:16:35 EST
Umm Ok well FYI it was a fresh install - so I wasn't upgrading from a 
previous release. And the circumstances and error message that that 
guy gave weren't just very similar - they were infact in every aspect 
identical. Can identical circumstances that produce identical error 
messages have different cause? Possibly. Stranger things have happend 
I guess. The error message produced is extremely specific:

quoute: 

Firstboot. py4112: Warning GTkText SearchFlags is not an enum type:

Warning: Failed to open connection to a session manager, so windows 
will not be saved.

Session_Manager environment variable not defined.

I have ran 2.6x kernels for some time now accross several distro and 
have never run into a problem like this before - although admittedly 
Fedora probably has some quite specific Red Hat customistations - 
which might be a little more difficult to predict how they will play 
when paird against a 2.6x series kernel.

In any case I'm not even sure it has got anything to do with XFree - 
although since ultimately it resulted in no display - it is the best 
match I could find.

Unfortunately attaching the log files has not proved possible - 
predominantly because as I indicated Fedora Core 2 beta 1 locks up 
when I try to boot it. I tried via knoppix to recover them - but 
since my other partitions are NTFS I couldn't save them - and due to 
premissions retrictions in Knoppix (even when acting as a su) it 
ultimately proved to not be possible to mail them to myself as an 
attachment.

I am sorry I cannot be more helpful.

GJ
Comment 3 Mike A. Harris 2004-02-26 14:42:34 EST
The above error:

>Firstboot. py4112: Warning GTkText SearchFlags is not an enum type:

Is not an XFree86 error, it is an error from firstboot itself,
concerning GTK.  On that alone, I can not conclude the problem
you are experiencing is an XFree86 bug, and can not investigate
it without having detailed description of a real XFree86 bug/problem
with the log files, config files I requested above.

Reassigning to firstboot for now, in case this is a known bug in
firstboot.  If it is indeed considered an XFree86 bug, please
attach the requested information or there is nothing I can do
to troubleshoot the problem as "XFree86 doesn't start" with no
further information is not useful.
Comment 4 raid517 2004-02-26 14:52:27 EST
Dude I tried hard to get you the logs - but it just was not 
happening. Perhaps you can suggest a way I might have got hold of 
them? The system locks up hard before I can do anything useful with 
it. The best I could do was print the only useful information I could 
obtain - which was the error message itself.

I'm sorry if somehow that wasn't good enough. But I can only do as 
much as it is possible to do.

I couldn't save them to a floppy drive in Knoppix as I don't own one.

Like I said, if you have any other ideas then let me know. Otherise I 
will just have to wait for the next beta.

GJ



Comment 5 Brent Fox 2004-02-26 15:31:43 EST
The error message about "GTKText SearchFlags is not an enum type"
comes from GTK and not firstboot.  However, it's just GTK being very
verbose.  This message will not cause a system hang or anything like that.

I suspect that this problem has to do with the switch from /dev/psaux
to /dev/input/mice for mice input.  Probably the best thing I can
recommend is to wait for beta 2 and try again there.  I have changed
the way that we handle mice in the installer and the X configuration
tool, so hopefully beta 2 will be better.
Comment 6 Mike A. Harris 2004-02-26 22:24:49 EST
raid517) All I can do is look at the information I've been given,
and make a judgement call based upon that.  Since the information
you have provided does not sound like any /new/ bug, I can only
assume that it is an existing known one, or a problem with something
else.  I presented the top 3 bugs of this nature to you above,
and reassigned to firstboot for analasis by Brent in case he
had seen people report a similar issue, which was already known
by him, but not by me.

While you may or may not be able to get logs from XFree86 for the
problem, without those logs, there is nothing further that I can
personally do to investigate your specific problem other than to
assume it is one of the existing reported problems, or to leave it
in a limbo state that we can do nothing about without further
information.

You can install via text mode, then configure and run XFree86
afterward if you like.  Otherwise, just wait for the next test
release.
Comment 7 raid517 2004-02-27 11:02:18 EST
I can't man - the system hard locks - I never get access to X - not
even in text mode. But thanks anyway.

I really didn't expect anything to be perfect at this early stage -
but I tried my best and that is what happend - and beyond informing
you of it and my genuine efforts to resolve it, there isn't much else
I can do.

I will try the next beta - and if the bug persists - and if it is
physically possible for me to investigate the cause of the bug in more
depth (which wasn't the case in this instance) I will be happy to do so.

If it is a clue to you, if I do try a graphical install, the display
starts and the mouse can be moved about the screen for about the first
four seconds. After that the mouse and the grphical installer itself
hard locks. So your hunch about the way you have changed the handling
of the mouse may indeed be accurate.

As I said, we will see in the next release.

GJ
Comment 8 Brent Fox 2004-03-04 16:08:53 EST
Well, if the mouse can be moved for a few seconds before the machine
locks, then the problem is not the /dev/psaux mouse configuration
problem.  If that were the case, X would not start at all.

Since X isn't even working for you in the installer, the problem must
lie somewhere deeper than firstboot.  To me, the first step seems to
be to get the graphical installer working.  Therefore, I'm changing
the component to anaconda.
Comment 9 Brent Fox 2004-03-04 16:40:55 EST
*** Bug 115755 has been marked as a duplicate of this bug. ***
Comment 10 Brent Fox 2004-03-04 17:33:41 EST
*** Bug 114576 has been marked as a duplicate of this bug. ***
Comment 11 Jeremy Katz 2004-04-15 01:04:03 EDT
Does this still happen with test2?
Comment 12 raid517 2004-09-22 16:50:08 EDT
I don't know if it still happens. i stopped monitoring it some time 
ago - as I did the Fedora project in general.

I assume it is fixed as it has now been closed.

The RH/Fedora installer has always been fairly robust in the past so 
I assume any glitches were due to the very beta state of the software.

But as a somewhat comitted debian user I can add no further comment.

GJ

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