Nvidia not working for non-root user after upgrade to Leap 42.1

English Hardware
1

Hello,

I’ve got a problem with my nvidia graphics card (GeForce 7600).

I was using OpenSuSE 13.2 with no problem with the nouveau driver. However, the machine has a long history of upgrades of OpenSuSE and there was time in history I had been using original nvidia drivers.

After upgrade to Leap 42.1 and reboot the nouveau driver caused problems. I could see the graphical login screen, KDE started without apparent problems but soon after that yellow rectangles stared to appear on my monitor.

So I tried to install the nvidia drivers. I took the yast way of adding community repo for nvidia drivers. Then I installed the drivers with zypper inr as suggested on OpenSuSE pages which installed the G02 driver. The drivers installed ok and were loaded properly after reboot. I also added my non-root user to video group to give him access to /dev/nvidia* devices. I also had to remove some old libglx.so in some …/extensions/updates directory (if i remember it correctly), which was some old nvidia stuff from earlier installations.

Now, when I login to KDE, my plasmashell crashes with the following error:

Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0)

However, when I login as root, KDE starts without problems and works well.

This seems to me like a permission-related problem, maybe in combination with earlier nvidia drivers installations. Could it be some older .so is being loaded instead of the current one? How can I debug this?

Any help will be highly appreciated as the computer is not very usable now. I also prefer not to reinstall the whole machine as it would require a lot of setup of different software.

Thanks

2

Well, if it works as root, it’s likely a permission-related problem, yes. (or something wrong with the user’s settings)
If it was an installation problem (e.g. if some older .so would be loaded instead), it would affect root as well.

Please install the package “Mesa-demo-x” and post the output of:

glxinfo|grep render

Run it as affected user, even if plasmashell crashes, you may be able to run konsole or xterm via Alt+F2, or choose IceWM at the login screen.

Btw, adding your user to the video group should not be necessary since years, a local user should get the necessary permissions automatically at login by logind.

3

glxinfo fails with the following output:


X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  84
  Current serial number in output stream:  85

Edit: I ran glxinfo as the affected user from console with

DISPLAY=:0.0 glxinfo

The result is the same even without DISPLAY.

4

Can this be a hint? When the affected user was not a member of video group, there was an error line in plasmashell error output that said “Access denied to /dev/nvidiactl”. Maybe it is not the problem and probably it is not the core of the problem as I remember the line appeared after “Failed to create OpenGL context” message. But maybe it could lead us to library that can be used instead the right one. Is the error line expected to appear in nowadays output of plasmashell?

5

Hm, doesn’t look like a permission problem then…
What do you get when you run that logged in as root?

