Closed guysoft closed 2 years ago
First observation/regression: changing the password via octopi-password.txt
seems to no longer work on the 32bit image. As that is what we tell people to use when they have managed to forget their SSH credentials, this needs to be fixed. Possibly a side-effect of the userless image? On rc1 that was only a problem with the 64bit image (comment), on the 32bit image that previously worked. octopi-hostname.txt
does work on 32bit.
Ill have to look. So regression list for now:
octopi-password.txt
does not work (32bit + 64bit)octopi-hostname.txt
does not workWrote SD card 32bit armf, adjusted wifi details and set static IP over ssh, loaded two plugins: Navbar Temperature Display and Slicer Thumbnails. Ran simple test print. All OK except SoC temp not showing on Navbar Temp display, tool and bed temp showing and responding properly.
Pi3B with Pi camera, Prusa Mini printer.
My printer is in the rebuild stage moving from 8 bit to 64 bit PandaPi v2.9. As such, I'm getting everything ready in Virtual Mode.
I installed the 64 bit release of 1rc2 onto a USB Flash Drive and used it in my Pi3B+ without my PandaPi Board. It launched with no hickups, so I SSHd into OctoPi, setup the printer and began loading Plugins one at a time. I've installed fifteen Plugins, rebooting each time, and experienced no issues. Snip of Plugins is attached.
Using SimplyPrint, I sliced a file and began a virtual print, again with no issues.
If a Virtual printer installation is not of any value to you, let me know and I'll wait till I have the printer functioning again at some point in the future.
Wrote SD card 32bit armf, adjusted wifi details and set static IP over ssh, loaded two plugins: Navbar Temperature Display and Slicer Thumbnails. Ran simple test print. All OK except SoC temp not showing on Navbar Temp display, tool and bed temp showing and responding properly.
Pi3B with Pi camera, Prusa Mini printer.
I've got a pull request in for a fix for this plugin. Although it doesn't look like the plugin has been maintained for a little bit so I'm not sure when it will get approved and merged or if I will have to take over it. My fix looks like it also works for the 64 version too after just testing it. I also made sure it still works on the previous version too.
Just wanted to let you know i saw the announcement on OctoPrint main site and i'm installing the image right now :) Will report any errors / problems.
Is it from "devel" github branch? README there is not up to date (for example about pi username/password).
Testing on raspberry pi 3b, 64bit variant (only keyboard and monitor connected).
On boot userconfig.service is started which runs curses-based program to set keyboard layout and also new username for existing 'pi' user and new password. That program sometimes fails to switch console to proper TTY which looks like start stuck on A start job is running for User configuration dialog
(switching manually via alt+arrows allows to find correct TTY). Not a octopi fault. Just a bit confusing at start.
Q: is octopi / octoprint ready to work with any username other than 'pi' ?
wlan didn't start because "dhcpcd[3621]: dhcpcd_prestartinterface: wlan0: Operation not possible due to RF-kill". Soft rfkill is active (as shown by rfkill list).
The default rfkill kernel module state is to soft block. There is a systemd-rfkill.service which saves/load rfkill state.
Image provides platform files with default, blocked state:
# grep "" 1/var/lib/systemd/rfkill/*
1/var/lib/systemd/rfkill/platform-3f300000.mmcnr:wlan:1
1/var/lib/systemd/rfkill/platform-fe300000.mmcnr:wlan:1
systemd-rfkill.service will pickup rfkill active block state from these files at start for matching platform.
These should have 0 or rfkill unblock wlan
should be called from scripts or /etc/modprobe.conf.d/octopi.conf with options rfkill.default_state=0
provided. Tested only first solution with setting platform files to 0 in image.
(manual workaround if anyone hits this: rfkill unblock wlan; systemctl start systemd-rfkill.service; reboot
)
Changing password via octopi-password.txt works for me. btw. this is duplicating functionality from /usr/lib/userconf-pi/userconf-service
:
for BOOT_CONF_FILE in /boot/userconf /boot/userconf.txt; do
If one of these files contain "newusername:newpassword" scripts will change "pi" user in the system to newusername and set newpassword for it.
So far no octopi problems noticed. octoprint complains about one asset but that's more octoprint problem than octopi:
2022-08-09 16:13:54,486 - octoprint.server.util.tornado - WARNING - Precompressed assets expected but bootstrap-colorpicker.css.map.gz does not exist in /home/pi/.octoprint/generated/webassets, using plain file instead.
Edit: can we get vim in default install, too ? :D
@arekm 1.devel branch is the current branch used for nightly builds which become RCs
@guysoft
User sets own username (using imager or at first boot via userconfig.service ). And indeed no password in images:
$ sudo mount 2022-04-04-octopi-bullseye-armhf-lite-1.0.0.img 32bit -o loop,offset=$((532480*512))
$ sudo mount 2022-04-04-octopi-bullseye-arm64-lite-1.0.0.img 64bit -o loop,offset=$((532480*512))
$ sudo grep pi *bit/etc/shadow
32bit/etc/shadow:pi:*:19086:0:99999:7:::
64bit/etc/shadow:pi:*:19086:0:99999:7:::
$ ls -l *bit/var/lib/systemd/rfkill/
32bit/var/lib/systemd/rfkill/:
total 0
64bit/var/lib/systemd/rfkill/:
total 8
-rw-r--r-- 1 root root 2 Apr 4 16:30 platform-3f300000.mmcnr:wlan
-rw-r--r-- 1 root root 2 Apr 4 16:30 platform-fe300000.mmcnr:wlan
$
Hello! The default password 'raspberry' does not work for me at all. I've got the 64 bit version.
EDIT:
Fixed it. Had to activate SSH within the Raspberry Pi Imager
@arekm indeed fixed it there once I saw I forgot to update. I updated only the "Changes in the image since RC1" section initially and missed it in the summary. Thanks for all the testing and sanity reading.
@EddyMI3d Interesting. They might have changed the mechanisim because of rpi imager.
As I wrote earlier:
There is no default 'pi' user and 'raspberry' password anymore with latest raspbian OS (as mentioned in note on https://www.raspberrypi.com/documentation/computers/getting-started.html).
To quote that note exactly:
In the past Raspberry Pi OS had a default user name and password; user name pi, with password raspberry.
This is no longer the case. However if you are using an older version of the operating system, or you are
working with an existing installation, this default user may be present. If you have not already done so,
you should change the default password straight away to ensure your Raspberry Pi is [secure]
(https://www.raspberrypi.com/documentation/computers/configuration.html#securing-your-raspberry-pi).
It's not related to imager. They changed it (so user is required to set new own username and own password via imager or at first boot or via /boot/userconf /boot/userconf.txt files) to avoid problem with raspberry pis getting exposed to internet with default username and password that then get picked up by botnets.
Yap, that gave me the hint. It's well hidden in the masses on that page.
As far as I knew, OctoPi intended to keep the default username/password for now. In the 32 bit image this is exactly the case, everything is setup with pi
/raspberry
as it has been. On the 64 bit image it is not, which I think is a bug at the moment.
Being able to change the username is something that should probably be added. It is supported through the RPi imager at the moment with this script that Gina added - we had a large number of people not reading instructions and changing the username, so a quick patch had to be added. Maybe this just needs to be moved into the main OctoPi image? I had forgotten about it for a while, and maybe there is a better way of doing things.
I'm not sure if this has been fixed, but it seems the webcamd
service continues to restart as systemd is waiting for webcamd to fork - however it doesn't.
Changing Type=forking
to Type=simple
in /etc/systemd/system/webcamd.service
seems to fix the problem.
Saw this happen in 2022-07-16_2022-04-04-octopi-bullseye-arm64-lite-1.0.0.zip
- or filename 2022-04-04-octopi-bullseye-arm64-lite-1.0.0.img
I'm not sure if this has been fixed
It's fixed: https://github.com/guysoft/OctoPi/commit/6cb38c20755f9d1dc3cff493545b88738fc8e41d
Saw this happen in
2022-07-16_2022-04-04-octopi-bullseye-arm64-lite-1.0.0.zip
- or filename2022-04-04-octopi-bullseye-arm64-lite-1.0.0.img
This file is not the one listed at the top of this issue, make sure that you are testing the correct images. In the images posted in the original issue, webcamd is set to simple, dated 2022-08-03.
Edit: to correct this, it is only fixed in the 32 bit images.
Not a "bug" but: https://github.com/guysoft/OctoPi/blob/devel/src/modules/octopi/filesystem/root/etc/haproxy/haproxy.2.x.cfg#L35 replace-path operates only on path, so no need for that "not matching space and :" part (which was needed for 1.x reqrep - since it operated on request+headers buffer).
What's purpose of this anyway? It tries to rewrite thing into the same thing again (in 2.x and 1.x configs).
This file is not the one listed at the top of this issue, make sure that you are testing the correct images. In the images posted in the original issue, webcamd is set to simple, dated 2022-08-03.
To be fair - this problem still exists in RC2 using the file: 2022-08-03_2022-04-04-octopi-bullseye-arm64-lite-1.0.0.zip
and 2022-04-04-octopi-bullseye-arm64-lite-1.0.0.img
.
@guysoft - Is that supposed to be fixed in this build?
I noticed after doing a clean flash that Type=forking
was still set in /etc/systemd/system/webcamd.service
.
Hmm, it is fixed in 32bit image only.
Downloaded https://unofficialpi.org/Distros/OctoPi/nightly-arm64/2022-08-03_2022-04-04-octopi-bullseye-arm64-lite-1.0.0.zip again just to be sure.
$ mount |grep 2022-04-04
/home/users/arekm/test/opi/2022-04-04-octopi-bullseye-armhf-lite-1.0.0.img on /home/users/arekm/test/opi/32bit type ext4 (rw,relatime)
/home/users/arekm/test/opi/2022-04-04-octopi-bullseye-arm64-lite-1.0.0.img on /home/users/arekm/test/opi/64bit type ext4 (rw,relatime)
$ grep Type *bit/etc/systemd/system/webcamd.service
32bit/etc/systemd/system/webcamd.service:Type=simple
64bit/etc/systemd/system/webcamd.service:Type=forking
$ ls -l *bit/etc/systemd/system/webcamd.service
-rw-r--r-- 1 root root 351 Jun 17 01:00 32bit/etc/systemd/system/webcamd.service
-rw-r--r-- 1 root root 354 Jul 15 12:50 64bit/etc/systemd/system/webcamd.service
@guysoft how is that possible? Edit: ok, separate file with the same content (too bad that file duplication is needed leading to bugs like this)
The gspca_main/gspca_ov534 modules no longer seem to be included in RpiOS 2022-04-04 so my Playstation Eye webcam fails to initialise on both versions of RC2. I assume these were removed due to incompatibility with the new camera stack, but since OctoPi is using the legacy one would it be possible to add them back in?
EDIT: Seems like the removal was not intended and it has been resolved upstream, guess I'll wait until the next RC 😃 : https://github.com/raspberrypi/linux/commit/3dd028beb5ff4f01d447754b9bf0bac4732e7713
As workaround: apt-get update; apt-get dist-upgrade; reboot
and you should get 5.15.56-v8+ kernel which has gspca_ov534
As workaround:
apt-get update; apt-get dist-upgrade; reboot
and you should get 5.15.56-v8+ kernel which has gspca_ov534
Thanks, not sure why that didn't occur to me last night, too tired I guess!
I can also confirm that changing the service type in the 64bit image from forking to simple fixes the issue I was having with the webcam freezing in the RC1 (64bit) build.
As far as I knew, OctoPi intended to keep the default username/password for now. In the 32 bit image this is exactly the case, everything is setup with
pi
/raspberry
as it has been. On the 64 bit image it is not, which I think is a bug at the moment.Being able to change the username is something that should probably be added. It is supported through the RPi imager at the moment with this script that Gina added - we had a large number of people not reading instructions and changing the username, so a quick patch had to be added. Maybe this just needs to be moved into the main OctoPi image? I had forgotten about it for a while, and maybe there is a better way of doing things.
+1 for adding official support for changing the username. In addition to the locations that script modifies I needed to manually change the interpreter directive at the top of ~/oprint/bin/octoprint as well to get it to start successfully with a custom username.
I've added a PR for the username changes, and a couple of other fixes I noticed.
Thanks all for testing and reporting. I am planning to fix this though I've been swamped with a new job. Puled fixes from @cp2004 they should go in a nightly. But the 64bit username and 32bit username not matching is strange and i need to find the time to take a look why its not working
A quick question. Which version of wpa_supplicant does 1.0 come with? The current released version uses 2.8, which is broken for wpa2 enterprise, so just checking to see if there is a chance 1.0 would allow me to use wifi again.
@GurliGebis
pi@octopi:~$ wpa_supplicant -v
wpa_supplicant v2.9
Copyright (c) 2003-2019, Jouni Malinen <j@w1.fi> and contributors
Is that new enough?
The latest is 2.10 atm which is only on debain sid: https://packages.debian.org/search?suite=all&keywords=wpasupplicant
Latest is listed here: https://w1.fi/wpa_supplicant/
@GurliGebis
pi@octopi:~$ wpa_supplicant -v wpa_supplicant v2.9 Copyright (c) 2003-2019, Jouni Malinen <j@w1.fi> and contributors
Is that new enough?
The latest is 2.10 atm which is only on debain sid: https://packages.debian.org/search?suite=all&keywords=wpasupplicant
Latest is listed here: https://w1.fi/wpa_supplicant/
That should fix the issue, looking forward to the release :)
Looking at preparing 2022-10-19 as RC3 - only issue left is that the dialog pops on 64bit but not on 32bit
All three issues above (octopi-password.txt
, octopi-hostname.txt
and the user change dialog seem to work now
Tested output:
Just tested and octopi-password.txt
does work on the 32bit image.
output (date is not relevant because no internet):
pi@octopi:~$ sudo systemctl status change_password | cat
● change_password.service - LSB: Change pi's password via /boot/octopi-password.txt
Loaded: loaded (/etc/init.d/change_password; generated)
Active: active (exited) since Mon 2022-04-04 13:23:43 BST; 1min 15s ago
Docs: man:systemd-sysv-generator(8)
Process: 248 ExecStart=/etc/init.d/change_password start (code=exited, status=0/SUCCESS)
CPU: 1.528s
Apr 04 13:23:32 octopi systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Apr 04 13:23:43 octopi chpasswd[335]: pam_unix(chpasswd:chauthtok): password changed for pi
Apr 04 13:23:43 octopi change_password[333]: Password for user pi changed and change file deleted.
Apr 04 13:23:43 octopi systemd[1]: Started LSB: Change pi's password via /boot/octopi-password.txt.
Setting hostname also works on 32bit:
sudo systemctl status change_hostname | cat
● change_hostname.service - LSB: Change pi's hostname via /boot/octopi-hostname.txt
Loaded: loaded (/etc/init.d/change_hostname; generated)
Active: active (exited) since Mon 2022-04-04 13:29:29 BST; 1min 39s ago
Docs: man:systemd-sysv-generator(8)
Process: 245 ExecStart=/etc/init.d/change_hostname start (code=exited, status=0/SUCCESS)
CPU: 108ms
Apr 04 13:29:24 foo systemd[1]: Starting LSB: Change pi's hostname via /boot/octopi-hostname.txt...
Apr 04 13:29:29 foo systemd[1]: Started LSB: Change pi's hostname via /boot/octopi-hostname.txt.
It looks like there is a difference between the 32bit and 64bit. That the user change dialog pops up on the 64bit but does not in the 32bit. And I am not sure why. I need to investigate, if anyone knows why it would help me.
Found it, expect RC3 :)
Second release candidate for OctoPi 1.0.0
There are both 32bit and 64bit images available. Which give support to new Raspberry Pi 4B hardware pis that have been shipping out there. The 64bit image is based on on RpiOS 64bit and not Ubuntu 20.04.4 as it was in RC1, since it seemed more stable than RaspberryPi OS when testing 64bit, it might improve later on.
Raspsberrypi 3 and up can try the 64bit version. No performance gain in normal OctoPi is expected. It might help future plugins.
Please try the release candidate so we know it works.
32bit armf: Download it at: https://unofficialpi.org/Distros/OctoPi/nightly/2022-08-03_2022-04-04-octopi-bullseye-armhf-lite-1.0.0.zip
Md5:
7697e9e235e22ce3cab992be074e4a9a
.64bit arm64/aarch64: Download it at: https://unofficialpi.org/Distros/OctoPi/nightly-arm64/2022-08-03_2022-04-04-octopi-bullseye-arm64-lite-1.0.0.zip
Md5:
28b817abcfcef877219f3c9b05913d01
.Changes in the image since RC1
/opt/ffmpeg-hls/ffmpeg
#784Changes in the image
OctoPrint 1.8.0