Make vcgencmd and PiSupport bundled plugin work on RaspberryPi hosts

[oerkel47]

Is your feature request related to a problem? Please describe.
When using Octoprint-docker on a RPi, the bundled Plugin PiSupport doesn't load because it doesn't detect a RasperryPi. This means there will be no warning about undervoltage, throttling etc.

Describe the solution you'd like
Add information to the docs how to get the plugin and detection to work or integrate a solution that makes this "workaround" unnecessary.

Possible Solution
add to docker-compose.yml:

 volumes:
    - /usr/bin/vcgencmd:/usr/bin/vcgencmd        
    - /usr/lib/aarch64-linux-gnu/libvcos.so.0:/usr/lib/aarch64-linux-gnu/libvcos.so.0        
    - /usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0:/usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0             
 privileged: true

With the privileged setting active, octoprint is able to determine the host as a Pi and enable the plugin. Adding the 3 other mounts gives it access to vcgencm (which doesn't work without privileged as well).

The paths for the files are only valid for aarch64, unsure where exactly they are on the 32 bit version of rpi os (google results suggest /opt/vc/lib and /opt/vc/bin)

Other options
Maybe integrate vcgencmd into the image directly to avoid privilege setting or find a way without privileged mode.
Google results suggest that adding/installing raspberrypi packages can do the trick (example: "RUN apk add raspberrypi" in Dockerfile which adds rpi support to alpine images).

Additional context
The privilege mode might not be desirable. Cap_add SYS_ADMIN is not enough.

[piter-pit]

for raspberry pi 4 32-bit I had to set up following volumes:
- /usr/bin/vcgencmd:/usr/bin/vcgencmd
- /opt/vc/lib/libvcos.so:/usr/lib/arm-linux-gnueabihf/libvcos.so.0
- /opt/vc/lib/libvchiq_arm.so:/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0

[Caroga]

For those running DietPi on a RPI3B+ 64bit, this is a working setup:

version: '3.8'
services:
  octoprint:
    image: octoprint/octoprint:1.8.1
    restart: unless-stopped
    privileged: true
    ports:
      - 80:80
    volumes:
     - octoprint:/octoprint
     - /usr/bin/vcgencmd:/usr/bin/vcgencmd
     - /usr/lib/arm-linux-gnueabihf/libvcos.so.0:/usr/lib/arm-linux-gnueabihf/libvcos.so.0
     - /usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0:/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0
    logging:
     options:
      max-size: "10m"
volumes:
  octoprint:

This has a pre-existing octoprint volume which you create simply like docker volume create octoprint before upping the docker compose file.
Log settings are not mandatory ofcourse.

-- Edit

I also added root to the video group on the host, I don't know if this is mandatory or not but I did it anyways.

[danielXengines]

Thank you for sharing Caroga, your solution worked for me. vcgencmd now works and now warnings reported on this issue. I am running a Raspi 4B with bullseye.

    volumes:
     - octoprint:/octoprint
     - /usr/bin/vcgencmd:/usr/bin/vcgencmd
     - /usr/lib/arm-linux-gnueabihf/libvcos.so.0:/usr/lib/arm-linux-gnueabihf/libvcos.so.0
     - /usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0:/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0

[simowilso]

Hi I'm running Octoprint 1.86.1 on an Rpi4 in a docker container. Ubuntu 22.0.4.2 LTS.
I've added these volumes:

/usr/bin/vcgencmd: /usr/bin/vcgencmd
/usr/lib/aarch64-linux-gnu/libvcos.so: /usr/lib/aarch64-linux-gnu/libvcos.so
/usr/lib/aarch64-linux-gnu/libvchiq_arm.so: /usr/lib/aarch64-linux-gnu/libvchiq_arm.so
/usr/lib/aarch64-linux-gnu/libc.so.6: /usr/lib/aarch64-linux-gnu/libc.so.6

But I get the following errors in Octoprint log:
WARNING - Cannot parse "/usr/bin/vcgencmd get_throttled" output: /usr/bin/vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: versi
on GLIBC_2.34' not found (required by /usr/bin/vcgencmd) /usr/bin/vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /usr/lib/aarch64-linux-gnu/libvchiq_arm.so)
/usr/bin/vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /usr/lib/aarch64-linux-gnu/libvcos.so) 2023-02-28 12:08:07,481 - octoprint.plugins.pi_support - WARNING - Cannot parse "/usr/bin/vcgencmd get_throttled" output: /usr/bin/vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /usr/bin/vcgencmd)
/usr/bin/vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /usr/lib/aarch64-linux-gnu/libvchiq_arm.so) /usr/bin/vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by /usr/lib/aarch64-linux-gnu/libvcos.so)

vgencmd get_throttled works fine if I run it on the host.

Any idea how to fix this?

[mcamou]

I'm also running octoprint in Docker on Ubuntu 22.04.2 LTS. After bind mounting vcgencmd and the shared libs, I also get the following:

root@67d6642b12fc:/octoprint# vcgencmd
vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by vcgencmd)
vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /lib/aarch64-linux-gnu/libvchiq_arm.so)
vcgencmd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /lib/aarch64-linux-gnu/libvcos.so)
root@67d6642b12fc:/octoprint# 

It looks like the issue is different versions of libc used by Raspbian/Debian vs. Ubuntu. Looking at all the libraries that vcgencmd references (on the host system):

$ ldd /usr/bin/vcgencmd 
        linux-vdso.so.1 (0x0000ffffb32d7000)
        libvchiq_arm.so => /lib/aarch64-linux-gnu/libvchiq_arm.so (0x0000ffffb3260000)
        libvcos.so => /lib/aarch64-linux-gnu/libvcos.so (0x0000ffffb3240000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffb3090000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffffb329e000)

linux-vdso.so.1 is a virtual shared library provided by the kernel. I tried some tricks with bind-mounting the other 4 shared libs into /opt/vcgencmd/lib and setting LD_LIBRARY_PATH to load them. I got as far as vcgencmd starting but dumping core:

# LD_LIBRARY_PATH=/opt/vcgencmd/lib /opt/vcgencmd/bin/vcgencmd
Segmentation fault (core dumped)
# LD_LIBRARY_PATH=/opt/vcgencmd/lib /opt/vcgencmd/bin/vcgencmd get_throttled
Illegal instruction (core dumped)

At this point the only "viable" option I see is reflashing using Raspbian/RaspberryPiOS instead of Ubuntu and use the bind mount. Not THAT much of a problem since I'm mounting /home/ubuntu/ via NFS from my NAS, and I changed the volume declaration in docker-compose.yml to bind-mount /home/ubuntu/octoprint on /octoprint instead of using a Docker volume (so that all my configurations are safe on my NAS in case e.g. of an SD failure), but still... not good.

Unless perhaps someone has a statically-linked version of vcgencmd around?

[mcamou]

Here's the process to get vcgencmd and the shared libs from another image: https://raspberrypi.stackexchange.com/a/120976. Perhaps the Dockerfile could be modified to add these? Either that, or modify the docker-compose.yml file and README to add the proper bind mounts, and add a mention to the README that this will only work properly if the base OS is Raspbian/RaspberryPiOS

[mcamou]

I ended up flashing Raspbian Buster. I wanted the version to be the same as the one in the Docker image to prevent .so version issues. My main gripe is that it's 32-bit only (which, now that I think about it, might have been the issue with Ubuntu)

This is my docker-compose.yml:

version: '2.4'

services:
  octoprint:
    image: octoprint/octoprint:latest
    restart: unless-stopped
    privileged: true
    ports:
      - 80:80
    volumes:
      - /home/ubuntu/octoprint:/octoprint
      - /usr/bin/vcgencmd:/usr/bin/vcgencmd
      - /opt/vc/lib/libvchiq_arm.so:/lib/arm-linux-gnueabihf/libvchiq_arm.so
      - /opt/vc/lib/libvcos.so:/lib/arm-linux-gnueabihf/libvcos.so

Everything else is commented out. I set privileged: true so that the container will start even if the printer is turned off, I assume that it's also necessary for vcgencmd to work.

With this, vcgencmd get_throttled works inside the container, and I now see the RPi temperature in the navbar (courtesy of the "Navbar Temperature Plugin").

[idaband]

i don't believe this works anymore for Bookworm release. Can anyone else confirm that too
'

[Paraphraser]

I'm seeing the opposite - still working.

On a 4GB Raspberry Pi 4 Model B Rev 1.1 running Debian GNU/Linux 12 (bookworm) installed from:

