nvidia 346.72 setup fails

opensuse 13.1 x86_64

after update of nvidia driver
i get a text console

i tried to start 2times but no effect

i tried to install again nvidia-gfx-G04 but no effect


in recovery mode i get no console
so now i use my old mandriva to communicate

i tried to install again nvidia-gfxG04-kmp-desktop and nvidia-uvm-gfxG04.kmp-desktop but no effect .

here is the Xorg.0.log


there is a curious thing

23.439] Module class: X.Org Server Extension
23.439] (II) NVIDIA GLX Module 346.59 Tue Mar 31 13:38:58 PDT 2015
23.449] Loading extension GLX

346.59 ? but this is 346.72 now . no ?

again later

23.485] ABI class: X.Org Video Driver, version 14.1
23.485] (II) NVIDIA dlloader X Driver 346.59 Tue Mar 31 13:17:41 PDT 2015
23.485] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

and this

23.648] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
23.648] (II) NVIDIA(0): may not be running or the “AcpidSocketPath” X
23.648] (II) NVIDIA(0): configuration option may not be set correctly. When the
23.648] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
23.648] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For
23.648] (II) NVIDIA(0): details, please see the “ConnectToAcpid” and
23.648] (II) NVIDIA(0): “AcpidSocketPath” X configuration options in Appendix B: X
23.648] (II) NVIDIA(0): Config Options in the README.
23.670] (II) NVIDIA(0): Setting mode “CRT-0:nvidia-auto-select”
23.760] Loading extension NV-GLX

It should be, yes. 346.72 is the current version in the repos.

again later

23.485] ABI class: X.Org Video Driver, version 14.1
23.485] (II) NVIDIA dlloader X Driver 346.59 Tue Mar 31 13:17:41 PDT 2015
23.485] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

Well, your Xorg driver (x11-video-nvidiaG04) seems to be still at 346.59 as well.

According to your package list, you do seem to have the 346.72 packages installed though.

Your Xorg log is from Fri May 29 10:07:16 2015 though.
Probably Xorg is quitting again before even trying to load?

As in your previous thread/problem, check again what you have in /etc/sysconfig/displaymanager. Is it still DISPLAYMANAGER_XSERVER=“Xorg”?
If not, change it to that.

and this

That should be irrelevant.

there is a curious thing

23.439] Module class: X.Org Server Extension
23.439] (II) NVIDIA GLX Module 346.59 Tue Mar 31 13:38:58 PDT 2015
23.449] Loading extension GLX

no more pb this is now 346.72


that was the pb .

all works now

thank you very much

Good. :slight_smile:

that was the pb .

Ok, the update changed it to use nvidia’s script again, which for some reason doesn’t seem to work on your system.

So if you have problems after the next update, please check this file first.

Unfortunately I see no way to prevent this change on updates…

an hypothesis about the origin of pb :

i use “kde sc current” and “kde sc current extra” then :
i get differents versions for kde packets

  • 4.11.3
  • 4.11.17
  • 4.13.3
  • 4.14.3
  • 4.14.6
  • 14.12.3

No, that’s normal.

And at that point during boot KDE is not involved at all anyway.

Your problem seems to be that nvidia’s X.x11-video-nvidiaG04 wrapper script quits before starting Xorg.
This should only happen because of this AFAICT:

  # rmmod nvidia_uvm first
   mods=$(lsmod | grep -v -E "nvidia_agp|nvidiafb" | grep -o -E "^(nvidia_uvm|nvidia|fglrx)" | sort -u | tac)   if  $? -eq 0 ]; then
     for m in ${mods}; do       # bail out, if an existing module cannot be unloaded
       # this can happen if a second Xsession starts
       /sbin/rmmod -v $m || exit 1

I.e the script tries to unload the kernel modules nvidia_uvm, nvidia, and fglrx first if loaded, and exits if unloading one of them fails.
But actually none of them should be loaded before Xorg starts, so that’s what seems to be wrong on your system.

The only way that could happen IMHO is when nvidia and/or nvidia_uvm is in the initrd (it/they will be loaded by plymouth then), which shouldn’t happen if NO_KMS_IN_INITRD=“yes” is set in /etc/sysconfig/kernel.
If it does, it might be a bug in mkinitrd (but I am not aware of such a bug), or you maybe have some non-standard mkinitrd script installed that puts nvidia into the initrd nonetheless.

If you want to investigate this further, here are some ideas:
Have a look at the output of lsinitrd (whether nvidia is present or not) and the output of mkinitrd (it should tell what graphics modules it puts into the initrd in a line “KMS drivers: xxx”).
Also have a look at the contents of /lib/mkinitrd/scripts/setup-kms.sh, it should have this at the end:

if  "$NO_KMS_IN_INITRD" != "yes" ] && pciids_on_system

Which means it doesn’t do anything if NO_KMS_IN_INITRD=“yes”.
This also implies that you should actually have set that in /etc/sysconfig/kernel of course, as you should know already anyway.

