OctoPi 1.1.0 RC2 Status

[guysoft]

Second release candidate for OctoPi 1.1.0

There are both 32bit and 64bit images available for Raspberry Pi

There is also a new beta release for Le Potato AML-S905X-CC.
Its beta because I is not as tested as OctoPi for Raspberrypi. And I hope that having it available might let people play with it and tell me what can be done to get the wifi and cameras working correctly.

This image brings support to Raspberry Pi 5. It also drops wpa-supplicant support due to raspberrypi/bookworm-feedback#72
Please try the release candidate so we know it works.

Also a request for help in OctoPi - Our second mirror that was supplied by @wille on discord has been removed, so if anyone wants to help host a second mirror for https://unofficialpi.org/Distros/ that would help a lot so we don't loose OctoPi images.

32bit armf:
Download it at:
https://unofficialpi.org/Distros/OctoPi/nightly/2025-01-06_2024-11-19-octopi-bookworm-armhf-lite-1.1.0.zip

Md5: 64c2d6c5d0eb82d25007511395866901.

64bit arm64/aarch64:
Download it at:
https://unofficialpi.org/Distros/OctoPi/nightly-arm64/2025-01-06_2024-11-19-octopi-bookworm-arm64-lite-1.1.0.zip

Md5: 414fd01b4727bd387a4eb92e306bcf53.

Let Potato AML-S905X-CC (based on debian):
https://unofficialpi.org/Distros/OctoPi/debian_lepotato/nightly/2025-01-06_debian-12-base-arm64+aml-s905x-cc-1.1.0.zip
Md5: 3f2841fb39140e160f6cd4fce89137e3

Changes in the image

• Raspberry Pi 5 support Debian 12 Bookworm / Raspberry Pi 5 support #823
• Beta support for Le Potato AML-S905X-CC
• Images uses Debian bookworm
• Due to bookworkm /boot/config.txt has moved to /boot/firmware/config.txt See The file /boot/config.txt has moved to /boot/firmware/config.txt CustomPiOS#220
• Support changing default user name on rpi-imager
  • Move octoprint python virtualenv to /opt/custompios/oprint and add a symlink e62bada
• Dropped support for wpa supplicant due to wpa_supplicant autoconfigure removed in bookworm but not replaced with other mechanism raspberrypi/bookworm-feedback#72
  Please try the release candidate so we know it works.
• New NetworkManager headless support added, its pretty basic for now since it is expected most people configure the wifi via rpi-imager. There is a new wifi.nmconnection file in the /boot/firmware folder that lets you configure wifi headless. Its more limited at the moment than the wpa supplicant version
• Remove camera ID 046d:0825 Fixes Camera model 046d:0825 is known to not work with -f parameter, stripping it out #759

Changes from RC1:

• Fixed issue with webcam not working OctoPi 1.1.0 RC1 Status #837 (comment)
• Fixed wifi blocking guysoft/CustomPiOS@e553cad
• Network check has been fixed Adding missing if closing statement #840 (Thanks @david-forster10)

[bengalih]

How is the network check working in the RC?
Maybe I'm not looking at the right code base, but it appears enable_network_monitor is still looking for wpa_supplicant configuration?
I would like to know how the RC attempts to recover via Network Manager when connectivity is lost.

[guysoft]

@bengalih yes you are right, this needs to be updated:

OctoPi/src/modules/octopi/filesystem/root/usr/local/bin/networkcheck

Line 10 in 252e4f1

if [ $enable_network_monitor == 1 ] && [ "$destination_host" != "" ]; then

If anyone has time to implement it would greatly help. Otherwise I might just remove it.

[guysoft]

@hawkeyexp if you want to update this to work with NetworkManager. That would help, otherwise I might only ship it for wpa supplicant.

[b-morgan]

I downloaded 2025-01-06_2024-11-19-octopi-bookworm-arm64-lite-1.1.0.zip and installed it on an RPi 3B. When I login with SSH I get the "welcome" text including "This image comes without a desktop environment...". However, the ".../install-desktop" script isn't there. Obviously, there are two potential fixes... fix the "welcome" text or add a working script.

[guysoft]

@b-morgan The script path has moved to:
/opt/octopi/scripts/install-desktop

Will update the message, not sure I'll make an RC3 for that. will consider, perhaps for that and removing enable_network_monitor

[foosel]

Sorry for taking so long with feedback here, the OctoPrint RC has kept me busy.

I've now shot both the 32bit and the 64bit image against the testrig + e2e tests here, and both runs came away green:

• 32bit test
• 64bit test

Those were run against a Pi3 with a picam (PiC in my testrig). WiFi configuration was done using the same approach as the imager uses, firstrun.sh matching the sources of the imager.

So, from my end I can confirm for both images that they:

• boot
• get on wifi
• have a running OctoPrint 1.10.3
• have a running Webcam server (picam)
• have OctoPrint's E2E test suite pass against them, so logging in, out, settings, printer connection against the virtual printer, upload of files all work

I also did some quick manual testing against the 64bit image (I'm assuming the 32bit one behaves identical):

• plugin install works
• restarting the server works
• rebooting the server works
• printing against the virtual printer works
• updating to OctoPrint 1.11.0rc2 works (and no healthcheck triggered)
• system info shows no issues
• ~/oprint/bin/python still works (as a fallback via a symlink)

The wrong path for the install-desktop script was already mentioned.

So from my side with my testing options, things are looking good! 👍

[thinkjk]

@foosel @guysoft I'm testing with an rpi5 and a pi cam module 3 via MIPI and I don't know how to get the camera working. Are there any logs that I can provide you to help troubleshoot? I'm happy to help anyway I can :)

I can see the camera in libcamera-hello but I can't get it to work in octoprint. FWIW I had to camera enable auto-detect in /boot/firmware/config.txt for the camera to show up. Edit: PR to fix this: guysoft/CustomPiOS#246

I've also tested in RC1. I don't have to enable camera auto-detect but the camera still does not work for me.

Available cameras

0 : imx708 [4608x2592 10-bit RGGB] (/base/axi/pcie@120000/rp1/i2c@88000/imx708@1a)
Modes: 'SRGGB10_CSI2P' : 1536x864 [120.13 fps - (768, 432)/3072x1728 crop]
2304x1296 [56.03 fps - (0, 0)/4608x2592 crop]
4608x2592 [14.35 fps - (0, 0)/4608x2592 crop]

[thinkjk]

@guysoft I've been trying everything I can think of, but can't get the camera working in octoprint.

[guysoft]

@thinkjk Perhaps this change needs to be reverted for v3
#837 (comment)
Its really hard to know because I found no docs on what this does.

tl;dr
I switch in /boot/firmware/config.txt
from camera_auto_detect=1 to camera_auto_detect=0

So you can try switching in /boot/firmware/config.txt
back to camera_auto_detect=1 and see if that helps?

[cp2004]

This is the switch between the new (current) libcamera-based webcam system and the legacy webcam system. Mjpg streamer only works with the legacy system.

For a V3 camera you need the new libcamera system, so it won't work if you have legacy enabled. Unless I've missed a change, OctoPi doesn't have support for libcamera.

When you see supported=1 detected=1 you have legacy stack. If you see libcamera interfaces=1, you're using new stack.

[guysoft]

@cp2004 thanks for reminding me.
It looks like the only way around is to switch the default camera stack. OctoPi Up-to has a script to update libceamera.
This is the relevant issue:
#802

Its a bug that should be fixed, but not in this release. hopefully in the next one.

[thinkjk]

@guysoft @cp2004 Thanks for the responses. The OctoPi Up-to image doesn't support the Rpi5. Did you mean to use the scripts in that image to update your image? If so, I'm having a hard time getting the task build to run against the rc2 image.

#802 I've been unable to get this to work and the script creator said it's been discontinued due to the new camera stack.

Would it be possible to get the updated camera stack added in RC3?

Thank you!

Edit: I was able to get it working by using raspiCamSrv for the camera with your RC2. https://github.com/signag/raspi-cam-srv/

[guysoft]

@thinkjk

• Doesn't work with Pi Camera 3 #802 is still an open issue, I am not sure how to fix it, let alone for RC3.
• OctoPi Up-to image runs on the OctoPi images and updates it, not the other way round.
• raspi-cam-srv looks cool! I have no time to evalute it if its any good and worth shipping, if you could ask in the Doesn't work with Pi Camera 3 #802 issue perhaps people could test it out and report if its a good replacement.

[foosel]

@guysoft please don't do any experiments with the camera server, especially not on a third RC. The code should be frozen apart from regression fixes at this point.

Based on my experience with alternatives, the risk that stuff breaks for everyone one way or another is extremely high. Replacing the current camera stack with something different requires a long test phase related to hardware, performance and stability. And issues with the latter is also the reason why I haven't yet sent you a PR to replace the current one with the new camera stack I pushed out as an alternative OctoPi-UpToDate based image the past two years now. Modernizing the stack is frankly a project in itself, not something to quickly fix, especially since the alternative software stacks out there aren't backwards compatible, performant or stable enough yet.

Once you have a stable version of OctoPi 1.1.0 out that will be the base image I'll build OctoPi-UpToDate against, and that will also mean a new camera stack build so people can use that then with RPi Cam 3 (with the downside of it being less stable - which again is the reason it has not become the default, I'm blocked on a big issue on camera-streamer and the maintainer has sadly basically gone AWOL).

[guysoft]

@foosel just to be clear, I am not planning to do that on RC3. But posting it to the camera issue might be relevant.

[foosel]

After a quick look at that server you linked, it doesn't look like it has support for usb cameras but only RPI cameras, so it's a no go. Additionally, I have some doubts about the performance and that it only supports mjpeg is also not that great. Given that it's 2025 it would be preferable to also have a replacement support webrtc.

[lpla]

To avoid getting it lost into the void, a year ago I suggested ustreamer as a possible replacement (quoting Debian 12 Bookworm, Raspberry Pi 5 and Camera Module 3 support from them) also because it is an active project (a release yesterday) with many contributors, support for WebRTC (h.264), direct replacement interface for mjpg-streamer as denoted in the README.md and compatible with USB cameras: #823 (comment)

[cp2004]

Ustreamer didn't have Pi Cam V3 (libcamera) support for a long time, especially when we first looked at new camera stacks. It could be useful to look at that again - worth opening its own issue somewhere.

[lpla]

The issue I linked in that comment was closed by confirming that it works using the command line wrapper libcamerify ustreamer ...

EDIT: more currently supported projects like motion also use that libcamerify command to make the Camera Module 3 work, and have it documented officially (see the header of the following issue): Motion-Project/motion#1434

[thinkjk]

An updated on my part. I ended up returning the rpi5 and got an rpi4. I was just having too many issues with plugins with the 5.

[foosel]

I might be wrong, but I'm pretty sure I tested libcamerify a while ago and the performance impact was quite bad. And libcamera itself also changed it's API a ton causing breaking in things compiled against it on updates of it from apt. But yes, wrong issue to discuss this IMHO.