Fedora 10 Installation Guide: Difference between revisions

From cchtml.com
No edit summary
(14 intermediate revisions by 7 users not shown)
Line 1: Line 1:
==Tom Walker's method==
There are two methods to install the fglrx driver. [http://rpmfusion.org RPMFusion.org] provides an RPM repository that fits in with yum for simple installation and updating. AMD provides a script installer that can generate Fedora RPMs or install the driver directly.


Hello. I provided the original entry on the page - essentially a link to this thread...
==RPMFusion Repository==
*This method will give you automatic updates when they become available from AMD.
===Step 1 Install RPMFusion repository information===
*Visit [http://rpmfusion.org RPMFusion.org] and install the RPM.
dont have a test box just a live production severr with some support software I installed but needs to have mcrypt to run, I guess if it does not install thats the worst , just dont want sites to fail. Well I'll give it a go and see what happens.Thanks Michael.


http://forums.fedoraforum.org/showthread.php?t=155503&pp=10
===Step 3 Restart===
*Restart your computer for changes to take effect.


... that contains useful info on how to install your ATI driver on Fedora 10.  It is this thread to which the 'important information' below pertains. 


The contents of that thread are not at all my work, by the way, but pleasingly the UALDW admins decided to give the name "Tom Walker's method" to the process of clicking on the link and reading the info that 'leigh123@linux' had spent hours working out.
==AMD Repository==
*Visit the Catalyst {{Catalystversion}} page and download the installer.
===Step 1 Install Development Tools===
The fglrx driver has a small kernel module that is required for hardware 3D and OpenGL acceleration.
$ su -c `yum install gcc kernel-devel rpm-build`


However, <b>since then a far easier and more reliable method has been developed</b> by the clever types at RPMFusionYou can read about it here:
issue is that OFED doesn't support the Fedora 9 keelrns (or keelrns 2.6.25 or later) at this point.  So our choice is (for this customer who wants Fedora), to roll back the kernel to something OFED will support, or to fix the OFED component (ofa_kernel) for the forward port.  Rolling back the kernel will be easier and less intrusive to the customer, as I am assuming that sometime in the not so distant future, OFED will support the 2.6.25 and later keelrns.This is less of a performance issue, and more of a core support of functionality issue.The problem I ran into is that building our own version of the kernel (down-rev) using the spec file they provide, and selecting a vanilla build of 2.6.24 doesn't work.  It doesn't work, as RPM appears to be doing things in an un-expected way.  More to the point, the spec file is doing virtual backflips within it to handle multiple cases of things that, arguably, should not be handled there, and certainly not in that manner.  Again, this is my opinion, and I am aware that many others disagree. The issue here is building the customized kernel is just short of a full-on nightmareThe only way I see to make it un-nightmare-ish, is to pull all the business logic out of the spec file, and use the spec file for precisely what it is supposed to be used for, repeatable packaging with a fixed build flow (but pull the business logic about that build out of the RPMs control so it doesn't try to be so    helpful  ).  Yeah this is a rant, yeah, others may think kernel builds are easy as pie using distro supplied rpm spec files and one or two line change.  I don't see it.  (and yes, I have looked at the howto's which add a patch or two  but don't try anything like a kernel down-rev).It should be easier, but it isn't.  The kernel itself has an rpm target that works quite well.  All we need for this, is a make rpm_headers or rpm_devel and this would be IMO the right method to use.FWIW: I am seriously contemplating building this kernel outside of the RPM system, as a) it will work, b) everything will be installed properly.


http://www.fedorafaq.org/#radeon
===Step 3 Reboot===
*Restart your computer for changes to take effect.


It takes five minutes.
[[Category:Installation Documentation]]
 
Sincerely,
 
 
Tom Walker,
IT Technician at a school you've never heard of.
 
 
 
 
'''''Additional important information:''''' (author Robert Schumann)
 
The procedure above worked for me for the original release kernel 2.6.27-5 and according drivers. After updating to 2.6.27-7, 2.6.27-9 and
an update of akmod-fglrx in the fc9 repo compiz didn't start anymore and e.g. awn quit although fglrxinfo showed normal ATI, even glxinfo reported
direct rendering and glxgears worked.
 
 
If you experience the same problem, first check your Xorg.0.log:
$ grep EE /var/log/Xorg.0.log
 
 
If the output is like
(EE) AIGLX error: fglrx exports no extensions (/usr/lib64/dri/fglrx_dri.so: undefined symbol: __driDriverExtensions)
then you have to relink libglx.so and libdri.so to the ATI versions (not the original ones from xorg). Thanks to the gentoo hackers
for this hint ;-)
 
$ sudo -i
 
$ mv /usr/lib64/xorg/modules/extensions/libglx.so /usr/lib64/xorg/modules/extensions/libglx.so.xorg
 
$ mv /usr/lib64/xorg/modules/extensions/libdri.so /usr/lib64/xorg/modules/extensions/libdri.so.xorg
 
 
And link the ATI ones:
 
$ ln -s /usr/lib64/xorg/modules/extensions/fglrx/libglx.so /usr/lib64/xorg/modules/extensions/libglx.so
 
$ ln -s /usr/lib64/xorg/modules/extensions/fglrx/libdri.so /usr/lib64/xorg/modules/extensions/libdri.so
 
