From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Description of problem: Anaconda (?, the installer that is loaded by Fedora Install Disk 1) correctly identifies my NVIDIA Geforce 2 MX and my Gateway CM751 monitor (same as Hitachi CM751). The graphical installer fails with: XIO: fatal IO error 104 I can install with linux text mode, and set up X later on, so we know X can handle the setup. A similar install with Redhat 9 works just fine in graphical mode. This is not a show stopper, of course, but it might upset newbie users. Rather than a cryptic XIO error message, how about a user friendly (that is, usable and self-explanatory) message, or better yet using the same code as the X configuration later in the setup? Version-Release number of selected component (if applicable): anaconda 9.0.95 How reproducible: Always Steps to Reproduce: 1. Load Fedora Test 3 (0.95) Install Disk 1 2. Default graphical install Actual Results: Waiting for X server to start...log located in /tmp/X.log 1...2...3...4...5.... X server started successfully. XIO: fatal IO error 104 (Connection reset by peer) on X server ":1.0" install exited abnormally sending termination signals...done [and so forth] Expected Results: good: an understandable error message better: drop back into text install best: drop back to real X setup as Additional info: Fedora Test 3 Install Disk 1 NVIDIA GeForce 2 MX Gateway CM751 (same as Hitachi CM751)
Can you reproduce this reliably? If so, can you hit ctrl-s before "sending termination signals" and go see what errors are listed in /tmp/X.log?
Created attachment 95684 [details] Startup X.log file for serial mouse This is the X.log file for fedora test 3 install anaconda failed X startup, with a 3 button Logitech serial mouse connected to COM1/ttyS0. Fedora install works fine with a PS/2 mouse.
Thanks again for the ctrl-s idea, which combined with ctl-alt-f2 let me view all sorts of things about the setup. It appears that in this case Fedora will not install with a Logitech (mouseman?) serial mouse connected to COM1. I swapped between serial and PS/2 mice, tried both reset and power cycling. The behavior seems to track the type of mouse only. Note that I normally run signals through an ancient ATEN CS-106 KVM box, which does not pass DDC info to the video card, but for these experiments I connected directly and bypassed the KVM. The good news is that the keyboard and monitor connections do not affect the X startup, only the mouse connection and type.
Description of problem: RedHat 8 (2.4.18-14 i686 ELF)install successful on IBM Netfinity 5k5 server - correctly identifies the S3 Trio64V2 (generic)card, and PS/2 mouse & kboard connected via a new BLACK BOX SW626A KVM box. Viewsonic E70 Monitor couldn't be probed so monitor info was manually provided during install process (vsync/vertrefresh/depth info also correctly listed in the XF86Config file output). The graphical installer fails upon firstboot with: XIO: Fatal IO Error 104 (connection reset by peer) on X server ":0.0" Fatal Server Error: no screens found Keyboard and mouse seem to work fine in text mode, but can't seem to get a graphics screen mode .... thanx for your kind assistance with this pesty puzzle!
Alvan: I think you are seeing a different problem than the original bug reporter was.
I was about to enter a new bug when I saw this one. I get the same crash with all archs of Fedora Core 2 and Fedora Core 3 Test 1. It happens with every type of mouse I try but (here's the klicker). I'm not particullary patient so just after I've skipped the media check (already done it) and right after it announces it's starting Anaconda I begining to wiggle the mouse around (impatiently) waiting for X to start. That crashes it EVERY time with ANY mouse (USB or PS/2). If I let it reboot, do everything exactly the same except I don't touch the mouse X starts up fine and the installation can continue and I can roll the mouse around all I want with no ill affects. After the initial installation I cannot get the mosue to crash the X server.
*** Bug 122984 has been marked as a duplicate of this bug. ***
*** Bug 132337 has been marked as a duplicate of this bug. ***
This seems to actually be an X bug. It seems to happen whenever you start up the X server and then move the mouse around before starting up any X clients. I thought it might have been something in mini-wm, but the error from X occurs before mini-wm actually starts, so I don't see how it can be a bug in it.
*** Bug 110477 has been marked as a duplicate of this bug. ***
Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. Users who have experienced this problem are encouraged to upgrade to the latest version of Fedora Core, which can be obtained from: http://fedora.redhat.com/download If this issue turns out to still be reproduceable in the latest version of Fedora Core, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates.
Created attachment 105938 [details] Fix for X crash Apparently wiggling the mouse offsets the timing between starting mini-wm and the setRootResource() calls in doStartupX11Actions(), so that the setRootResource() calls reach the server before mini-wm. This shuts down the server as it's started with the -terminate option. The attached patch adds a simple synchronization mechanism so that anaconda waits for mini-wm to establish connection before proceeding.
Btw., patch is against CVS anaconda.
Commited, thanks Kristian.
When can we see this in a RHEL 3 Update ?
Amit: If you prefer, please file a bug report for anaconda against RHEL 3 for this issue, and the anaconda development team will review it for consideration in a future RHEL3 update release. Please pastepaste a link to this bug report in the new bug report. Thanks.
Thanks for the response Mike. Opened an internal ticket with RH against RHEL 3 Update 4 and cross-referenced this Bugzilla.
Bug appears in same way in FC 4 test2
Several people have indicated this still occurs, but nobody has actually set the bug to "REOPENED", which is probably why nobody's looked at it again. I just happened to catch the bugzilla email from the last comment. When you discover a bug still exists that was closed, always remember to not only add a comment, but to "REOPEN" the bug if you want to ensure it gets looked at again. If bugzilla wont let you reopen it for some reason, then file a new bug report, indicating the problem, and provide links to the previous closed bug instead. This ensures that there will be an "open" bug that an engineer will eventually see, since we do not normally ever look at bugs that are "closed". Hope this helps. Reassigning to "anaconda" owner.
Still exists on Fedora Core 4. Using a Vivitron monitor and an Addertec Gem 4 KVM switch.
Please try again with FC6 or FC6 test 2. Lots of work has gone into X configuration and startup for this release.
Closing per previous comment and lack of response. FC3 and FC4 are supported for security fixes only by Fedora Legacy. If this is a security bug, please reopen. Please retest against FC5 or FC6 and set the version appropriately if the bug still occurs in one of those still supported versions of Fedora Core. Thanks!