Docker images v1.1.0 and latest fail to start: GLIBC_2.38 / GLIBC_2.39 not found

[artemrootman]

The published Docker images for v1.1.0 and latest fail immediately on startup, because the morph-reth binary is linked against a newer glibc than the runtime layer provides.

Reproduction

$ docker run --rm ghcr.io/morph-l2/morph-reth:v1.1.0 --version
/usr/local/bin/morph-reth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /usr/local/bin/morph-reth)
/usr/local/bin/morph-reth: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by /usr/local/bin/morph-reth)

latest currently points at the same build and fails identically. Any subcommand fails the same way, so the image is unusable.

Affected tags

Tag	Runtime base	glibc in image	Starts
v1.1.0	Ubuntu 22.04.5 LTS	2.35	no
latest	Ubuntu 22.04.5 LTS	2.35	no
v1.0.0	Ubuntu 22.04.5 LTS	2.35	yes
v0.3.0	Ubuntu 22.04.5 LTS	2.35	yes

Analysis

The runtime layer did not change between v1.0.0 and v1.1.0 — both are Ubuntu 22.04.5 with glibc 2.35. Only the binary changed: the v1.1.0 build now requires GLIBC_2.38/GLIBC_2.39, which corresponds to Ubuntu 23.10/24.04. This looks like the build stage moved to a newer toolchain image while the runtime stage stayed on 22.04, so the resulting binary can never load.

Possible fixes

• Pin the build stage back to the same Ubuntu release as the runtime stage, or
• Move the runtime stage to Ubuntu 24.04 (glibc 2.39) to match the current builder, or
• Build a statically linked binary (e.g. musl target) so the runtime glibc no longer matters.

Also worth adding a CI smoke step that runs docker run --rm <image> --version on the built image before publishing — it would have caught this.

Host environment used for the reproduction: Ubuntu 24.04 (glibc 2.39), x86_64, Docker.