Unlike other distros, using a .run file from Nvidia seems to be the quickest way to bork graphics in Fedora. Although some have been successful, the consensus (from reading the Fedora Forums) is that it rarely works
It seems that Red Hat ties the Open Source Nouveau driver tightly to its kernel, and, from what I'm reading, is putting resources into the mesa-dri experimental drivers, which, have already had success with rendering 3D with some Nvidia cards. Though I don't use ATI cards, I've read posts where ATI users were asked to try the mesa-dri experimental drivers also. I guess I'll have to wait for an Alpha release of Fedora 13 before I get to test them out, as they will be included in that release. They are available right now in the rawhide repo, but, I need an experimental install to test them, and I haven't had time for that.

Anyway, back to sgfxi.

Fedora keeps it's version in /etc/fedora-release


In Fedora 11, blacklisting of Nouveau wasn't necessary in Grub, and kernel names were uniform.
ex. Part of my Fedora 11 grub.conf


In Fedora 12, blacklisting Nouveau was necessary in Grub, and kernel names were less uniform.
ex. Part of my Fedora 12 grub.conf


All installations of Nvidia drivers require enabling of the rpmfusion repos.

For akmods to work one must

or if using a PAE kernel

also.

Then your installation depends on what type of kernel your using.
For an x86 & x86_64 kernel:

For an x86-PAE kernel:


Installing the kmod drivers necessitate reinstallation when new kernels come in. Using the akmods builds the required kmod on bootup. I use the akmods, why install kmods when the akmods are install once and forget about it. Also, kmod's aren't always released the same day as the new kernels, so, using the akmods means you don't have to wait a day or two when a new kernel comes out to do your update. If sgfxi was to install a driver, installing the akmod's would make the most sense.

Installing akmods for FX:


Installing akmods for Geforce 4 and below:


Both Fedora 11 and 12 had to have Nouveau modules blackisted by adding "blacklist nouveau" to /etc/modprobe.d/blacklist.conf. (In F12 a file called blacklist-nouveau.conf was added to the /etc/modprobe.d/ folder reminiscient of sources.d in Debian, either way works)

Rebooting after this point would build the kmod if the akmod method was used. If the blacklisting didn't do it's job, they recommend remaking initrd by:

In Fedora 11


In Fedora 12


Note that in Fedora 12 drivers have i686 instead of i586 due to newer Fedora kernels no longer supporting some older processors.

Note that in Fedora 12 kernel line in Grub contains options to blacklist nouveau: rdblacklist=nouveau (I used nouveau.modeset=0, same result), allocate memory: vmalloc=256m if you have a multi GPU card or a PAE kernel and an extra command must be executed if you have SELinux enabled and don't want it to interfere with driver loading:


Additional commands can be executed if ... lol ... Nouveau still refuses to die. Basically to remove nouveau driver more completely, then rebuild initrd again.

Now if all of that doesn't seem like to much of a PIA, just realize that Fedora 13 will probably tie the new Open Source drivers even tighter into the newer kernels, and since I haven't seen a stable enough rawhide yet to test them on (if they are even available), there will probably be extra steps to execute to make Binary drivers workable.

OK, need some sleep, till next time.
Back to top

great work, thanks. The main question is this: what is the exact procedure to remove/purge akmod modules? is it simply: yum purge <akmod module> or whatever, or is it like with dkms, that leaves a lot of cr#p and cruft behind that can screw up the install?

With this many steps, it's obvious why users are having trouble, it's simply too many steps to not have scripted.

Seems like it will be good to wait for fedora 13 and to see what it does, but if you provide this quality of information I may have to get tempted to actually look into this a bit.

What are the commands in yum that are the same as:

dpkg -l | grep nano (for example)
dpkg -i package
apt-get install package (yum install <package>)
apt-get remove package
apt-get purge package
apt-get update

I think that's the ones the script uses.

Does fedora have kernel header packages separate, and if not, do the header files live in /usr/src/$(uname -r)/ and /lib/modules/$(uname -r)/ which is where nvidia installer expects to find that stuff. What are the package names.

There's actually a fairly finite set of things sgfxi needs to know and test, then you get into the nv drivers, and the nouveau drivers, sounds like re-enabling nouveau involves a bit more than installing an xorg driver and updating xorg.conf, or deleting it I guess, whatever.

Also, what does a current fedora nvidia xorg.conf file look like?

Basically sgfxi has to be able to undo what it does, technically, so it if installs akmod stuff, it must be able to clean it up, if it removes nouvea and blacklists, it must be able to add it, for the regular: sgfxi and the sgfxi -s (distro driver install) methods. Plus of course sgfxi -n and sgfxi -N nouveau in the end would need to work.

Also, does fedora use /etc/lsb-release ? which I prefer because it gives me all the data I need in a very clean and predictable way. Parsing the files you listed is easy too, but I'd rather use one method for as many distros as possible than individual methods for individual distros.
Back to top

