Bug 799703 - Cannot open /dev/dri/card0 from within LXC container: No such device
Summary: Cannot open /dev/dri/card0 from within LXC container: No such device
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-04 13:17 UTC by Robin Green
Modified: 2013-04-05 19:27 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-05 19:27:05 UTC
Type: ---


Attachments (Terms of Use)

Description Robin Green 2012-03-04 13:17:16 UTC
Description of problem:
X (nouveau driver) won't start inside an LXC container, because it says
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
even though I've enabled device creation in cgroups and created the device node at that path. I've simplified the test case to just cat below, after the setup steps.

Version-Release number of selected component (if applicable):
kernel-3.2.7-1.fc16.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create an LXC container called Rawhide (for a rawhide tree in my case, but it probably doesn't matter) in virt-manager
2. Start the LXC container
3. In a host terminal, as root do
echo a > /sys/fs/cgroup/devices/libvirt/lxc/Rawhide/devices.allow
4. In the LXC guest, as root do: mknod -m 660 /dev/dri/card0 c 226 0
5. In the LXC guest, as root do: cat /dev/dri/card0
  
Actual results:
cat: /dev/dri/card0: No such device

Expected results:
cat should wait indefinitely trying to read from the device, but not exit with an error. This is the behaviour observed on the host.

Additional info:
The ACLs reported by getfacl /dev/dri/card0 are different on the host and guest, but I don't see why this should make a difference - I'm running cat as root in both cases.

Comment 1 Josh Boyer 2012-03-05 15:49:36 UTC
I'm going to be honest here.  This isn't going to take a high priority with the fedora kernel maintainers.  You will probably have better luck using a rawhide or self-built mainstream kernel and working directly with upstream.

Comment 2 Dave Jones 2012-03-22 17:04:29 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 3 Dave Jones 2012-03-22 17:07:38 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 4 Dave Jones 2012-03-22 17:18:34 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 5 Josh Boyer 2012-09-04 17:22:14 UTC
Clearing needinfo flags here.

Robin, did you ever take your request upstream?

Comment 6 Fedora End Of Life 2013-04-03 15:38:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 7 Justin M. Forbes 2013-04-05 19:27:05 UTC
Closing insufficient data since it has been so long without any response from the original reporter


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