On 24/02/11 21:45, Michael Tokarev wrote:
Do you have these 65-kvm.rules files somewhere still?
I found two in the backups. One was:
KERNEL==kvm, MODE=0660, GROUP=kvm
ACTION==add|change, SUBSYSTEM==dmi, KERNEL==id, RUN+=/bin/sh -c
'grep -q vmx /proc/cpuinfo /sbin/modprobe kvm-intel; grep -q svm
/proc/cpuinfo /sbin/modprobe kvm-amd'
The other was:
KERNEL==kvm, MODE=0660, GROUP=kvm
but had kvm_intel in /etc/modules.
Currently qemu-kvm ships /lib/udev/rules.d/60-qemu-kvm.rules,
but the rules in there (especially setting permissions/
ownership) may be owerwritten by 65-kvm.rules (since it
sorts after 60-*), so the only possible explanation of
this issue is an error in 65-kvm.rules.
Lenny (and not Squeeze) also had a entry
KERNEL==kvm, GROUP=kvm
in /etc/udev/rules.d/91-permissions.rules, which might have covered over
latent problems.
And the only place I can think of where that file may
come from is kvm package v. 85 or nearby, which were
present in backports for some time, and for which I
don't have any upgrade paths.
Hmm, it looks like I started with Etch kvm-72, dallied with upstream
from qemu-kvm-0.10.5 to 0.12.3, backports as soon 0.12.3 hit there, then
back to official with Squeeze. Really, anything could have happened
while I was installing from upstream sources ...
In any case, it'd be nice to see the content of that
file (if it's still possible), and the solution is to
just remove that file. Maybe I will be able to come
with some automatic solution, but I'm afraid it's too
late for squeeze, -- I don't want to mess up with
config files risking to create more serious breakage.
Hope that helps. I can't speak for Richard's case, but as happy to
regard my own as self-inflicted.
Thanks,
Mark.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