Can you please post /var/log/Xorg.0.log?
(upload it to http://susepaste.org/ or similar and post a link)

Also, please try to create a new user account and see whether it works there (glxinfo, that is).

6

Well, that definitely is a (permission) problem, yes, and would break OpenGL for that user.
So the affected user is member of the video group now?

Is the error line expected to appear in nowadays output of plasmashell?

No, it definitely isn’t.

7

glxinfo for root: SUSE Paste

Can you please post /var/log/Xorg.0.log?

Xorg.0.log: SUSE Paste

Also, please try to create a new user account and see whether it works there (glxinfo, that is).

glxinfo is the same for new user as for the affected user (fails).

Some more logs:

.xsession-errors-:0 (when user not in video group): SUSE Paste

.xsession-errors-:0 (when user in video group): SUSE Paste

.xsession-errors-:0 (for user root): SUSE Paste

8

Yes.

So why is it reporting access permission problems? logind? I do not know much about that.

9

Ok, so it is indeed working fine as root.

Xorg.0.log: SUSE Paste

The driver seems to be fine, and the correct libglx is loaded too.

glxinfo is the same for new user as for the affected user (fails).

Ok, so it’s not specific to this one user account, but rather a general problem.

Well, that’s what we need to find out.

Normally only members of the “video” group have direct access to the video hardware which is necessary for OpenGL to work e.g.
OTOH, it’s a security risk to put all users in every possible group that they may need.
So years ago, it was decided to not put users into other groups than “users” by default any more.

logind is a part of systemd, and amongst other things it takes care that when a user logs in locally, it will be granted the necessary permissions to access certain things.
Apparently this seems not to be working in your case.
But there’s another problem as well, as putting the user in the “video” group should still be enough.

So let’s check whether the login session is actually registered with logind:

loginctl

And what are the device permissions for the nvidia device files?

getfacl /dev/nvidia*

Also, which systemd version do you have installed?

rpm -qi systemd

And what exact nvidia package versions?

rpm -qa |grep nvidia
10

Thank you for your support and explanation. If it matters all the following output is from konsole that I started from root’s console session via command

DISPLAY=:0.0 sudo -uaffected-user konsole

loginctl


   SESSION        UID USER             SEAT            
         3          0 root             seat0           
         7       1004 new-user         seat0           
        25       1004 new-user         seat0           
        33       1004 new-user         seat0           
        35       1004 new-user         seat0           
        37       1004 new-user         seat0           
      6817       1001 other-user                       
      6839       1000 affected-user    seat0           


8 sessions listed.

getfacl /dev/nvidia*


# file: dev/nvidia0
# owner: root
# group: video
user::rw-
group::rw-
mask::rw-
other::---


# file: dev/nvidiactl
# owner: root
# group: video
user::rw-
group::rw-
mask::rw-
other::---

rpm -qi systemd


Name        : systemd
Version     : 210
Release     : 98.1
Architecture: x86_64
Install Date: Mon Oct 17 18:03:14 2016
Group       : System/Base
Size        : 12040162
License     : LGPL-2.1+
Signature   : RSA/SHA256, Fri Oct  7 18:33:07 2016, Key ID b88b2fd43dbdc284
Source RPM  : systemd-210-98.1.src.rpm
Build Date  : Fri Oct  7 18:31:21 2016
Build Host  : cloud117
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://www.freedesktop.org/wiki/Software/systemd
Summary     : A System and Session Manager
Description :
Systemd is a system and service manager, compatible with SysV and LSB
init scripts for Linux. systemd provides aggressive parallelization
capabilities, uses socket and D-Bus activation for starting services,
offers on-demand starting of daemons, keeps track of processes using
Linux cgroups, supports snapshotting and restoring of the system state,
maintains mount and automount points and implements an elaborate
transactional dependency-based service control logic. It can work as a
drop-in replacement for sysvinit.
Distribution: openSUSE Leap 42.1

rpm -qa |grep nvidia


nvidia-gfxG02-kmp-default-304.132_k4.1.12_1-42.1.x86_64
nvidia-computeG02-304.132-43.1.x86_64
x11-video-nvidiaG02-304.132-43.1.x86_64
11

No, you need to really login as that user.
The point is to check whether the user gets assigned the necessary permissions at login and this doesn’t happen when using sudo (on purpose).

getfacl /dev/nvidia*

file: dev/nvidia0

owner: root

group: video

user::rw-
group::rw-
mask::rw-
other::—

file: dev/nvidiactl

owner: root

group: video

user::rw-
group::rw-
mask::rw-
other::—

Your user indeed has no access.
But that’s because you only used sudo to switch to that user.

The question remains what happens when you really login.

And I’d like to ask how exactly you login. AIUI you use a display manager, i.e. you have a standard login screen, and are not e.g. running startx from text mode (which is unsupported and would bypass logind).
But what display manager/login screen are you using?
This can be set in /etc/sysconfig/displaymanager (the DISPLAYMANAGER=xxx line).

12

Logind adds rights correctly if I can tell as getfacl /dev/nvidia* after login adds the following line to both nvidia devices


user:affected-user:rw-

This means that we should forget about adding the user into video group as the standard process works well. The error appeared apparently only when I started plasmashell from root’s console via sudo.

And I’d like to ask how exactly you login. AIUI you use a display manager, i.e. you have a standard login screen, and are not e.g. running startx from text mode (which is unsupported and would bypass logind).
But what display manager/login screen are you using?
This can be set in /etc/sysconfig/displaymanager (the DISPLAYMANAGER=xxx line).

I’m using kdm. I tried sddm too the last week, which resulted in the same plasmashell crash as with kdm. Now, when I try sddm as display manager, I end up with a black screen instead of login screen. In journalctl I can see error “sddm-greeter: Failed to create OpenGL context for format …”

13

Looks good.

This means that we should forget about adding the user into video group as the standard process works well. The error appeared apparently only when I started plasmashell from root’s console via sudo.

Yes.

But then it’s even more strange that you get those “NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).” errors.

Well, let’s check which OpenGL libraries are actually used:

