[BUG] Running armv7 container on aarch64 raspberry os host breaks with Loading failed - Passive login failed

[Apfelwurm]

Describe the bug If you start a latest octoprint container with platform linux/arm/v7 specified on an aarch64 raspbian (raspberry pi 4) and open a web Browser it returns

Loading failed
Passive login failed. Please check your [browser's error console](https://faq.octoprint.org/browser-console) and [octoprint.log](https://faq.octoprint.org/logs) for possible reasons.Also make sure that the server is actually running by reloading this page.

if i change from arm/v7 to aarch64 everything works like it is intended, but since i would like to use the 32bit version i noticed the problem

Container Details

2022-01-20T11:23:25.806Z

To Reproduce Steps to reproduce the behavior:

• use the following docker-compose.yml

version: '2.4'

services:
  octoprint:
    image: octoprint/octoprint
    platform: linux/arm/v7
    restart: unless-stopped
    ports:
      - 80:80
    volumes:
     - /var/octoprint:/octoprint

Expected behavior The container should work normally and bring up the initial setup wizzard

Screenshots

Server:

• Raspberry Pi 4 - 4gb
• Raspberry OS ( Debian GNU/Linux 11 (bullseye) )
• Docker Version: 20.10.14
• Docker Compose version v2.4.1

Desktop (please complete the following information):

• OS: Debian 10
• Browser: Brave Version 1.36.111 Chromium: 99.0.4844.51

[LongLiveCHIEF]

Does this fail every time with this same error with this same configuration?

[Paul-B]

I had the same problem on a Pi4 with 64 bit OS. After switching back to 32 bit and rebooting the Pi octoprint works normally again.

[LongLiveCHIEF]

The octoprint image is multi-arch, so leaving the platform blank should allow docker to pull the appropriate image for your docker engine.

After switching back to 32 bit and rebooting the Pi octoprint works normally again.

When you say "switching back" are you talking about a docker-compose platform config?

[Paul-B]

I mean the OS on the Pi4. There is a 32 bit version and a 64 bit version and you can switch between them at boot. If I have time to figure out how to do that (use arm64 docker build) then I will check if using docker compose with the arm64 option makes a difference so that I can run it on 64 bit Pi OS.

[LongLiveCHIEF]

it should just be used automatically based on your OS when you boot 64 bit. Next time you boot to 64 bit, run a docker info command and take a look at the engine details and it should tell you what arch it will pull for images that are multi-arch.

[Apfelwurm]

shouldn't it be possible to run an arm/v7 container on an aarch64 system? Because i need to run my raspberry on aarch64 because of some stuff happening on there which depends on the 64 bit extension, but i want to run octoprint as a 32 bit version because of the well known stability.

And like mentioned in the initial issue basically the pulling and starting of the image works like its intended, and the webserver seems to work like it should, therefore i guess the basic functionality of running an arm/v7 container on an aarch64 engine also works but something under the hood does not work.

I will run another test tomorrow to check if i can still reproduce it, initially it was reproducable. Currently i'm running the container as aarch64 but it would feel better to get the arm v7 variant running.

If i still can get it in that state (which i guess works since @Paul-B had the same problem a few days ago) i am willing to either give you any information that you need or if you can give me a little guidance i would love to help debugging the problem.

thanks anyways :)

[LongLiveCHIEF]

shouldn't it be possible to run an arm/v7 container on an aarch64 system?

That's a complicated answer when it comes to docker. I think it involves enabling Multiarch on debian, so that you get required kernel library packages for arm/v7.

Docker images rely on the host to bring library files specific to the kernel, so if your're running and pulling a platform image that isn't native to your architecture, then there could be problems.

If you're around this weekend, maybe we could connect on the OctoPrint discord and I can see if we can dig a bit deeper into this issue.