[BUG] Loading error: Passive login failed. raspi 4 about octoprint-docker HOT 8 OPEN

It looks like this is a problem with haproxy inside the container.
I opened up port 5000:5000 and hit that with my browser and the octoprint UI is working fine.

from octoprint-docker.

fwiw, I have tried docker images for 1.7.1, 1.8.1, bleeding, latest
all with the same result as above.

waboring@octoprint-pi4:~/docker/octoprint $ docker version
Client: Docker Engine - Community
 Version:           23.0.1
 API version:       1.42
 Go version:        go1.19.5
 Git commit:        a5ee5b1
 Built:             Thu Feb  9 19:46:47 2023
 OS/Arch:           linux/arm
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          23.0.1
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.19.5
  Git commit:       bc3805a
  Built:            Thu Feb  9 19:46:47 2023
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.6.18
  GitCommit:        2456e983eb9e37e47538f59ea18f2043c9a73640
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

from octoprint-docker.

I can confirm this, with port 5000 it works. Port 80 does not let you log in. I checked it also with a fresh blank container. The only thing which changed was the kernel on the Raspi4 with an update a few days ago:

uname -m via console showes it´s now:
aarch64

I tried roll it back in /boot/config.txt but this produced an instable OS so it´s not reproduce the problem.

from octoprint-docker.

waboring@octoprint-pi4:~ $ uname -a
Linux octoprint-pi4 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux

from octoprint-docker.

I have the same problem. It appeared after dist-upgrade Raspbian from buster to bullseye. The workaround with exposing port 5000 and bypassing HA PROXY works.

Tracking down this problem I noticed that haproxy respond with connection reset (NS_ERROR_NET_RESET) to POST requests where GET requests are working fine. The first request that is failing is POST http://octopi/api/login (octopi is a DNS name of my raspberry pi)

I'm using latest stable image (1.8.7)
My kernel and docker version are:

# uname -a
Linux raspberrypi 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux
#
# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
#
# docker vesrion
docker: 'vesrion' is not a docker command.
See 'docker --help'
root@raspberrypi:~/octoprint-docker# docker version
Client:
 Version:           20.10.5+dfsg1
 API version:       1.41
 Go version:        go1.15.15
 Git commit:        55c4c88
 Built:             Mon May 30 18:34:49 2022
 OS/Arch:           linux/arm
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.5+dfsg1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.15.15
  Git commit:       363e9a8
  Built:            Mon May 30 18:34:49 2022
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.4.13~ds1
  GitCommit:        1.4.13~ds1-1~deb11u3
 runc:
  Version:          1.0.0~rc93+ds1
  GitCommit:        1.0.0~rc93+ds1-5+deb11u2
 docker-init:
  Version:          0.19.0
  GitCommit:
#
# docker-compose version
docker-compose version 1.25.0, build unknown
docker-py version: 4.1.0
CPython version: 3.9.2
OpenSSL version: OpenSSL 1.1.1n  15 Mar 2022
#

from octoprint-docker.

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/update-broke-octoprint-via-docker/50813/4

from octoprint-docker.

I had the same issue and I used the workaround so far.

Then I noticed PrintTimeGenius plugin stopped working as well. Analysing the problem, I saw that it calls an aarch64 binary, because "uname -a" reports "aarch64". The "marlin-calc.aarch64" binary did not work inside the docker container, but outside, on the raspi host it worked. As the PTG plugin had worked before, and stopped working at the same time I got the "passive login problem" I knew that the problem was introduced by a change from a 32bit kernel to aarch64 kernel.

How I got this kernel is not clear to me, I suspect I used the "rpi-update" tool once, which gave me perhaps an aarch64 version of the kernel (/boot/kernel8.img), and later it was activated by an "apt upgrade" (I had checked before, I did not update the kernel via apt prior the problem appeared).

So then I tried to get rid of the aarch64 kernel, I did a
"WANT_64BIT=0 rpi-update"
but that did not do the trick -- I do not know if the firmware installed depends on that flag though.
Afterwards I just added "kernel=kernel7l.img" to the /boot/config.txt file, this worked.
Somehow wlan0 was working strangely and I guess an important step is to do
"sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel"
to configure everthing correctly. Since then the system is behaving as before and I can reach the octoprints again via
haproxy (portmapping to port 80) and PrintTimeGenius works properly again.

So even though the raspi aarch64 kernel can run 32bit userspace programs fine, as well as aarch64 binaries -- the docker containers can only be 32bit (armv7l) (I also tried aarch64 octoprint image -- does not work, I guess because the docker engine is 32bit), and somehow not working perfectly fine with the aarch64 kernel, showing in this strange haproxy behaviour inside the octoprint image.

If someone has more insight on how to configure raspi to use a 32bit kernel, or a more appropriate way to "downgrade" to 32bit kernel, please correct me here -- I am no expert here and I do not want to spread "improper" information....

from octoprint-docker.

Feeding off of @hemna comment that "looks like this is a problem with haproxy" and doing some googling based on @possebaer guess that haproxy was getting confused by the host having a 64bit kernel, I found at least one other haproxy-using-package that claimed the problem went away if you upgrade haproxy

Given the dockerfile loads haproxy via apt-get (instead of building directly) the upgrading in place is kinda tricky ... that is unless the base os image itself is upgraded, moving all the libraries forward (which can break all sorts of other things)

... but I thought I would give it a try by switching the OS image to bullseye, by changing the ARG PYTHON_BASE_IMAG (on the first line of the Dockerfile) to 3.8-slim-bullseye

Happily that built ok and seemed like it might run, but the updated version of haproxy turned out to have major version update, so it (un-happily) deprecated the reqrep lines in the haproxy.cfg, and caused it to go into an exit-and-restart loop.

So, I tried to build again, but this time taking a guess at the way the reqrep lines should be updated in the 'root/etc/haproxy/haproxy.cfg' file:
replacing the "backend octoprint" reqrep line with http-request replace-uri /(.*) /\1
and the "backend webcam" reqrep line with http-request replace-uri /webcam/(.*) /\1

As a result, I have a build that seems to be working, though I'm only 10 minutes into configuring a fresh setup. If I can get it fully setup I'll submit a PR

from octoprint-docker.