Bug 116937

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.

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

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.

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

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.

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.

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

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.

*** Bug 115755 has been marked as a duplicate of this bug. ***

*** Bug 114576 has been marked as a duplicate of this bug. ***

Does this still happen with test2?

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