Well, I'm amazed I actually got to this today. Every time I started, I was interrupted. But, hopefully, I answered everything. Let me know if I left anything out.

There is no /etc/lsb-release but there is an /etc/lsb-release.d/ which contains empty files matching the names in LSB Version below. Running ./lsb_release in /usr/bin outputs the info below. According to Red Hat, this matches lsb standards.



I've talked folks through reversing Nvidia graphics installs gone bad, most recently on Linux.com. To clean up Nvidia graphics you first remove the options on the kernel line in Grub.conf which could be dblacklist=nouveau or nouveau.modeset=0. Then, the following commands:

The last command depends on whether the user put "blacklist nouveau" in the blacklist.conf file or let the
akmod-nvidia installer create the blacklist-nouveau.conf file in the /etc/modprobe.d/ folder.
Rebooting after these instructions brings back the nouveau driver. Unless the user needed to go the extra step and remove the nouveau driver completely, and that would be an extreme case.

To the commands:


From the Fedora rpm how-to:
When erasing or removing packages, use the package name, not the RPM file name. If you think about this, it makes sense. You don't always have the original RPM files when the time comes to remove a package.
My understanding of this is:



Does fedora have kernel header packages separate, and if not, do the header files live in /usr/src/$(uname -r)/ and /lib/modules/$(uname -r)/ which is where nvidia installer expects to find that stuff. What are the package names.
Kernel files in /usr/src/kernels/$(uname -r) /lib/modules/$(uname -r)
BTW - akmods in /usr/src/akmods/nvidia-kmod-190.53-1.fc11.src.rpm and soft link to nvidia-kmod.latest


My current xorg.conf on my laptop - 32 bit:

Back to top

was that a yes, there is a kernel headers package, or a no? I'm not clear on that.

A few other things too, I'll have to check some package names etc, have to look into the script for that.

First step is to get binary install working, next step is to restore xorg / nouveau support, doing one at a time is easiest.
Back to top

The kernel source files are there, but not in /usr/src/$(uname -r)/ but in /usr/src/kernels/$(uname -r)/

Modules are in /lib/modules/$(uname -r)/ just as you asked.

If you need anything else, just ask.
Back to top

I'll have to wait for testing to determine if this will matter, in debian/ubuntu, it's easy to check, is package linux-headers-$(uname -r) installed or not, if not, install it, if not available, give error, but if the kernel header files are there, that shouldn't matter I guess.

The real test is always a raw fresh install, no user tweaks or packages added.

Maybe tomorrow I'll post a package list to test for equivalents in fedora, that's about all that's needed now I think.
Back to top

Does the file /etc/issue exist in fedora, and if so, what is its content?
Back to top

Package names to check. Please check that each literal name installs when tested, ie.: yum install logrotate

logrotate
patch
fakeroot # I cannot remember why sgfxi has fakeroot in it,
# I think it's not needed, at least not for 32 bit

libstdc++5
libstdc++6

confirm that no package of type: linux-headers-$(uname -r) exists, or if there is one in yum.

Confirm the command: X -version
shows output, if it doesn't, find the X command that will show X version.

Should output for: rpm -qa | grep nvidia
on a system that has all the native drivers installed.

when you say:
yum list | grep nano - which returns nano.i586 but is slower than
rpm -qa | grep nano - which returns nano-2.0.6-6.fc11.i586
does this mean that is all that is returned? Ie, no long string of information as with dpkg -l?

Does fedora use - in package names? I need to know this for parsing remove commands, but it may not be required.

f you do: yum remove nano-2.0.6-6.fc11.i586 does that remove it?

if so, there will not be any problems, and I can simply use the entire string, which would be an ideal case.

For the first tests, I'm going to ignore nouvea completely, so the test system will need to already be ready for nvidia non free drivers, after that's debugged and working, the nouvea stuff can be handled.

What is the equivalent command to apt-cache policy, ie, I need to query rpm/yum to find if a package exists in the package pool, not the user system.

for now I'll use: yum list available "<package name>"
but if I understand that right, it's a wildcard search for anything containing that, can you see if using say: yum list available "logrotate" gives the expected outcome?

and paste the output, and for an error case: yum list available "grrrrrr"

Please note this: linux.die.net/man/8/yum


this is NOT equivalent to apt-get update.
Back to top

More: the output of this command:


Does fedora show: /usr/bin/gcc-4.3 or 4.4 or just /usr/bin/gcc

if /usr/bin/gcc exists, does:
readlink /usr/bin/gcc
show anything?

Is there a package mesa-glx, or anything with that in it?u (this is for fglrx, but might as well do that now).

Also, I'm not clear above, please reread the package names you entered compared to what you said about 586/686. Also, are 64 bit package names 686 or amd64 as in debian?

Always physically confirm ALL package names you type in by doing a simulate install of that precise name, copy and pasted in.

Forget about all Fedora's pre version 12, support starts now, and I am not going to worry about older fedoras.
Back to top

