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 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)

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.

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

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 ...

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)

Yes, as it should (if it needs it, obviously).
Right?

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.

I agree.

Thanks so much for your input.

Cheers,

A.

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.

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.

I think I got the right idea.  =^)

Just commenting out chmod 0666 /dev/kvm and chgrp kvm /dev/kvm (reported as a bug in the thread I linked to) should suffice. 

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
~$ 

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.

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.

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.

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

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.

I'll have a read.
But you know I have a thing for cats.  8^D

No.

Yes, but if I'm not installing qemu ...

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.

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:

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.

~$ cat /etc/group | grep -i kvm
~$

Better command:

grep kvm /etc/group

See also http://porkmail.org/era/unix/award.html#cat

Do you have QEMU installed? I think the qemu-kvm package creates that system group.

Does that use KVM for hardware virtualisation?

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.