From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)
Description of problem:
The anaconda installer is failing when trying to start X to begin the
GUI-based installer. It actually locks up the computer, but I ran the
installer again and kept the F4 screen active and was able to look at
/tmp/X.log to find out what the exact error is:
(EE) Failed to load module "glx" (module does not exist, 0)
(EE) Failed to load module "record" (module does not exist, 0)
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1)
found error opening security policy file /etc/X11/xserver/SecurityPolicy
(EE) xf86OpenSerial: cannot open device /dev/input/mice
no such device
(EE) DevInputMice: cannot open input device
(EE) PreInit failed for input device "DevInputMice"
I am using a KVM switch, but disconnected it and tried with the
mouse/keyboard/monitor directly connected and got the same error.
Mouse and KB are both PS/2 and work fine on my Windoze PC.
I can run the text-based installer, and may just go ahead and do this
and upgrade XFree to see if that's the problem. Anaconda is correctly
detecting my monitor and video card.
All installation disks have been PASSed by the installer disk check
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert yarrow disk 1 and boot computer in graphical mode install.
2. When the installer tries to load X, boom.
Expected Results: I'm going to go out on a limb here and say that the
installer should have started X and continued the installation without
Hate to assign this high, since I can do a text-based install, but
since I've not tried that yet, I don't know if I can get X to start
just yet. I can update this info when I try that.
Ok, quick update. After keying in this bug, I switched over to F7 and
to my suprise, X had started successfully and I was looking at the
welcome screen. But before you break out the champagne, I clicked
Next and it went to the language selection screen. I clicked next and
X froze. I'll reboot to see what the X log says. Hopefully the /tmp
dir isn't wiped so I can see it... It was wiped. But clearly the
module loading error is not the problem since the installer managed to
find a way past it...
Installed fine via the text installer, rebooted and computer froze
when X tried to load. Booted 'linux rescue' and changed inittab to
runlevel 3 and rebooted. Things seem fine, mouse and keyboard are
working fine in runlevel 3. I am going to try and telinit to runlevel
Ok, telinit 5 worked and I was able to get to the login screen. I
logged in as root (i know....bad) and the Fedora Core (GNOME) loader
screen came up and the entire computer froze again.
I rebooted and there's nothing funky in the log file, i.e., no glaring
errors. There is something about the resolution, but I don't think
it's critical. The mouse just went haywire so I tried a USB mouse to
see if perhaps the PS2 port is bad. It worked fine under the
terminals, but X froze again....
Will shutdown and wait for some feedback.
I have the same problem - having tried graphical and text based
install - using skipddc and noprobe options.
With graphical install I get a hard lock when the X tries to initalise
installaion screen for mouse and graphics card selection
With a text install i get to complete the install, but on first boot
the system hangs when attempting to enter runlevel 5
My theory is as follows:
1) UNDER RH9 If I install RH9 my Radeon 9800 pro is detected as a
generic vesa card. If I select Generic Radeon or Radeon 9700 pro from
the install options, I can install ok, but on first boot I get the
same message as your first post "failed to load....."
2) With RH9, on first (and subsequent) boots the X server
re-initialises using a generic vesa driver - overriding the selection
I made during installation and I can login using the X GUI
3) With FC1, my card detects as Radeon 9800 pro and assuming I use the
text based to complete install, I reach a point entering runlevel 5
where the old RH9 X server would re-initialise - but FC1 doesn't and
the system hangs.
I assume two things here - A) Support for Radeon 9x00 is not 100% rock
solid (or any openGL card??) B) Anaconda and X don't fail safe and
install a generci vesa driver anymore.
Just my two cents ;)
Bingo! I just booted the RH9 CD and sure enough, it used the VESA
driver instead of the Mach 64 driver. I, too, have the Radeon 9800
(but not pro).
Did you hack your XFree86 config file to load the vesa driver instead
of the Mach64? I can do that and get my system up and running from there.
Oooo! Just found this on ATI's website:
Looks like ATI is providing drivers for the 9800 via their website for
XF86 4.1, 4.2, and 4.3.
I'll check it out and update this as appropriate.
Ok, I installed the RPM and followed the instructions in the readme.
Note that you WILL need the kernel source!!! Did NOT have to rebuild
kernel, but did go into /lib/modules/... directory to run the two make
scripts the readme mentions (but probably didn't need to) after
installing the RPM and before running the XFree config binary the
script tells you to run after the RPM installs.
After answering all the questions, I looked at the config file,
/etc/X11/XF86Config-4 and for whatever reason it put (null) as my
vertical refresh rate, so I had to fix that. I ran 'startx' and
everything worked fine.
The supported video cards for this RPM are:
- ATI Radeon 8500 / 9100
- ATI FireGL 8700 / 8800 / E1
- ATI FireGL T2
- ATI Radeon 9000
- ATI Radeon 9200
- ATI Radeon 9500
- ATI Radeon 9600
- ATI Radeon 9700
- ATI Radeon 9800
- ATI FireGL Z1 / X1 / X2
- ATI Mobility M9
- ATI Mobility FireGL 9000
- ATI Mobility M9PLUS
Radeon 9200/9600/9800 hardware is not supported at all by XFree86.org's
stock XFree86 4.3.0 release. We have patched 4.3.0 to add
experimental support for /some models/ of the 9200/9600/9800, however
other models are still unsupported.
There are numerous bug reports open in bugzilla for 9200/9600/9800
which you may wish to query for, as they may provide useful
information for trying to work around the problem for now.
If time permits, I may investigate these problems for the Fedora
Core 2 release, and future erratum for FC1/RHL9/RHEL3 as well.
Attach your X config file and log file as individual bugzilla file
attachments, and I'll review them when I'm investigating these
Created attachment 97482 [details]
XFree config file created by running the fglrxconfig binary.
I modified the config file a tiny amount after creation. I had to fix the
(null) parameter that was there instead of the vertical synch range and I
added/corrected my monitor information.
Created attachment 97483 [details]
XFree log file containing all successful/failed attempts to start X
I think there might be some stuff missing from the log because most of the
stuff appears to be from the new fire gl driver I built from ATI....not sure
Your wish is my command. I've attached said logs. The module works
like charm and X runs just fine now. Wasn't really hard at
all...don't know why more people are made aware of the "fix." Though,
I do understand if they're not Linux-saavy yet.
I think you might misunderstand me... Red Hat does not support 3rd
party video drivers at all, proprietary or open source. If you use
a 3rd party driver at all, and have any problems with it and need
technical support, you must go to the supplier of the driver to seek
support. We wont provide tech support, nor track bugs with 3rd party
>don't know why more people are made aware of the "fix."
Because it is not a "fix". It is a workaround, and is unsupported.
Bugzilla is here for people to report bugs, and for us to track
the bug and fix it or determine another resolution, and not for
to point people at binary drivers and then leave things sit broken.
When I asked for the files above, I wanted the config/log file
from configuring X using _our_ tools, not fglrxconfig, and the
log file from using the radeon driver we ship, not ATI's unsupported
driver. That stuff isn't useful to me.
Radeon 9200/9600/9800, and the Pro, SE, and XT variants of these
are now officially supported in Fedora Core 2 and later OS releases.
Once you've upgraded to Fedora Core 2 or later, this hardware should
be automatically detected and configured. If you experience problems
with the "radeon" driver in Fedora Core 2, please file a bug report
in the X.Org bugtracker located at http://bugs.freedesktop.org in
the "xorg" component.
Setting status to "CURRENTRELEASE"