home-assistant / home-assistant/supervisor
LEDs in `/sys/class/leds` not usable due to Supervisor's read-only mount; related to `GPIO: true`
- Dominant language
- Python
- Stars
- 2.2k
- Forks
- 806
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 55
Description
### Describe the issue you are experiencing
My addon to control RPi power and activity LEDS needs write access to `/sys/class/leds`. https://docs.kernel.org/leds/leds-class.html. HassOS + Supervisor mounts it read-only. No perm setting, e.g. `full_access: true` can enable this. This issue is the mount as read-only. Therefore, it is not possible to control these LEDs from an addon. 😞
This issue is more about permission policies/feature. Refer to the sister issue of GPIO support `gpio: true` in https://github.com/home-assistant/supervisor/issues/201#issuecomment-333289235.
On RPi+kernels I've tested...individual LEDs in `/sys/class/leds` are symlinks to `../../devices/platform/leds` aka `/sys/devices/platform/leds`. The technical solution is a rw mount of `/sys/class/leds` and `/sys/devices/platform/leds` like was done for GPIO in the sister issue and implemented here
https://github.com/home-assistant/supervisor/blob/2605f856687cac5a4918d2e545a563a0a8de1b23/supervisor/docker/addon.py#L409
A fixes can be trivial. It is a philosophy choice...
* Since LEDs are very often controlled by GPIOs, the two needed rw mounts could be added to the set of GPIO mount points above. I lean towards this approach since they are highly related. Happy to submit a PR.
* Or a new permission setting `leds: true` could be created which is likely a copy/paste of much of the GPIO code.
* Or something using the "boards API" of https://github.com/home-assistant/supervisor/pull/3984 might be used. This seems far more complex, a lot of code to do what seems simple https://github.com/home-assistant/supervisor/pull/4556, and is only supported by HA+Supervisor. I do not prefer this solution due to its complexity and that it requires a Supervisor install.
### What type of installation are you running?
Home Assistant OS
### Which operating system are you running on?
Home Assistant Operating System
### Steps to reproduce the issue
### Repro
1. Haos install on RaspberryPi 3 or 4B. (will likely reproduce on all RPi)
2. Create a basic addon.
3. Add every possible permission to `config.yaml`. Any combination will repro the issue. For example
```
usb: true
gpio: true
apparmor: false
privileged:
- SYS_ADMIN
- SYS_RAWIO
```
4. In your addon Dockerfile, make it run a bash script that has `echo "none" > /sys/class/leds/PWR/trigger`
5. install your addon, disable protection if you want (doesn't matter), and start your addon
### Result
Addon fails with error in logs
```
/run.sh: line xx: /sys/class/leds/PWR/trigger: Read-only file system
```
If you add in your `run.sh` a line with `mount`, then the log will also show all mounts within that container. And you will see the cause of the error is due to the RO mount of /sys.
```
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
```
### Expected
No error.
### Anything in the Supervisor logs that might be useful for us?
```txt
n/a
```
### System Health information
## System Information
version | core-2023.9.1
-- | --
installation_type | Home Assistant OS
dev | false
hassio | true
docker | true
user | root
virtualenv | false
python_version | 3.11.5
os_name | Linux
os_version | 6.1.21-v8
arch | aarch64
timezone | Europe/Berlin
config_dir | /config
Home Assistant Cloud
logged_in | false
-- | --
can_reach_cert_server | failed to load: timeout
can_reach_cloud_auth | failed to load: timeout
can_reach_cloud | ok
Home Assistant Supervisor
host_os | Home Assistant OS 10.5
-- | --
update_channel | stable
supervisor_version | supervisor-2023.08.3
agent_version | 1.5.1
docker_version | 23.0.6
disk_total | 57.8 GB
disk_used | 5.0 GB
healthy | true
supported | true
board | rpi3-64
supervisor_api | ok
version_api | failed to load: timeout
installed_addons | AdGuard Home (4.8.14), Studio Code Server (5.10.1), Z-Wave JS (0.1.90), Cloudflared (4.2.6), Terminal & SSH (9.7.1), Raspberry Pi LED control (0.1.37)
Dashboards
dashboards | 2
-- | --
resources | 0
views | 1
mode | storage
Recorder
oldest_recorder_run | September 12, 2023 at 3:00 PM
-- | --
current_recorder_run | September 12, 2023 at 5:00 PM
estimated_db_size | 47.34 MiB
database_engine | sqlite
database_version | 3.41.2
### Supervisor diagnostics
[config_entry-hassio-2cb0d81ab06d8ffebfd5deffc58e5aaa.json.txt](https://github.com/home-assistant/supervisor/files/12597319/config_entry-hassio-2cb0d81ab06d8ffebfd5deffc58e5aaa.json.txt)
### Additional information
_No response_
Contributor guide
Research direction
Start with supervisor/docker/addon.py around line 409 and review the existing GPIO mount handling. Reproduce the issue with an add-on that writes to /sys/class/leds/PWR/trigger, then determine which permission-policy approach is accepted. Done means an add-on can control the relevant LED paths without a read-only filesystem error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, python
- Domain
- embedded-iot, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100