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
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