service lightdm modifing /etc/alternatives/x86_64-linux-gnu_gl_conf

Question

I've installed nvidia-367 on my system (Ubuntu 16.04). For a reason i don't know, restarting the lightdm service leads to a modification of /etc/alternatives/x86_64-linux-gnu_gl_conf.

I run manually:

root@tron:~# update-alternatives --config x86_64-linux-gnu_gl_conf
There are 3 choices for the alternative x86_64-linux-gnu_gl_conf (providing /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf).

  Selection    Path                                       Priority   Status
------------------------------------------------------------
  0            /usr/lib/nvidia-367/ld.so.conf              8604      auto mode
  1            /usr/lib/nvidia-367-prime/ld.so.conf        8603      manual mode
  2            /usr/lib/nvidia-367/ld.so.conf              8604      manual mode
* 3            /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf   500       manual mode

Press  to keep the current choice[*], or type selection number: 0
update-alternatives: using /usr/lib/nvidia-367/ld.so.conf to provide /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf (x86_64-linux-gnu_gl_conf) in auto mode

and service lightdm restart ending up with:

There are 3 choices for the alternative x86_64-linux-gnu_gl_conf (providing /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf).

  Selection    Path                                       Priority   Status
------------------------------------------------------------
* 0            /usr/lib/nvidia-367/ld.so.conf              8604      auto mode
  1            /usr/lib/nvidia-367-prime/ld.so.conf        8603      manual mode
  2            /usr/lib/nvidia-367/ld.so.conf              8604      manual mode
  3            /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf   500       manual mode

Press  to keep the current choice[*], or type selection number: 

again. That problem is, that with the wrong ld.so.conf the nvidia driver can not be loaded:

/var/log/Xorg.0.log:

[  1649.307] (II) LoadModule: "nvidia"
[  1649.308] (WW) Warning, couldn't open module nvidia
[  1649.308] (II) UnloadModule: "nvidia"
[  1649.308] (II) Unloading nvidia
[  1649.308] (EE) Failed to load module "nvidia" (module does not exist, 0)

Any ideas what, where and why the restart touches these alternative-settings?

root@tron:~# dpkg -s nvidia-367 | grep 'Version'
Version: 367.57-0ubuntu0.16.04.1
root@tron:~# dpkg -s lightdm | grep 'Version'
Version: 1.18.3-0ubuntu1

P.S. I tried already to purge nvidia* and reinstalling the driver, without any success.

Answer 1

I was having the same issue with Dell Vostro 1500 (GeForce 8400M GS, the nvidia-340 driver) after updating to the recent Ubuntu 16.04.2. It took me almost a day to find out.

It turned out that after

• setting the alternatives back auto (i.e. nvidia proprietary drivers)
• running ldconfig
• and manually inserting the DRI modules (sudo modprobe nvidia_340 nvidia_340_uvm nvidiafb)

startx run from commandline started X correctly with the proprietary driver. Also the display manager when run manually (not as a systemd service) was using the proprietary driver.

After some more investigation it turned out that the culprit was the /usr/bin/gpu-manager (run via /lib/systemd/system/gpu-manager.service). Its log /var/log/gpu-manager.log was saying:

Looking for nvidia modules in /lib/modules/4.4.0-72-generic/updates/dkms
Found nvidia module: nvidia_340_uvm.ko
Is nvidia loaded? yes
Was nvidia unloaded? no
Is nvidia blacklisted? yes

And eventually it updated the alternatives to the mesa/ld.so.conf.

From this point on it was easy to find out that the nvidia-340 module was indeed blacklisted in /etc/modprobe.d/bumblebee.conf

This was apparently a leftover from a previous driver nvidia-304, which was using bumblebee. The nvidia-340 driver doesn't use bumblebee.

So simply deleting /etc/modprobe.d/bumblebee.conf solved the problem. The other alternative is to purge delete previous nvidia driver installation, as other tutorials say. Obviously I haven't sufficiently purged the previous driver installation...