Bug 108777 - Graphic Installer Fails XIO: fatal IO error 104
Graphic Installer Fails XIO: fatal IO error 104
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
:
: 110477 122984 132337 (view as bug list)
Depends On:
Blocks: 133260 135921
  Show dependency treegraph
 
Reported: 2003-11-01 16:32 EST by Keith Lofstrom
Modified: 2008-08-02 19:40 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-29 16:08:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Startup X.log file for serial mouse (1.58 KB, text/plain)
2003-11-03 14:01 EST, Keith Lofstrom
no flags Details
Fix for X crash (2.17 KB, patch)
2004-10-29 10:24 EDT, Kristian Høgsberg
no flags Details | Diff

  None (edit)
Description Keith Lofstrom 2003-11-01 16:32:12 EST
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-02 22:24:59 EST
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 14:01:57 EST
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 14:13:30 EST
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 08:56:56 EST
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 16:56:31 EST
Alvan: I think you are seeing a different problem than the original
bug reporter was.
Comment 6 David M Burgess 2004-08-04 10:53:24 EDT
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 15:47:30 EDT
*** Bug 122984 has been marked as a duplicate of this bug. ***
Comment 8 Jeremy Katz 2004-09-22 15:58:32 EDT
*** Bug 132337 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Katz 2004-10-04 11:35:29 EDT
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 11:41:06 EDT
*** Bug 110477 has been marked as a duplicate of this bug. ***
Comment 11 Mike A. Harris 2004-10-12 03:37:17 EDT
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 10:24:53 EDT
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 10:32:20 EDT
Btw., patch is against CVS anaconda.
Comment 15 Jeremy Katz 2004-10-29 10:51:14 EDT
Commited, thanks Kristian.
Comment 16 Amit Bhutani 2004-11-04 17:45:15 EST
When can we see this in a RHEL 3 Update ?
Comment 17 Mike A. Harris 2004-11-08 12:07:02 EST
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 12:00:11 EST
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 12:26:30 EDT
Bug appears in same way in FC 4 test2
Comment 20 Mike A. Harris 2005-05-04 20:27:51 EDT
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 18:24:53 EDT
Still exists on Fedora Core 4. Using a Vivitron monitor and an Addertec Gem 4 
KVM switch.
Comment 22 Chris Lumens 2006-08-03 16:14:54 EDT
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 16:08:52 EST
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!

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