Making OctoPi build on Ubuntu 64bit so we have 64bit builds

@CRCinAU

Ok, so following what was going on in #692 . We are thinking about using Ubuntu to make 64bit builds. And also testing to see how using a distro with predictable release cycles works with OctoPi (we might actually like this long-term).

Current status:

There is a build at:
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

There is an Ubuntu user and also the Pi user (can be fixed).
Pi user has no sudo
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.

Possible fix by @CRCinAU at: #692 (comment)

So what's broken / known problems at this point? Only the haproxy? Just about to give it a whirl...

I haven't tested more. Its about an hour old

Heh - noted - I won't overwrite my working RC setup then ;)

EDIT: Good sign - even though its on a very slow USB stick for testing:

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Ok, good news is that it seems to work well enough that I'm going to back up my RC1 config and load it into this on my faster USB stick.... It boots fine, resizes ok, starts octoprint ok, haproxy starts with my modified config as per the quoted post, connects to the printer ok....

EDIT: Also, apt update && apt -y dist-upgrade works fine too....

Extra packages that can be removed:

* snapd (and rm -fR /run/snapd)
* squashfs-tools
* bcache-tools
* cloud-* (and rm -fR /etc/cloud)
* cryptsetup-*
* *nginx*

There may be more - but that's a quick overview...

I will download this and test as well - I have been running RC1 64bit since you released it (and nightly before)
not having an aarch64 image (ubuntu or otherwise) for a pi4 host is a bad idea in my personal opinion.

the speed of the system and the interface IS significantly better (faster?); I do understand the comments about support/etc that was indicated in the previous thread.

I only want to say, in 2021; sticking to 32bit only is short-sighted (PI Foundation, for instance).

testing here I go! :P

based on my limited testing, I am unable to get my webcam working with mpegstreamer. I will spend more time on it... just adding to the discussion.

I have downloded the 64bit version and could start it on my raspberry Pi4 8GB.
With Putty I can access the system as user pi.
I was able to change the password but thats it.
After this I can't continue with any configuration because user pi is not allowed for root access.
Is there a Ubuntu admin user which will have this access or how should I be able to test further when I can't further configure my rasbperry to work correctly.
Any feedback would be great helping you to continue with testing.

@XboxOldie

@XboxOldie see: #712 ... there is also the ubuntu/ubuntu user on the current images. that user is allowed to sudo.

Next nightly should have the pi user able to run sudo. I hope so at least, testing appreciated!

@guysoft

@guysoft
I have installed the latest nightly build now from 12.01.2021 and the user pi is having now sudo rights.
Thanks for the change

I could do then the password change , the sudo apt update and upgrade like always under the user pi.
All was running with a view messages and ended after a view minutes.
sudo raspi-config does not exist anymore on the RC2 so nothing i can do there.

However after all the system updates I was not able to open the octoprint webinterface on any browser like Opera or Edge.
Not with the IP nor with http;//octopi

Hope you can still solve the issue that I can continue testing.
I added the whole installation procedure I did as a text file for your reference

Install octopi RC2.txt

Hope that helps.

PS: So far I have the RC1 with the 64bit running and all is working well on my Pi 4B 8GB

@XboxOldie

@XboxOldie See the first post. HAproxy needs to be fixed because it is not working on ubuntu, I don't know why:
#711 (comment)

Seems like HAproxy on Raspbian/Rpios is 1.8.19 and on Ubuntu 2.2, which means the settings need to be upgraded.

Seems like HAproxy on Raspbian/Rpios is 1.8.19 and on Ubuntu 2.2, which means the settings need to be upgraded.

If you swap out the original two backend blocks and replace them with the two blocks I posted on the original ticket we discussed this, it works fine.

@guysoft

@guysoft Please keep me informed when HAproxy is solved into a new nightly distribution to continue testing.
I'm not a linux specialist only a normal user trying to inform you when all is working as expected.

@guysoft

@guysoft
Have installed nightly 2021-02-22_octopi-20.10-preinstalled-server-arm64+raspi-1.0.0 on Pi4B 8GB
After copy of system to the SD and adding my WLAN access into the "octopi-wpa-supplicant.txt" the system started immediately and very fast into the WEB interface with the further setup screens.
After the plugin installation of "Creality-2x-temperature-reporting-fix" for my Ender 3 Pro, all is working perfect and fast.
Also camera is recognized and working normal.
I also did sudo update and upgrade +reboot without errors.
So far all works perfect and I will continue print tests with this new nightly version.

@XboxOldie

i can't tell how great it feels to read that - i can rarely contribute. This feels great to be a part of a nice community getting projects like this forward :D

Thank you for testing and the feedback @XboxOldie :D
Mine is running also fine, no stuttering of Octoprint crashing since then - with raspiOS i had regular downtimes and had to ssh into and needed to reboot.

@guysoft

I made a pr #724 with the minimum set of changes I believe is required to get (the current version of) ws281x to work. @guysoft @cp2004

Tested here too. Boots, works well and the raspberry pi camera I have also works.

The desktop script does not work because there is no package raspberrypi-ui-mods and would need to be changed if we want the desktop on 64bit.

I'm currently testing/using the latest nightly build 2021-02-23_octopi-20.10-preinstalled-server-arm64+raspi-1.0.0.zip on my RPI4 8GB and PSU control (and GPIO Control/anything that uses RPi.GPIO) fails to be installed due to the following error:

2021-02-23 21:52:16,545 - octoprint.plugins.pluginmanager - ERROR - Reason: UnicodeEncodeError('latin-1', '  source/c_gpio.c: In function ‘setup’:\n', 31, 32, 'ordinal not in range(256)')

