[BUG] Running container on Pi4 doesn't work "Passive login failed"

[TobbeJ]

Describe the bug
When starting up the container like described in reproduction steps below, when you open the octoprint web page the initial setup wizard of octoprint should start but instead you end up with an error.
The web page says "Loading error" and the text:
"Passive login failed. Please check your browser's error console and octoprint.log for possible reasons. Also make sure that the server is actually running by reloading this page."

To Reproduce
start container, for example like this:
docker run --rm --name=octoprint -p 80:80 octoprint/octoprint:1.5
on a raspberry pi.
once started, open browser and point it at the container in question and watch the error

Expected behavior
Container starts up and initial setup wizard is displayed.

Screenshots

Desktop (please complete the following information):

• OS:
• Browser chrome
• Version 87

Additional context
# uname -a
Linux pi4 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux

Note that this is aarch64 (Raspbian with 64 bit kernel)

[TobbeJ]

forgot to say, running the exact same docker command on an x86 computer results in container and octoprint working as expected

[LongLiveCHIEF]

duplicate of #159.

@TobbeJ when was the list time you ran docker pull octoprint/octoprint:1.5? I need to determine if your image is from before release from #162 or after. If you haven't pulled that image in a while, stop container, destroy container, run a pull, then start and see if you can connect. (make sure you use same volume mounting to keep state)

[TobbeJ]

it is from earlier today, see below

# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
octoprint/octoprint 1.5 a215729efa3c 7 days ago 700MB
octoprint/octoprint latest a215729efa3c 7 days ago 700MB

[LongLiveCHIEF]

Can you share your docker run command or the docker-compose.yml you're running so I can see how you're mounting volumes?

Also can you run this command for me and give me the output?

docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.created"}}'  octoprint/octoprint:1.5

[TobbeJ]

docker run command was as in the initial report, see reproduction steps at the top.
i kept the command deliberately very simple for testing purposes, didn't want to complicate matters with volumes and so on.

# docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.created"}}' octoprint/octoprint:1.5
2021-01-07T23:19:53.030Z

[LongLiveCHIEF]

I've been testing aarch64 using ubuntu 64, I wonder if there's a host lib dependency difference that could be causing this? 🤔

Can you give me the output of docker info so I can see client and engine information?

When you connect to the instance from the browser, are you using IP, mDNS url, or localhost? (are you hitting it from another machine on the network or using a browser installed on that raspberry pi?) I'm going to see if I can reproduce locally.

[TobbeJ]

i have tested using ip and dns name (not using mdns, i got my own internal dns alias setup) doesn't make any difference
i use raspbian but with a 64 bit kernel instead of the default 32bit.
cant remember exactly why i changed but must have been related to getting a docker image running.

# docker info
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.4.2-docker)

Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 8
Server Version: 20.10.0
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 5.4.79-v8+
Operating System: Raspbian GNU/Linux 10 (buster)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 1.808GiB
Name: pi4
ID: HJQD:3T6C:73CT:HGEQ:BFCG:JLZS:DTNW:7INQ:P6DS:TA2F:HIHD:GOLN
Docker Root Dir: /var/lib/docker
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 memory limit support
WARNING: No swap limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support
WARNING: No blkio weight support
WARNING: No blkio weight_device support

[LongLiveCHIEF]

Thanks. I'll see what I can do, though it might require implementing #161 first so we can get more info for debugging from the container.

I'm also studying for some AWS certification tests I have coming next week, so I don't expect I'll have a resolution for this issue right away. If it requires a deep dive, I won't be able to start that work until Jan 23rd.

[TobbeJ]

i use a browser (chrome) on a different computer since my pi4 with octoprint on it is in a different room without any kind of screen.
also if i open up the developer console in chrome when the error page is visible, there is a lot of stuff in the console there.
mainly about http://myhostnameorip/api/login sometimes connection refused and sometimes empty response

[TobbeJ]

if i use port 5000 instead of 80 it works.
did something like this:
docker run --rm --name=octoprint -p 80:80 -p 81:5000 octoprint/octoprint:1.5

so i could test both.
pointing browser to http://hostname:81 makes the initial setup wizard start properly.

[LongLiveCHIEF]

I wonder if it's something going on with haproxy on this particular arch.

[torresmvl]

I've realized the same issue on my testings. It occured when i've restored a backup where in my config.yaml it was restored to something like this:

accessControl:
  userfile: /octoprint/octoprint/users.yaml
server:
  host: 127.0.0.1
  port: 5000
  commands:
    serverRestartCommand: sudo service octoprint restart

What got me working again was setting:

server:
  host: 0.0.0.0
  port: 5000

But i guess @LongLiveCHIEF is wondering right about the haproxy. Looks like it isn't forwarding like it would..

[LongLiveCHIEF]

@TobbeJ where did you get the 64 bit raspbian disto?

[TobbeJ]

It is normal raspbian with arm_64bit=1 in /boot/config.txt
that's all i did (i think)
if i remember correctly i was force to do this due to a docker container only providing aarch64 binaries

[LongLiveCHIEF]

I tried to reproduce. Fresh raspbian 64 bit (https://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2020-08-24/2020-08-20-raspios-buster-arm64.zip), fresh docker install, and the exact command you ran, and everything works as expected (I used http://ip-of-my-raspberry-pi). Did this 3 times with the same results.

Each new install I made sure to to update the operating system after install.

Whatever this is, it's not likely a docker issue, or at least not an issue with this docker image. It could be something with your host or network configuration.

[LongLiveCHIEF]

It is normal raspbian with arm_64bit=1 in /boot/config.txt

@TobbeJ Yes.

[TobbeJ]

It is normal raspbian with arm_64bit=1 in /boot/config.txt

@TobbeJ Yes.

Yes what?

[LongLiveCHIEF]

yes to the question you asked that i even quoted so you would know what question I was answering.

[TobbeJ]

It wasn't a question, it was me replying to you and telling what i did to get 64 bit raspbian.

[denalena]

I experienced this exact issue today with the latest 32bit raspbian, this worked for me too (remember to change the port mapping in the docker-compose file too):

server:
  host: 0.0.0.0
  port: 5000

Thanks @torresmvl !