HELP: udev rules file suddenly not working on F39 beta

I’ve got a udev rules file in a project that has been working perfectly on about half a dozen different distro types, including Fedora prior to F39 beta. But I’ve had an Arch user reporting that it fails to perform its ACL fix at boot, which is weird because running the manual commands that just tell udev to reload the available rules fixes the problem.

I’m working on the assumption that something has changed in systemd that ended up changing the way the udev rules get processed at boot. But I can’t find any errors in the journal related to this. The RUN command in the rules file just doesn’t seem to get run at boot. Or the whole file doesn’t get processed.

Not sure where to even look for the explanation of what is happening and how to get the rules file to work again.

The rule sets the ownership on /dev/uinput to root:input, and that seems to work, but I’m not sure if that gets reset when rebooting, so that may not be an indication that a portion of the rules file is working at boot. Maybe that was taken care of during the initial run of the installer script, which runs the commands below.

Mainly, the rules file also runs a setfacl command that I’ve found necessary recently on multiple distros, to enable group r/w ACL permissions. That is definitely not working, but it is only not working at boot.

Running these manual commands after booting and logging in will fix the issue, without needing to change the rules file at all:

sudo udevadm control --reload-rules
sudo udevadm trigger

But on each reboot the ACL permissions are reset so that there are no group r/w permissions.

Is there some new way of doing things with udev rules files installed in /etc/udev/rules.d/?

Any info about this would be much appreciated.

This rings a bell… i think I read something like this issue on the systemd dev mailing list.

You could look in the mailing list archive.

Maybe the order of udev events or the type changed, but I am guessing what I read.

1 Like

So, might actually be caused by a bug in systemd v254, that will hopefully be fixed by an update at some point.

permissions issues with openzfs · Issue #28653 · systemd/systemd · GitHub

1 Like

Arch user reported updating “from 254.1-1 to 254.3-1” and problem was resolved. So it was just a regression in systemd v254.