Map generator crashes on arm64 libSkiaSharp undefined symbols no timeline thumbnails

[sebastianeggersberger]

Logfile

11.08.2026 15:36:13 : cmd: dotnet OSMMapGeneratorNET8.dll -jobfile /tmp/6388ab60-...
dotnet: symbol lookup error: /etc/teslalogger/Debug/net8.0/runtimes/linux-arm64/native/libSkiaSharp.so: undefined symbol: FT_Get_BDF_Property

(one per map generation attempt; after preloading the system libfreetype the next symbol fails: undefined symbol: uuid_generate_random)

Bug description
On arm64 the map generator crashes instantly, so no Timeline thumbnails are ever written and .../teslalogger-timeline-panel/dist/maps/ stays empty.

The bundled linux-arm64 libSkiaSharp.so calls into libfreetype and libuuid without declaring them: ldd lists only libpthread/libdl/libm/libc, so it loads fine and dies on the first actual call. linux-x64 is unaffected; the same installation worked before I moved it from x86_64 to arm64.

Not a duplicate of #1121: there the PNGs existed and only Grafana refused to serve them (grafana/grafana#66472, fixed in Grafana 9.5.2). Here the files are never created.

Two things in the same code path made this hard to find:

• /etc/teslalogger/Debug/net8.0/MAP-Data (referenced in the jobfile) does not exist in the container and is not created on startup.
• The parent ignores the child's exit code and stderr, so a completely broken generator looks like a healthy run; only "cmd: dotnetOSMMapGenerator..." followed by the routine Grafana restart is logged.

To Reproduce

1. Run the NET8 Docker stack on an arm64 host.
2. Complete a drive, or run the generator manually with a captured jobfile:

docker exec teslalogger sh -c 'cd /etc/teslalogger/Debug/net8.0 && \
    dotnet OSMMapGeneratorNET8.dll -jobfile /tmp/<uuid>'

3. Symbol lookup error, no PNG written.

Expected behavior
Thumbnail is written to the maps folder and shown in the Timeline panel.

Screenshots

Teslalogger Type
Docker (NET8), bassmaster187/teslalogger:latest, image created 2026-06-21,
arch arm64/linux, container base Debian 12. Host: aarch64 (Apple M1).
Unmodified official image.

11.08.2026 15:47:35 : TeslaLogger Version: 1.63.20.4
11.08.2026 15:47:35 : Logfile Version: 1.0.15.0
bassmaster187/teslalogger@sha256:65c0eebeaa5bcdbff328c245dd9dcf9177ec90bb0853d6e97bdfe2a90c0cffc5
created: 2026-06-21T12:43:17.238950239Z
arch: arm64/linux
Version 10.0.1 (commit: 5a30620b85, branch: HEAD)
aarch64

Do you use FleetAPI or old OwnersAPI
FleetAPI

Additional context
Workaround, verified: set as a container environment variable so child processes inherit it

LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libfreetype.so.6:/usr/lib/aarch64-linux-gnu/libuuid.so.1

Both libraries are already in the image. With this set the generator exits 0 and writes a correct PNG.

Proper fix would be to link libSkiaSharp for linux-arm64 with correct DT_NEEDED entries, or use SkiaSharp.NativeAssets.Linux(.NoDependencies).

ldd output:

linux-vdso.so.1 (0x0000ffff5ee78000)
	/usr/lib/aarch64-linux-gnu/libfreetype.so.6 (0x0000ffff5e530000)
	/usr/lib/aarch64-linux-gnu/libuuid.so.1 (0x0000ffff5e500000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff5e4d0000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff5e4a0000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff5e400000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff5e240000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff5ee40000)
	libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff5e200000)
	libpng16.so.16 => /lib/aarch64-linux-gnu/libpng16.so.16 (0x0000ffff5e1a0000)
	libbrotlidec.so.1 => /lib/aarch64-linux-gnu/libbrotlidec.so.1 (0x0000ffff5e170000)
	libbrotlicommon.so.1 => /lib/aarch64-linux-gnu/libbrotlicommon.so.1 (0x0000ffff5e130000)

[superfloh247]

RasPi3b also affected

[bassmaster187]

Thanks for the very detailed bug report!
I can confirm that bug occurs on docker / raspberry pi 5 arm 64bit as well.
On regular RPI3/4 images as well.

please try to use the beta tag in your docker-compose.yml file instead of latest tag.
e.g.:

teslalogger:
    image: bassmaster187/teslalogger:beta
    container_name: teslalogger
    restart: always

don't forget to go back to latest tag after test!

bug should be fixed with: https://github.com/bassmaster187/TeslaLogger/tree/NET8-fix-1747-arm64-skiasharp

@superfloh247 it seems like that fix should also apply to RPI3 / RPI4 images, so I'll try to make a version

[bassmaster187]

How to test it on docker without driving around:

docker exec -it teslalogger bash

cd /etc/teslalogger/Debug/net8.0
wget https://raw.githubusercontent.com/bassmaster187/TeslaLogger/refs/heads/master/UnitTestsTeslalogger/Testfile-T1.txt

sed -E -e 's|"filename":"[^"]*"|"filename":"/tmp/test.png"|' \
       -e 's|"MapCachePath":"[^"]*"|"MapCachePath":"/tmp/"|' \
       Testfile-T1.txt > Testfile-T1-updated.txt

dotnet OSMMapGeneratorNET8.dll -jobfile Testfile-T1-updated.txt  -debug
ls -l /tmp/*.png

if it works:

root@7d685126ef00:/etc/teslalogger/Debug/net8.0# ls -l /tmp/*.png
-rw-r--r-- 1 root root 30140 Aug 12 09:22 /tmp/14_8809_5473.png
-rw-r--r-- 1 root root 27767 Aug 12 09:22 /tmp/14_8809_5474.png
-rw-r--r-- 1 root root 27106 Aug 12 09:22 /tmp/14_8810_5473.png
-rw-r--r-- 1 root root 28288 Aug 12 09:22 /tmp/14_8810_5474.png
-rw-r--r-- 1 root root 16474 Aug 12 09:22 /tmp/test.png

on raspberries the dotnet path is different:

/home/cli/dotnet OSMMapGeneratorNET8.dll -jobfile Testfile-T1-updated.txt  -debug