I’ve tried deploying from balenahub, as well as cloning the github repo and deploying with the balena CLI with identical results.
In each case - despite the dashboard suggesting that the octoprint container is ‘Running’ - I’m getting a recurring error in the Logs window from this container:
octoprint standard_init_linux.go:211: exec user process caused “no such file or directory”
Attempting a shell connection to the container results in:
SSH reconnecting…
Spawning shell…
Error response from daemon: Container d3cec7f7b30252ff6133855bfffc9a7174cf95cb60086fe3a94a9d51f51bf77b is restarting, wait until the container is running
Error response from daemon: Container d3cec7f7b30252ff6133855bfffc9a7174cf95cb60086fe3a94a9d51f51bf77b is restarting, wait until the container is running
SSH session disconnected
Needless to say, the system is not available at it’s expected network location (octobalena.local): I can ping the device (and establish a Host OS shell) - but octoprint is non-responsive on port 5000.
$ curl octobalena.local:5000
curl: (7) Failed to connect to octobalena.local port 5000: Connection refused
I’ll log a similar issue on the GitHub repo – anyone know if the author has a presence here in the forums? I’ll look momentarily.
It might be worth pointing out that I’ve been using (non-balena’d) OctoPrint, octolapse and a few other plugins quite successfully for awhile now. Working on adding some WS2812b LEDs to my Ender 3 Pro 3D printer, and an associated OctoPrint plugin – and decided I’d give the balena route a go for quickly deploying a new octoprint instance for testing my wiring setup (including level converter) prior to installing on my ‘production rig’. #ScratchMonkey
Hi Billy, thank you we are aware of this. There is a PR to fix one of the issues with the build of Pi3 device type, which should allow you to build the project against a RaspberryPi3 application/device type. If you are using any of the Pi2/3/4 variants, please ensure your balenaCloud app is type of RaspberryPi3. Any other device type will revert to the the Dockerfile.template, which builds the Octoprint container with the wrong binary architecture. You could open an issue for this against the GH repository.
Funny (??) story: I went to revisit this effort, with renewed interest and vigor in building a latest/greatest OctoPrint container, with a hand-crafted selection of plug-ins that specifically support my hardware and configurations (including the new WLED plug-in).
The funny part is – I got well back into it (rev’d my balena CLI, made sure all repos were up-to-date, and… completely forgot about this. “Hey – why isn’t the container starting?”
Building a raspberry Pi3 image now, and will report back how it goes.
I think I must not quite be following here. I built a new ‘device’ - and selected RPi3 as the Device Type – and then I installed that image in an RPi4 device. It probably comes as no surprise to those who know what they are doing - but this failed to ‘startup’ and report in to the console.
So I pulled that same SD card, and dropped in into an RPi3, and – voila! OctoPrint.
I’m just trying to connect the right dots and to the underlying issue – and, ultimately am going to want to run this “app” (with a target of multiple containers) on the RPi4 platform with its increased performance and memory availability. But - for today, I’m just using the RPi3, and learning the local development loop, how to customize and update the existing container (add plugins, change settings, etc). Once I have that part of the workflow figured out - I can come back to the device type.