2023-10-10-raspios-bookworm-arm64-lite.img.xz

Fetch temperature:

$ vcgencmd measure_temp
temp=47.2'C

Script with a few calls to other vcgencmd sub-commands:

#!/usr/bin/env bash

SCRIPT=$(basename "$0")

# fetch status
STATUS=$(vcgencmd get_throttled | cut -d "=" -f 2)

# decode - https://www.raspberrypi.com/documentation/computers/os.html#get_throttled
echo "vcgencmd get_throttled ($STATUS)"
IFS=","
for BITMAP in \
   00,"currently under-voltage" \
   01,"ARM frequency currently capped" \
   02,"currently throttled" \
   03,"soft temperature limit reached" \
   16,"under-voltage has occurred since last reboot" \
   17,"ARM frequency capping has occurred since last reboot" \
   18,"throttling has occurred since last reboot" \
   19,"soft temperature reached since last reboot"
do set -- $BITMAP
   if [ $(($STATUS & 1 << $1)) -ne 0 ] ; then echo "  $2" ; fi
done

echo "vcgencmd measure_volts:"
for S in core sdram_c sdram_i sdram_p ; do printf '%9s %s\n' "$S" "$(vcgencmd measure_volts $S)" ; done

echo "Temperature: $(vcgencmd measure_temp)"

Running that script:

$ vcgencmd_power_report
vcgencmd get_throttled (0x0)
vcgencmd measure_volts:
     core volt=0.8438V
  sdram_c volt=1.1000V
  sdram_i volt=1.1000V
  sdram_p volt=1.1000V
Temperature: temp=47.7'C

Or fetching the amount of RAM:

$ vcgencmd get_config total_mem
total_mem=4096

I think the basic vcgencmd command is working, and at least some of its sub-commands still are, but there may be sub-commands that don't. Do you have an example of something that isn't working? If you do, I'll give it a try.

[idaband]

hmm ok. Unless i'm forwarding the wrong files from the host to the container. I'm running 32bit.

  - /usr/bin/vcgencmd:/usr/bin/vcgencmd
  - /lib/arm-linux-gnueabihf/libvchiq_arm.so.0:/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0
  - /lib/arm-linux-gnueabihf/libvcos.so.0:/usr/lib/arm-linux-gnueabihf/libvcos.so.0

[Paraphraser]

Well, to be clear:

1. My OctoPrint container is running on a 64-bit Bullseye Pi4.
2. I used a 64-bit Bookworm to test your hypothesis but OctoPrint wasn't running on that system.
3. I don't actually use the approach you describe. I wasn't even aware that it was a possibility until this moment so I'm sorry if my answer was off-point.
4. That said, the approach of mapping files (as distinct from folders) is something that I do my level best to avoid in all containers because of the way docker-compose defaults to treating any missing mappings as folders rather than files, after which you get a mess you have to unpick.
5. I do, however, track the CPU temperature of the Pi where the OctoPrint container is running so I'll explain my approach in case it helps you in your quest for a solution. I do it by having a cron job run every 5 minutes to call vcgencmd and wrap the response in an MQTT payload that goes off to Mosquitto, Node-RED, InfluxDB and is then displayed by Grafana. I do the same for all my Pis and Intel-based Macs (Apple Silicon either doesn't have an API for this or nobody's found it yet) so I can get all temps on a single chart (which helps anomalies stand out). If there was some reason why I needed the host CPU temperature to be available to a container (any container), I'd almost certainly start by subscribing to the relevant MQTT topic from inside the container.

[idaband]

4. That said, the approach of mapping files (as distinct from folders) is something that I do my level best to avoid in all containers because of the way docker-compose defaults to treating any missing mappings as folders rather than files, after which you get a mess you have to unpick.

have you tried using bind with source / destination for single files in docker?
https://stackoverflow.com/a/59554543

I could try going to 64bit but i was avoiding that due to the nature of not wanting to deal with other non-supported 64 bit stuff.

[Paraphraser]

No. But I will keep that in mind for next time. Up until now I have had two workarounds. Wherever possible I use folders. If I can't and a file is essential, I make sure to tag it :ro so there's no prospect of damage.

[Paraphraser]

That actually works quite well. I will put that on my to-do list over at IOTstack to revisit the remaining file mappings in the various service definition templates and swap those over. Thanks!