Hali-halo!
How come the qemu accelerator kernel module kqemu.ko is still shipping with wrong default permissions? You must either use it as root or chmod it after every reboot! Now, that’s what I call a deal-breaker. Couldn’t the brave SuSErs have configured it to just run without such low-level user intervention? Does anyone know of a recommended/preferred procedure to get the beast behave in openSuSE 11.0? Maybe an openSUSE-specific tutorial or howto? I gotta automatize the thing somehow, I got 2 brats that want qemulated windows games and sure don’t know how to modprobe or chmode stuff.
Thanx in advance!
Nobody cared to reply, so here goes an update: the default procedure listed on Ballard’s site works in openSUSE too (no modifications required). Haven’t tried the other method (setting up a qemu group and giving it specific permissions). Anyone has?
I suppose everything you need is read/write permissions to /dev/kqemu, so it doesn’t matters if you give them to everybody or just to a group your user is in.
About automating the thing… if you cared to search “kqemu” in bugzilla you would have found this: https://bugzilla.novell.com/show_bug.cgi?id=348987
If you have any idea about how to fix this, post it there.
Well, the automatic loading is not the biggest issue here – although it could be made into a setting that the user could simply enable/disable via YaST. The biggest issue is that, even if loaded, kqemu is not accessible to ordinary users, thus severely limiting the usability of QEMU. This can become quite tricky in certain scenarios, such as kids (with no access to root account) running emulated games – where speed is of the essence. Or, to take another situation: you’re trying to convert a Windows user, a total newbie to GNU/Linux, and you’d like to make the transition as smooth as possible for them: as we all know, there’s always this or that Windows program that “just has no counterpart in GNU/Linux”, so after much negotiation you barely manage to persuade them to forgo double-booting and try QEMU instead – only to be put off immediately by this terrible sluggishness.
The point is, Ballards one-liner
echo 'KERNEL=="kqemu", NAME="%k", MODE="0666"' \
> /etc/udev/rules.d/60-kqemu.rules
solves the problem magnificiently. I just regret that this one-liner has to be dug out by the user instead of being put in there automatically, say, when you install kqemu in YaST, or when you run kqemu for the first time. Not a big deal at all, it’s just that it’s been lingering on for some time now.
As a side note: I may be totally wrong, perhaps kqemu running in the kernel represents a security liability and is kept away from non-rooties on purpose?
In bug #391287 (marked duplicate of #348987)
KERNEL=="kqemu", NAME="%k", MODE="0660", GROUP="kvm"
is suggested (“kvm” group?). Probably that’s the option that makes more sense.
If you think that’s enough the way to make that change into the offical openSUSE package is:
- Add a comment in bug #348987 saying:
While a solution for the autoloading is found, someone has any problem patching the package to change the device node default permissions so a non-root user can use qemu with the accelerator?
Michael Meeks proposed
$ cat /etc/udev/rules.d/60-kqemu.rules
KERNEL==“kqemu”, NAME=“%k”, MODE=“0660”, GROUP=“kvm”
at bug #391287, marked duplicate of this one (GROUP shouldn’t better be “qemu” or “kqemu”?). Also, I’m not sure if there is a need to limit the usage to users of a specific group… MODE=“0666” would be enough or it supposes a security risk? For sure is more convenient for users.
I don’t think such a patch will interfere with a future fix for the autoloading problem.
- Attach the spec file patch to the bug report to improve your possibilities
- Create a “submitreq” (Build Service/Collaboration - openSUSE) with your patch to improve even more your possibilities
Thanx. I think the wisest thing to do would be to sleep on it and wait to see the situation in 11.1 – and then maybe fill a bug report.