Well, I solved this issue and it's almost too embarrassing to discuss, 
but I learn more by broadcasting my ignorance than trying to hide it.

This system is a multi-boot (SL6 mainly but also Ubuntu and Windows) 
that I use to develop and test cross platform apps.

I prefer ubutnu's grub-mkconfig because I haven't found anything like it 
on SL.  It searches all partitions, mounted or not for bootable images 
and adds them to the grub boot menu.

So what happened was I started my process with yum update which updated 
the kernel to 2.6.32-358.6.1.el6.x86_64 but didn't update the grub 
config so it was booting the old kernel 2.6.32-358.2.1.el6.x86_64

This confused not only me but also the nvidia install scripts. Rerunning 
the grub-mkconfig script in Ubuntu allowed me to run the installation of 
kmod-nvidia, nvdia-x11-drv, nvidia-x11-drv-32bit without issue.

A very red-faced apology for the red-herring,

Joe



On 04/25/2013 07:51 AM, Joseph Areeda wrote:
> On 04/25/2013 01:03 AM, John Pilkington wrote:
>> On 25/04/13 03:23, Joseph Areeda wrote:
>>> Here I am again.
>>>
>>> I have my system working well with nouveau drivers but I need to 
>>> install
>>> the nvidia drivers because I do do some GPU work.
>>>
>>> I tried installing kmod-nvidia and nvidia-x11-drv from ELREPO but X
>>> won't start.
>>>
>>> BTW - if this happens to you it is very helpful to set the boot 
>>> level to
>>> 3 so you can poke around.  Edit /etc/inittab and change the level in 
>>> the
>>> last line from 5 to 3.
>>>
>>> I reread the thread from a few weeks ago on this problem but didn't see
>>> any resolution.
>>>
>>> The error messages that seem pertinent are:
>>>
>>>  From /var/log/Xorg.0.log.old (I'm now running nouveau drivers)
>>>
>>>     [    45.437] (II) LoadModule: "glx"
>>>     [    45.449] (II) Loading
>>>     /usr/lib64/xorg/modules/extensions/nvidia/libglx.so
>>>     [    46.197] (II) Module glx: vendor="NVIDIA Corporation"
>>>     [    46.197]    compiled for 4.0.2, module version = 1.0.0
>>>     [    46.197]    Module class: X.Org Server Extension
>>>     [    46.197] (II) NVIDIA GLX Module  310.44  Wed Mar 27 15:10:55 
>>> PDT
>>>     2013
>>>     [    46.197] Loading extension GLX
>>>     [    46.197] (II) LoadModule: "nvidia"
>>>     [    46.206] (II) Loading 
>>> /usr/lib64/xorg/modules/drivers/nvidia_drv.so
>>>     [    46.269] (II) Module nvidia: vendor="NVIDIA Corporation"
>>>     [    46.269]    compiled for 4.0.2, module version = 1.0.0
>>>     [    46.269]    Module class: X.Org Video Driver
>>>     [    46.581] (EE) NVIDIA: Failed to load the NVIDIA kernel module.
>>>     Please check your
>>>     [    46.581] (EE) NVIDIA:     system's kernel log for additional
>>>     error messages.
>>>     [    46.581] (II) UnloadModule: "nvidia"
>>>     [    46.581] (II) Unloading nvidia
>>>     [    46.581] (EE) Failed to load module "nvidia" (module-specific
>>>     error, 0)
>>>     [    46.581] (EE) No drivers available.
>>>
>>> from /var/log/messages:
>>>
>>>     Apr 24 18:53:21 george kernel: nvidia: module license 'NVIDIA'
>>>     taints kernel.
>>>     Apr 24 18:53:21 george kernel: Disabling lock debugging due to
>>>     kernel taint
>>>     Apr 24 18:53:21 george kernel: NVRM: The NVIDIA probe routine was
>>>     not called for 1 device(s).
>>>     Apr 24 18:53:21 george kernel: NVRM: This can occur when a driver
>>>     such as nouveau, rivafb,
>>>     Apr 24 18:53:21 george kernel: NVRM: nvidiafb, or rivatv was loaded
>>>     and obtained ownership of
>>>     Apr 24 18:53:21 george kernel: NVRM: the NVIDIA device(s).
>>>     Apr 24 18:53:21 george kernel: NVRM: Try unloading the conflicting
>>>     kernel module (and/or
>>>     Apr 24 18:53:21 george kernel: NVRM: reconfigure your kernel 
>>> without
>>>     the conflicting
>>>     Apr 24 18:53:21 george kernel: NVRM: driver(s)), then try loading
>>>     the NVIDIA kernel module
>>>     Apr 24 18:53:21 george kernel: NVRM: again.
>>>     Apr 24 18:53:21 george kernel: NVRM: No NVIDIA graphics adapter 
>>> probed!
>>>
>>> Checking /etc/modprobe.d (with the nvidia drivers installed) showed
>>> those modules were either in bloacklist.conf or blacklist-nouveau.conf.
>>>
>>> I also tried
>>>
>>>     dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
>>>
>>> which has worked in the past when blacklist wasn't really blacklisting.
>>>
>>> I'm not sure I will be running 6.4 from now on.  It has not been tested
>>> with the rpms from our group.
>>>
>>> I'd appreciate any suggestions.
>>>
>>> Joe
>>>
>> I've just had what looks like a similar problem on Fedora 17, solved 
>> by editing the 'files' section of xorg.conf.  Modules sourced by 
>> X.org were being loaded instead of those from nvidia. Here's an 
>> extract from the thread (304.64) on rpmfusion-users.
>>
>>>> Section "Files"
>>>> #    ModulePath "/usr/lib64/xorg/modules/extensions/nvidia"
>>>>           ModulePath   "/usr/lib64/nvidia/xorg"
>>>> #    ModulePath   "/usr/lib64/xorg/modules/extensions"
>>>>     ModulePath   "/usr/lib64/xorg/modules"
>>>>     FontPath     "/usr/share/fonts/default/Type1"
>>>> EndSection
>>>>
>>>> as suggested here:
>>>>
>>>> http://forums.fedoraforum.org/showthread.php?t=286084
>>
>> John P
> Thanks for the suggestion John but that doesn't seem to be my problem 
> at least not exactly.
>
> Reading the thread and following the suggestions did not solve my 
> problem.  I believe that refers to a packaging issue with 304.64 and 
> the current ELREPO version is 310.44.  /etc/X11/xorg.conf was using 
> different paths and changing them to the ones suggested gave the same 
> errors.
>
> I don't seem to be able to go back 304 because I need the 32 bit 
> drivers also and those seem to only be available for the current 
> version.  I wish I didn't need to install 32 bit drivers but that's 
> not my program that uses them.
>
> My next straw to grasp is to try the drivers from nvidia even though I 
> hate to do it.  I had an issue a couple of years ago doing that on 
> ubuntu.  Seems their packagers put files in a different location than 
> nvidia.  So mixing the deb package and the run download ended up with 
> mismatched dynamic libraries which was a whole lotta fun tracking 
> down.  I mention that to remind myself what a bad idea it is to mix 
> the two.
>
> I'll report back if that works.
>
> Joe