DietPi-Software | OctoPrint: Migrate to support new internal updater #3940
Comments
|
Hi, many thanks for your message. I tried to replicate the issue without success. I installed Octprint as well in my RPi4B (aarch64) and run the update offered by Octprint to version 1.5.0.
the only thing needed was a reboot of the whole system as it seems self initiated service restart did not worked correctly. Did you tried to reinstall Octoprint? |
|
Thank you for your prompt response! Having said that... The problem arises either by starting octoprint as a service using The errors are the same as in the main post. I specify that I am running the commands as root. EDIT: In addition... If I try to reach the login page... This appears in the log: |
|
Let's start from the beginning. Can you run the following to check for the missing vcgencmd command: |
|
Sure, here is the output: |
|
Ah I guess root (or And with the last update we switched to a non-root service user. Hmm, not sure whether permission to run vcgencmd can be gained via certain group or capability. Will check that, however, it is just a warning, not responsible for the failure. Responsible for the failure is a bunch of missing files in If it still does not work, probably the left files from the old instance are responsible. Currently not sure why I chose to not remove the previous install dir but merge the new files into the old directory instead 🤔 (as configs have been moved to So another test would be, if the above fails the same way: |
|
Regarding the first test... Nothing to do, the errors remain the same. At this point having a backup of OctoPrint... I tried a more drastic solution:
At this point... I can't say what happened/changed. The imported backup is 5 minutes before my last octoprint update (and just before it broke). I really don't know |
Hmm, will try the same now on RPi. |
|
Interesting, I'm pretty sure that Git was used by the internal updater, the last time I checked, however now pip is used only. This means the install/Git dir in The problem is that pip global install requires root permissions. The internal updater however does not recognise that itself is a globally installed instance and runs pip in user mode, hence installing a second instance to Further check:
So now the question is, whether a virtual environment or user mode install is the better choice. Not sure what the practical difference are but on first view user mode install seems to be simpler since there is no need to "activate" a venv first but |
|
Ah found a better way, probably: https://docs.octoprint.org/en/master/configuration/config_yaml.html#server Change setting: I'll add a sudoers config as well to allow OctoPrint restarting itself, calling pip the defined way, shutting down and restarting the server, to re-enable those commands from the web UI. |
|
Same error here! |
|
It did cost some headache and I ran into a nasty bug on Debian Bullseye, but (aside of Bullseye) have a working solution now that is still based on a system-level install of OctoPrint, i.e. being installed to The alternative would be to make it a user-level install, i.e. installed with For now I fixed/implemented it the way that it works as intended before, but I'm open for opinions whether a local install into the octoprint directory would be better in your opinion or not. |
MichaIng
added
Solution available 🥂
|
Honestly I find the solution adopted now the best one, I have never been a fan of user level installed applications (where there is no real need of course). Then in daily use I think that an installation method rather than another one to the end user who just wants to print in 3D changes very little... |
For single-user SBCs or pure server devices I totally agree. I've never heard of an SBC that is used by multiple persons which all install their own server/daemon applications, so that e.g. multiple OctoPrint servers would be running on the same machine 😄. But just to clarify, it would have been a user-level install for the
That is true, but with ~~2000 OctoPrint instances it is worth to think through pros and cons of the different options 🙂. |
|
Hey guys, just going to chime in for following and to offer another testing bed. I think I'm in the same boat of issue with the latest update to the Octoprint install. I'm receiving similar errors around permissions trying to update octoprint and install plugins. One such offending line excerpt below. Also happy to open a separate issue if this needs different tracking. Basics was that after the update, my system came up without any of my plugins, I can't update, start/stop/reboot commands don't work, and attempted installation of plugins "succeed", but never actually work or show up installed anywhere. |
|
I'm not sure how well the regular update works since the updater itself has vastly changed:
I suggest to update to our beta branch: This includes a reinstall of OctoPrint, preserving your current config and data, of course. |
Got it. I will look to try that later. Octoprint has been a decently finicky application to run on dietpi - but I think it's also a bit finicky in itself too. Just to validate I understand, each of those 3 lines is a command to run verbatim on the CLI to the dietpi host? |
Exactly. the first to create/updater your backup, which is always good when switching branch or installing new software, just in case 😉, the second to switch to the beta branch (I just changed it, since the beta is out now) and the third to run the update. If you are anyhow unhappy, you can the easily revert via |
|
Thanks for the confirm. Just wanted to be sure as I was thinking the second line might be an output from line 1. :) So in running through this, I believe I have in fact been able to get this running again. Specifically, my plugins have all come back, and thankfully I believe the data for them was still intact. In the Octoprint console there was a "cleanup" list of plugins, so I knew which plugins to re-install. After doing this, my Octoprint looks to be back in shape, pre-update. I think there are a few random settings that have been changed along somewhere, but I'll see after resetting them if there is any real issue (such as a permission missing maybe). I have one plugin that is being stubborn and won't install - but I'll have to dig into it later. So for the time being - I would say it looks like this does indeed fix the issue. Unfortunately, it will require some manual work on re-installing the plugins, but their data seems intact. Will keep you posted when I try testing some more. |
|
Many thanks for the feedback. Yes the last OctoPrint update was a larger one. The changes in the internal updater was what we recognised (what broke the internal updater with our implementation basically), but very likely that something around the plugins and settings has changed as well. Yes, please let us know if there is anything not working, especially permissions, so that we can implement/fix it prior to v6.34 release. Also if there is some settings/plugin migration we can automate with the update. |
|
Ya it's a good catch and well timed. I think I had updated to the version that broke things first. Then the dietpi update helped the service at least start. Now its all working! 🙌🏻 The plugin was a plugin specific issue it appears. In case anyone else is using the Bed Visualizer, there is a note on their plugin page that for Python3 implementations there is a library needed or it will fail silently.
Can you point me to where the data/plugins may have been stored earlier? It might be possible they're still there and I can validate there might be a way to simply migrate them. As I recall, most of the plugins are simply a call to install necessary OS libs and then a few linked files usually. If I can test pulling those over you may be able to fully migrate? I do vaguely recall Octoprint indicating that plugins are not backed up, however, but their settings are. I'll leave that to the pro's to know! 😉 |
AFAIK all plugins are own Python modules as well, right? So they should have been installed to the same system Python path as now: |
|
Ok that totally makes sense then. That would explain why the first update rendered it dead. Then my update of dietpi, brought me into the realm of living and the service starting. The plugins being python2 is a good point - so it likely wouldn't even work to move them as there may be minor discrepancies in the actual plugin. Perhaps a readout somewhere of current plugins installed (aka folders stored) just so user knows they'll need to re-install. Not sure there is a way to automate it on OP side. That would be best for them to implement so backups could also include a listing to auto re-install. Either way, looks good to me then. I'll let it run, see if I can just play around make sure no other odd errors. I'll keep myself subbed for when the fix gets put in prod release so I can switch back to mainline. |
I was just thinking the same. Although probably not all plugins are available for Python 3 or names changed, also not all plugins for OctoPrint also have it in their name: https://plugins.octoprint.org/
Full loop: But that might also reinstall abandoned plugins 🤔. |
|
Looks likely the best option that can allow for re-install automagically - though you make a valid point. One of my plugins for example is no longer available as it's not compatible with P3 I believe. But running a Bigger issue is likely that there are 3 supported models for install (which 2 I think are really just pip anyway): https://docs.octoprint.org/en/master/plugins/distributing.html Not sure if you have a sample but I can work to sanitize a copy if it's of use as well to look at possibly just dumping the plugins list from the current config file for the user to the console? At least again just knowing what you had is useful at the very least when you have a long list like me. It's a yaml located in |
Since you were coming from Python 2:
Luckily the destination for any Python module that should be recognised by the system-wide installed OctoPrint instance, is installed into the same directory structure, and it can be detected via the same |
MichaIng
changed the title
|
@bombjack7000 I ping you here as you might be interested as well. Hey guys. It looks like there are still OctoPrint internal bugs with the method I was relying on to do a system-wide/global OctoPrint install: OctoPrint/OctoPrint#3700 (comment) There is another issue present since Debian Bullseye that breaks the method at a different level: #3959 But it is unlikely that both issues are addressed with an OctoPrint release until December 20 when I want to release DietPi v6.34 at latest. The problem is the following:
So, since I do not want to run OctoPrint as root user anymore, as a strict rule for all software titles where I touch the install code, there are only two possibilities that would work without the above bugs resolved:
For me, both above solutions look pretty similar: A dedicated Python environment that can only be accessed by the octoprint user. The second option looks a bid simpler to me. In both cases it means that all OctoPrint plugins (which are Python modules as well) need to be reinstalled after the migration ( I would go with the "--user" level install which seems to be the easiest implementation, also when it's about maintaining it from console, but if someone has any suggestion or a different idea, I am happy to hear it. |
|
Thanks for the well document, thought out, and extensive research and involvement to solving this. I always appreciate the stuff you guys do here - it's why I try to always run DietPi on my small boards. I'm with you and totally understand it, as I've run into this with HASS on another board running DietPi. 😃 As I started to read that one block, I started to go oh ya, like HA - then you mentioned exactly that. I'd lean on your wisdom as I don't know any better solutions and I think the pro/con you laid out makes sense. In the end, I think if there is fork-lift effort involved (plugin re-installs) - its just the nature of the beast. As long as there is something like breaking change notice listed in the release notes, you've done what you can to advise and help alert people of the coming change. Thanks as always - happy to test when the new release is ready. |
|
Nice, an X-based touch screen interface for OctoPrint: https://github.com/Z-Bolt/OctoScreen |
|
That is pretty neat - though I dont' have a touch screen on mine. It's actually hidden away in a full case as an addon to my printer. So mine just hides away, and I use the actual printer interface if I'm in there nearby it. |
|
Does this mean you've rolled the changes into the next release? I saw an OP update, so I wanted to wait and test on the new revision of DP first, and use that to test upgrade to latest OP. |
It's part of the just released DietPi v6.34 🙂. |
|
Wow - I really could have just read the release notes. That was dumb. Thank you though, I'll try it out this week! Keep up the fantastic work!! And happy holidays! |
|
Just followup, tested latest update and it all worked. Had to re-install the plugins as expected, but hopefully the last time! 😉 One tip for anyone who lands here after updating for the first time in a long time - don't freak out about forgetting what plugins are there. Simply login as usual and navigate to the Plugin Manager. Once there, click on the Cleanup tab at the top. This will show you a laundry list of the plugins that have data, but no associated plugin. I'd suggest a second tab or more separate window in your favorite browser connected to the UI and on that section, while on the other you open the Get More section and start searching all your plugins quickly to reinstall. Once done it'll need a restart of octoprint, and you should be all set. Mine went seamlessly ... both times now 😄 |
That is an extremely helpful hint, many thanks for sharing 👍. Merry Xmas or holidays at least 🎄. |
Creating a bug report/issue
Required Information
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=33
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
Linux octopi 5.4.72-v8+ #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020 aarch64 GNU/LinuxAdditional Information (if applicable)
Steps to reproduce
Expected behaviour
The software should update and a web interface should appear on port 5000
Actual behaviour
OctoPrint software stays blocked to the web page "Connecting to Octoprint Server..."
Extra details
If i try to start the service manually there are some lost components, OctoPrint probably expects to update things that were not imported in the installation from DietPi software store:
The text was updated successfully, but these errors were encountered: