This bug was fixed in the package qemu-kvm - 1.2.0+noroms-
0ubuntu2.12.10.4
---
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.4) quantal-proposed; urgency=low
* qemu-kvm.preinst: add kvm group if not present. (LP: #1103022)
-- Serge Hallyn serge.hal...@ubuntu.com Fri, 22 Mar 2013
This bug was fixed in the package qemu-kvm - 1.2.0+noroms-
0ubuntu2.12.10.4
---
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.4) quantal-proposed; urgency=low
* qemu-kvm.preinst: add kvm group if not present. (LP: #1103022)
-- Serge Hallyn serge.hal...@ubuntu.com Fri, 22 Mar 2013
Thanks Daviey. confirmed, with quantal-proposed I get
crw-rw 1 root kvm 10, 232 May 17 15:43 /dev/kvm
** Description changed:
When qemu-system gets installed, the newly installed udev rule causes
/dev/kvm to gets chgrpd to kvm and its mode to get set to g+rw.
However, because
Thanks Daviey. confirmed, with quantal-proposed I get
crw-rw 1 root kvm 10, 232 May 17 15:43 /dev/kvm
** Description changed:
When qemu-system gets installed, the newly installed udev rule causes
/dev/kvm to gets chgrpd to kvm and its mode to get set to g+rw.
However, because
Hello Serge, or anyone else affected,
Accepted qemu-kvm into quantal-proposed. The package will build now and
be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.2.0
+noroms-0ubuntu2.12.10.4 in a few hours, and then in the -proposed
repository.
Please help us by testing this new
Just a note, udev-acl is gone in saucy. It was replaced with uaccess,
which is similar in spirit, but a different implementation.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
Hello Serge, or anyone else affected,
Accepted qemu-kvm into quantal-proposed. The package will build now and
be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.2.0
+noroms-0ubuntu2.12.10.4 in a few hours, and then in the -proposed
repository.
Please help us by testing this new
Just a note, udev-acl is gone in saucy. It was replaced with uaccess,
which is similar in spirit, but a different implementation.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103022
Title:
qemu-kvm in quantal was replaced by qemu in raring. Hence this bug is
invalid in raring qemu-kvm, fix released in raring qemu, and exists in
quantal qemu-kvm.
** Also affects: qemu-kvm (Ubuntu)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Quantal)
Importance:
** Description changed:
When qemu-system gets installed, the newly installed udev rule causes
/dev/kvm to gets chgrpd to kvm and its mode to get set to g+rw.
However, because /dev/kvm was tagged with ACL previously, there is a
group:: acl on /dev/kvm which does not get removed. Therefore
** Changed in: qemu-kvm (Ubuntu Quantal)
Assignee: Serge Hallyn (serge-hallyn) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/1103022
Title:
70-udev-acl.rules
qemu-kvm in quantal was replaced by qemu in raring. Hence this bug is
invalid in raring qemu-kvm, fix released in raring qemu, and exists in
quantal qemu-kvm.
** Also affects: qemu-kvm (Ubuntu)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Quantal)
Importance:
** Description changed:
When qemu-system gets installed, the newly installed udev rule causes
/dev/kvm to gets chgrpd to kvm and its mode to get set to g+rw.
However, because /dev/kvm was tagged with ACL previously, there is a
group:: acl on /dev/kvm which does not get removed. Therefore
** Changed in: qemu-kvm (Ubuntu Quantal)
Assignee: Serge Hallyn (serge-hallyn) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103022
Title:
70-udev-acl.rules needs to put g+rw
This bug was fixed in the package qemu - 1.4.0+dfsg-1expubuntu4
---
qemu (1.4.0+dfsg-1expubuntu4) raring; urgency=low
* re-add qemu-system-x86.modprobe to set nesting=1 (LP: #1155177)
* qemu-system-x86.qemu-kvm.upstart:
- remove NESTED workarounds from upstart file.
-
The bug really is in udev-acl. However, as udev-acl will soon go away,
and I can work around it in qemu, I am marking it against qemu and
implementing the workaround until we switch to logind.
** Changed in: udev (Ubuntu)
Status: Confirmed = In Progress
** Changed in: udev (Ubuntu)
Just for the record, udev-acl will hopefully go away RSN (either in
raring, or immediately after), see
https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303
-consolekit-logind-migration and bug 1153224.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
This test case shows the bug in udev-acl.c.
When udev-acl is called to add a user acl, it
1. gets the current acl
2. removes any acl for non-current user
3. adds acl for user
4. writes the result.
Any existing group acl is kept.
What this test case shows, is that in step 1 udev will get what
So really, the above is what triggers the bug, but I think the real bug
is that when udev-acl later gets called to update the permissions, it
simply keeps the existing group acl instead of updating it for the new
MODE=0660 in the new udev rule.
--
You received this bug notification because you
Can you please try that a few more times? If I script that, I find that
I get your results if I don't put a sleep before the udevadm trigger,
but the right results if I do. I.e.:
cat kvmudevtest EOF
mv /lib/udev/rules.d/40-qemu-system.rules{,.disabled}
mv /lib/udev/udev-acl{,.disabled}
rmmod
The 40-qemu-system.rules is not the problem and we're not trying to recover
from it.
Well, it is a problem in the sense that the setfacl call there should
not be necessary and also should be redundant, as it is essentially
equivalent to chmod g+rw?
I'd love to remove it (I only very
This is where you've gone wrong in your experiment. The /dev/kvm perms will
be correct because you've reloaded kvm_intel
after a (any) 40-qemu-system.rule existed.
Ah, thanks for pointing out!
I just noticed another problem which we might have overlooked here:
$ sudo rmmod kvm_intel kvm
$
As discussed on IRC: As this is an one-time upgrade fix for cleaning up
after the currently wrong /lib/udev/rules.d/40-qemu-system.rules, I'd
much rather like to see this as an one-time action in postinst (which is
the standard way of doing such operations on upgrade) than this patch,
which would
I'm assuming (hoping) comment #2 as entered before we proceeded with our
irc conversation?
The 40-qemu-system.rules is not the problem and we're not trying to recover
from it.
As mentioned in irc, the steps are:
1. set up a new ubuntu system, it modprobes kvm_intel, /dev/kvm gets created,
2.
In fact udev-acl appears to be doing it.
When logging into a simple ubuntu desktop with qemu-system not
installed, I log in and find /dev/kvm is root:root rwm-- with a
group::--- acl installed. I verify the acl by doing 'chmod g+rw
/dev/kvm' followed by ls -l /dev/kvm and getfacl /dev/kvm
Serge Hallyn [2013-01-29 6:22 -]:
I'm assuming (hoping) comment #2 as entered before we proceeded with our
irc conversation?
Yes, I did after the first part when it seemed to me that we agreed
that this was only an upgrade fix for the wrong
40-qemu-system.rules.
The 40-qemu-system.rules
** Patch added: Proposed fix
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1103022/+attachment/3495184/+files/udev-kvm.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103022
Title:
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103022
Title:
70-udev-acl.rules needs to put g+rw on /dev/kvm
To manage notifications about this bug go to:
28 matches
Mail list logo
