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 2a Generate RPMs Method====

+

−

* Open a terminal, and run the package.

+

−

$ sh {{Catalystfilename}} --buildpkg Fedora/F10

+

−

* Become root and install the RPM files that were generated.

+

−

$ su -

+

−

# rpm -ihv filename.rpm

+

−

====Step 2b Script Install Method====

−

*Open a terminal, become root, and run the package.

−

$ su -

−

# sh {{Catalystfilename}}

===Step 3 Reboot===

===Step 3 Reboot===

*Restart your computer for changes to take effect.

*Restart your computer for changes to take effect.

[[Category:Installation Documentation]]

[[Category:Installation Documentation]]

Revision as of 19:36, 10 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

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

AMD Repository

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.