You could run “rpm -V mkinitrd” to see whether some script has been modified for whatever reason, no output means that all files are ok.

I would also check that there is no additional script in that directory, e.g. by running:

rpm -qf /lib/mkinitrd/scripts/* | grep own

And another idea I just had:
Verify that the nvidia module is neither specified in INITRD_MODULES="…" nor in MODULES_LOADED_ON_BOOT="…" (both are in /etc/sysconfig/kernel, although the latter one might not be there at all which would be ok)

PS: I just noticed that systemd-modules-load.service already existed in 13.1 (I thought it got introduced in 13.2…).
So also have a look in those directories whether they contain a file that specifies to load nvidia or nvidia-uvm:

Perhaps it’s nothing, but I notice that in my desktop oS 13.2 64-bits KDE 4.14.6, /etc/sysconfig/displaymanager display variables are all double quoted except the one quoted above, like this:

## Path:        Desktop/Display manager
## Type:        string(Xorg)
## Default:     "Xorg"
## Path:    Desktop/Display manager
## Description:    settings to generate a proper displaymanager config
## Type:    string(kdm,xdm,gdm,wdm,entrance,console,lightdm,sddm)
## Default:    ""
# Here you can set the default Display manager (kdm/xdm/gdm/wdm/entrance/console).
# all changes in this file require a restart of the displaymanager

## Type:    yesno
## Default:    no
# Allow remote access (XDMCP) to your display manager (xdm/kdm/gdm). Please note
# that a modified kdm or xdm configuration, e.g. by KDE control center
# will not be changed. For gdm, values will be updated after change.
# XDMCP service should run only on trusted networks and you have to disable
# firewall for interfaces, where you want to provide this service.
## Type:    yesno
## Default:    no
# Allow remote access of the user root to your display manager. Note
# that root can never login if DISPLAYMANAGER_SHUTDOWN is "auto" and
# System/Security/Permissions/PERMISSION_SECURITY is "paranoid"

## Type:    yesno
## Default:    yes

Obs: using driver version 340.65.

That’s irrelevant, as long as there are no spaces.

And where from/how did you install it? Probably “the hard way”…

The nvidia repo only has 340.76 at the moment, and the packages from that repo would change that entry to DISPLAYMANAGER=“X.x11-video-nvidiaG0X” on installation, which is a script that’s included in the packages.

You’d have to put a gun to my head first. If memory serves I tried “the hard way™” twice since I started using oS/nvidia. Once it sort of worked, the other time it completely borked my system.

Installed from the nvidia repo.

You should always fully uninstall before reinstalling using a different method.

But the packages from the repo do modify the DISPLAYMANAGER_XSERVER line in /etc/sysconfig/displaymanager on installation, to call the supplied wrapper script (X.x11-video-nvidiaG0X) instead of Xorg.
And they do that regardless whether there are quotes or not. The exact command is this:


But on second thought, it should work if you remove that line completely (Xorg is the default anyway), the packages won’t add/modify it then on updates because the sed doesn’t find anything to replace.
This is untested though, I cannot guarantee you that Xorg starts then (although it should)…

I only install from the nvidia repo. I don’t know why it’s different, I only know it is.
Mind you, this is a new / install of 13.2, not and upgrade or anything. Only /home was preserved.
The system works normally as is, obviously.

I only mentioned it because it might have some bearing in the OP’s problem.

I only install from the nvidia repo. I learned this a long time ago.

Well, /home definitely doesn’t have any influence on this either.

I have no idea why yours is set to Xorg (without quotes) then, as even the template shipped in 13.2 contains quotes.
And as I wrote, the nvidia packages change it when you install them, unless that line isn’t there in the first place.
So the only explanation I would have is that the line wasn’t there when you installed the nvidia packages and it only got added later by something, or something overwrote the line after you installed the nvidia packages.

And still, the current version in the repo is 340.76. Your system does not seem up to date (regarding the nvidia packages at least).
Probably if you install that update, you’ll have DISPLAYMANAGER_XSERVER=X.x11-video-nvidiaG03 as you should (and it should work).

But that’s all totally irrelevant to the OP’s problem/this thread anyway IMHO.

I’m wary of updating for update’s sake. NVidia repo does not keep previous versions, so if a downgrade is necessary I have to go "the Hard Way"TM that is not something I appreciate…
Besides, as the hardware gets older there’s usually no new functionality or corrections targeted at it, and for a desktop that doesn’t suspend or hibernate and where thermal throttling works as designed, I don’t see it as a must - quite the opposite, in fact.
From time to time, if I can afford to be without my main machine a day or two, and after checking out the fora for new driver related problems, I do upgrade it. And on new installs, obviously.

Next update, if ever, I’ll check it if I remember - which is not a sure thing nowadays. :wink:

Indeed it is. My apologies to the OP. :slight_smile:

Summing up, I’m inclined to follow the popular saying, if it’s not broken (*) don’t fix it. This, indeed, I learned ""the Hard Way"TM.

(*) - and it meets your needs, of course.