Contents of /etc/issue

Fedora release 11 (Leonidas)
Kernel \r on an \m (\l)

logrotate is installed.
patch is installed
fakeroot is installed

I find no occurrence of libstdc++5 or libstdc++6

linux-headers-$(uname -r) does not exist or comes up on yum list.

[root@Fedora11xps13 GoinEasy9]# X -version

X.Org X Server 1.6.3.901 (1.6.4 RC 1)
Release Date: 2009-8-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-164.el5 i686
Current Operating System: Linux Fedora11xps13 2.6.30.10-105.2.23.fc11.i686.PAE #1 SMP Thu Feb 11 07:05:37 UTC 2010 i686
Kernel command line: ro root=UUID=29f371ed-2c8e-499b-ac22-ddff335844cd rhgb quiet
Build Date: 09 September 2009 11:25:24AM
Build ID: xorg-x11-server 1.6.4-0.1.fc11
Before reporting problems, check wiki.x.org
to make sure that you have the latest version.


[root@Fedora11xps13 GoinEasy9]# rpm -qa | grep nvidia
nvidia-xconfig-1.0-1.fc11.i586
kmod-nvidia-2.6.30.10-105.2.16.fc11.i686.PAE-190.53-1.fc11.3.i686
xorg-x11-drv-nvidia-libs-190.53-1.fc11.i586
kmod-nvidia-PAE-190.53-1.fc11.4.i686
akmod-nvidia-190.53-1.fc11.i686
kmod-nvidia-2.6.30.10-105.2.13.fc11.i686.PAE-190.53-1.fc11.2.i686
kmod-nvidia-2.6.30.10-105.2.23.fc11.i686.PAE-190.53-1.fc11.4.i686
nvidia-settings-1.0-3.2.fc11.i586
xorg-x11-drv-nvidia-190.53-1.fc11.i586

when you say:
yum list | grep nano - which returns nano.i586 but is slower than
rpm -qa | grep nano - which returns nano-2.0.6-6.fc11.i586
does this mean that is all that is returned? Ie, no long string of information as with dpkg -l?
[root@Fedora11xps13 GoinEasy9]# yum list | grep nano
nano.i586 2.0.6-6.fc11 installed
[root@Fedora11xps13 GoinEasy9]# rpm -qa | grep nano
nano-2.0.6-6.fc11.i586

Does fedora use - in package names? I need to know this for parsing remove commands, but it may not be required.
If you mean like kmod-nvidia is a package name, yes.

If you do: yum remove nano-2.0.6-6.fc11.i586 does that remove it? Yes

apt-cache policy in yum/fedora is a question I've tried to answer since starting Fedora. I've been unsuccessful and have used other commands like yum list and waded through the verbosity, I'll try to confirm or narrow it down as soon as I can.

[root@Fedora11xps13 GoinEasy9]# yum list available "logrotate"
Loaded plugins: presto, protectbase, refresh-packagekit
2 packages excluded due to repository protections
Error: No matching Packages to list
[root@Fedora11xps13 GoinEasy9]# yum list available logrotate
Loaded plugins: presto, protectbase, refresh-packagekit
2 packages excluded due to repository protections
Error: No matching Packages to list
[root@Fedora11xps13 GoinEasy9]# yum list logrotate
Loaded plugins: presto, protectbase, refresh-packagekit
2 packages excluded due to repository protections
Installed Packages
logrotate.i586 3.7.8-3.fc11 @updates


[root@Fedora11xps13 GoinEasy9]# grep -Eio 'gcc[[:space:]]*version[[:space:]]*[4-6]\.[0-9]{1,2}' /proc/version | grep -Eo '[4-6]\.[0-9]{1,2}'
4.4
It returned 4.4 if that isn't clear.

if /usr/bin/gcc exists, (it does)
does:
readlink /usr/bin/gcc
show anything? (No) I click on it and nothing happens, Hope I'm not missing your instruction.


[root@Fedora11xps13 GoinEasy9]# rpm -qa mesa*
mesa-dri-drivers-7.6-0.1.fc11.i586
mesa-libGL-7.6-0.1.fc11.i586
mesa-libGL-devel-7.6-0.1.fc11.i586
mesa-libGLU-7.6-0.1.fc11.i586
mesa-libGLU-devel-7.6-0.1.fc11.i586
There is an experimental mesa-dri package showing 3D rendering both with Nvidia and Ati, This is Fedora 11, Fedora 12 doesn't have it but it is present in Fedora 13, I'm closely following it, I want to get rawhide up as soon as it's stable to see how it works.
BTW - I'm going to check all of these commands on my Fedora 12 desktop after I'm done here. I don't really see why any of the questions you asked should be different in Fedora 12. Sorry, I should have done all experiments on Fedora 12 first. As soon as I get into my Fedora 12 box I'll show you the difference between i586 and i686 file names and get you the exact names including the way they show in x86_64.

Any other questions? I'll be back soon to finish.
Back to top