(Bug report) No docker images available for ARM machines, despite the documentation advertising their availability.

[fvbommel]

TriliumNext Version

v0.90.3

What operating system are you using?

Ubuntu

What is your setup?

Server access only

Operating System Version

Ubuntu 24.04: Linux pi4b 6.8.0-1008-raspi #8-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 16 19:17:49 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

Description

According to the Docker Server Installation for Trilium instructions:

Official docker images are published on docker hub for AMD64, ARMv6, ARMv7 and ARMv8/64: https://hub.docker.com/r/triliumnext/notes/

(emphasis added)

Unfortunately, this does not seem to be correct: I tried to install the docker image on my Raspberry Pi 4B, but got

no matching manifest for linux/arm64/v8 in the manifest list entries

Clicking on the Docker Hub link above, I found only linux/amd64 images.

---

Looking for the GitHub workflows, I found a docker.yaml in the workflows_old folder that should work with minor modifications to also push non-amd64 versions of the containers. Presumably this workflow is what zadam/trilium used to push the image I'm trying to upgrade from?

Error logs

$ cat docker-compose.yaml

version: '3.9'

services:
  trilium:
    image: triliumnext/notes:v0.90.3
    container_name: trilium
    hostname: trilium
    volumes:
      - ./data:/home/node/trilium-data
    restart: unless-stopped

$ docker compose pull
[+] Pulling 0/1
⠇ trilium Pulling 1.9s
no matching manifest for linux/arm64/v8 in the manifest list entries

[eliandoran]

@fvbommel , you are right. I'll check what the original workflow did and address it ASAP.

[perfectra1n]

Currently there's a lot of issues with building arm/v7 and arm/v6 using GitHub Actions, we're trying to work through them:
docker/build-push-action#1071
docker/build-push-action#977
nodejs/docker-node#2077

[fvbommel]

According to this comment, the issue is triggered by running npm install with Node v20 on 32-bit ARM using QEMU in an Action, and a workaround is running that part in Node v18 instead (the rest of the build can still use v20).

I see this project's Dockerfile is indeed using node:20.15.1-alpine, so perhaps that workaround could be used here too? It'd require splitting the Dockerfile into two stages, a new initial one to run npm install in a stage running on node:18-alpine (or a more specific version if you prefer), then something like COPY --from=npm-install-stage /usr/src/app/node_modules /usr/src/app/node_modules in the "main" stage.

[eliandoran]

@fvbommel , I believe @perfectra1n already tried this approach and he ran into a new obscure problem when trying to run it. I think related to https://issues.chromium.org/issues/42201927 (most likely due to our transition from CJS to ESM).

[Aareon]

Commenting to say I'm available to test on ARM64v8

[perfectra1n]

Yeah I tried exactly the process you suggested @fvbommel and ran into quite a few strange errors, such as:

docker run testingnotes
No USER_UID specified, leaving 1000
No USER_GID specified, leaving 1000
(node:1) ExperimentalWarning: Importing JSON modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Generated session secret


#
# Fatal error in , line 0
# Check failed: module->status() == kLinked || module->status() == kEvaluated.
#
#
#
#FailureMessage Object: 0x7ffc01003cf0
----- Native stack trace -----

I split the container into the "build step" using Node v18, and then changed to use the "run step" at Node v20, copying over the node modules, etc., and the above error popped up every time.

So the next best option that I found was to instead use node's slim Debian container instead, so that we could at least get ARM builds out the door. We will have to drop ARMv6 compatibility, but instead we can then add ARM64v8 builds.

I know that Debian's slim containers are larger than Alpine's, but at least we can then have ARMv7 / ARM64v8.

#314

[perfectra1n]

So this change will work for @fvbommel since they're using the Pi4 Model B, which uses ARMv7 ARMv8.

Edit: Meant to say ARMv8, typo

[fvbommel]

the Pi4 Model B, which uses ARMv7

I think that's a typo? The Pi4B uses ARMv8. (The Pi2B uses ARMv7 according to Wikipedia)

So yes, for me personally this change should work since linux/arm64/v8 is what my Docker was looking for.

We will have to drop ARMv6 compatibility

Then the docs should probably be updated to reflect that.

[Aareon]

Looking forward to a release for this fix. Would anyone be willing to offer some steps to run prior to release via compose?

[eliandoran]

@Aareon , you could have a look at the develop images, which have support for linux/amd64, linux/arm64 and linux/arm/v7.

See https://hub.docker.com/layers/triliumnext/notes/develop/images/sha256-a48db5e2cc67d509c42218d0d2ca2272cea66fb1b8be1d1b929e503fc4e16d5e?context=repo

I don't have any ARM-based machines on my side so a test on this image would be much appreciated.

[ndaidong]

@Aareon , you could have a look at the develop images, which have support for linux/amd64, linux/arm64 and linux/arm/v7.

See https://hub.docker.com/layers/triliumnext/notes/develop/images/sha256-a48db5e2cc67d509c42218d0d2ca2272cea66fb1b8be1d1b929e503fc4e16d5e?context=repo

I don't have any ARM-based machines on my side so a test on this image would be much appreciated.

This image works on my Raspberry Pi 5.

[fvbommel]

The released version works, thanks. 👍

[eliandoran]

@fvbommel , thank you for being so reactive!