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):
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]
good: an understandable error message
better: drop back into text install
best: drop back to real X setup as
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
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
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
*** 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:
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"
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 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
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.