ldd /usr/bin/glxinfo

According to Google, that BadValue error can happen if trying to use nvidia’s OpenGL libraries with nouveau, but maybe also the other way round?

I’m using kdm. I tried sddm too the last week, which resulted in the same plasmashell crash as with kdm. Now, when I try sddm as display manager, I end up with a black screen instead of login screen. In journalctl I can see error “sddm-greeter: Failed to create OpenGL context for format …”

Likely the same problem, the sddm login screen runs as user sddm (not root), and uses QML which requires OpenGL.
It may be worth a try to use xdm instead though, as a test at least.

14

But then it’s even more strange that you get those “NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).” errors.

No, there are no more these messages. They appeared as I was getting the messages via sudo plasmashell. My mistake. Looking into xsession-errors now without video group membership there are no “NVIDIA: … /dev/nvidiactl (Permission denied)” any more. Sorry for misleading you.

ldd /usr/bin/glxinfo


        linux-vdso.so.1 (0x00007fff3d1ce000)
        libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f4236bf9000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f42368bb000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4236512000)
        libnvidia-tls.so.304.132 => /usr/lib64/tls/libnvidia-tls.so.304.132 (0x00007f423630f000)
        libnvidia-glcore.so.304.132 => /usr/lib64/libnvidia-glcore.so.304.132 (0x00007f4233f25000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f4233d12000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4233b0e000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f42338ee000)
        /lib64/ld-linux-x86-64.so.2 (0x0000561a156c5000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f42335ec000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f42333e8000)

All libraries seem good to me, libGL is from nvidia package:


# rpm -qf /usr/X11R6/lib64/libGL.so.1
x11-video-nvidiaG02-304.132-43.1.x86_64

According to Google, that BadValue error can happen if trying to use nvidia’s OpenGL libraries with nouveau, but maybe also the other way round?

I was looking into this earlier too, but it seems to me that all binaries I checked use nvidia libraries from current packages. I checked kwin and plasmashell.

I’ve also blacklisted nouveau module to be sure it is not loaded in /etc/modprobe.d/50-blacklist.conf, as suggested by nvidia:


blacklist nouveau
options nouveau modeset=0

Likely the same problem, the sddm login screen runs as user sddm (not root), and uses QML which requires OpenGL.

Yes, exactly.

It may be worth a try to use xdm instead though, as a test at least.

Behaves the same.

The question we cannot answer now is why OpenGL does not work for non-root user when we know that

  • it works for root without problems,
  • logind sets proper access rights to /dev/nvidia* drivers to logged-in user,
  • nvidia kernel module loads properly,
  • the binaries are using nvidia libraries from the current (latest) nvidia packages.

(I’ve also tested access rights to /dev/nvidia*by replacing sddm-greeter with a wrapper that inspected access rights on those devices. Both had correct rights for sddm user.)

15

Ok, so there never was (and still isn’t) a device access permission problem.

I was looking into this earlier too, but it seems to me that all binaries I checked use nvidia libraries from current packages. I checked kwin and plasmashell.

Yes, that looks fine.

I’ve also blacklisted nouveau module to be sure it is not loaded in /etc/modprobe.d/50-blacklist.conf, as suggested by nvidia:

That’s not necessary, as the rpm packages already do that.
And you’d need to run mkinitrd afterwards for full effect.

Try to add “nomodeset” to the kernel boot options to rule out any problem with the blacklist.
This would have effect already before the root partition is mounted.
I.e. press ‘e’ at the boot menu screen and append “nomodeset” to the line starting with “linux” or “linuxefi”, then press F10 to boot.
If it helps, you can add it permanently in YaST->System->Boot Loader e.g.

But that shouldn’t be necessary normally.

The question we cannot answer now is why OpenGL does not work for non-root user when we know that

  • it works for root without problems,
  • logind sets proper access rights to /dev/nvidia* drivers to logged-in user,
  • nvidia kernel module loads properly,
  • the binaries are using nvidia libraries from the current (latest) nvidia packages.

Correct.

The only way I could explain this would be a difference in the user’s environment (compared to root’s), or some config file. But we already ruled out the latter by trying a fresh user account.
FWIW, I found this, which suggests that this error occurs when trying to use indirect rendering with nvidia:

Of course I’m not sure if you have exactly the same problem, but at least it would sound plausible.

The question then would be what cause indirect rendering to be used though.

Could you please post the output of “env” (again run as user in the user’s session), maybe I spot something.
Also, do you have any extra files in /etc/skel/?

ls -la /etc/skel

Another thing I know that causes problems with the nvidia driver is libvdpau_va_gl1, though this should only affect video playback (and starting nvidia-settings) AFAIK.
Still, look if you have it installed and remove it in this case.

16

Exactly.

That’s not necessary, as the rpm packages already do that.
And you’d need to run mkinitrd afterwards for full effect.

OK. I didn’t notice nvidia-default.conf.

Try to add “nomodeset” to the kernel boot options to rule out any problem with the blacklist.
This would have effect already before the root partition is mounted.
I.e. press ‘e’ at the boot menu screen and append “nomodeset” to the line starting with “linux” or “linuxefi”, then press F10 to boot.

No change.

FWIW, I found this, which suggests that this error occurs when trying to use indirect rendering with nvidia:
https://devtalk.nvidia.com/default/topic/891349/quadro-k600-x_glxcreatecontext-issue/?offset=8
Of course I’m not sure if you have exactly the same problem, but at least it would sound plausible.

No change.

Could you please post the output of “env” (again run as user in the user’s session), maybe I spot something.


ALSA_CONFIG_PATH=/etc/alsa-pulse.conf
AUDIODRIVER=pulseaudio
CLASSPATH=/usr/share/fop-0.20.5/hyph
COLORTERM=1
CONFIG_SITE=/usr/share/site/x86_64-unknown-linux-gnu
CPU=x86_64
CSHEDIT=emacs
CVS_RSH=ssh
FROM_HEADER=
GPG_TTY=/dev/tty1
G_BROKEN_FILENAMES=1
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
HISTSIZE=1000
HOME=/home/test
HOST=linpok
HOSTNAME=linpok
HOSTTYPE=x86_64
INPUTRC=/home/test/.inputrc
JAVACMD=/usr/bin/java
JAVA_BINDIR=/usr/lib64/jvm/java/bin
JAVA_HOME=/usr/lib64/jvm/java
JAVA_ROOT=/usr/lib64/jvm/java
JDK_HOME=/usr/lib64/jvm/java
JRE_HOME=/usr/lib64/jvm/java/jre
LANG=en_US.UTF-8
LESS=-M -I -R
LESSCLOSE=lessclose.sh %s %s
LESSKEY=/etc/lesskey.bin
LESSOPEN=lessopen.sh %s
LESS_ADVANCED_PREPROCESSOR=no
LOGNAME=test
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.xz=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
LS_OPTIONS=-N --color=tty -T 0
MACHTYPE=x86_64-suse-linux
MAIL=/var/mail/test
MANPATH=/usr/local/man:/usr/local/share/man:/usr/share/man
MINICOM=-c on
MORE=-sl
NLS_LANG=ENGLISH_AMERICA.AL32UTF8
NNTPSERVER=news
NO_PROXY=localhost,127.0.0.1,intra.excon.cz,virt.excon.cz,.local,192.168.8.0/24,192.168.16.0/24,192.168.10.0/24,10.0.0.0/8
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
OSTYPE=linux
PAGER=less
PATH=/home/test/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/kde3/bin:/usr/local/alex-tools/bin:/usr/local/node/bin
PROFILEREAD=true
PWD=/home/test
PYTHONSTARTUP=/etc/pythonstart
QEMU_AUDIO_DRV=pa
QT_SYSTEM_DIR=/usr/share/desktop-data
SDK_HOME=/usr/lib64/jvm/java
SDL_AUDIODRIVER=pulse
SHELL=/bin/bash
SHLVL=1
SOCKS5_SERVER=
SOCKS_PROXY=
TERM=xterm-256color
USER=test
WINDOWMANAGER=/usr/bin/startkde
XCURSOR_THEME=DMZ
XDG_CONFIG_DIRS=/etc/xdg
XDG_DATA_DIRS=/usr/local/share:/usr/share:/opt/602filler/share
XDG_RUNTIME_DIR=/run/user/1004
XDG_SEAT=seat0
XDG_SESSION_COOKIE=c20d183762ffa6fd2d64f2aa0000021f-1477991885.95058-707097776
XDG_SESSION_ID=1381
XDG_VTNR=1
XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
XNLSPATH=/usr/share/X11/nls
ftp_proxy=http://10.2.3.4:4480
gopher_proxy=
http_proxy=http://10.2.3.4:4480
https_proxy=http://10.2.3.4:4480
no_proxy=localhost,127.0.0.1,intra.excon.cz,virt.excon.cz,.local,192.168.8.0/24,192.168.16.0/24,192.168.10.0/24,10.0.0.0/8
socks_proxy=
BASH_FUNC_mc()=() {  . /usr/share/mc/mc-wrapper.sh
}
_=/usr/bin/env

