[GH-ISSUE #2050] [ARM64v8] Unable to get it to start #1137

Closed
opened 2026-03-03 02:06:33 +03:00 by kerem · 8 comments
Owner

Originally created by @XxAcielxX on GitHub (Oct 20, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2050

Subject of the issue

Unable to get vaultwarden/server:latest image to work on ARM64v8.

Deployment environment

  • vaultwarden version: N/A

  • Install method: Docker cli

docker run -d \
  --name vaultwarden \
  --net=adnio \
  --ip=172.18.0.22 \
  -v /media/Docker/appdata/vaultwarden/:/data/ \
  -p 8020:80 \
  --restart unless-stopped \
  vaultwarden/server:latest
  • Clients used: Android

  • Reverse proxy and version: Couldn't even get to this part.

  • MySQL/MariaDB or PostgreSQL version: N/A

  • Other relevant details: N/A

Steps to reproduce

  1. Do docker pull vaultwarden/server:latest
  2. Then run docker cli (as mentioned above)

Expected behaviour

The container should start normally.

Actual behaviour

The container doesn't start at all and goes into bootloop with nothing showing up in container logs.

Troubleshooting data

# uname -a
Linux NanoPC-T4 5.10.47 #1 SMP Tue Aug 10 16:48:07 CEST 2021 aarch64 GNU/Linux

# docker info
Client:
 Debug Mode: false

Server:
 Containers: 15
  Running: 13
  Paused: 0
  Stopped: 2
 Images: 15
 Server Version: 19.03.15
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: journald
 Cgroup Driver: systemd
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8fba4e9a7d01810a393d5d25a3621dc101981175
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version:
 Kernel Version: 5.10.47
 Operating System: LibreELEC (official): 10.0.0
 OSType: linux
 Architecture: aarch64
 CPUs: 6
 Total Memory: 3.778GiB
 Name: NanoPC-T4
 ID: DTLH:RKKR:V54S:BNJK:LPAG:6KVA:5TVY:5VNT:GI5Q:HD54:R7VM:7CRD Docker Root Dir: /var/media/Docker/root
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

# docker pull vaultwarden/server:latest
latest: Pulling from vaultwarden/server
Digest: sha256:fe2a236b792fb2304ef50f86f1c25076ac5b2748e1b776fce260ad12ad29188d
Status: Image is up to date for vaultwarden/server:latest
docker.io/vaultwarden/server:latest

# docker inspect vaultwarden/server:latest | grep Id
        "Id": "sha256:6d345ab27b52b91aced94e9508634cb6d267e6378198e2c1e54103a936ead164",

There is only root user from which evrything is installed through.

Originally created by @XxAcielxX on GitHub (Oct 20, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2050 ### Subject of the issue Unable to get `vaultwarden/server:latest` image to work on ARM64v8. ### Deployment environment * vaultwarden version: N/A * Install method: Docker cli ``` docker run -d \ --name vaultwarden \ --net=adnio \ --ip=172.18.0.22 \ -v /media/Docker/appdata/vaultwarden/:/data/ \ -p 8020:80 \ --restart unless-stopped \ vaultwarden/server:latest ``` * Clients used: Android * Reverse proxy and version: Couldn't even get to this part. * MySQL/MariaDB or PostgreSQL version: N/A * Other relevant details: N/A ### Steps to reproduce 1. Do `docker pull vaultwarden/server:latest` 2. Then run docker cli (as mentioned above) ### Expected behaviour The container should start normally. ### Actual behaviour The container doesn't start at all and goes into bootloop with nothing showing up in container logs. ### Troubleshooting data ``` # uname -a Linux NanoPC-T4 5.10.47 #1 SMP Tue Aug 10 16:48:07 CEST 2021 aarch64 GNU/Linux # docker info Client: Debug Mode: false Server: Containers: 15 Running: 13 Paused: 0 Stopped: 2 Images: 15 Server Version: 19.03.15 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: journald Cgroup Driver: systemd Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: 8fba4e9a7d01810a393d5d25a3621dc101981175 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec init version: Kernel Version: 5.10.47 Operating System: LibreELEC (official): 10.0.0 OSType: linux Architecture: aarch64 CPUs: 6 Total Memory: 3.778GiB Name: NanoPC-T4 ID: DTLH:RKKR:V54S:BNJK:LPAG:6KVA:5TVY:5VNT:GI5Q:HD54:R7VM:7CRD Docker Root Dir: /var/media/Docker/root Debug Mode: false Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false WARNING: No cpu cfs quota support WARNING: No cpu cfs period support # docker pull vaultwarden/server:latest latest: Pulling from vaultwarden/server Digest: sha256:fe2a236b792fb2304ef50f86f1c25076ac5b2748e1b776fce260ad12ad29188d Status: Image is up to date for vaultwarden/server:latest docker.io/vaultwarden/server:latest # docker inspect vaultwarden/server:latest | grep Id "Id": "sha256:6d345ab27b52b91aced94e9508634cb6d267e6378198e2c1e54103a936ead164", ``` There is only root user from which evrything is installed through.
kerem closed this issue 2026-03-03 02:06:33 +03:00
Author
Owner

@BlackDex commented on GitHub (Oct 20, 2021):

What do you see if you start it without -d?

<!-- gh-comment-id:947688502 --> @BlackDex commented on GitHub (Oct 20, 2021): What do you see if you start it without `-d`?
Author
Owner

@XxAcielxX commented on GitHub (Oct 20, 2021):

What do you see if you start it without -d?

Nothing shows up at all. In Portainer, Status is Stopped for 2 minutes with exit code 132. The image sha256 for arm64 my system pulled doesn't even match with the one from the latest arm64.

<!-- gh-comment-id:947732412 --> @XxAcielxX commented on GitHub (Oct 20, 2021): > What do you see if you start it without `-d`? Nothing shows up at all. In Portainer, Status is ` Stopped for 2 minutes with exit code 132`. The image sha256 for arm64 my system pulled doesn't even match with the one from the latest arm64.
Author
Owner

@XxAcielxX commented on GitHub (Oct 21, 2021):

My guess was totally correct, doing docker pull vaultwarden/server:latest is not pulling the correct image for my arch (arm64v8 or aarch64), but some unknown image.

I now pulled using the digest id, vaultwarden/server@sha256:4b072e53a84aa6fe57a658d71e6674466b9719b3a066a3c915ba052647503b08 which was updated like 10h ago. Now I'm able to run Vaultwarden container.

Why is this even happening?

<!-- gh-comment-id:948347607 --> @XxAcielxX commented on GitHub (Oct 21, 2021): My guess was totally correct, doing `docker pull vaultwarden/server:latest` is not pulling the correct image for my arch (arm64v8 or aarch64), but some unknown image. I now pulled using the digest id, `vaultwarden/server@sha256:4b072e53a84aa6fe57a658d71e6674466b9719b3a066a3c915ba052647503b08` which was updated like 10h ago. Now I'm able to run Vaultwarden container. Why is this even happening?
Author
Owner

@jjlin commented on GitHub (Oct 21, 2021):

What does docker inspect vaultwarden/server:latest | grep -i arch say?

You could also try upgrading to Docker 20.10.x since the 19.03.x branch is pretty much dead anyway.

<!-- gh-comment-id:948924084 --> @jjlin commented on GitHub (Oct 21, 2021): What does `docker inspect vaultwarden/server:latest | grep -i arch` say? You could also try upgrading to Docker 20.10.x since the 19.03.x branch is pretty much dead anyway.
Author
Owner

@XxAcielxX commented on GitHub (Oct 22, 2021):

What does docker inspect vaultwarden/server:latest | grep -i arch say?

# docker inspect vaultwarden/server:latest | grep -i arch
                "io.balena.architecture": "rpi",
        "Architecture": "arm",

You could also try upgrading to Docker 20.10.x since the 19.03.x branch is pretty much dead anyway.

I'm using latest release of LibreELEC 10 and Docker 19.03.x is the only version available.

The one I'm using now is:

# docker inspect vaultwarden/server@sha256:4b072e53a84aa6fe57a658d71e6674466b9719b3a066a3c915ba052647503b08 | grep -i arch
                "io.balena.architecture": "aarch64",
                "io.balena.qemu.version": "6.0.0+balena1-aarch64",
        "Architecture": "arm64",
<!-- gh-comment-id:949330371 --> @XxAcielxX commented on GitHub (Oct 22, 2021): > What does `docker inspect vaultwarden/server:latest | grep -i arch` say? ``` # docker inspect vaultwarden/server:latest | grep -i arch "io.balena.architecture": "rpi", "Architecture": "arm", ``` > You could also try upgrading to Docker 20.10.x since the 19.03.x branch is pretty much dead anyway. I'm using latest release of LibreELEC 10 and Docker 19.03.x is the only version available. The one I'm using now is: ``` # docker inspect vaultwarden/server@sha256:4b072e53a84aa6fe57a658d71e6674466b9719b3a066a3c915ba052647503b08 | grep -i arch "io.balena.architecture": "aarch64", "io.balena.qemu.version": "6.0.0+balena1-aarch64", "Architecture": "arm64", ```
Author
Owner

@jjlin commented on GitHub (Oct 22, 2021):

Well, it's up to the local Docker install to select the proper image based on its local arch, so if it's not doing that, you should probably bring it up with the LibreELEC project. Maybe they ship a build of Docker with their own patches, or maybe the issue is fixed in a later version of Docker.

I have access to an ARMv8 machine running Docker 20.10.x, and it pulls the correct image there. Using docker pull --platform linux/arm64 vaultwarden/server:latest might be a viable workaround for now, assuming your Docker version supports the --platform flag -- I don't remember when support for that was added.

<!-- gh-comment-id:949365470 --> @jjlin commented on GitHub (Oct 22, 2021): Well, it's up to the local Docker install to select the proper image based on its local arch, so if it's not doing that, you should probably bring it up with the LibreELEC project. Maybe they ship a build of Docker with their own patches, or maybe the issue is fixed in a later version of Docker. I have access to an ARMv8 machine running Docker 20.10.x, and it pulls the correct image there. Using `docker pull --platform linux/arm64 vaultwarden/server:latest` might be a viable workaround for now, assuming your Docker version supports the `--platform` flag -- I don't remember when support for that was added.
Author
Owner

@XxAcielxX commented on GitHub (Oct 22, 2021):

You might be right as this could be a distro related or docker version issue. I'll see if I can ask the Team LibreELEC to update the Docker to the latest version.

--platform is a workaround for now, but it is still an experimental feature in Docker 19.03.x, I'll try to enable it for now to use that. Thanks for the help mate.

<!-- gh-comment-id:949369051 --> @XxAcielxX commented on GitHub (Oct 22, 2021): You might be right as this could be a distro related or docker version issue. I'll see if I can ask the Team LibreELEC to update the Docker to the latest version. `--platform` is a workaround for now, but it is still an experimental feature in Docker 19.03.x, I'll try to enable it for now to use that. Thanks for the help mate.
Author
Owner

@BlackDex commented on GitHub (Oct 22, 2021):

These were indeed also issues which other users reported having with docker and multi-arch images. Not sure if you can update the docker daemon on it? If it is Debian based then you could take a look here: https://docs.docker.com/engine/install/debian/
Since docker-ce does have arm64/aarch64 builds.

<!-- gh-comment-id:949382589 --> @BlackDex commented on GitHub (Oct 22, 2021): These were indeed also issues which other users reported having with docker and multi-arch images. Not sure if you can update the docker daemon on it? If it is Debian based then you could take a look here: https://docs.docker.com/engine/install/debian/ Since docker-ce does have arm64/aarch64 builds.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#1137
No description provided.