Exit Code 139 with new docker multiarch on Pi Zero W

[kennymc-c]

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 (moby/moby#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: MichaIng/DietPi#3258 (comment)
So RBPi1/Zero always need their own image /builds.

[jjlin]

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 armv6 is not an amd64 image, despite what it says. It's just a limitation in Docker tooling.

[kennymc-c]

It was working without any problems before. Good to know that thecirrent hub armv6 image still works.
Output:

"Architecture": "amd64",
"Os": "linux",

So probably docker is selecting the wrong arch here like in the linked comment?

[jjlin]

It's probably pulling the wrong image for some reason. What's the output of docker inspect bitwardenrs/server:latest | grep Id?

[kennymc-c]

docker inspect bitwardenrs/server:latest | grep Id "Id": "sha256:4c27ca5a5705fad8197a8bb61936ecd55703d73f955e23ebe6aa0208e7aa2be4",

[jjlin]

Yeah, that's the arm/v7 image. It looks like it's basically this issue: moby/moby#41017

Similar to moby/moby#41017 (comment), 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 --platform option was introduced, so your Docker version may or may not be too old.

[kennymc-c]

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]

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]

But the arch-specific tags seem not to be updated anymore

[jjlin]

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]

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.