Rules have invalid modes specified

CameronNemo commented 5 years ago

https://github.com/void-linux/void-packages/pull/2884#issuecomment-422624997

Some rules in systemd are generated now:

https://github.com/systemd/systemd/blob/master/rules/meson.build#L31

They use the following variables:

https://github.com/systemd/systemd/blob/master/meson_options.txt#L181

As well as rootbindir

https://github.com/systemd/systemd/blob/master/rules/64-btrfs.rules.in#L15

darkshram commented 5 years ago

I can confirm. Tested eudev 3.2.6 and the following errors are shown because invalid variables:

[ 1433.943337] udevd[324]: specified group 'render' unknown
[ 1433.943441] udevd[324]: specified group 'kvm' unknown
[ 1433.957734] udevd[14912]: ignoring invalid mode '@GROUP_RENDER_MODE@'
[ 1433.964924] udevd[14900]: ignoring invalid mode '@GROUP_RENDER_MODE@'
[ 1434.068205] udevd[14900]: ignoring invalid mode '@DEV_KVM_MODE@'
[ 2117.738601] udevd[324]: specified group 'render' unknown
[ 2117.739603] udevd[324]: specified group 'kvm' unknown
[ 2117.755333] udevd[10609]: ignoring invalid mode '@GROUP_RENDER_MODE@'
[ 2117.783521] udevd[10621]: ignoring invalid mode '@GROUP_RENDER_MODE@'
[ 2117.859136] udevd[10623]: ignoring invalid mode '@DEV_KVM_MODE@'

These will need to be set from configure or set automatically.

blueness commented 5 years ago

thanks. i should have looked carefully before accepting the latest update to the rules. i'm not sure we can support the same type of generated rules as systemd, but i'll take a look and push out a new release when i have this fixed.

any suggestions here are welcome.

darkshram commented 5 years ago

Groups render and kvm should exists too. I don't think all distros will support 'render' group. Seems like replacing 'render' with 'video' should make everyone happy, unless render group is really being used by any distro using eudev.

darkshram commented 5 years ago

My Suggestion:

diff -Naur eudev-3.2.6.orig/rules/50-udev-default.rules eudev-3.2.6/rules/50-udev-default.rules
--- eudev-3.2.6.orig/rules/50-udev-default.rules    2018-02-20 06:36:19.000000000 -0600
+++ eudev-3.2.6/rules/50-udev-default.rules 2018-09-20 09:07:58.283867136 -0500
@@ -36,8 +36,8 @@
 SUBSYSTEM=="media", GROUP="video"
 SUBSYSTEM=="cec", GROUP="video"

-SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="@GROUP_RENDER_MODE@"
-SUBSYSTEM=="kfd", GROUP="render", MODE="@GROUP_RENDER_MODE@"
+SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="video", MODE="0666"
+SUBSYSTEM=="kfd", GROUP="video", MODE="0666"

 SUBSYSTEM=="sound", GROUP="audio", \
   OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"
@@ -79,7 +79,7 @@
 KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"

 # The static_node is required on s390x and ppc (they are using MODULE_ALIAS)
-KERNEL=="kvm", GROUP="kvm", MODE="@DEV_KVM_MODE@", OPTIONS+="static_node=kvm"
+KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"

 SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK += "ptp_kvm"

blueness commented 5 years ago

This should be fixed as of the latest commit a8ffcd1b985fb4b3e2c3a1cb9051bed86f69d3f3. Can you test and get back to me to confirm everything is working right on your systems. If so, I'll cut another release in a few days with this update. I'd like to wait a while to see if more bugs come forwards before cutting a new release.

darkshram commented 5 years ago

I have been working with eudev 3.2.6 in my PC with that patch applied since yesterday without issues. Everything seems to work Ok. I had to create the 'kvm' group (gid 36) before updating to eudev 3.2.6.

To test the use of 'video' group instead of 'render', in case there are other hidden surprises:

Tested several OpenGL-based games.
Tested MATE Desktop with compiz with ConsoleKit2.
Tested KDE Plasma with several graphical effects enabled.
Cinnamon desktop with elogind.

Again, everything went Ok without issues or error/warning messages. I'm using a custom SystemD-less Fedora-based small distro named ALDOS.

