OctoPi 0.18.0 RC1 Status

[guysoft]

First release candidate for OctoPi 0.18.0

There are both 32bit and 64bit Based on RpiOS images available. Which give support to Raspberry Pi 4B 8GB and Raspberry Pi 400

The main change that would be likely noticable to plugin developers is that OctoPi comes with Python3 now.

Please try the release candidate.

32bit armf:
Download it at:
http://unofficialpi.org/Distros/OctoPi/2020-11-02_2020-08-20-octopi-buster-armhf-lite-0.18.0.zip

Md5: d3cb6af431e326cb8bd27719016d3922.

64bit arm64/aarch64:
Download it at:
http://unofficialpi.org/Distros/OctoPi/2020-11-02_2020-08-20-octopi-buster-arm64-lite-0.18.0.zip

Md5: 643a6f4da6170607c57769a0c5bf2e7e.

Changes in the image

• OctoPrint 1.4.2
• OctoPi now uses Python3
• /home/pi/scripts/safemode (thanks @OutsourcedGuru )
• Fix Shutdown requires network #619 Shutdown requires network (Thanks @da4id )
• Add workaround for a bug in Raspberry Pi 4 VL805 0x000137ab firmware (streaming issues) #623 from szopen111/fix-issue-621 (Workaround for low resolution cameras)
• Fix/enable haproxy logging fix/enable haproxy logging #640 and enable compression at haproxy layer enable compression at haproxy layer #643 (thanks @tedder )
• Experimental HLS support Experimental HLS support. #650 HLS proxying and tuning #668 Made HLS stream adaptive. #688 (thanks @chudsaviet )
• Removed old Cura. See Cura on OctoPi is too old #654 and Consider adding slic3r to the image #444 .
• Some usb cameras setting fixed (additional_brokenfps_usbdevices=(046d:0825) #657 b64a544 0d0ea37 )
• Fixes [Request] Add numpy to octoprint virtualenv #676 and adds deps to install numpy from wheel for plugins taht need numpy
• New arm64 builds
• Set HAProxy Diffie-Hellman key size to 2048 Set HAProxy Diffie-Hellman key size to 2048 #685

Build notes

• Uses CustomPiOS 1.4.0

[carl5765]

im running multiple instances on one pi will this upgrade include upgrading them as when i install python 3 it doesn't see my second or third image

[Prutsium]

Will the 64bit also work in the 2GB Pi4?
Have to setup a second Pi anyway as i cant get multiple instances to work (all guides are based on the 0.17 version that seems to have /etc/default/octoprint but 0.18 doesnt have that :).

[guysoft]

@Prutsium
Should work with any device that supports 64bit instruction set. That includes all Pi4 and also 3B+

[guysoft]

@carl5765 I didn't understand. This is an OctoPi image, not an OctoPrint package upgrade. You need to physically flash your SD card.

[derekslenk]

Any way to update a current instance to this or just format/backup and restore

[dxgldotorg]

@guysoft should the 64-bit image be used on a minimum 4GB system?

[LMS0815]

First release candidate for OctoPi 0.18.0

There are both 32bit and 64bit Based on RpiOS images available. Which give support to Raspberry Pi 4B 8GB and Raspberry Pi 400

64bit amd64/aarch64 version working like a charm on RASPBERRY PI 3B+ Raspberry Pi 3 B+, 4x 1,4 GHz, 1 GB RAM, WLAN, BT
Restoring backup from old config was seamless.

Thank you!

[guysoft]

@derekslenk Yes, see below your comment.
@dxgldotorg No, see above your comment.

[dorfman2]

Had a very successful transition on a Raspberry pi 4 (1gig). Backup was seamless as well.

[PistolsAtDawn]

Hi! Love the software!

Just wanted to say that I cannot get my PS3 camera to work out of the box on 0.18 RC1. I didn't have time to test why this is though. It works flawlessly on 0.17.

Thanks!

[sohxet]

Hi, glad I can contribute a little by testing!

Sending an M997 command to reboot the printer after uploading a firmware file through marlin-bft plugin causes octoprint to become unresponsive, pi doesn't respond to ssh connections, M997 iteself doesn't execute. Raspi 4B 4GB, Ender 3 pro with SKR V1.3 mainboard running marlin 2.0.6.1 bugfix. Worked previously with octopi 0.17/octoprint 1.4.2 on a raspi 2B.
octoprint.log

[Will-wastelander]

Back and restore from 0.17.0 to 0.18.0 RC1 went w/o a hitch on my rPi 4 4GB. I have 2 more to do. Currently running multiple plugins that were imported, and also installed OctoDash for screen use. Will be doing the same for the other 2 systems.

[rbrian]

Not sure what happened... but... I have an external USB SSD attached to my Pi that held my uploads, timelapses, etc. Initial setup was easy several months ago, just formatted it via SSH and it mounted automatically. Has been working fine ever since. Today I decided it was time to bite the bullet and upgrade to Python 3, and figured I'd just use the RC to do it. So I backed up via the OctoPi settings page, and copied my home directory on the Pi to the SSD so that I'd have all my other files, like my Klipper config. I flashed the RC just fine, and everything seemed to be OK. (I am having a bit of trouble with it not finding octopi.local for SSH, but it works via the IP address, so I'm not too concerned.) Then I went to go look on the SSD for my SAMBA config file... and there's nothing. Drive won't automount, and is empty when I mount manually. File recovery tools aren't helpful. This just cost me a week or so of tinkering with the Klipper configuration to get it working right & calibrated again. :( If anyone has ANY clue what might have happened, I'll be grateful to hear about it. I'm going to leave the SSD offline for the time being, just in case there is actually some form of recovery that will help.

I'll keep on with the RC, and let you know if I find anything else out of the ordinary.

[sohxet]

OctoPrint 1.5.0rc1 was released, does this affect testing of octopi 0.18?

[guysoft]

Talk to @foosel she mentioned it. Didn't seem to bother her.
Just making sure. You rather not wait?

[foosel]

Considering that people were running into issues with current Pi4s vs the 0.17 image and the Pi400 also having gotten released (which I rightfully anticipated people would ask for support for, even though I don't understand WHY), I figured it would make more sense to push an OctoPi image RC now with the current stable OctoPrint on it, rather than wait until 1.5.0 hits stable (which depending on how this RC phase goes might still take until December). I stand by this decision.

[guysoft]

Ok. Also we could always make 0.18.1

[foosel]

Yeah... all that would change there would be the preinstalled OctoPrint version then, no need for a lengthy RC phase for that. Right now the testing of 0.18.0 is really more to iron out any kind of issues with the new base image and any changes done to OctoPi outside of OctoPrint, as far as I see it.

[cp2004]

Sending an M997 command...
@sohxet

Could this be related to OctoPrint/OctoPrint#3683 since OctoPi 0.18 is likely now pulling in this upstream kernel update?

[XRyu]

is it possible the arm64 does not come with raspi cam support?

i am running it on a Raspberry Pi 4 4GB

Starting up webcamDaemon...

--- Configuration: ----------------------------
cfg_file:      /boot/octopi.txt
camera:        raspi
usb options:   -r 640x480 -f 10
raspi options: -fps 10
http options:  -w ./www-octopi -n --listen 127.0.0.1

Explicitly USB device:
-----------------------------------------------

Found video devices:
/dev/video0
/dev/video10
/dev/video11
/dev/video12
/dev/video13
/dev/video14
/dev/video15
/dev/video16
raspi
config file='/boot/octopi.txt':Start MJPG-streamer with video device: raspi
<13>Nov 11 17:42:15 root: Starting Raspberry Pi camera
Checking for VL805 (Raspberry Pi 4)...
  - It seems that you don't have VL805 (Raspberry Pi 4).
    There should be no problems with USB (a.k.a. select() timeout)
Running ./mjpg_streamer -o output_http.so -w ./www-octopi -n --listen 127.0.0.1 -i input_raspicam.so -fps 10
MJPG Streamer Version: git rev: 85f89a8c321e799fabb1693c5d133f3fb48ee748
ERROR: could not find input plugin
       Perhaps you want to adjust the search path with:
       # export LD_LIBRARY_PATH=/path/to/plugin/folder
       dlopen: input_raspicam.so: cannot open shared object file: No such file or directory
Done bring up all configured video device

Goodbye...

[sohxet]

Sending an M997 command...
@sohxet

Could this be related to OctoPrint/OctoPrint#3683 since OctoPi 0.18 is likely now pulling in this upstream kernel update?

That sounds exactly like my problem. I'll try to get any useful information from the pi and open a ticket upstream.

[rbrian]

Are there any known backup./restore issues? i have a backup from my octoprint before the upgrade, and trying to restore it I get the "Uploading please wait" dialog for at least 12 hours. Not going to let it go any further, will be easier to just redo things from scratch.

edit: running 18rc x64 on a pi4 4gb

[Will-wastelander]

I have been having random drops where the system becomes inaccessible all together via SSH and WebGUI, but OctoDash is still able to access it ? When connecting via hardwire, no DHCP is pulled at all. I do not have a HDMI connected to it, but I do have a 7" screen, ask I am running OctoDash as previously mentioned.

What info can I provide to assist with trouble shooting ?

rPi 4 4GB,, OctoPi 0.18.0 RC1 armhf, OctoDash 2.1.1, 7" DSI screen. This is the 3rd time it has happened in 24 hours. However my OctoPi 0.17.0 armhf, and 0.18.0 arm64 seem to be working fine. 0.17.0 I have no issues w/ network drops at all on the same system(s).

[Will-wastelander]

Plugging in a Wireless USB kb/mouse appears to do nothing also. ctrl-alt-del does nothing, ctrl-c does nothing.

[CRCinAU]

64bit amd64/aarch64

I'm sure you mean: 64bit arm64/aarch64?

Also, nice:

$ dmesg | grep Rasp
[    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.2
pi@ender3v2:~ $ cat /proc/version 
Linux version 5.4.72-v8+ (dom@buildbot) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020

I don't have a webcam on this one - but it booted via USB etc fine - so that's a great sign.

Once my other one has finished printing, I'll do the upgrade on that too.... If you hear nothing back from me, the second one will be fine too...

One is a Pi 4 4Gb, the other a Pi 4 2Gb 4Gb as well...

[guysoft]

I'm sure you mean: 64bit arm64/aarch64?

Yea my bad, fixed. Its really a pain that its only one letter difference.

[CRCinAU]

Its really a pain that its only one letter difference.

Hahahah - tell me about it - that's why I call things aarch64 and x86_64 - even though debian loves to use amd64 :\

[CRCinAU]

Hmmm - here we go - trying to use the HLS webcam stuff:

Nov 12 09:02:07 ender3.local ffmpeg[2381]: [h264_omx @ 0x558d4d4870] libOMX_Core.so not found
Nov 12 09:02:07 ender3.local ffmpeg[2381]: [h264_omx @ 0x558d4d4870] libOmxCore.so not found
Nov 12 09:02:07 ender3.local ffmpeg[2381]: Error initializing output stream 1:0 -- Error while opening encoder for output stream #1:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Nov 12 09:02:07 ender3.local ffmpeg[2381]: [video4linux2,v4l2 @ 0x558d4c9de0] Some buffers are still owned by the caller on close.
Nov 12 09:02:07 ender3.local ffmpeg[2381]: Conversion failed!
Nov 12 09:02:07 ender3.local systemd[1]: ffmpeg_hls.service: Main process exited, code=exited, status=1/FAILURE
Nov 12 09:02:07 ender3.local systemd[1]: ffmpeg_hls.service: Failed with result 'exit-code'.

[guysoft]

@chudsaviet any insight on this? ^

[rbrian]

Getting a black rectangle where the Pi cam is supposed to display. Worked fine in previous versions. Not sure where a log would be that would have any info.

[gunnarx]

FYI in 62eabbf you forgot to change README.rst because it still suggests that Cura is pre-installed.
ref #654

[bvrielink]

As Python 2 is now unsupported I want to start using 0.18 for some testing. Is RC2 already released? If not would it better to use the latest nightly or use RC1? TIA.

[guysoft]

@bionik If you want to test python3 RC1 should be enough. I am investigating RC2 using Ubuntu for only 64bit today/during this week and will decide if its worth releasing an experimental with it for RC2, since Rpi Foundation are saying that they are not maintaining a 64bit build.

[CRCinAU]

Rpi Foundation are saying that they are not maintaining a 64bit build.

That's a bit weak on their part..... given that 64 bit is quite a lot faster than the 32 bit OS on the same hardware...

[cp2004]

Experimental 64 bit build sounds like the way to go then. Shame Raspberry Pi Foundation didn't want to do it. To be honest, their initial blog post never really seemed like they thought it had much benefit, it never sounded keen.

From a community perspective, supporting two different base distros would be a bit of a pain, so maybe if the experiment proves successful, would it be worth switching the 32 bit to (I assume) ubuntu server? It's a massive shift, and probably quite a lot of work for you to adapt all the scripts etc, appreciate all of that. We will wait and see if there is an improvement to not using Raspberry Pi OS images. One downside I did think of is it may be slower to support new RPi boards that come out, as opposed to the RPiOS images which have to be compatible when they first go on sale.

[guysoft]

@cp2004 Yes that is what I am thinking too.
I will want to hear @foosel thoughts, but frankly Rpi foundation have an unorganized release cycle which has been giving us a hard time here, we never know if something will come out. For example RC1 came out here and then they released an image at the start of December, a month after. Ubuntu has defined release dates so we can match them.
I would have also loved to use the Debian Rpi builds. But their approach is to have an image for every machine. And I really rather have 2 images to maintain.

But again, I am starting this as a 64bit experiment for RC2, and we will see how it goes from there.

[chudsaviet]

I would like to oppose moving away from RaspberryPi OS because of possible issues with cameras/encoders support. RaspberryPi OS is still the official supported OS.

[guysoft]

@chudsaviet That is why I have been keeping it.
However, it seems like now I also have the potability to build OctoPi for Ubuntu too.
Having this time where there is no 64bit Raspberrypi OS might be a good time to test this argument. The kernel should be the same kernel so cameras/encoders support. But we won't know until we put it out there for people to test and report.
@foosel would value your input before I release an RC2 with this.

[CRCinAU]

RaspberryPi OS is still the official supported OS.

If they don't support a 64bit OS, is it?

[guysoft]

@foosel Says we also need support for vcgencmd. So I need to install the PPAs at:
https://wiki.ubuntu.com/ARM/RaspberryPi
Can try add that too.

[foosel]

Especially vcgencmd get_throttled, because otherwise no undervoltage warnings by OctoPrint on the image and that would mean a support nightmare.

[chudsaviet]

@guysoft , I do see a lot of extra steps needed to make Ubuntu build usable - https://wiki.ubuntu.com/ARM/RaspberryPi . And I predict even more steps I don’t see.
Actually, I don’t think having a officially supported 64bit release is worth all the hassle. I think Raspberry PI OS will fully support arm64 eventually. They have 8 gb RAM boards anyway, and I don't think they will abandon them.
Lets just call our 64bit release experimental until RaspberryPi OS 64bit is called experimental. I will make HLS work on it.
Its just my opinion, @guysoft snd @foosel are the bosses :)

[foosel]

After taking a closer look at that wiki node, I agree. We already have enough support hassle, we don't need to make things worse by trying to enforce a stable 64bit build.

My vote: ignore 64bit outside of nightlies until Raspbian declares the base image stable. Push out an rc2 with OctoPrint 1.5.2 asap.

[gdombiak]

@foosel that is a practical comment! Well said. ROI is not there for 64bit. It has high chances of creating more headache/support/issues than benefit of running in 64bit. I've been using RC1 32 bit and it is pretty solid and meets the needs. I bet that will be enough for 99% of our community.

[4wrxb]

Note: these comments are based on the assumption that the recommend upgrade path for non-expert OctoPi uses to move to Python 3 will be do a new install of v0.18. With this being the case I would expect a greater user-base wanting to restore backups when installing the released v0.18 over time (as more extension etc. begin to rely on Python 3). If there's a plan to provide (non-expert user) Python 3 upgrade capabilities w/in previous OctoPi installs then it would be safe to assume that the backup restore path remains an expert-usage case.

From a use-ability standpoint it would be helpful to offer to update the Octopi server at the beginning of the set-up wizard since this is required in order to restore a backup (if there is a version mismatch). I know folks should be comfortable enough with SSH access to log-in and change the default password and thus would be able to run a simple pip command to update octopi, but the extra hurdle seems unnecessary.

At the very least, in order to avoid support requests from the google-challenged, I would have the UI link here: https://community.octoprint.org/t/how-can-i-update-the-octoprint-installation-on-my-octopi-image/207

[cp2004]

Create a request over on the OctoPrint repository, for a wizard for software update. Something like that can probably be done.

[guysoft]

I actually have OctoPi building for Ubuntu 64bit. Thankfully most of the lifting was done in CustomPiOS for PhotoPrismPi/UbuntuDockerPi (BTW UbuntuDockerPi is pretty awesome).
I did a few commits last week that build it, the only missing part now is the PPA. Here is the issue I am facing: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1849714

[foosel]

Considering that this issue has been open for 1.5y that doesn't look too promising. And as you know, it building and it actually working in the field in a stable way are two different pairs of shoes. I'd rather not have this block progress of getting 0.18 out further. There's IMHO no harm in pushing out a 32bit rc2 (with a stable release within a month or so) and playing around with 64bit in the nightlies until we have something stable.

[guysoft]

So I found out that libraspberrypi-bin is not part of the Ubuntu repos. Its only there from groovy (20.10) and AFAIK there is no way to get in to focal (20.04). I'd rather have 20.04 because its LTS. But it seems to work and I have a nightly built:
http://unofficialpi.org/Distros/OctoPi/nightly-arm64/2021-01-11_octopi-20.10-preinstalled-server-arm64+raspi-0.18.0.zip
md5: b0296e50919cc16d1d84bfb0e15e0b2c

It seems to load but

1. There is an Ubuntu user and also the Pi user (can be fixed).
2. Pi user has no sudo
3. HA proxy does not load. I get:

/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -S /run/haproxy-master.sock
[NOTICE] 010/111929 (4074) : haproxy version is 2.2.3-2
[NOTICE] 010/111929 (4074) : path to executable is /usr/sbin/haproxy
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:35] : The 'reqrep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-path', 'http-request replace-uri' or 'http-request replace-header' instead.
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:36] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:37] : The 'reqadd' directive is not supported anymore since HAProxy 2.1. Use 'http-request add-header' instead.
[ALERT] 010/111929 (4074) : parsing [/etc/haproxy/haproxy.cfg:43] : The 'reqrep' directive is not supported anymore since HAProxy 2.1. Use 'http-request replace-path', 'http-request replace-uri' or 'http-request replace-header' instead.
[ALERT] 010/111929 (4074) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT] 010/111929 (4074) : Fatal errors found in configuration.

[CRCinAU]

        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
        reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }

Is this just to redirect to from http -> https?

If so, its better to use:

redirect scheme https code 301 if !{ ssl_fc }

I'm not sure why you need the X-Scheme: header at all - unless its used in OctoPrint somewhere?

If so, use:

http-request add-header X-Scheme https if needs_scheme { ssl_fc }
http-request add-header X-Scheme http if needs_scheme !{ ssl_fc }

To make life easier, I think these blocks will work:

backend octoprint
        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0

        http-request replace-path ^([^\ :]*)\ /(.*) \1\ /\2
        http-request add-header X-Scheme https if needs_scheme { ssl_fc }
        http-request add-header X-Scheme http if needs_scheme !{ ssl_fc }
        option forwardfor
        server octoprint1 127.0.0.1:5000
        errorfile 503 /etc/haproxy/errors/503-no-octoprint.http

backend webcam
        http-request replace-path ^([^\ :]*)\ /webcam/(.*)     \1\ /\2
        server webcam1  127.0.0.1:8080
        errorfile 503 /etc/haproxy/errors/503-no-webcam.http

[guysoft]

New RC2: #710

[guysoft]

Ubuntu talks will continue elsewhere

[CRCinAU]

Just edited my comment above with what I believe could be working haproxy config...