[BUG] Loading error: Passive login failed. raspi 4 #252
Comments
|
fwiw, I have tried docker images for 1.7.1, 1.8.1, bleeding, latest |
|
It looks like this is a problem with haproxy inside the container. |
|
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: I tried roll it back in /boot/config.txt but this produced an instable OS so it´s not reproduce the problem. |
|
|
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) |
|
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 |
|
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 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.... |
|
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 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 So, I tried to build again, but this time taking a guess at the way the 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 |
Describe the bug
Can't login or get normal first start web UI on octoprint start.
Container Details
please run `docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.created"}}' octoprint/octoprint:<tag_you_are_using>' and list the date returned.
Container details
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect to see the first start octoprint ui web page
Screenshots
Desktop (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: