This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 626559 - Wrong permissions on /dev/dri
Wrong permissions on /dev/dri
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
: Reopened
: 633121 655309 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-23 16:12 EDT by atswartz
Modified: 2010-11-22 05:18 EST (History)
17 users (show)

See Also:
Fixed In Version: dracut-008-0.10.gitb2415f4.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-18 18:11:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
compiz screenshot (1.20 MB, image/png)
2010-08-23 16:12 EDT, atswartz
no flags Details
glxinfo (14.20 KB, text/plain)
2010-08-23 23:19 EDT, atswartz
no flags Details
F14 glxinfo (17.23 KB, text/plain)
2010-08-23 23:30 EDT, atswartz
no flags Details
boot.log for 2.6.36-rc3-dirty (3.51 KB, text/plain)
2010-09-06 14:12 EDT, atswartz
no flags Details
boot.log for 2.6.36-0.16.rc3.git0 (651 bytes, text/plain)
2010-09-06 14:14 EDT, atswartz
no flags Details
dmesg for 2.6.36-rc3-dirty (29.85 KB, text/plain)
2010-09-06 14:14 EDT, atswartz
no flags Details
dmesg for 2.6.36-0.16.rc3.git0 (44.38 KB, text/plain)
2010-09-06 14:15 EDT, atswartz
no flags Details
2.6.36-rc3-dirty .config (57.30 KB, text/plain)
2010-09-06 14:17 EDT, atswartz
no flags Details
working config for 2.6.36-0.18.rc3.git1 (60.06 KB, application/octet-stream)
2010-09-09 16:14 EDT, atswartz
no flags Details
working config for 2.6.36-0.18.rc3.git1 with working selinux (60.27 KB, application/octet-stream)
2010-09-09 17:15 EDT, atswartz
no flags Details
latest working config for 2.6.36-0.23 (60.61 KB, application/octet-stream)
2010-09-20 18:09 EDT, atswartz
no flags Details
2.6.36-1 config (60.55 KB, application/octet-stream)
2010-11-08 17:40 EST, atswartz
no flags Details

  None (edit)
Description atswartz 2010-08-23 16:12:52 EDT
Created attachment 440473 [details]
compiz screenshot

Description of problem:
reports "Accelerated 3D graphics is not available Desktop effects require hardware 3D support" when compiz is active and operational
 

Version-Release number of selected component (if applicable):
desktop-effects-0.8.7-2.fc14.x86_64

How reproducible:
every time

Steps to Reproduce:
1.select System>Preferences>Desktop Effects
2.
3.
  
Actual results:
see screenshot

Expected results:

the selection screen 
Additional info:
Comment 1 Owen Taylor 2010-08-23 16:19:58 EDT
Please provide information about your graphics hardware and drivers, and attach (as an attachment) the output of glxinfo.
Comment 2 atswartz 2010-08-23 23:19:04 EDT
Created attachment 440547 [details]
glxinfo
Comment 3 atswartz 2010-08-23 23:21:11 EDT
description: 	VGA compatible controller
product: 	RV630 [Radeon HD 2600XT]
vendor: 	ATI Technologies Inc
xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14.x86_64
xorg-x11-server-common-1.9.0-1.fc15.x86_64
xorg-x11-server-Xorg-1.9.0-1.fc15.x86_64
desktop-effects-0.8.7-2.fc14.x86_64
mesa-libGL-7.9-0.6.fc14.x86_64
mesa-libGLU-devel-7.9-0.6.fc14.x86_64
mesa-libGLU-7.9-0.6.fc14.x86_64
mesa-libGL-devel-7.9-0.6.fc14.x86_64
mesa-dri-drivers-7.9-0.6.fc14.x86_64
mesa-dri-drivers-experimental-7.9-0.6.fc14.x86_64
compiz-fusion-extras-0.8.6-1.fc14.x86_64
compizconfig-backend-gconf-0.8.4-4.fc14.x86_64
compiz-fusion-unsupported-gnome-0.8.4-4.fc14.x86_64
libcompizconfig-0.8.4-3.fc14.x86_64
compiz-0.8.6-3.fc15.x86_64
compiz-fusion-unsupported-0.8.4-4.fc14.x86_64
compiz-fusion-0.8.6-1.fc14.x86_64
compiz-manager-0.6.0-10.fc12.noarch
compizconfig-python-0.8.4-3.fc14.x86_64
compiz-fusion-extras-gnome-0.8.6-1.fc14.x86_64
compiz-gnome-0.8.6-3.fc15.x86_64
compiz-fusion-gnome-0.8.6-1.fc14.x86_64
Comment 4 atswartz 2010-08-23 23:29:18 EDT
(In reply to comment #2)
> Created attachment 440547 [details]
> glxinfo
from F14 on same machine
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV630 9588) 20090101  TCL DRI2
OpenGL version string: 2.0 Mesa 7.9-devel
OpenGL shading language version string: 1.10
Comment 5 atswartz 2010-08-23 23:30:22 EDT
Created attachment 440550 [details]
F14 glxinfo
Comment 6 Yanko Kaneti 2010-08-24 03:08:45 EDT
On a couple of my (f14+rawhide mix) machines /dev/dri ends up with 0750 permissions and no acl for the current user, unlike /dev/dri/card0. Which can also lead to this. 
I haven't tracked what exactly changed in the kernel/udev/radon/mesa/consolekit setup that lead to this.
Comment 7 atswartz 2010-08-24 12:01:45 EDT
(In reply to comment #6)
> On a couple of my (f14+rawhide mix) machines /dev/dri ends up with 0750
> permissions and no acl for the current user, unlike /dev/dri/card0. Which can
> also lead to this. 
> I haven't tracked what exactly changed in the kernel/udev/radon/mesa/consolekit
> setup that lead to this.

Yes, permissions are 755 on /dev/dri on the working partition(F14)
and they are 750 on rawhide
Comment 8 Owen Taylor 2010-08-24 13:13:32 EDT
desktop-effects is perfectly right:

 OpenGL renderer string: Software Rasterizer

Don't know why permissions on /dev/dri aren't right. Reassigning to ConsoleKit, which at least in the past used to set the perms there, according to consensus on 
#fedora-desktop.
Comment 9 atswartz 2010-08-24 14:20:46 EDT
[andrew@790x ~]$ rpm -qa|grep Console
ConsoleKit-0.4.1-5.fc13.x86_64
ConsoleKit-libs-0.4.1-5.fc13.x86_64
ConsoleKit-x11-0.4.1-5.fc13.x86_64
Comment 10 Fedora Admin XMLRPC Client 2010-08-24 18:18:43 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 atswartz 2010-08-27 10:55:37 EDT
could this possibly be a udev problem?
Comment 12 atswartz 2010-09-04 21:34:54 EDT
(In reply to comment #4)
> (In reply to comment #2)
> > Created attachment 440547 [details] [details]
> > glxinfo
> from F14 on same machine
> OpenGL vendor string: Advanced Micro Devices, Inc.
> OpenGL renderer string: Mesa DRI R600 (RV630 9588) 20090101  TCL DRI2
> OpenGL version string: 2.0 Mesa 7.9-devel
> OpenGL shading language version string: 1.10

I just updated the above install to rawhide and now have
[andrew@790x ~]$ glxinfo|grep OpenGL
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.9-devel
OpenGL shading language version string: 1.20
OpenGL extensions:
[andrew@790x dev]$ ls -al|grep dri
drwxr-x---.  2 root root          80 Sep  4 15:29 dri
Comment 13 atswartz 2010-09-04 21:40:35 EDT
This cannot be a ConsoleKit bug because my ConsoleKit packages did not change, yet the permissions on /dev/dri did change.
Comment 14 Adel Gadllah 2010-09-05 10:19:59 EDT
(In reply to comment #13)
> This cannot be a ConsoleKit bug because my ConsoleKit packages did not change,
> yet the permissions on /dev/dri did change.

It might be a change somewhere that causes ConsoleKit to set the wrong permissions. But udev is *not* responsible for setting the correct permissions here, ConsoleKit is, hence why assigning it to udev does not make much sense.
Comment 15 Lennart Poettering 2010-09-06 05:31:11 EDT
It's i's udev's udev-acl tool which adjusts the permissions properly. Reassigning.
Comment 16 Harald Hoyer 2010-09-06 05:51:56 EDT
(In reply to comment #15)
> It's i's udev's udev-acl tool which adjusts the permissions properly.
> Reassigning.

Huh? not really... udev-acl sets ACL... not unix file modes.

We might need a udev rules syntax for directory ownership and permission.

It might be, that the kernel itself set the permission via devtmpfs.
Comment 17 atswartz 2010-09-06 14:12:53 EDT
Created attachment 443344 [details]
boot.log for 2.6.36-rc3-dirty
Comment 18 atswartz 2010-09-06 14:14:00 EDT
Created attachment 443345 [details]
boot.log for 2.6.36-0.16.rc3.git0
Comment 19 atswartz 2010-09-06 14:14:46 EDT
Created attachment 443346 [details]
dmesg for 2.6.36-rc3-dirty
Comment 20 atswartz 2010-09-06 14:15:28 EDT
Created attachment 443347 [details]
dmesg for 2.6.36-0.16.rc3.git0
Comment 21 atswartz 2010-09-06 14:17:21 EDT
Created attachment 443348 [details]
2.6.36-rc3-dirty .config
Comment 22 atswartz 2010-09-06 14:25:51 EDT
I just compiled an upstream kernel that sets the proper permissions on /dev/dri

I have attached the boot.log and dmesg files along with the .config for the
working kernel.  Among the notable differences were
a)2.6.36-rc3-dirty
b)2.6.36-0.16.rc3.git0
a)Starting udev: Starting Huge Pages File System...
  OK
b)Starting udev: udevd[419]: matchpathcon(/dev/hugepages) failed
a)dracut: Loading SELinux policy
dracut: /sbin/load_policy: Can't load policy: No such device
b)dracut: Loading SELinux policy
type=1404 audit(1283772614.398:2): enforcing=1 old_enforcing=0 auid=4294967295
ses=4294967295
Comment 23 atswartz 2010-09-06 15:36:03 EDT
Furthermore, I just booted 2.6.35.4-12.fc14.x86_64 #1 SMP Fri Aug 27 07:45:05 UTC 2010 and the permissions are also set properly.  So it is a kernel problem, no?
Comment 24 Harald Hoyer 2010-09-07 04:34:10 EDT
(In reply to comment #23)
> Furthermore, I just booted 2.6.35.4-12.fc14.x86_64 #1 SMP Fri Aug 27 07:45:05
> UTC 2010 and the permissions are also set properly.  So it is a kernel problem,
> no?

looks like it
Comment 25 atswartz 2010-09-09 16:13:27 EDT
The problem seems to be in the .config of the latest kernels.  I recompiled 2.6.36-0.18.rc3.git1 and the permissions are set properly I am attaching the .config that I used as config-2.6.36-0.18.rc3.git1.20100909se.fc15
Comment 26 atswartz 2010-09-09 16:14:37 EDT
Created attachment 446364 [details]
working config for 2.6.36-0.18.rc3.git1
Comment 27 atswartz 2010-09-09 17:14:09 EDT
OK, I screwed up that previous kernel and selinux was disabled, but I made another one that works all around. 
[ats@asus ~]$ uname -a
Linux asus 2.6.36-0.18.rc3.git1.20100909se2.fc15.x86_64 #1 SMP PREEMPT Thu Sep 9 15:54:22 CDT 2010 x86_64 x86_64 x86_64 GNU/Linux
[ats@asus ~]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
[ats@asus ~]$ glxinfo|grep OpenGL
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV670 9501) 20090101  TCL DRI2
OpenGL version string: 2.1 Mesa 7.9-devel
OpenGL shading language version string: 1.20
OpenGL extensions:
[ats@asus ~]$ rpm -qa|grep selinux-policy
selinux-policy-doc-3.9.3-3.fc15.noarch
selinux-policy-targeted-3.9.3-3.fc15.noarch
selinux-policy-mls-3.9.3-3.fc15.noarch
selinux-policy-3.9.3-3.fc15.noarch
selinux-policy-minimum-3.9.3-3.fc15.noarch
Comment 28 atswartz 2010-09-09 17:15:19 EDT
Created attachment 446378 [details]
working config for 2.6.36-0.18.rc3.git1 with working selinux
Comment 29 Yanko Kaneti 2010-09-13 03:20:22 EDT
*** Bug 633121 has been marked as a duplicate of this bug. ***
Comment 30 atswartz 2010-09-18 01:04:01 EDT
I was also experiencing this bug ( https://bugzilla.redhat.com/show_bug.cgi?id=634239 ,) before compiling my own kernels.
Comment 31 atswartz 2010-09-20 18:09:39 EDT
Created attachment 448563 [details]
latest working config for 2.6.36-0.23
Comment 32 atswartz 2010-09-22 17:19:19 EDT
This difference may be enough.
< # CONFIG_LOCKUP_DETECTOR is not set
< # CONFIG_HARDLOCKUP_DETECTOR is not set
> CONFIG_LOCKUP_DETECTOR=y
> CONFIG_HARDLOCKUP_DETECTOR=y
Comment 33 atswartz 2010-09-22 19:09:53 EDT
(In reply to comment #32)
> This difference may be enough.
> < # CONFIG_LOCKUP_DETECTOR is not set
> < # CONFIG_HARDLOCKUP_DETECTOR is not set
> > CONFIG_LOCKUP_DETECTOR=y
> > CONFIG_HARDLOCKUP_DETECTOR=y
No makes no difference.  This was to try and remedy https://bugzilla.redhat.com/show_bug.cgi?id=634239 not this bug anyway.
Comment 34 Sean Middleditch 2010-10-08 18:08:14 EDT
Just as an update, this is still happening on Rawhide for me today.  kernel and udev versions running:

kernel-2.6.36-0.32.rc6.git2.fc15.x86_64
udev-161-4.fc15.x86_64
Comment 35 atswartz 2010-10-12 11:06:59 EDT
(In reply to comment #34)
> Just as an update, this is still happening on Rawhide for me today.  kernel and
> udev versions running:
> 
> kernel-2.6.36-0.32.rc6.git2.fc15.x86_64
> udev-161-4.fc15.x86_64

I believe that it is a kernel problem, since the problem does not occur when booting a f14 kernel in Rawhide and it does occur when booting a Rawhide kernel in f14.  I have not tried a kernel that I did not compile myself for quite awhile, I am using kernel-2.6.36-0.35.rc7.git0.20101006.fc15.x86_64 now.

When the next version hits koji, I will try the standard version.
Comment 36 atswartz 2010-10-16 20:09:11 EDT
I have just tested kernel-2.6.36-0.39.rc8.git0.fc15.x86_64 and the problem persists.  No problems with custom compiled kernels.
Comment 37 Sean Middleditch 2010-10-21 02:32:56 EDT
Definitely still happening for me too.  I note that the /dev/dri and /dev/dri/* files are now set with the group 'video' instead of just root, but my user never is added to the video group by ConsoleKit.  (I think that's how it's supposed to work.  I lost track when people decided to redesign the Linux bootup/login system to require 37 daemons arbitrarily using umpteen different configuration file formats, almost none of which are documented thoroughly.)
Comment 38 Harald Hoyer 2010-10-26 05:54:23 EDT
(In reply to comment #37)
> Definitely still happening for me too.  I note that the /dev/dri and /dev/dri/*
> files are now set with the group 'video' instead of just root, but my user
> never is added to the video group by ConsoleKit.  (I think that's how it's
> supposed to work.  I lost track when people decided to redesign the Linux
> bootup/login system to require 37 daemons arbitrarily using umpteen different
> configuration file formats, almost none of which are documented thoroughly.)

It's _not_ done via groups and normal unix permissions! It's done via ACLs.

$ getfacl /dev/dri/card0
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
user:harald:rw-                  <--------------------------
group::rw-
mask::rw-
other::---
Comment 39 Harald Hoyer 2010-10-26 05:55:53 EDT
The directory /dev/dri should have unix perms 0755, though!
Comment 40 Sean Middleditch 2010-11-08 00:21:15 EST
Not to be overly annoying intentionally, but this is a particularly irritating bug and I just have no freaking clue how to fix it because I still have no idea how the 2010 flavor of the Linux/Fedora bootup sequence works.

Is there some kind of quick-hack I can do that'll make it work other than just putting a chmod o+rwx /dev/dri in my rc.local ?  (Or does rc.local not even work anymore?  wouldn't surprise me.)

If there's any more information I can provide to help identify the bug, I'm more than willing to provide it; just let me know what you need.  Thanks.
Comment 41 atswartz 2010-11-08 17:39:41 EST
I haven't tried a stock kernel since kernel-2.6.36-0.39, but my custom kernels have the permissions set properly.  Have you tried to compile your own?  I realize that this is not a proper solution, but since I compile my own kernels on other distros I already have configs that I know work good so it isn't such a big deal for me.  I will attach my latest.  If you add in your hardware you probably should be able to adapt it to work.
Comment 42 atswartz 2010-11-08 17:40:54 EST
Created attachment 458912 [details]
2.6.36-1 config
Comment 43 Harald Hoyer 2010-11-18 10:18:07 EST
dracut-008-0.10.gitb2415f4.fc15
Comment 44 atswartz 2010-11-18 17:01:51 EST
Does not work for me.
[ats@asus ~]$ glxinfo | grep OpenGL
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.10-devel
OpenGL shading language version string: 1.20
OpenGL extensions:
[ats@asus ~]$ ls -al /dev/dri
ls: cannot open directory /dev/dri: Permission denied
[ats@asus ~]$ sudo ls -al /dev/dri
[sudo] password for ats: 
total 0
drwxr-x---.  2 root root       80 Nov 18 09:55 .
drwxr-xr-x. 22 root root     4060 Nov 18 15:56 ..
crw-rw----+  1 root video 226,  0 Nov 18 15:55 card0
crw-rw-rw-.  1 root video 226, 64 Nov 18 15:55 controlD64
[ats@asus ~]$ rpm -qa |grep dracut
dracut-008-0.10.gitb2415f4.fc15.noarch
Comment 45 atswartz 2010-11-18 18:11:08 EST
My bad, it did work.  I guess that I got the kernel before the dracut update, so I had to regenerate the initramfs.  Now all is good.  Thanks.
Comment 46 Yanko Kaneti 2010-11-22 05:18:27 EST
*** Bug 655309 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.