I compared test user’s env to root’s env and didn’t spot anything. Root’s env


ALSA_CONFIG_PATH=/etc/alsa-pulse.conf
AUDIODRIVER=pulseaudio
CLASSPATH=/usr/share/fop-0.20.5/hyph
COLORTERM=1
CONFIG_SITE=/usr/share/site/x86_64-unknown-linux-gnu
CPU=x86_64
CSHEDIT=emacs
CVS_RSH=ssh
FROM_HEADER=
GPG_TTY=/dev/tty2
G_BROKEN_FILENAMES=1
HISTSIZE=1000
HOME=/root
HOST=linpok
HOSTNAME=linpok
HOSTTYPE=x86_64
INPUTRC=/etc/inputrc
JAVACMD=/usr/bin/java
JAVA_BINDIR=/usr/lib64/jvm/java/bin
JAVA_HOME=/usr/lib64/jvm/java
JAVA_ROOT=/usr/lib64/jvm/java
JDK_HOME=/usr/lib64/jvm/java
JRE_HOME=/usr/lib64/jvm/java/jre
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LESS=-M -I -R
LESSCLOSE=lessclose.sh %s %s
LESSKEY=/etc/lesskey.bin
LESSOPEN=lessopen.sh %s
LESS_ADVANCED_PREPROCESSOR=no
LOGNAME=root
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.xz=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
LS_OPTIONS=-A -N --color=tty -T 0
MACHTYPE=x86_64-suse-linux
MAIL=/var/mail/root
MANPATH=/usr/share/man:/usr/local/man:/usr/local/share/man
MINICOM=-c on
MORE=-sl
NLS_LANG=ENGLISH_AMERICA.AL32UTF8
NNTPSERVER=news
NO_PROXY=localhost,127.0.0.1,intra.excon.cz,virt.excon.cz,.local,192.168.8.0/24,192.168.16.0/24,192.168.10.0/24,10.0.0.0/8
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
OSTYPE=linux
PAGER=less
PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/opt/kde3/bin:/usr/local/alex-tools/bin:/usr/local/node/bin
PROFILEREAD=true
PWD=/root
PYTHONSTARTUP=/etc/pythonstart
QEMU_AUDIO_DRV=pa
QT_SYSTEM_DIR=/usr/share/desktop-data
SDK_HOME=/usr/lib64/jvm/java
SDL_AUDIODRIVER=pulse
SHELL=/bin/bash
SHLVL=1
SOCKS5_SERVER=
SOCKS_PROXY=
TERM=xterm-256color
USER=root
WINDOWMANAGER=/usr/bin/startkde
XCURSOR_THEME=DMZ
XDG_CONFIG_DIRS=/etc/xdg
XDG_DATA_DIRS=/usr/local/share:/usr/share:/opt/602filler/share
XDG_RUNTIME_DIR=/run/user/0
XDG_SEAT=seat0
XDG_SESSION_COOKIE=c20d183762ffa6fd2d64f2aa0000021f-1477927288.421755-65194054
XDG_SESSION_ID=17
XDG_VTNR=2
XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
XNLSPATH=/usr/share/X11/nls
ftp_proxy=http://10.2.3.4:4480
gopher_proxy=
http_proxy=http://10.2.3.4:4480
https_proxy=http://10.2.3.4:4480
no_proxy=localhost,127.0.0.1,intra.excon.cz,virt.excon.cz,.local,192.168.8.0/24,192.168.16.0/24,192.168.10.0/24,10.0.0.0/8
socks_proxy=
BASH_FUNC_mc()=() {  . /usr/share/mc/mc-wrapper.sh
}
_=/usr/bin/env

Also, do you have any extra files in /etc/skel/?

ls -la /etc/skel


