Repository navigation
GPIO permission errors after upgrade to 3.18.x (Raspbian) #791
Description
Activity
I think this is happening because
/lib/udev/rules.d/60-python-pifacecommon.rulesand/lib/udev/rules.d/60-python3-pifacecommon.rulesno longer function as expected.For example, here's
/lib/udev/rules.d/60-python3-pifacecommon.rules:KERNEL=="spidev*", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'"The directory
/sys/devices/virtual/gpiono longer exists, so the rule doesn't work.I came round this issue when testing my PiFace Digital, where pifacecommon/interrupts.py threw an exception of not finding /sys/devices/virtual/gpio.
Setting device_tree=off in config.txt makes /sys/devices/virtual/gpio reappear.
After that, PiFace Digital works as expected again.BR
OliverCan somebody explain how PiFace (my phone really wanted to write "pigface" there) uses these file nodes, and why it doesn't/can't use the nodes under /sys/class/gpio/ instead?
I believe it's just used in /lib/udev/rules.d/60-python3-pifacecommon.rules (which we include in raspbian image)
I don't buy that. Why bother changing permissions on files or directories that you aren't otherwise going to use?
Phil,
the /sys/..../gpio is used in pifacecommons/interrupts.py.I tried changing above file. Pifacedigital-emulator started up afterwards,
but didn't read the input lines then. Only output settings worked.Hope that helped,
OliverAm 07.02.2015 um 20:10 schrieb Phil Elwell notifications@github.com:
I don't buy that. Why bother changing permissions on files or directories
that you aren't otherwise going to use?—
Reply to this email directly or view it on GitHub
#791 (comment).In order for user pi to be able to access gpios without root permissions on a michine with the device tree disabled, udev rules are needed for both
/sys/class/gpioand/sys/devices/virtual/gpio. They are needed for/sys/devices/virtual/gpiobecause thegpioNdirectories in/sys/class/gpioare links to thegpioNdirectories in/sys/devices/virtual/gpio. For example, see directorygpio4here:pi@raspberrypi /sys/class/gpio $ echo 4 > export pi@raspberrypi /sys/class/gpio $ ls -la total 0 drwxrwx--- 2 root gpio 0 Feb 7 20:11 . drwxr-xr-x 38 root root 0 Feb 7 19:28 .. -rwxrwx--- 1 root gpio 4096 Feb 7 20:11 export lrwxrwxrwx 1 root gpio 0 Feb 7 20:11 gpio4 -> ../../devices/virtual/gpio/gpio4 lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0 -rwxrwx--- 1 root gpio 4096 Feb 7 19:40 unexport pi@raspberrypi /sys/class/gpio $I can't think of a sane reason to use
/sys/devices/virtual/gpioin source code as/sys/class/gpiocan always be used instead, if I'm not mistaken.Note that this only functions when the device tree is disabled. When the device tree is enabled,
/sys/devices/virtual/gpiodisappears.If the device tree is enabled, the udev rules on the Pi 2 need to use
/sys/devices/soc/3f200000.gpio/gpio/instead. The address3f200000may be different on the Pi 1, I'm not sure.Note that
/sys/devices/virtual/gpiois used in both/lib/udev/rules.d/60-python3-pifacecommon.rulesand/lib/udev/rules.d/60-python-pifacecommon.rulesin Raspbian. I've no idea how many users rely on this now.Can somebody try this modified version of
/lib/udev/rules.d/60-python-pifacecommon.rules(change either or both versions)?:KERNEL=="spidev*", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/soc/*.gpio/gpio && chmod -R 770 /sys/devices/soc/*.gpio/gpio'"It should work with and without DT, on Pi1 and Pi2.
Hi, I'm one of the Tom's at PiFace -- we're looking into this right now. :)
@pelwell The new rule works when the interrupt module in pifacecommon points to
/sys/class/gpioinstead of/sys/devices/virtual/gpio. I'm going to patch this in and the updated package should go live asap.That sounds like the right change - you can think of /sys/class/gpio as the generic interface, and /sys/devices/*/gpio as the specific implementation.
- added a commit that references this issue
on Feb 11, 2015 in /boot/config.txt
device_tree=
is the only solution for me. i am using lric_rpi and some gpios. even lirc_rpi dt_overlay is not working correctly... :(
16 remaining items
The udev rules modify the permissions asynchronously and your code runs at the same time, so your code may end up trying to access the files before the permissions are changed.
If that is the case, then how long should one wait after exporting before using the pin?
There isn't really a good answer to this question as it will be highly dependent on the current system load.
In onoff it's done like this. The code keeps attempting to set the direction of the GPIO until it succeeds. In theory it tries up to 10000 times. In practice it only has to try once or twice when the system load is "normal". After the direction has been set, onoff doesn't have any further special code for dealing with the issue.
Thank you for the tip @fivdi and the link.
I've implemented that solution now, and works great.
Sorry for late reply. I was away from my pi.
$ ls -l /sys/class/gpio/gpio10/ total 0 -rw-r--r-- 1 root root 4096 Apr 3 08:38 active_low lrwxrwxrwx 1 root root 0 Apr 3 08:38 device -> ../../../gpiochip0 -rw-r--r-- 1 root root 4096 Apr 3 08:38 direction -rw-r--r-- 1 root root 4096 Apr 3 08:38 edge drwxr-xr-x 2 root root 0 Apr 3 08:38 power lrwxrwxrwx 1 root root 0 Apr 3 08:38 subsystem -> ../../../../../../../class/gpio -rw-r--r-- 1 root root 4096 Apr 3 08:38 uevent -rw-r--r-- 1 root root 4096 Apr 3 08:38 valueThe udev rule uses $devpath to locate the device nodes, and it is looking like that mechanism isn't working in your case. Can you try these tests?:
echo 10 >/sys/class/gpio/export udevadm info --query=all --path=/sys/class/gpio udevadm info --query=all --path=/sys/class/gpio/gpio10$ udevadm info --query=all --path=/sys/class/gpio P: /class/gpio E: DEVPATH=/class/gpio E: SUBSYSTEM=subsystem $ udevadm info --query=all --path=/sys/class/gpio/gpio10 P: /devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio10 E: DEVPATH=/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio10 E: SUBSYSTEM=gpioThat all looks OK. What do you have in /etc/udev/rules.d/99-com.rules? You can omit the spi/i2c/tty rules.
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'" SUBSYSTEM=="input", GROUP="input", MODE="0660" SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"That rule for "gpio*" doesn't match the current Raspbian version - try using this instead (replacing
/devices/platform/soc/*.gpio/gpiowith$devpath):SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys$devpath && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"@XECDesign - @trgtylcnky says he is running OctoPi Raspbian. Does this look like an old Raspbian rules file, or is it some other concoction?
It looks like it's an older version of the file:
https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/c2f4795c7214a2c87589391acbae73d31e8099a3/etc/udev/rules.d/99-com.rulesWhat is the md5sum of the file? Is raspberrypi-sys-mods installed? If so, what version?
See also: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=183481
Had the same issues.
raspberrypi-sys-modswas not installed. Installing it, and confirming to overwrite/etc/udev/rules.d/99-com.rulesif prompted, resolved the issue for me. Be sure to remove any existing GPIO exports, or simply reboot - or existing exports will still have the broken permissions.In regards to @XECDesign's above question, this is what I had before (non-working):
$ ll 99-com.rules ; md5sum 99-com.rules -rw-r--r-- 1 root root 506 Nov 21 2015 99-com.rules 1de39a305333e7c5bf0dca7ba5df9bdf 99-com.rules... and after (working):
$ ll 99-com.rules ; md5sum 99-com.rules -rw-r--r-- 1 root root 983 Mar 21 2016 99-com.rules 279f8967ca1013b96aa59416fd8557ab 99-com.rulesRegarding OctoPi: I am not using OctoPi, but vitormhenrique/OctoPrint-Enclosure#16 also looks to be the same.
This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.
Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.
- added a commit that references this issue
on Apr 7, 2023
When the latest package raspberrypi-bootloader:armhf 1.20150130-1 was installed, the gpio symbolic links in /sys/class/gpio/ moved from /sys/devices/virtual/ to /sys/devices/soc/20200000.gpio.
The permissions in /sys/devices/soc/20200000.gpio do not include the "x" bit, as as such nobody but root can use the gpio.
This has changed since the latest bootloader, and the only way I can fix this is on boot, as root, run
chmod -R +x /sys/devices/soc/20200000.gpio
Is there a better way to allow a non-root user to access the GPIO?