I’m really liking the idea of Fedora IoT on the Raspberry Pi and it’s Podman usage.
I haven’t had much success in interfacing the GPIO pins inside a Podman container, is there any documentation or support out there which I may find useful?
I don’t know, sorry.
But many softwares, like the gpiozero Python library, use the GPIO sysfs interface (/sys/class/gpio), while in Fedora the kernel is compiled without this support, in favour of the more modern character device /dev/gpiochipN.
Maybe Node-RED still expect that there is a GPIO sysfs interface?
I’m not an expert: this is only a hypothesis.
That may be so, seems like a lot of software which interacts the GPIO pins use /sys/class/gpio.
Why would Fedora not have compiled kernel GPIO sysfs support for Raspberry Pis?
Well, since linux 4.8 the GPIO sysfs interface is deprecated, and as far as I can understand, in Fedora the goal is to have follow upstream as much as possible.
I was also following the instructions in the article (thanks a lot for that) to get me started with libgpiod.
I got two related questions:
Is there any way to avoid running the podman container with sudo and still have access to GPIO inside the container?
Tried giving the user running podman ownership and permissions (rw) on /dev/gpiochip0 with
Starting from the setup according to the article, I tried to control the GPIO on a RPi3 with Rust using this crate and ran into an “UnknownModel” Error:
/// Unknown model.
///
/// The Raspberry Pi model or SoC can't be identified. Support for
/// new models is usually added shortly after they are officially
/// announced and available to the public. Make sure you're using
/// the latest release of RPPAL.
///
/// You may also encounter this error if your Linux distribution
/// doesn't provide any of the common user-accessible system files
/// that are used to identify the model and SoC.
So I was wondering if that was related to the podman user not having access to the relevant info or a more general issue with Fedora IOT on my RPi3.
Output of sudo dmidecode -t baseboard on the host gave me
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
Wrong DMI structures length: 209 bytes announced, only 128 bytes available.
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.