Yesterday I did the new upgrade to OSMC 2022-3 with Kodi 19.4. Everything worked fine (despite my “slightly” non standard osmc usecase running many non-kodi services).
But there was one exception: After the upgrade I could no longer access the GPIO ports of my raspi3 from within the smarthome environment fhem. The problem was triggered by the udev rule /etc/udev/rules.d/996-fix-gpiomem.rules which is in conflict with /lib/udev/rules.d/60-rpi.gpio-common.rules. The latter udev rule is part of the package rpi.gpio-common
After removing /etc/udev/rules.d/996-fix-gpiomem.rules GPIO access works again after reboot.
Additionally the user fhem should be member of group dialout. That membership was lost when I did my first osmc installation, but I didn’t notice that till today (because fhem to my surprise worked even if not member of group dialout). Does osmc installation change group memberships (aside from adding user osmc to some groups as necessary)?
My suggestion: Please do no longer provide 996-fix-gpiomem.rules. Instead either recomment to intall rpi.gpio-common or install it automatically (it contains only the 60-rpi.gpio-common.rules udev granting access to GPIO).
We don’t ship this package by default, so I’m not sure where it came from.
Our goal is to provide the correct GPIO rules for the standard OSMC installation, which I believe we are doing.
The package rpi.gpio-common seems to be a standard debian package to adjust the access rights of GPIO ports, see
And exactly that package did the trick for my raspi3 to get access onto GPIO ports without any additional changes. On the other side, using your fix udev rule did fail for me.
Thus my suggestion: instead of providing a special udev rule you could go with the standard debian package to fix GPIO access. The only thing that I know about this package is, that it is working fine for me and that it only installs one udev rule.
i.e. I had to insert the four stars. And I had to add the user fhem into the group osmc. With the Debian package the “standard” group dialout is used being compatible with fhem. And I didn’t need to tweak the udev rule from Debian.
It was a longer “journey” for me to discover that simple solution. Of course I’m an ol’ UNIX user (using it for over 35 years), but udev is new to me.
I did a fresh bullseye installation of OSMC 2022-09 on my rasperry pi3. And sadly I encounterred exactly the same problem again. Thus I’ve deleted the OSMC provided /etc/udev/rules.d/996-fix-gpiomem.rules and replaced it from
apt update
apt install rpi.gpio-common
It would be great if OSMC would either use the debian default package or correct the broken 996-fix-gpiomem.rules.
Yes because the apt contains only one udev rule replacing the one from OSMC - see my comments some posts above. If I remember correctly, there is only a very small difference between both udevs. To be honest I didn’t even look into OSMC’s udev from bullseye (silently assuming that it will be identical to the buster one) - when I discovered the failing of GPIOs, Idirectly deleted it and installed the apt.
Sorry for coming back over and over again to my (old) problem, but it still persists within the current july OSMC release 2023.07-1.
Nevertheless the update from kodi 19.5 to kodi 20.2 worked flawlessly. Only the (old) plugin ctuplink now fails (but that’s probabely a job for the plugin developer).
Addendum: ctuplink now works fine. It “repaired” itself after some restarts of mediacenter. I assume that kodi/OSMC might do some configuration after first activation despite the kodi GUI is fully functional.
Thus I’m now completely happy with the new OSMC release (despite my GPIO issue).
I’d suggest to drop the OSMC specific udev rule for GPIO and instead provide the installation of the GPIO udev apt (see above) optionally as part of OSMC’s store (where you also provide cron). Or you change your GPIO udev as described above.
The RPI GPIO package changes groups and this probably isn’t necessary. Instead, I’d suggest removing the old rule (as you did before) and seeing if this rule works sufficiently:
To clarify: you should remove the /etc/udev/rules.d/996-fix-gpiomem.rules rule that we provide as well as the rpi.gpio-common package, and then reboot.
If this works as expected, I’ll get it in for the next update
Thanks for your reply. Of course I will test your proposal. But I have two questions:
Why not using the (probably) well established apt package rpi.gpio-common and duplicating it more or less instead? Even the group dialout is well established for such usecases (I remember back to old UNIX times when modems only worked for group dialout:-).
What filename/path should I use for your suggested change, again /etc/udev/rules.d/996-fix-gpiomem.rules?
Today I had time to read my documentation on this topic - in short: for me it’s essential to go with group dialout.
I’m using the smarthome tool fhem to access the GPIO ports. fhem is a perl program running as a service with the user fhem. This user fhem is by default member of the group dialout (BTW, the complete fhem installation tree is given to group dialout). Thus if using the standard debian package rpi.gpio-common, fhem is granted access to GPIO exactly by that group dialout without any additional configuration.
Of course I could add fhem into group video which probably will grant access by your proposed udev rule. But the group video is not the “correct” group for GPIO pins (see SystemGroups - Debian Wiki). But one might as well discuss if group dialout is any better:-)
Inspecting the debian package Debian -- Informationen über Paket rpi.gpio-common in bullseye a little deeper, you’ll see that there is still a known & pending problem due to its udev rule, it’s shell command is truncated after 1023 chars triggering problems. I guess that this issue is a problem within udev itself. But from that you may conclude that going with a standard package might be better, since you’ll get updates automatically when a fix becomes available.
Since osmc doesn’t use GPIO pins to my knowledge at all (despite IR senser, but that does NOT depend on this udev rule), maybe the “best” solution for osmc might be to drop 996-fix-gpiomem.rules completely without replacement? Why should osmc “solve” problems for “other” tools unrelated with osmc/kodi?