> 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 $ sudo mv /lib/udev/rules.d/40-qemu-system.rules{,.disabled} $ sudo mv /lib/udev/udev-acl{,.disabled} $ sudo modprobe kvm_intel $ sudo cp /lib/udev/rules.d/40-qemu-system.rules{.disabled,} $ udevadm trigger --sysname-match=kvm --verbose /sys/devices/virtual/misc/kvm $ ls -l /dev/kvm crw------- 1 root root 10, 232 Jan 30 07:21 /dev/kvm i. e. triggering a change (or add) event does not actually apply the GROUP and MODE settings to /dev/kvm, it remains as root. This is without any udev-acl magic, and happens both with the current package rules as well as the simpler rules I tried above (without the := and RUN). So that part of the postinst doesn't currently work as expected. When I work around this by setting the permissions manually (as the postinst intends to do) sudo chgrp kvm /dev/kvm sudo chmod g+rw /dev/kvm then running sudo /lib/udev/udev-acl.disabled -a change --device=/dev/kvm seems to have the desired effect: $ getfacl /dev/kvm # file: dev/kvm # owner: root # group: kvm user::rw- user:martin:rw- group::rw- mask::rw- other::--- So may it be that this was a red herring, caused by the unexpected/wrong group and permissions of /dev/kvm after triggering the rule? -- 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: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1103022/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs