You are not logged in.
Pages: 1
Hello:
While trawling log files to fine tune my new Beowulf, I found this in my dmesg output:
--- snip ---
[ 14.484174] udevd[395]: specified group 'kvm' unknown
--- snip ---
Quite so, the group 'kvm' does not exist ...
~$ cat /etc/group | grep -i kvm
~$
... so I guess it is unknown.
I have seen some chatter on the web with respect to this but as it seems (?) Poettering is involved, I decided to ask here.
ie: people argued against and he argued for.
I installed cpu-checker and ran it ...
~# kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used
~#
... confirming that /dev/kdm is there.
Why?
I run my VMs with VMWare but have not installed it yet.
Why does the kernel/system generate /dev/kvm and but does not also generate a 'kvm' group, maybe just empty?
Should I create a 'kvm' group to get rid of the dmesg line?
Thanks in advance,
A.
Offline
~$ cat /etc/group | grep -i kvm ~$
Better command:
grep kvm /etc/group
See also http://porkmail.org/era/unix/award.html#cat
Why does the kernel/system generate /dev/kvm and but does not also generate a 'kvm' group, maybe just empty?
Do you have QEMU installed? I think the qemu-kvm package creates that system group.
I run my VMs with VMWare
Does that use KVM for hardware virtualisation?
Brianna Ghey — Rest In Power
Offline
Hello:
I'll have a read.
But you know I have a thing for cats. 8^D
Do you have QEMU installed?
No.
... the qemu-kvm package creates that system group.
Yes, but if I'm not installing qemu ...
Does that [VMWare] use KVM for hardware virtualisation?
Apparently not.
From what I make from the thread linked below, only the qemu package uses it.
I found a bug report from 2017 with respect to this here -> https://github.com/systemd/systemd/issues/6360
It would seem that PR #5597 introduced a rule for /dev/kvm in Debian unstable, the result of which is the line in dmesg and someone filed the bug report.
This now causes a journal error.
systemd-udevd: Specified group 'kvm' unknown
in any place where it doesn't exist. That could be initrds, non-x86 systems (which don't have this concept) or simply machines which don't have QEMU installed, where it doesn't make sense to create the group. "kvm" is not at all a generally useful and LSB defined standard group, so creating it everywhere seems like a waste.
What the OP wrote makes (to me) a lot of sense, more so if we take into account that there seem to be no applications which would need a system generated 'kvm' group save the qemu package.
The thread is really worth a read.
It seems this 'kvm' group was another one of Poettering's brilliant ideas.
And as such, it was shoved through in the usual fashion:
Anyway, I am very sure that /dev/kvm should be considered a standard system concept now, sharedby apps, and generic enough to be set up by systemd properly. I hope this makes some sense, and will close this now...
There you have it.
That's how we got a systemd-udevd: Specified group 'kvm' unknown line in dmesg.
@Poettering: no [asshole], it does not make any sense.
Cheers,
A.
Offline
To avoid the complaint and be without a "kvm" group, some surgery of /lib/udev/rules.d/50-udev-default.rules might be sufficient; perhaps just removing the GROUP="kvm", bit, or that whole line, whichever feels more pleasing. The effects would be either that a /dev/kvm device node gets created with group root without complaint, or that it doesn't get created at all.
Online
Hello:
... surgery of /lib/udev/rules.d/50-udev-default.rules might be sufficient ...
Right.
I'll try that.
But ...
The file starts like this:
# do not edit this file, it will be overwritten on update
# The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"
Is this ^^ the line?
I guess I could comment out the whole line, see what happens and remember when an update comes along.
Q: isn't s390x a 64bit IBM mainframe and PPC PowerPC?
ie: need a diiferent kernel than the one (amd64) we're using?
If so, what valid motive is there for this 'kvm' group thing?
I'm not a maintainer, coder or even an advanced user but I get a bad feeling when I see things like these being done in this manner ie: just because.
From reading the thread I linked to I cannot but suspect that, coming from systemd's creator, there may be something else behind this.
But then that's just me.
Thanks for your input.
A.
Offline
Hi
What about "apt purge qemu-kvm". Or in aptitude stroke p (for purge) over the not installed packages to get rid of configuration files of all previously installed packageswich is not installed or present any more ??
Have a nice day
Lars H
Offline
Hello:
Hi
What about "apt purge qemu-kvm".
... get rid of configuration files of all previously installed ...
I don't think that would have any effect.
The qemu-kvm package was never installed and I think what is happening is not because of configuration file from the qemu-kvm installation.
~# apt purge qemu-kvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'qemu-kvm' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
~#
Normally, the qemu-kvm package would set up a 'kvm' group and set up user r+w access to /dev/kvm.
For reasons that do not seem at all clear, this has changed in Beowulf.
Like ralph.ronnquist points out, now the system has a default udev rule (set up at OS install time and overwritten on every update) that wants to set /dev/kvm to world-read-write.
I expect that it also wants a 'kvm' group and not finding it, prints out the result in dmesg.
At least that is how I understand it, corrections welcome. =-)
Cheers,
A.
Last edited by Altoid (2020-09-26 09:04:15)
Offline
Yes;
afaiui there is a hotplug event generated when the "kvm subsystem" (Kernel-based Virtual Machine) has been initialized. That event is (like all) handled by the hotplug handler (aka udev/eudev) via that "rule", which directs the handler to create the device node "/dev/kvm" with the particular permissions and group.
The same actions by hand would be these:
# mknod /dev/kvm c 10 232
# chmod 0666 /dev/kvm
# chgrp kvm /dev/kvm
Commenting out the rule will result in the absence of the device node, but not the sub system itself of course. This should be fine until there's some software needing it; eg qemu or virtualbox or whatever. Under an ideal modularization principle, the device node would rather be created as needed by that software, but few things are ideal.
Online
Hello:
... hotplug event generated when the "kvm subsystem" ...
... by the hotplug handler (aka udev/eudev) via that "rule"
... to create the device node "/dev/kvm" with the particular permissions and group.
I think I got the right idea. =^)
... same actions by hand ...:
# mknod /dev/kvm c 10 232 <- this was also done in ascii # chmod 0666 /dev/kvm <- not this # chgrp kvm /dev/kvm <- not this
Commenting out the rule ...
... absence of the device node
... not the sub system itself ...
Just commenting out chmod 0666 /dev/kvm and chgrp kvm /dev/kvm (reported as a bug in the thread I linked to) should suffice.
... until there's some software needing it ...
From what I have read (not nearly enough) it seems that it is something used solely by the qemu-kvm package.
eg: I run a couple of VMs via VirtualBox in my ascii installation
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64 GNU/Linux
groucho@devuan:~$
The node is there: (the cpu-checker package does not seem to be in the ascii repository)
~$ ls /dev/kvm
/dev/kvm
~$
I don't have a 'kvm' group:
~$ grep kvm /etc/group
~$
... ideal modularization principle, the device node would rather be created as needed by that software ...
Yes, under the modularization principles that governed Debian development and maintenance from the start, crap like this would never have happened.
Nor would a thread as the one I linked to even existed.
That's where we are.
Thanks a lot for your input.
Cheers,
A.
Offline
It seems this 'kvm' group was another one of Poettering's brilliant ideas.
No, the kvm group is one of the kernel developers' ideas. It allows users to access hardware virtualisation (via /dev/kvm) if they are a member of the group. The existence of that group pre-dates systemd.
Normally, the qemu-kvm package would set up a 'kvm' group and set up user r+w access to /dev/kvm.
I thought that too but I've just tried installing QEMU in the Devuan live system and it doesn't do that. Perhaps it's different in an installed system if you want to check.
FWIW my Alpine system creates the group when the qemu package is installed: https://git.alpinelinux.org/aports/tree … re-install
Anyway, why is a random error message so important? Just ignoring it is a definite option here and I think creating the kvm group manually would be better than editing the udev rule only to have to re-edit it whenever the package is updated.
Brianna Ghey — Rest In Power
Offline
Hello:
No, the kvm group is one of the kernel developers' ideas.
You are quite right, I did not express myself correctly.
I should have written: ... seems that setting the /dev/kdm to world-read-write was ...
... allows users to access hardware virtualisation (via /dev/kvm) if they are a member of the group.
Why not do it when installing qemu-kvm?
Not a question that I bring up for I would have not known of its existence if I had not looked at my dmesg, which I always do.
It was so out of place that a maintainer actually filed it as a bug. (see the thread I linked to)
... Alpine system creates the group when the qemu package is installed ...
Yes, as it should (if it needs it, obviously).
Right?
... why is a random error message so important?
Because ...
... it is there?
... people who know much more than I have made what seems to be a strong case against it being there/generated?
... the (seemingly valid) arguments against this were railroaded by Poettering?
Isn't that how systemd came to be?
You may or may not agree with me, but it is not so much what is there but how it got to be there.
... ignoring it is a definite option ...
... creating the kvm group manually would be better than editing ...
I agree.
Should I create a 'kvm' group to get rid of the dmesg line?
Thanks so much for your input.
Cheers,
A.
Offline
seems that setting the /dev/kdm to world-read-write was ...
Alpine apply a patch to eudev so that only root and members of the kvm group can edit the node: https://git.alpinelinux.org/aports/tree … ules.patch
You could create /etc/udev/rules.d/51-kvm.rules to do the same thing. But it would only work if the kvm group exists
Brianna Ghey — Rest In Power
Offline
Hello:
... patch to eudev so that only root and members of the kvm group can edit the node ...
Please correct me if I am wrong ...
Am I to understand that the Alpine distribution has issued a patch that basically backpedals on what Poettering so stubbornly pushed through?
And that in doing so, the line in dmesg complaining about group 'kvm' not being found is then not generated by the system?
TIA
A.
Last edited by Altoid (2020-09-26 18:03:02)
Offline
Am I to understand that the Alpine distribution has issued a patch that basically backpedals on what Poettering so stubbornly pushed through?
Alpine is fundamentally incompatible with systemd so they use eudev rather than udev. And anyway I've just checked my Alpine box and the patch is applied to the line before the one that appears in your Devuan system so it is overridden:
~$ ls -l /dev/kvm
crw-rw-rw- 1 root kvm 10, 232 Sep 26 19:11 /dev/kvm
~$
I'm not even sure why they apply it
the line in dmesg complaining about group 'kvm' not being found is then not generated by the system?
The error would still appear if the kvm group didn't exist because the (e)udev rule tries to place the node under that group's ownership.
It may be best to ask the eudev developers about this — I'm no expert.
irc://irc.gentoo.org/gentoo-udev (Freenode)
Brianna Ghey — Rest In Power
Offline
Pages: 1