/etc/skel:
total 84
drwxr-xr-x   8 root root  4096 Nov  1 10:08 .
drwxr-xr-x 164 root root 12288 Nov  1 10:32 ..
-rw-------   1 root root     0 May 18  1996 .bash_history
-rw-r--r--   1 root root  1177 May 27 12:07 .bashrc
drwx------   2 root root  4096 Sep 30  2015 .config
-rw-r--r--   1 root root   315 Sep 30  2015 .dvipsrc
-rw-r--r--   1 root root  1637 Sep 11  2014 .emacs
drwxr-xr-x   2 root root  4096 Sep 30  2015 .fonts
-rw-r--r--   1 root root   305 Sep 30  2015 .i18n
-rw-r--r--   1 root root   861 Sep 11  2014 .inputrc
drwx------   2 root root  4096 Sep 30  2015 .local
-rw-r--r--   1 root root  6043 Oct 25  2015 .muttrc
-rw-r--r--   1 root root  1028 May 27 12:07 .profile
-rw-r--r--   1 root root   311 Sep 11  2015 .urlview
-rw-r--r--   1 root root  1952 Sep 30  2015 .xim.template
-rwxr-xr-x   1 root root  1112 Sep 24  2015 .xinitrc.template
drwxr-xr-x   2 root root  4096 Jun 12  2015 Desktop
drwxr-xr-x   2 root root  4096 Sep 30  2015 bin
drwxr-xr-x   2 root root  4096 Oct 18 13:49 public_html

/etc/skel/.config:
total 8
drwx------ 2 root root 4096 Sep 30  2015 .
drwxr-xr-x 8 root root 4096 Nov  1 10:08 ..

/etc/skel/.fonts:
total 8
drwxr-xr-x 2 root root 4096 Sep 30  2015 .
drwxr-xr-x 8 root root 4096 Nov  1 10:08 ..

/etc/skel/.local:
total 8
drwx------ 2 root root 4096 Sep 30  2015 .
drwxr-xr-x 8 root root 4096 Nov  1 10:08 ..
                                                                                                                                         
/etc/skel/Desktop:                                                                                                                       
total 8                                                                                                                                  
drwxr-xr-x 2 root root 4096 Jun 12  2015 .                                                                                               
drwxr-xr-x 8 root root 4096 Nov  1 10:08 ..                                                                                              
                                                                                                                                         
/etc/skel/bin:                                                                                                                           
total 8                                                                                                                                  
drwxr-xr-x 2 root root 4096 Sep 30  2015 .                                                                                               
drwxr-xr-x 8 root root 4096 Nov  1 10:08 ..                                                                                              
                                                                                                                                         
/etc/skel/public_html:                                                                                                                   
total 12                                                                                                                                 
drwxr-xr-x 2 root root 4096 Oct 18 13:49 .                                                                                               
drwxr-xr-x 8 root root 4096 Nov  1 10:08 ..                                                                                              
-rw-r--r-- 1 root root   48 Nov 14  2014 .directory

Another thing I know that causes problems with the nvidia driver is libvdpau_va_gl1, though this should only affect video playback (and starting nvidia-settings) AFAIK.
Still, look if you have it installed and remove it in this case.

It was installed. Now it is not. No change even after reboot.

To get a working environment I installed enlightment and I’m using it with OpenGL off until we get it fixed.

17

Hm, I don’t spot anything obvious in there either, nor in the list of /etc/skel/.

Another thing came to my mind though:
Maybe it is in fact a permission issue, but not about the device files (/dev/nvidia*), but rather some other nvidia files.
I.e. root may be able to load some nvidia library, but the user(s) not.

ls -l /usr/X11R6/lib64

Should not happen normally (unless you manually modified some file permissions), so I’m not confident at all that this is the case…

18

Hello all,

I have the same problem with a Nvidia card Geforce 6200 TurboCache

I have try with openSuse driver and with Nvidia driver. With both I had the same problem: with non privileged user graphic applications that use OpenGL does not work, with root user they work correctly.

To probe the suggestions i use glxinfo and glxgears.

Some moths ago all work correctly but now not.

Any suggestion?

Yours sincerely,
Miguel.

19

No more ideas?

Is there a way to find out what causes the OpenGL error? Some sort of OpenGL debuging?

20

Post the output of glxinfo (run as user).

Well, there are some debug options/environment variables for Mesa, but I have no idea about nvidia (which replaces Mesa with its own proprietary closed-source stuff).

Have you checked the file permissions?