This is the output of dmesg using eudev 3.2.6 in a Core i3 PC (for beta testing):

[    0.755369] udevd[183]: starting version 3.2.6
[    0.755595] random: udevd: uninitialized urandom read (16 bytes read, 11 bits of entropy available)
[    0.755615] random: udevd: uninitialized urandom read (16 bytes read, 11 bits of entropy available)
[    0.755622] random: udevd: uninitialized urandom read (16 bytes read, 11 bits of entropy available)
[    0.755630] random: udevd: uninitialized urandom read (16 bytes read, 11 bits of entropy available)
[    0.756417] udevd[184]: starting eudev-3.2.6
[    1.403552] random: udevd: uninitialized urandom read (16 bytes read, 13 bits of entropy available)
[    1.796827] random: udevd: uninitialized urandom read (16 bytes read, 14 bits of entropy available)
[    5.590684] udevd[324]: starting version 3.2.6
[    6.300925] udevd[325]: starting eudev-3.2.6

Pretty much the same output in an Intel Atom netbook (for beta testing) and an AMD Athon X2 laptop (production). No error/warning messages.

Don't know if any other distros use the 'render' group. As far as I know Fedora deprecated 'video' group a few releases ago. Guess this has to be tested in major non-systemd/optional-systemd distros like Gentoo and Devuan (they use eudev 3.2.2).

udeved commented 5 years ago

In Artix Linux(arch based but systemd free) we use render group. Currently experimenting with render vs video group.

blueness commented 5 years ago

I may switch from render to video for gentoo. Let me see what direction gentoo wants to go in.

darkshram commented 5 years ago

Thinking about this, anything using eudev most likely lacks 'render' group. There were no rules in eudev using this group until 3.2.6. I have checked on Fedora and CentOS, the first uses render group (because of latest systemd) and the second does not (using systemd 219).

The most neutral thing to do would be adding a few macros in configure.ac to let packagers pick either 'render' (tagged with modern) or 'video' (tagged with legacy) from configure with an option as --with-render-group=xxxx and default to 'video'. Same with the '@DEV_KVM_MODE@' and '@GROUP_RENDER_MODE@' with something like --with-kvm-mode=xxx and --with-render-mode=xxx and default both to 0666, which would be the safest values if packager ignores to configure them.

CameronNemo commented 5 years ago

What is the rational for the new render group?

darkshram commented 5 years ago

@CameronNemo Most likely is Lennart Poettering (as always) trying to piss as much people as possible. But seriously, NEWS file from SystemD reads the following in the changes for systemd-336:

    * The "uaccess" udev tag has been dropped from /dev/kvm and
      /dev/dri/renderD*.  These devices now have the 0666 permissions by
      default (but this may be changed at build-time). /dev/dri/renderD*
      will now be owned by the "render" group along with /dev/kfd.

There are no more details. But digging into systemd files, the sysusers.d/basic.conf.in, which does not exist in eudev, we can find this:

# Hardware access groups
g audio   -     -            -
g cdrom   -     -            -
g dialout -     -            -
g disk    -     -            -
g input   -     -            -
g kvm     -     -            -
g lp      -     -            -
g render  -     -            -
g tape    -     -            -
g video   -     -            -

So, the 'render' group seems to be systemd-specific.

Before eudev 3.2.6, /dev/dri/renderD12* and /dev/kfd (if available) already belonged to 'video' group, but with 0660 permissions. So, @blueness it seems commit a8ffcd1 may be permanent (let's discuss if permissions should be 0660 instad of 0666) and probably you may issue eudev 3.2.7 after somebody do some testing with KVM with eudev 3.2.6. Probably uaccess tags will have to be back-ported from 3.2.5 but it may work Ok just creating kvm system-group (groupadd -g 36 kvm). I would offer myself to do the testing but all my machines use VirtualBox and that disables kvm kernel modules.

FYI: LinuxFromScratch removes render group most likely becase the reasons I have discovered and explained. http://www.linuxfromscratch.org/blfs/view/stable-systemd/general/systemd.html http://www.linuxfromscratch.org/lfs/view/systemd/chapter06/systemd.html

blueness commented 5 years ago

okay i think i'm going to leave things as is. if various distros need to change things, they can patch the rules locally.

eudev-project / eudev

Rules have invalid modes specified #160