evcc on Raspberry Pi 1 Model B+ Docker version isn't working anymore - config works using macOS

[kevbenjam]

The evcc.io Docker installation on my Raspberry Pi 1 Model B+ isn't working anymore. It was working for a very long time and it seems that it isn't a problem with the evcc.yaml because the config is working with the macOS version of evcc. Raspberry Pi 1 Model B+ on Alpine Linux – Docker version is 24.0.7 – Docker Compose version is 2.23.0 – evcc Docker image 0.121.5

The docker-compose.yml looks the following:

version: '3'
services:
evcc:
command:
- evcc
image: evcc/evcc:latest
container_name: evcc
ports:
- 7070:7070/tcp
- 8887:8887/tcp
- 7090:7090/udp
- 9522:9522/udp
volumes:
- ./evcc.yaml:/etc/evcc.yaml
- ./.evcc:/root/.evcc
restart: unless-stopped

The error code in docker-compose while starting evcc is either 0 or 132 – What could be the issue?

[StefanSchoof]

What does docker compose log say?

[kevbenjam]

It currently says "evcc exited with code 132" or "evcc exited with code 0"

[StefanSchoof]

Did you pull the latest version. There was one version with at bug at the mqtt: #10549

[kevbenjam]

Thank you for helping. I've set image: evcc/evcc:0.121.5 in Docker Compose – So it should be the latest version currently available.

[GrimmiMeloni]

@kevbenjam You mentioned it worked for a long time. What did you change that caused these issues to start?

[kevbenjam]

@GrimmiMeloni Raspberry Pi 1 with Alpine Linux 3.22.0_alpha20241224 (Linux version 6.12.6-0-rpi). Locally 0.132.0 is starting up and running, within the Docker container it isn't. @StefanSchoof Really good catch with the GOARM value.

@andig die Frage ist wirklich, ob sich das lohnt. Unter #9104 sah es jedoch auch mal ähnlich aus. Danke für die Infos, die mir helfen könnten, lokal selbst einen Docker container zu bauen. Das Problem von @repo-fredo könnte jedoch auch zusammenhängend gewesen sein. Klar ist da die Frage, ob sich das mit dem Mapping auf GOARM=5 wirklich lohnt, zumal ARMv6 wohl mit der Zeit immer weniger werden wird.

[GrimmiMeloni]

Bliebe nur linux/arm/v6 auf GOARM=5 statt 6 zu mappen.

Das Problem ist doch das die docker buildx Platform (linux/arm/v6) nicht zu GOARM=6 führt. Da scheint es am Zusammenspiel von buildx und go zu scheitern. Würde ein explizites GOARM=6 im build env nicht bereits ausreichen? Anders gefragt, wieso „all the way“ zurück auf 5 ?

Ich habe auch #4178 im Verdacht

Ja, das hatte ich vorhin auch gesehen. Soweit ich es gesehen habe, wird TARGETVARIANT nirgends gesetzt. Ist das ein Überbleibsel vom alten build System das vor buildx im Einsatz war?

[andig]

Du hast recht, das ist tatsächlich komisch. Da brauchts wohl Debugging des Dockerfiles. Anscheinend tut das nicht wie erwartet:

 => [builder 16/17] RUN case "v6" in  "armhf") export GOARM='6' ;;  "armv7") export GOARM='6' ;;  "v6") export GOARM='6' ;;  "v7") export GOARM='7' ;;  esac;                                                                         0.1s
 => [builder 17/17] RUN RELEASE=0 GOOS=linux GOARCH=arm make build      

[StefanSchoof]

Soweit ich es gesehen habe, wird TARGETVARIANT nirgends gesetzt. Ist das ein Überbleibsel vom alten build System das vor buildx im Einsatz war?

TARGETVARIANT kommt von buildx
https://docs.docker.com/build/building/variables/#multi-platform-build-arguments

[GrimmiMeloni]

Gave it a shot: #17959

Not sure how robust the variable translation is, but locally this does not break also for multiarch builds and platforms where TARGETVARIANT is not present.