OctoPi 1.0.0 RC3 Status

[guysoft]

Third release candidate for OctoPi 1.0.0

As before, there are both 32bit and 64bit images available.
The 64bit image is based on on RpiOS 64bit.

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-10-27_2022-09-22-octopi-bullseye-armhf-lite-1.0.0.zip

Md5: 88135c1af2491aa4f114190c728d5fa2.

64bit arm64/aarch64:
Download it at:
https://unofficialpi.org/Distros/OctoPi/nightly-arm64/2022-10-27_2022-09-22-octopi-bullseye-arm64-lite-1.0.0.zip

Md5: a0fe9dd406f7bb4f8bf0a3d0af1d4582.

Changes since RC2

• OctoPrint 1.8.6
• This release deals with the userless images changes ( Add support for new Raspberry Pi OS .xz. userless image CustomPiOS#163 ), updates OctoPrint to latest
• Uses Debian "bullseye" RpiOS 2022-09-22

Changes in the image since RC1

• OctoPrint 1.8.1
• ships ffmpeg with HLS support at /opt/ffmpeg-hls/ffmpeg HLS V4L2 M2M encoder #784
• 64 bit build has moved to raspios (Switch arm64 nightly build to raspios_arm64 #785)
• Uses new Rpi userless system
• Uses Debian "bullseye" RpiOS 2022-04-04

Changes in the image

• Version is 1.0.0, it seem like its about time b6b7f36
• Raspbery PI OS uses bullseye
• rpi.gpio-common has been added
• Fix webcamd daemon loop & handling of non-usb v4l2 devices Fix webcamd daemon loop & handling of non-usb v4l2 devices #741 (@foosel)
• Add a network monitoring for wifi connections Add a network monitoring for wifi connections #729 (thanks @hawkeyexp)
• Delete octopi-network.txt
• picam-bullseye-fix picam-bullseye-fix #763 (Thanks @PowerWiesel)

[foosel]

As already told you via DM, I totally lost sight of this with everything else going on and only now finally got around to testing this. Big big sorry for that.

However, I sadly have to report, that octopi-password.txt does not work (32bit), contrary to your comment #788 (comment). It may very well be showing as being executed, but it is not doing anything. My testrig setup involves flashing an image and then setting the hostname and password via octopi-hostname.txt and octopi-password.txt. Hostname setting worked. However, upon attempting to log into the machine with the newly set password, access was denied. Using the default raspberry instead however worked, so something is broken there.

Can also be confirmed by these lines in the motd:

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

And OctoPrint also warns about this:

Meanwhile:

root@octopia:/home/pi# 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 Thu 2022-09-22 01:23:58 BST; 2 months 16 days ago
       Docs: man:systemd-sysv-generator(8)
      Tasks: 0 (limit: 1472)
        CPU: 0
     CGroup: /system.slice/change_password.service

Sep 22 01:23:56 octopia systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:58 octopia systemd[1]: Started LSB: Change pi's password via /boot/octopi-password.txt.

-- Journal begins at Thu 2022-09-22 01:23:40 BST, ends at Thu 2022-12-08 11:19:00 GMT. --
Sep 22 01:23:46 octopi systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Succeeded.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 442 (change_password) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 444 (chpasswd) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: Stopped LSB: Change pi's password via /boot/octopi-password.txt.
Sep 22 01:23:49 octopi chpasswd[444]: pam_unix(chpasswd:chauthtok): password changed for pi
Sep 22 01:23:49 octopi change_password[442]: Password for user pi changed and change file deleted.

The change_password service basically consists of this:

do_start () {
  text_file="/boot/octopi-password.txt"
  if [ ! -f "$text_file" ]
  then
    exit 0
  fi

  new_password=`head -n1 "$text_file" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' | tr -d '\n'`
  if [ ! -n "$new_password" ]
  then
    log_failure_msg "No new password provided, refusing to change to empty password"
    exit 1
  fi

  (echo "pi:$new_password" | chpasswd && rm "$text_file" && log_success_msg "Password for user pi changed and change file deleted") || log_failure_msg "Could not change password"
}

Running echo "pi:newpassword" | chpasswd manually from a root prompt works and does what it's supposed to do, so I frankly have NO idea right now what's going wrong here. I wonder if it could be solved by getting rid of the init script and converting that into a proper unit instead.

A quick test with this seems to work at least:

/etc/systemd/system/change-password

[Unit]
Description=Allow changing the main user's password via /boot/octopi-password.txt

DefaultDependencies=no

Before=network-pre.target
Wants=network-pre.target

After=local-fs.target
Wants=local-fs.target

[Service]
Type=oneshot
ExecStart=/root/bin/change-password

[Install]
WantedBy=multi-user.target

/root/bin/change-password

#!/usr/bin/env bash

set -e

USERID=1000
FIRSTUSER=`getent passwd $USERID | cut -d: -f1`
PASSWORD_FILE="/boot/octopi-password.txt"

if [ ! -f "$PASSWORD_FILE" ]
then
        exit 0
fi

# read password from file
new_password=`head -n1 "$PASSWORD_FILE" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//' | tr -d '\n'`
if [ ! -n "$new_password" ]
then
        echo "No new password provided, refusing to change to empty password"
        exit 1
fi

# change password
(echo "$FIRSTUSER:$new_password" | chpasswd && rm "$PASSWORD_FILE" && echo "Password for user $FIRSTUSER changed and change file deleted") || echo "Could not change password for $FIRSTUSER"

-- Journal begins at Thu 2022-09-22 01:23:40 BST, ends at Thu 2022-12-08 11:20:00 GMT. --
Dec 08 11:14:11 octopia systemd[1]: Starting Allow changing the main user's password via /boot/octopi-password.txt...
Dec 08 11:14:13 octopia chpasswd[273]: pam_unix(chpasswd:chauthtok): password changed for pi
Dec 08 11:14:13 octopia change-password[271]: Password for user pi changed and change file deleted
Dec 08 11:14:13 octopia systemd[1]: change-password.service: Succeeded.
Dec 08 11:14:13 octopia systemd[1]: Finished Allow changing the main user's password via /boot/octopi-password.txt.

I haven't yet been able to test this against a completely fresh image however and also don't know if I will get around to doing that.

[foosel]

Just tested it again. So, it looks like it fails only on the initial boot. A subsequent creation of another /boot/octopi-password.txt file and then rebooting changes the password. Consider me even more confused now.

[foosel]

For reference, flashed and provisioned via my testrig (basically a scripted dd followed by some file copying to /boot):

[pi@flashhost.lan] out: 2906653696 bytes (2.9 GB, 2.7 GiB) copied, 181.438 s, 16.0 MB/s
[pi@flashhost.lan] out:

Flashing done, giving the system a bit to recover...
... done
[pi@flashhost.lan] sudo: mount /dev/disk/by-id/usb-LinuxAut_sdmux_HS-SD_MMC_000000000498-0:0-part1 /home/pi/mount/pia
[pi@flashhost.lan] put: <file obj> -> /home/pi/mount/pia/octopi-wpa-supplicant.txt
[pi@flashhost.lan] put: <file obj> -> /home/pi/mount/pia/octopi-network.txt
[pi@flashhost.lan] put: <file obj> -> /home/pi/mount/pia/octopi-hostname.txt
[pi@flashhost.lan] put: <file obj> -> /home/pi/mount/pia/octopi-password.txt
[pi@flashhost.lan] sudo: echo 'boot_delay=3' >> "$(echo /home/pi/mount/pia/config.txt)"
[pi@flashhost.lan] sudo: umount /home/pi/mount/pia
[pi@flashhost.lan] sudo: /home/pi/tools/usbsdmux/bin/usbsdmux /dev/usb-sd-mux/id-000000000498 dut
[pi@flashhost.lan] sudo: /home/pi/tools/ykush/bin/ykushcmd -u 3
[pi@flashhost.lan] sudo: systemctl restart um25c_octopia
[pi@flashhost.lan] run: /home/pi/tools/mqtt_annotation.sh pia "Switched pia to DUT mode"

Done.
Disconnecting from flashhost.lan... done.

Then SSH attempt after first boot, new password doesn't work, old one still in effect:

Linux octopia 5.15.61-v7+ #1579 SMP Fri Aug 26 11:10:59 BST 2022 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.


------------------------------------------------------------------------------
Access OctoPrint from a web browser on your network by navigating to any of:

    http://octopia.local
    http://192.168.1.221

https is also available, with a self-signed certificate.
------------------------------------------------------------------------------
This image comes without a desktop environment installed because it's not
required for running OctoPrint. If you want a desktop environment you can
install it via

    sudo /home/pi/scripts/install-desktop
------------------------------------------------------------------------------
OctoPrint version : 1.8.6
OctoPi version    : 1.0.0
------------------------------------------------------------------------------

pi@octopia:~ $ sudo journalctl -u change_password

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for pi:
-- Journal begins at Thu 2022-09-22 01:23:40 BST, ends at Thu 2022-12-08 16:17:28 GMT. --
Sep 22 01:23:46 octopi systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Succeeded.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 451 (change_password) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 455 (chpasswd) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: Stopped LSB: Change pi's password via /boot/octopi-password.txt.
Sep 22 01:23:50 octopi chpasswd[455]: pam_unix(chpasswd:chauthtok): password changed for pi
Sep 22 01:23:50 octopi change_password[451]: Password for user pi changed and change file deleted.
-- Boot c7e5d321d7194b689ef598ef20d91d0d --
Sep 22 01:23:57 octopia systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:58 octopia systemd[1]: Started LSB: Change pi's password via /boot/octopi-password.txt.

Create new password file, reboot:

pi@octopia:~ $ sudo -s
root@octopia:/home/pi# cat > /boot/octopi-password.txt
test
root@octopia:/home/pi# sudo reboot

Password now works?!

pi@octopia:~ $ sudo journalctl -u change_password
[sudo] password for pi:
-- Journal begins at Thu 2022-09-22 01:23:40 BST, ends at Thu 2022-12-08 16:23:47 GMT. --
Sep 22 01:23:46 octopi systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Succeeded.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 451 (change_password) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: change_password.service: Unit process 455 (chpasswd) remains running after unit stopped.
Sep 22 01:23:48 octopi systemd[1]: Stopped LSB: Change pi's password via /boot/octopi-password.txt.
Sep 22 01:23:50 octopi chpasswd[455]: pam_unix(chpasswd:chauthtok): password changed for pi
Sep 22 01:23:50 octopi change_password[451]: Password for user pi changed and change file deleted.
-- Boot c7e5d321d7194b689ef598ef20d91d0d --
Sep 22 01:23:57 octopia systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Sep 22 01:23:58 octopia systemd[1]: Started LSB: Change pi's password via /boot/octopi-password.txt.
Dec 08 16:18:11 octopia systemd[1]: Stopping LSB: Change pi's password via /boot/octopi-password.txt...
Dec 08 16:18:11 octopia systemd[1]: change_password.service: Succeeded.
Dec 08 16:18:11 octopia systemd[1]: Stopped LSB: Change pi's password via /boot/octopi-password.txt.
-- Boot bb3c9a336abf48cf84abb53ee9b46122 --
Dec 08 16:18:16 octopia systemd[1]: Starting LSB: Change pi's password via /boot/octopi-password.txt...
Dec 08 16:18:18 octopia chpasswd[455]: pam_unix(chpasswd:chauthtok): password changed for pi
Dec 08 16:18:18 octopia change_password[453]: Password for user pi changed and change file deleted.
Dec 08 16:18:18 octopia systemd[1]: Started LSB: Change pi's password via /boot/octopi-password.txt.

[foosel]

I'm wondering if we might see some interaction between the new userless stuff or something. Note the second boot in between the two successful runs of the script. I didn't trigger those. If it only fails on the very first boot but works on any after, I think this can be ignored for now. As long as users have a chance to reset their password once they've forgotten it, the thing works as intended.

[guysoft]

Ok good to know. Also I thought it worked for me when testing by hand, so you guess its something related to the userless stuff makes sense.

I think a possible fix would be to try and create a systemd unit and then make it run only after the userless unit. For not I rather just let it go since this image has been held long enough.

[wtremmel]

In octopi.txt, example for "Configuration of network monitoring" should also have a line for IPv6, like

destination_host=fdd1:9494:7978:15::1

[wtremmel]

32bit version worked fine on my Pi4 using an 8GB SD-card. Network is IPv6 only, after changing dhcpcd.conf to use the hardware address for SLAAC everything was fine (make this a config option for /boot ?)

Another suggestion would be a plugin so the .ssh/authorized_keys are included (and restored) using OctoPi backup.

64bit version did not work, RasPi was not accessible via Wifi, to debug I need to detach the Raspi from my printer which I might do next week.
Now I will try to print something.

[guysoft]

@wtremmel Strange, I use here the 64bit version on a dual-stack network and it reaches using the ipv6.
Are you using the ip directly or via mDNS hostname?

[wtremmel]

I tried the IPv6 IP directly. I will try again after the holidays when I can debug properly.

[guysoft]

I think ill release this when I get time to do it.

[wtremmel]

ok, finally got a HDMI cable to attach my RasPi to debug the 64bit problem, here is what I found so far:

• wpa_supplicant gets started twice, once via systemctl, once from dhcpcd (no idea if this can be a problem). I simply disabled it.
• dhcpcd reports error: dhcpcd_prestartinterface: wlan0: Operation not possible due to RF_kill
• rfkill unblock 0 brings the interface up
• adding this to rc.local brings it up every time.
• after upgrading everything to the newest versions (apt update; apt upgrade) the problem was solved, the rfkill in rc.local was no longer necessary.

[CoryCharlton]

I was finally able to get my hands on a RPI 4 at non-gouger pricing so I'll be rebuilding my OctoPI installation. I'd love to get on the latest and greatest and help test out this RC.

That being said I'm not familiar with the OctoPI release process so I'm curious if I install RC3 now would I need to restart from scratch to upgrade to another RC or the final release?

[guysoft]

@CoryCharlton
You can backup and restore your settings via the OctoPrint backup plugin:
https://docs.octoprint.org/en/master/bundledplugins/backup.html

Then restore:
https://community.octoprint.org/t/how-can-i-manually-restore-a-backup-created-with-the-backup-restore-plugin/5570

We should really have that documented somewhere

[CoryCharlton]

Thanks! There was a restore option when I first logged in so that worked.

I installed the 64bit version and everything worked fine out of the box.