==Another Way for X86_64 (maluyao#gmail.com)==
 
* 1. Download 2.6.27.8 kernel from www.kernel.org and compile it.
 
* 2.downgrade libdrm form Fedora9
 
rpm -Uvh --nodeps --oldpackage  ftp://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/9/Fedora/x86_64/os/Packages/libdrm-2.4.0-0.11.fc9.x86_64.rpm
 
* 3. run ati driver  8.12 or 9.1
 
./ati-driver-installer-8-12-x86.x86_64.run
 
* 4. ln -fs /usr/lib64/dri/fglrx_dri.so  /usr/lib/dri/fglrx_dri.so
 
* 5. aticonfig --initial -f
 
* 6. reboot
 
== One more way for i386 ==
 
Download and install libdrm package from Fedora 9, as described above. You have to prevent yum from updating these packages:
 
# perl -i -pe "s/(\[.*\])/\1\nexclude=libdrm/"  /etc/yum.repos.d/fedora.repo
# perl -i -pe "s/(\[.*\])/\1\nexclude=libdrm/" /etc/yum.repos.d/fedora-updates.repo
 
Install ati driver from amd's binary package.
 
Install system-config-display package:
 
# yum install system-config-display
 
After the successful install start system-config-display to create an xorg.conf template in /etc/X11.
Install ati driver from downloaded binary, edit /etc/X11/xorg.conf. Add these lines:
 
Section "Extensions"
Option "Composite" "Enable"
EndSection
 
 
Section "ServerFlags"
Option "AIGLX" "on"
EndSection
 
Section "DRI"
Mode 0666
EndSection
 
and add to 'Device section':
 
Option     "OpenGLOverlay" "off"
Option     "VideoOverlay" "on"
 
(From leigh123@linux's howto: [http://forums.fedoraforum.org/showthread.php?t=155503&pp=10 Howto for fglrx-Ati driver) and Compiz-fusion])
 
Edit /etc/grub.conf and add 'nopat' to the kernel line, and change the timeout to 10 seconds (timeout=10).
 
Reboot into single user mode, by pressing 'e' at grub's selection screen, select kernel line, press 'e', add 's' to the end of the line, press enter to finish editing and press 'b' to boot.
 
Log in as root. Add 'alias radeon off' to /etc/modprobe.conf, and add 'blacklist radeon' to /etc/modprobe.d/blacklist. If loaded, remove drm and radeon modules:
 
# rmmod radeon
# rmmod drm
 
Load flgrx module:
 
# modprobe fglrx
 
Back up your current initrd image and create a new one:
 
# mv /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.backup
# mkinitrd /boot/initrd-`uname -r`.img `uname -r`
 
After rebooting yor machine, fglrx should work. This method worked on a 'HP DC5750 microtower' with integrated Radeon X200.

Revision as of 00:36, 11 December 2012

There are two methods to install the fglrx driver. RPMFusion.org provides an RPM repository that fits in with yum for simple installation and updating. AMD provides a script installer that can generate Fedora RPMs or install the driver directly.

RPMFusion Repository

  • This method will give you automatic updates when they become available from AMD.

Step 1 Install RPMFusion repository information

dont have a test box just a live production severr with some support software I installed but needs to have mcrypt to run, I guess if it does not install thats the worst , just dont want sites to fail. Well I'll give it a go and see what happens.Thanks Michael.

Step 3 Restart

  • Restart your computer for changes to take effect.


AMD Repository

  • Visit the Catalyst 15.12 page and download the installer.

Step 1 Install Development Tools

The fglrx driver has a small kernel module that is required for hardware 3D and OpenGL acceleration.

$ su -c `yum install gcc kernel-devel rpm-build`

issue is that OFED doesn't support the Fedora 9 keelrns (or keelrns 2.6.25 or later) at this point. So our choice is (for this customer who wants Fedora), to roll back the kernel to something OFED will support, or to fix the OFED component (ofa_kernel) for the forward port. Rolling back the kernel will be easier and less intrusive to the customer, as I am assuming that sometime in the not so distant future, OFED will support the 2.6.25 and later keelrns.This is less of a performance issue, and more of a core support of functionality issue.The problem I ran into is that building our own version of the kernel (down-rev) using the spec file they provide, and selecting a vanilla build of 2.6.24 doesn't work. It doesn't work, as RPM appears to be doing things in an un-expected way. More to the point, the spec file is doing virtual backflips within it to handle multiple cases of things that, arguably, should not be handled there, and certainly not in that manner. Again, this is my opinion, and I am aware that many others disagree. The issue here is building the customized kernel is just short of a full-on nightmare. The only way I see to make it un-nightmare-ish, is to pull all the business logic out of the spec file, and use the spec file for precisely what it is supposed to be used for, repeatable packaging with a fixed build flow (but pull the business logic about that build out of the RPMs control so it doesn't try to be so helpful ). Yeah this is a rant, yeah, others may think kernel builds are easy as pie using distro supplied rpm spec files and one or two line change. I don't see it. (and yes, I have looked at the howto's which add a patch or two but don't try anything like a kernel down-rev).It should be easier, but it isn't. The kernel itself has an rpm target that works quite well. All we need for this, is a make rpm_headers or rpm_devel and this would be IMO the right method to use.FWIW: I am seriously contemplating building this kernel outside of the RPM system, as a) it will work, b) everything will be installed properly.

Step 3 Reboot

  • Restart your computer for changes to take effect.