home-assistant / home-assistant/supervisor

LEDs in `/sys/class/leds` not usable due to Supervisor's read-only mount; related to `GPIO: true`

Open
#4,560 14 comments 0 reactions 0 assignees View on GitHub
bug no-stale
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.