The issue you are currently experiencing with OSMC
I have homegear installed for home automation on my Raspberry Pi 2 running OSMC. Prior to the April 2019 update, the homegear software was able to access GPIOs to control the GPIO-attached CC1101 RF module. The homegear software is running as user homegear. With OSMC 2019.04-1, the user homegear no longer has access to the directory /sys/class/gpio, causing my homegear setup to be unable to communicate with the GPIO-attached RF module.
What you were doing when this issue occurred
The software homegear was trying to access the file /sys/class/gpio/gpio24/direction while running as user “homegear”. Instead of being able to access the file, a “permission denied” error happened. If you want to reproduce, create another user and access any file below /sys/class/gpio/.
The device you are currently running OSMC on
Raspberry Pi 2B
What peripherals are attached to the device?
CC1101 RF module via SPI/GPIO
Has this issue been introduced by a new version of OSMC? When did the issue first appear and can you recall a time when it was not present?
It worked prior to the April 2019 update. The issue appeared in OSMC 2019.04-1. To be exact, this commit in OSMC broke my system: [package] [base-files-osmc] Fix GPIO permissions for OSMC user automa… · osmc/osmc@30cfbaf · GitHub
Deleting /etc/udev/rules.d/996-fix-gpiomem.rules and rebooting fixes the issue.
You can add a 997 rule which re-chowns it.
Indeed, that would work as well.
I’m curious, though. The problematic rule is called 996-fix-gpiomem, and the issue it is supposed to fix is probably Troubles with reading my GPIO device - #5 by sam_nazarko .
996-fix-gpiomem.rules tries (among other actions) to change the permissions on /sys/devices/virtual/gpio which seems not to exist on the Pi. Is that intentional? AFAICS it’s not present on any device with a modern kernel either.
Permissions on a Pi2 with 996-fix-gpiomem.rules:
osmc@pi2:~$ ls -ld /sys/class/gpio /sys/devices/virtual/gpio /sys/devices/platform/soc/*.gpio/gpio
ls: cannot access ‘/sys/devices/virtual/gpio’: No such file or directory
drwxrwx— 2 root osmc 0 Jun 25 23:50 /sys/class/gpio
drwxrwx— 3 root osmc 0 Jun 25 23:50 /sys/devices/platform/soc/3f200000.gpio/gpio
The non existent path can be fixed
Maybe we should change the group to video?
Just above that post there’s a link to OSMC run add-on as root - #6 by dillthedog where I suggested a rules I called /etc/udev/rules.d/01-gpio-permissions.rules containing the line:
KERNEL=="gpiomem", SUBSYSTEM=="bcm2835-gpiomem", MODE="0640", GROUP="osmc"
This udev rule can be found on my Pi, which was a complete reinstall on 10 June, though strangely dpkg can’t find its source package. Can you find /etc/udev/rules.d/01-gpio-permissions.rules on your machine?
As I recall, I used udevadm to find the correct KERNEL and SUBSYSTEM names for /dev/gpiomem:
osmc@osmc:~$ udevadm info -a /dev/gpiomem
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/virtual/bcm2835-gpiomem/gpiomem':
KERNEL=="gpiomem"
SUBSYSTEM=="bcm2835-gpiomem"
DRIVER==""
If you read the rest of Troubles with reading my GPIO device - #5 by sam_nazarko you’ll see that @sam_nazarko’s proposed 996-fix-gpiomem.rules had exactly the same error, so I’m not sure why it made into the OSMC build six months later.
Oops, so how should this look?
I think we should wait for @raspi2user to respond but the line in my post above might be enough. (It might already be in the Pi2/3 build; I haven’t had time to check.)
Edit: I’ve checked OSMC_TGT_rbp2_20190522.img and it doesn’t contain /etc/udev/rules.d/01-gpio-permissions.rules, so I obviously added it after the reinstall – which the file date/time seems to confirm.
So, the udev rule
KERNEL=="gpiomem", SUBSYSTEM=="bcm2835-gpiomem", MODE="0640", GROUP="osmc"
gives user osmc group read permission to /dev/gpiomem but I’m not sure that this is what @raspi2user needs in this case.
For me, it works without any osmc-specific udev rules because homegear takes care of owning only a specific gpio ( /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio24 ). Please note that the devices required by homegear are in subsystem gpio, not subsystem gpiomem.
osmc@pi2:~$ udevadm info /sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio24
P: /devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio24
E: DEVPATH=/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio24
E: SUBSYSTEM=gpio
The rule suggested by @dillthedog does not break my setup, so if it solves the same problem as 996-fix-gpiomem.rules, I would prefer @dillthedog’s solution.
Thanks.
Thanks for the clarification. A number of people in the past needed non-root access to /dev/gpiomem, which is the reason for the rule I proposed. On Raspbian, /dev/gpiomem is accessible either via root or via group gpio – but OSMC doesn’t have such a group, hence the udev rule.
@sam_nazarko As to how it should look, I think it will depend on your definition of “it”.
I think using your rule makes sense.