OctoPi 1.0.0 RC3 Status #796
Comments
|
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 Can also be confirmed by these lines in the motd: And OctoPrint also warns about this:
Meanwhile: The 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 A quick test with this seems to work at least:
#!/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"
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. |
|
Just tested it again. So, it looks like it fails only on the initial boot. A subsequent creation of another |
|
For reference, flashed and provisioned via my testrig (basically a scripted Then SSH attempt after first boot, new password doesn't work, old one still in effect: Create new password file, reboot: Password now works?! |
|
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. |
|
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. |
|
In octopi.txt, example for "Configuration of network monitoring" should also have a line for IPv6, like
|
|
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. |
|
@wtremmel Strange, I use here the 64bit version on a dual-stack network and it reaches using the ipv6. |
|
I tried the IPv6 IP directly. I will try again after the holidays when I can debug properly. |
|
I think ill release this when I get time to do it. |
|
ok, finally got a HDMI cable to attach my RasPi to debug the 64bit problem, here is what I found so far:
|
|
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? |
|
@CoryCharlton Then restore: We should really have that documented somewhere |
|
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. |
|
I've been considering installing the RC image, because I would like to run 64-bits, but I have some questions, if you don't mind:
Thanks for your great work! |
|
As this is external, leaving this comment mostly as an FYI in case anyone else hits the issue. I had a persistent USB issue with 0.18, and it was resolved by updating the kernel. After installing rc3 64 bit, the issue is back, even after updating the kernel. This happens often enough that I cannot use my pi to print: ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32 This appears to be related to an issue that should be resolved in current kernels, but seems it is not at least in 64 bit. raspberrypi/linux#5211 Broken Version --> Linux octopi 5.15.89-v8+ #1620 SMP PREEMPT Wed Jan 18 12:26:08 GMT 2023 aarch64 GNU/Linux |
|
Hi. I'd like to try this in order to get a Raspberry Pi Camera Module.V3 working. I've been googling around and can't find a concise description of how to install a beta. My Debian skill's are a bit rusty, and although I've used imager to install octopi before the raspberry pi imager support came along, the memories are vague. I'm assuming that the first step would be to use apt-get to update the base system on the pi. Can someone point me to a good walkthrough on how to install the beta? Thanks. |
|
@rubyredrick you can take a backup from the Octoprint UI. Then download the .img from the links above and use the Raspberry PI imager to install it. |
Thanks. Will that update raspian or do I need to do that first? |
The Raspberry PI imager will wipe your SD card and install the image you downloaded. I didn't see any "upgrade" path for the RC other than "start fresh and restore backup" as I outlined but maybe I missed something 🤷 If you have a second SD card available you could always install the image on that so you could easily swap back to your current installation if you run into problems. |
|
Downloaded both images (32/64 bit). Put them on 32GB mSD cards via raspberry imager. next: First time ever attached a monitor to a raspberry :). Then checked what is going on. Nothing connected to raspi initially except power supply (although through gpio due to broken microSD port). Later added hdmi-monitor and usb-keyboard. I'll try on the other raspi once that is free (finished printing) to see if it is something weird local with that one pi or reproducible on others. edit:
edit2: lol, it's not bootlooping when I bend it a little. So something wrong with this specific one. If only these things would no longer be so expensive to replace :) edit 3: Works fine with restore of old octoprint settings. |
|
64bit version doesn't include the Looks like it's back to 32bit for me |
|
Didn't work for me on 32bit either :( I'm going back to stable for now, and resigning myself to a script to keep the network up as I wait for an RC4 that works with the pi camera |
|
I opened issue #804 related to network monitoring. It might not be specific to 1.0.0 RC3 but that is where I am currently experiencing it. I've fixed the script on my local system and sent a PR. |
As you stated yourself, the pi camera does work, albeit with |
|
Exactly - I got my Raspberry Pi Camera v3 working following these instructions: |
|
Yes, and that's precisely the fork I have in mind for patching this post-release with OctoPi-UpToDate, since it's really really time to get this build released. |
Okay, so it sounds like this needs to go through at least one more round of release candidacy, with full I really want to avoid using |
|
In the end it's something that @guysoft has to decide on, but frankly I don't see a reason why we should now do yet another round of RC on 1.0.0 just because of input-raspicam, when something that already works fine for all the hardware that existed when this RC phase started is available in the shape of input-uvc.so. This particular RC phase has been going on since Given that we have the option to add picam3 support AFTER the release on an updated image, without having to delay the release of 1.0.0 which works fine for the majority of existing use cases, and that will automatically fix this problem as well, personally I'd consider this not a reason to do an RC4. We already decided against that for some other issue (password change file not working on first boot). Considering that Guy has a ton of stuff on his plate I can imagine that putting in the work you are asking for is something that would cause a severe delay here. And I'd be happy to do this work instead, but rather via CustoPiZer in OctoPi-UpToDate since frankly that allows me a WAY faster turn-around and my resources for OctoPi stuff are severely limited as well given that I have all of OctoPrint already to manage. For the end-user, there's no difference, we'd simply backport things then from there. |
|
This isn't about the pi cam 3, it's about the contents of My concern is that this gets released and someone new will come along, see the comments in that file, update their config to use If it's acceptable to change just those comments in going from RC to release without another RC then that would work, but I'm very nervous at the thought of a release that actively tells people to use a known-broken strategy. I'd like to see all references to |
|
Release, pop a warning up. Especially if as mentioned the back porting stuff is fine. I assume the rest needs to be, does it work on all current RPi's upto before Camera3 was released. |
That is precisely my fear here since that has already been going on so long. I'd rather fight the fear stated by @kevinwright with documentation (and another quick update script) than causing yet MORE delay here for things that frankly don't even are issues for most of the users out there since they'd never ever touch |
My testing strategy was:
Lacking any guidance against this approach, I would contend that many others are going to upgrade in the exact same fashion, and that it therefore doesn't work on all current RPi's from before the camera 3 was released. This will hit literally everyone who is currently using the raspicam driver and then upgrades. All it takes is an update in the comments in that file to say "raspicam now doesn't work, and here's a link to a page stating why". That could be safely done without an RC but would still save a lot of people a lot of pain. |
|
32bit image: 64bit image: btt: PS: whishlist would be a config that just detects what is there and enumerates. To allow >1 cam. |
Exactly. I'm not concerned about support for the v3 camera, I'm not even concerned about the removal of the input_raspi library. What really bothers me is that Of course I'd like to see libcamera in the image, but as @foosel and @bsimmo suggest, that can come in a later release. And now I know what the issue is I'm comfortable building and configuring my own copy of the arducam fork of mjpg-streamer in the meantime. |
As wished for in #796 I'll add this to the OctoPi-UpToDate build so it will be already done in the images offered on OctoPrint's download page and on the Raspberry Pi imager, so there's IMHO no need for a RC4 for this.
If necessary, see discussion in guysoft/OctoPi#796
|
For the record... Have the following ready for OctoPi-UpToDate (the image that you on OctoPrint's download page, and on the Raspberry Pi Imager):
Will also see I can still make the rpi3 cam work (I finally got my hands on one). |
|
Some news on the RpiCam3/libcamera front. Experiments with the arducam mjpeg-streamer fork turned out rather disappointing, re performance and stability. Instead I have been building a replacement for the mjpg-streamer/webcamd combo based on camera-streamer the past few days, incl. multicam support. Currently running a Pi with a picam3 and two usb cams, working fine. USB stuff also is getting hot plug support. |
As wished for in #796 I'll add this to the OctoPi-UpToDate build so it will be already done in the images offered on OctoPrint's download page and on the Raspberry Pi imager, so there's IMHO no need for a RC4 for this.
|
Released, available on the release page and rpi-imager: |
So I guess this means that OctoPi-UpToDate doesn't reflect these experiments. Yes? If so do you have an ETA? Thanks! |
|
Sure it does. Details at OctoPrint/OctoPi-UpToDate#2 |
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
Changes in the image since RC1
/opt/ffmpeg-hls/ffmpegHLS V4L2 M2M encoder #784Changes in the image
The text was updated successfully, but these errors were encountered: