mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Exit Code 139 with new docker multiarch on Pi Zero W #752
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kennymc-c on GitHub (Jul 22, 2020).
I just wanted to try out the new server:latest multiarch docker image on my Pi Zero W. Unfortunately bitwarden_rs doesn't start anymore and ends with an error code 139. I guess it could be due to my outdated docker-ce version (18.06.3) on raspbian stretch which I can't update due to a bug, otherwise docker won't run on my Pi Zero anymore. There is already a long issue (https://github.com/moby/moby/issues/38175). Apparently it hasn't been fixed yet. Or could it be something else?
What can I do now to get the latest updates? The current armv6 image in the docker hub seems to support only amd64. Therefore I am currently stucked to my local image.
EDIT: Probably this is the reason: https://github.com/MichaIng/DietPi/issues/3258#issuecomment-563445349
So RBPi1/Zero always need their own image /builds.
@jjlin commented on GitHub (Jul 22, 2020):
What output do you get for
docker inspect bitwardenrs/server:latest | grep -e Architecture -e Os -e Variant?Was bitwarden_rs working on this board at any point in the past? BTW, the image tagged
armv6is not an amd64 image, despite what it says. It's just a limitation in Docker tooling.@kennymc-c commented on GitHub (Jul 22, 2020):
It was working without any problems before. Good to know that thecirrent hub armv6 image still works.
Output:
So probably docker is selecting the wrong arch here like in the linked comment?
@jjlin commented on GitHub (Jul 22, 2020):
It's probably pulling the wrong image for some reason. What's the output of
docker inspect bitwardenrs/server:latest | grep Id?@kennymc-c commented on GitHub (Jul 22, 2020):
docker inspect bitwardenrs/server:latest | grep Id "Id": "sha256:4c27ca5a5705fad8197a8bb61936ecd55703d73f955e23ebe6aa0208e7aa2be4",@jjlin commented on GitHub (Jul 22, 2020):
Yeah, that's the arm/v7 image. It looks like it's basically this issue: moby/moby#41017
Similar to https://github.com/moby/moby/issues/41017#issuecomment-634072417, you can hopefully work around this by running
docker pull --platform=linux/arm/v6 bitwardenrs/server:latest, although it requires enabling experimental features in the Docker daemon. I'm also not sure when this--platformoption was introduced, so your Docker version may or may not be too old.@kennymc-c commented on GitHub (Jul 22, 2020):
Okay, that seems to work. Unfortunately the platform option does not seem to be supported in docker-compose. At the moment the only way to start the container via systemd is to edit the pull command in the service file accordingly.
Does turning on the experimental features have any disadvantages, especially in terms of security or stability?
@dani-garcia Maybe there should be a note in the wiki about this? The whole thing seems to affect all armv6 pi's.
Ok, could now update the wiki page by myself
@jjlin commented on GitHub (Jul 22, 2020):
Enabling experimental features shouldn't affect security/stability, except to the extent that the experimental features you actually use have such issues.
I think the best solution for now is probably just to retain the arch-specific tags (
arm32v6, at least), though it clutters the tag list.@kennymc-c commented on GitHub (Jul 22, 2020):
But the arch-specific tags seem not to be updated anymore
@jjlin commented on GitHub (Jul 22, 2020):
The multi-arch build actually deletes the arch-specific tags after the multi-arch manifest list is created, so that there aren't a bunch of extra tags that most people won't find useful. I'm just saying the build could be modified to skip the arch-specific tag deletion.
@jjlin commented on GitHub (Jan 11, 2021):
FYI, this issue is fixed starting in Docker 20.10.0. Raspberry Pi 1 and Zero users that upgrade to Docker 20.10.0+ don't need the arch-specific tag anymore.