I've some logs available as a gist here: https://gist.github.com/ping-localhost/aad12f9619b13deaf5e2d6810407a0f5

@ping-localhost

@ping-localhost That error seem seems to be from the plugin manager console or something like it might be unrelated.
https://gist.github.com/ping-localhost/aad12f9619b13deaf5e2d6810407a0f5#file-octoprint-log-L21
This line says its using a Unicode Character 'LEFT SINGLE QUOTATION MARK' (U+2018).
I am not sure where its coming from, but its not an OctoPi issue. Should fail anywhere.

Need to find the actual log of the install to figure out what is going on.

@ping-localhost

@ping-localhost That error seem seems to be from the plugin manager console or something like it might be unrelated.

@guysoft I think you are right, because when I install the plugin directly through SSH, on the pi account and in the home dir, using pip install "https://github.com/kantlivelong/OctoPrint-PSUControl/archive/master.zip", everything works as expected.

However, I get a massive error when I run the following (which is what OctoPrint runs, but without the no cache dir):

/home/pi/oprint/bin/python -m pip --disable-pip-version-check install https://codeload.github.com/kantlivelong/OctoPrint-PSUControl/zip/master

Error it outputs: https://gist.github.com/ping-localhost/aad12f9619b13deaf5e2d6810407a0f5#file-terminal-log

EDIT: I was successful in installing PSU Control after I copied RPi/ and RPi.GPIO-0.7.0.egg-info from /usr/lib/python3/dist-packages to /home/pi/oprint/lib/python3.8/site-packages/. I did have to tell OctoPrint to install PSU control again, but after that stuff started working.

Not the way to actually resolve this issue, but at least I can use PSU control again, which does make me happy 😅

@foosel

@foosel looks like a plugin manager bug?

@guysoft

@guysoft Negative, the plugin manager isn't involved anymore at this point, that's a failing pip install during intake of a dependency.

Here are my version, in case it helps (they are the same):

pi@octopi:~$ /home/pi/oprint/bin/python -m pip --version
pip 21.0.1 from /home/pi/oprint/lib/python3.8/site-packages/pip (python 3.8)
pi@octopi:~$ /home/pi/oprint/bin/python --version
Python 3.8.6

pi@octopi:~$ python3 -m pip --version
pip 21.0.1 from /home/pi/.local/lib/python3.8/site-packages/pip (python 3.8)
pi@octopi:~$ python3 --version
Python 3.8.6

I'm currently testing/using the latest nightly build 2021-02-23_octopi-20.10-preinstalled-server-arm64+raspi-1.0.0.zip on my RPI4 8GB and PSU control (and GPIO Control/anything that uses RPi.GPIO) fails to be installed due to the following error:
2021-02-23 21:52:16,545 - octoprint.plugins.pluginmanager - ERROR - Reason: UnicodeEncodeError('latin-1', '  source/c_gpio.c: In function ‘setup’:\n', 31, 32, 'ordinal not in range(256)')
I've some logs available as a gist here: https://gist.github.com/ping-localhost/aad12f9619b13deaf5e2d6810407a0f5

As far as I can tell, this seems to be a silly error wherein the command-line output is being converted from Unicode to latin1 to strip out the colour control characters, and the string doesn't work as latin1 because the output contains non-latin1 characters. I hacked around it in my installation by just editing the offending file (/home/pi/oprint/lib/python3.8/site-packages/octoprint/util/commandline.py) to change line 57 from this:

 return _ANSI_REGEX.sub(b"", line.encode("latin1")).decode("latin1")

to this:

 return _ANSI_REGEX.sub(b"", line.encode("latin1", "namereplace")).decode("latin1", "namereplace")

and restarting octoprint. You could also use ignore instead of namereplace probably, but I didn't test that because it doesn't actually matter very much what the command-line output is, as long as it doesn't throw an error.

This is part of the nightly build and is planned to be released when we release. So new bugs should go in a separate issue. Closing.

🐛 Add haproxy.cfg for 2.x versions

Add rpi.gpio-common guysoft/OctoPi#711 (comment)

Navigation Menu

Repository navigation

Making OctoPi build on Ubuntu 64bit so we have 64bit builds #711

30 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Making OctoPi build on Ubuntu 64bit so we have 64bit builds #711

Description

Activity

CRCinAU commented on Jan 11, 2021

guysoft commented on Jan 11, 2021

CRCinAU commented on Jan 11, 2021

CRCinAU commented on Jan 11, 2021

CRCinAU commented on Jan 11, 2021

DrDrache commented on Jan 11, 2021

DrDrache commented on Jan 11, 2021

XboxOldie commented on Jan 11, 2021

dan-and commented on Jan 12, 2021

guysoft commented on Jan 12, 2021

XboxOldie commented on Jan 13, 2021

guysoft commented on Jan 13, 2021

guysoft commented on Jan 13, 2021

CRCinAU commented on Jan 13, 2021

XboxOldie commented on Jan 13, 2021

30 remaining items

XboxOldie commented on Feb 22, 2021

XRyu commented on Feb 22, 2021

Willmac16 commented on Feb 23, 2021

guysoft commented on Feb 23, 2021

ping-localhost commented on Feb 24, 2021

guysoft commented on Mar 1, 2021

ping-localhost commented on Mar 5, 2021

guysoft commented on Mar 5, 2021

foosel commented on Mar 5, 2021

ping-localhost commented on Mar 5, 2021

werdnum commented on Apr 3, 2021

guysoft commented on Apr 7, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions