In a fresh installed system, after the installation of qemu, I have: horizon ~ # ls -la /dev/kvm crw------- 1 root root 10, 232 apr 18 2016 /dev/kvm In this way I have permission denied when I try to start a vm. after a reboot I have: horizon ~ # ls -la /dev/kvm crw-rw---- 1 root kvm 10, 232 apr 18 2016 /dev/kvm A workaround is set by hand chmod 660 and chown root:kvm Is there a way that the ebuild can do this to avoid reboot or manually operations?
If you want to trigger the udev rule from pkg_postinst, here's some code: if [[ ${ROOT} == / ]] && type -p udevadm >/dev/null; then udevadm trigger -c add /dev/kvm fi
(In reply to Mike Gilbert from comment #1) > If you want to trigger the udev rule from pkg_postinst, here's some code: > > if [[ ${ROOT} == / ]] && type -p udevadm >/dev/null; then > udevadm trigger -c add /dev/kvm > fi We used to do that and then it was deemed not cool to poke udev from an ebuild so it was in an einfo but that might have been swallowed by the bit bucket at some point.
(In reply to Doug Goldstein from comment #2) yeah, i'm not keen on that sort of thing. if we do want to go that route, seems like the udev eclass should own most of it. that way the qemu ebuild would only hold something like: udev_trigger -c add /dev/kvm looking at the history in the tree, i'm not seeing any calls to udevadm. we have udev_reload right now already, and we still have a kvm related elog (for the first install, but that's what we're discussing here). maybe the simple fix is to just extend the DOC_CONTENTS to mention this initial perm reset/reload issue and leave it up to users to read/react/run that command themselves ?
(In reply to SpanKY from comment #3) > (In reply to Doug Goldstein from comment #2) > > yeah, i'm not keen on that sort of thing. if we do want to go that route, > seems like the udev eclass should own most of it. that way the qemu ebuild > would only hold something like: > udev_trigger -c add /dev/kvm > > looking at the history in the tree, i'm not seeing any calls to udevadm. we > have udev_reload right now already, and we still have a kvm related elog > (for the first install, but that's what we're discussing here). Hmm. It could be I proposed it and got whacked with a clue-by-four before I committed it. > > maybe the simple fix is to just extend the DOC_CONTENTS to mention this > initial perm reset/reload issue and leave it up to users to read/react/run > that command themselves ? Yeah that's probably the best way forward. I don't know the trick to peek at history now days that we've left the old bits behind and I nuked CVS but I'd be willing to guess I wrote DOC_CONTENTS and its just a bit to minimal and needs to be more clear / extended.
(In reply to Doug Goldstein from comment #4) i've pushed this: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=518837d554f9515ff583ecbdd36731c4c336abdb for your git history needs, check out: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_history_onto_the_active_repository
