Bug#607391: qemu-kvm: /dev/kvm should have group id kvm

2011-02-24 Thread Michael Tokarev
23.02.2011 23:10, Netvalue Support wrote:

 I found /etc/udev/rules.d/65-kvm.rules on some of my systems, which I
 had to remove.  These started off as Etchnhalf and were previously
 upgraded to Lenny; systems that started off as Lenny were fine.  But to
 muddy the waters a little, I've also had qemu-kvm from backports or
 built from upstream sources on these machines at times.

Do you have these 65-kvm.rules files somewhere still?

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.

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.

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.

Thanks!

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#607391: qemu-kvm: /dev/kvm should have group id kvm

2011-02-24 Thread Netvalue Support

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



Bug#607391: qemu-kvm: /dev/kvm should have group id kvm

2011-02-23 Thread Michael Tokarev
tags 607391 + moreinfo unreproducible
thanks

[Somehow I didn't see the bugreport - neither of the
 messages reached me.  Dunno why]

Richard Kettlewell wrote at Mon, 07 Feb 2011 22:12:18 +:
 There is actually a file in /lib which can help achieve this.  I used
 these commands:

 # cp /lib/udev/rules.d/60-qemu-kvm.rules /etc/udev/rules.d/
 # udevadm test $(udevadm info -q path -n /dev/kvm)

 There is also a section in the postinst which references a nonexistent
 rules file, which be a failed attempt to do the same.

The lines you refer to is a compensation for a very old
udev rules file which previously (in pre-historic times)
has been in /etc/udev/rules.d/.  Sure thing it does not
exist in modern systems.

But the thing is: /lib/udev/rules.d/60-qemu-kvm.rules file
is sufficient for udevd to pick that file up, there's no
need to copy that file into /etc/udev/rules.d/ unless
you want to _modify_ that file.  This was the intention
when moving stuff from /etc/udev/rules.d/ to /lib/udev/ -
in order to be able to modify the rules that comes with
each package without worrying about local changes.  If
a file named the same is present in /etc/udev/rules.d/,
that file will be used instead of the one in /lib/udev/rules.d/.

So I'm not sure I understand the problem, it all works
as intended, on my systems and on many other systems all
over the world.  Maybe you have very old udev package
(from Lenny?) which does not look at /lib/udev/rules.d
at all?

Thanks!

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#607391: qemu-kvm: /dev/kvm should have group id kvm

2011-02-23 Thread Richard Kettlewell

Michael Tokarev wrote:


So I'm not sure I understand the problem, it all works
as intended, on my systems and on many other systems all
over the world.  Maybe you have very old udev package
(from Lenny?) which does not look at /lib/udev/rules.d
at all?


In my case the system was upgraded from lenny, so my guess is that some 
bit of qemu-kvm doesn't handle the upgrade correctly.  I was on 
squeeze's udev by the point I found the problem, having followed the 
squeeze release notes instructions on upgrading.


I've since purged and reinstalled all the libvirt and kvm packages; the 
result seems to behave better.


ttfn/rjk



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#607391: qemu-kvm: /dev/kvm should have group id kvm

2011-02-23 Thread Netvalue Support

On 24/02/11 06:20, Richard Kettlewell wrote:

Michael Tokarev wrote:


So I'm not sure I understand the problem, it all works
as intended, on my systems and on many other systems all
over the world.  Maybe you have very old udev package
(from Lenny?) which does not look at /lib/udev/rules.d
at all?


In my case the system was upgraded from lenny, so my guess is that 
some bit of qemu-kvm doesn't handle the upgrade correctly.  I was on 
squeeze's udev by the point I found the problem, having followed the 
squeeze release notes instructions on upgrading.


I found /etc/udev/rules.d/65-kvm.rules on some of my systems, which I 
had to remove.  These started off as Etchnhalf and were previously 
upgraded to Lenny; systems that started off as Lenny were fine.  But to 
muddy the waters a little, I've also had qemu-kvm from backports or 
built from upstream sources on these machines at times.


Regards,

Mark.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#607391: qemu-kvm: /dev/kvm should have group id kvm

2010-12-17 Thread Regis Smith
Package: qemu-kvm
Version: 0.12.5+dfsg-5
Severity: normal


This is just a suggested convenience for users:  change the group ID of 
/dev/kvm to kvm when installing qemu-kvm.

-- Package-specific info:


/proc/cpuinfo:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Athlon(tm) II X4 640 Processor
stepping: 3
cpu MHz : 3013.786
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips: 6027.56
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Athlon(tm) II X4 640 Processor
stepping: 3
cpu MHz : 3013.786
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips: 6026.79
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor   : 2
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Athlon(tm) II X4 640 Processor
stepping: 3
cpu MHz : 3013.786
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 2
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips: 6026.82
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor   : 3
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 5
model name  : AMD Athlon(tm) II X4 640 Processor
stepping: 3
cpu MHz : 3013.786
cache size  : 512 KB
physical id : 0
siblings: 4
core id : 3
cpu cores   : 4
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni 
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 
misalignsse 3dnowprefetch osvw ibs skinit wdt
bogomips: 6026.79
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate




-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu-kvm depends on:
ii  adduser 3.112+nmu2   add and remove users and groups
ii  bridge-utils1.4-5Utilities for configuring the Linu
ii  iproute 20100519-3   networking and traffic control too
ii  libaio1 0.3.107-7Linux kernel AIO access library - 
ii  libasound2  1.0.23-2.1   shared library for ALSA applicatio
ii  libbluetooth3   4.66-2   Library to use the BlueZ Linux Blu
ii  libbrlapi0.54.2-6braille