|Summary:||Graphic Installer Fails XIO: fatal IO error 104|
|Product:||[Fedora] Fedora||Reporter:||Keith Lofstrom <keithl>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED CANTFIX||QA Contact:|
|Version:||rawhide||CC:||burgedm, deji, dnielsen, fedora-bugzilla, ian, katzj, otaylor, p.van.toorn|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-10-29 21:08:52 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||133260, 135921|
Description Keith Lofstrom 2003-11-01 21:32:12 UTC
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)
Comment 1 Jeremy Katz 2003-11-03 03:24:59 UTC
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?
Comment 2 Keith Lofstrom 2003-11-03 19:01:57 UTC
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.
Comment 3 Keith Lofstrom 2003-11-03 19:13:30 UTC
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.
Comment 4 Alvan Shotade 2003-11-20 13:56:56 UTC
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!
Comment 5 Brent Fox 2003-12-16 21:56:31 UTC
Alvan: I think you are seeing a different problem than the original bug reporter was.
Comment 6 David M Burgess 2004-08-04 14:53:24 UTC
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.
Comment 7 Jeremy Katz 2004-09-22 19:47:30 UTC
*** Bug 122984 has been marked as a duplicate of this bug. ***
Comment 8 Jeremy Katz 2004-09-22 19:58:32 UTC
*** Bug 132337 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Katz 2004-10-04 15:35:29 UTC
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.
Comment 10 Jeremy Katz 2004-10-05 15:41:06 UTC
*** Bug 110477 has been marked as a duplicate of this bug. ***
Comment 11 Mike A. Harris 2004-10-12 07:37:17 UTC
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.
Comment 13 Kristian Høgsberg 2004-10-29 14:24:53 UTC
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.
Comment 14 Kristian Høgsberg 2004-10-29 14:32:20 UTC
Btw., patch is against CVS anaconda.
Comment 15 Jeremy Katz 2004-10-29 14:51:14 UTC
Commited, thanks Kristian.
Comment 16 Amit Bhutani 2004-11-04 22:45:15 UTC
When can we see this in a RHEL 3 Update ?
Comment 17 Mike A. Harris 2004-11-08 17:07:02 UTC
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.
Comment 18 Amit Bhutani 2004-11-18 17:00:11 UTC
Thanks for the response Mike. Opened an internal ticket with RH against RHEL 3 Update 4 and cross-referenced this Bugzilla.
Comment 19 Peter van Toorn 2005-05-04 16:26:30 UTC
Bug appears in same way in FC 4 test2
Comment 20 Mike A. Harris 2005-05-05 00:27:51 UTC
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.
Comment 21 Ian Posner 2005-07-06 22:24:53 UTC
Still exists on Fedora Core 4. Using a Vivitron monitor and an Addertec Gem 4 KVM switch.
Comment 22 Chris Lumens 2006-08-03 20:14:54 UTC
Please try again with FC6 or FC6 test 2. Lots of work has gone into X configuration and startup for this release.
Comment 23 John Thacker 2006-10-29 21:08:52 UTC
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!