build: bump app base image to fix 'GLIBC_2.34' not found error

[JakobLichterfeld]

I mess around and went back a version of your PR which didn't result in an improvement in my sleep behavior (you're probably right that I need a new 12v). Now trying to pull and run the latest of your PR results in the follow error. The latest from the repo does successfully run, so something specific with the PR. Any ideas?
/opt/app/erts-14.2.2/bin/erlexec: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /opt/app/erts-14.2.2/bin/erlexec)

Originally posted by @Dhtjf in #3084 (comment)

My suspicion is now on the github action that builds the image.
I haven't look that much into it, but there is a new version, which might have changed something:

The right one works.
The left one fails with: /opt/app/erts-14.2.2/bin/erlexec: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /opt/app/erts-14.2.2/bin/erlexec

Originally posted by @micves in #3084 (comment)

Edge appears to also have the GLIBC_2.34 error.

Originally posted by @DrMichael in #3084 (comment)

I can take a look into the ghcr builds next week

Originally posted by @JakobLichterfeld in #3084 (comment)

Relevant log output

/opt/app/erts-14.2.2/bin/erlexec: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /opt/app/erts-14.2.2/bin/erlexec)

Type of installation

Docker

Version

ghcr.io/teslamate-org/teslamate:pr-3262

[JakobLichterfeld]

Has been an issue in the past, see

teslamate/CHANGELOG.md

Line 384 in 8e7d514

- Bump app base image to Debian 11 to fix `GLIBC_2.29' not found` error

[micves]

Nice find, would it make sense to use debian:latest to avoid similar things in the future? Or could that just cause other issues that we never now when it will change?

And we might have new problems with the build due to the new bookworm image:
https://github.com/teslamate-org/teslamate/actions/runs/8054386860

[JakobLichterfeld]

Nice find, would it make sense to use debian:latest to avoid similar things in the future? Or could that just cause other issues that we never now when it will change?

And we might have new problems with the build due to the new bookworm image:
https://github.com/teslamate-org/teslamate/actions/runs/8054386860

No, good practice is to pin all versions. Best would be to build the docker file with nix, as it would be really reproducible and declarative.

Damn, need more testing

[JakobLichterfeld]

libssl and netcat cause the problems in bookworm, local testing looks promising

[JakobLichterfeld]

Closed by 776e7a2 (Typo in referenced issue)

[brianmay]

The key issue here is that we use multi stage docker builds (as is recommended practice here). The build one has:

FROM elixir:1.16 AS builder

The final one has:

FROM debian:bookworm-slim AS app
...
RUN apt-get update && apt-get install ...

When you update the build image you also need to update the Debian image and Debian packages to keep them in sync. And determining what versions to use isn't always easy. There could be circumstances where this isn't always the latest Debian version - particularly if you want to build an old version of Teslamate that is based on an older version of elixir.

Yes, building the Docker image from nix would be another solution. Don't think we are quite ready for that though :-)
And I still haven't been able to work out how to use nix in CI yet without slowing the CI down excessively (current pain point where I did this for another project).