Upgrade-helper script

Having reviewed the steps here in the FAQ, I thought it might be useful to create a helper script, possibly to be included with OctoPrint or OctoPi.

If you're more familiar with OctoPrint/OctoPi and the upgrade process than am I, then please comment and let me know if anything needs to be tweaked for this to be useful. Thanks in advance.

Notes:

  • The restore side of things isn't 100% complete yet but the backup seems ready.
  • Some of the commands in the restore section just echo to the screen rather than run.
  • Includes syntax if called wrong.
  • I believe the screen messages accurately describe what is about to happen, allowing the user to exit.
  • If run once with the backup option, it will create a usable list of plugins later to reinstall.
  • The backup option and instructions could be useful to simply back up the .octoprint folder area.
  • Uses standard UNIX methods of backing up folder structures with their timestamps intact.
  • Includes a progress meter for long-running commands.

~/scripts/upgrade-help

#!/bin/sh

if [ $# -lt 1 ]
then
        echo "Usage: ~/scripts/upgrade-help backup | restore"
        exit 1
fi

if [ "$1" = "backup" ]
then
        tput bold; echo This script will STOP the OctoPrint service, generate a list of the current set; tput sgr0
        tput bold; echo "of plugins (overwriting the previous list) and create a tarball with instructions."; tput sgr0
        echo ""
        read -p "Do you want to continue? " -n 1 -r
        if [[ $REPLY =~ ^[Yy]$ ]]
        then
                echo ""
                echo First things first, we need to stop OctoPrint so that everything can be backed up:
                sudo service octoprint stop
                echo The OctoPrint service should now be stopped.
                echo ""
                echo Next, we need to create a list of your currently-running plugins for later reference:
                cat ~/.octoprint/logs/octoprint.log |grep "|" | grep "= /home/pi/" | sort | uniq | sed 's|\|||g'> ~/.octoprint/current$
                ls -l ~/.octoprint/current-plugins.txt
                echo ""
                echo Delete the previous backup if it exists:
                rm ~/dot_octoprint.tar.gz 2> /dev/null
                # Create a tarball in the home directory for the .octoprint folder structure
                echo Next, we create a tarball of the ~/.octoprint folder:
                tar -zcvf --atime-preserve=replace ~/dot_octoprint.tar.gz ~/.octoprint > /dev/null 2>&1 &
                pid=$!
                i=1
                sp="/-\|"
                echo -n ' '
                while kill -0 $pid 2>/dev/null
                do
                        printf '\b%.1s' "$sp"
                        sp=${sp#?}${sp%???}
                        sleep 0.1
                done
                printf '\b'
                ls -l ~/dot_octoprint.tar.gz
                echo ""
                echo Now run the following command from your workstation to download it:
                tput bold; echo scp pi@octopi.local:~/dot_octoprint.tar.gz \~/.; tput sgr0
                echo ""
                echo When you have upgraded your image and have remoted back
                echo into your Pi, then run the following to upload the tarball:
                tput bold; echo scp \~/dot_octoprint.tar.gz pi@octopi.local:\~/.; tput sgr0
                echo ""
                echo If you need OctoPrint running again, execute the following:
                echo sudo service octoprint start
                echo ""
        fi
fi

if [ "$1" = "restore" ]
then
        tput bold; echo This script will STOP the OctoPrint service, provide instructions for uploading your; tput sgr0
        tput bold; echo previous backup and then ask you again if you would like to proceed.; tput sgr0
        echo ""
        read -p "Do you want to continue? " -n 1 -r
        if [[ $REPLY =~ ^[Yy]$ ]]
        then
                echo ""
                echo First things first, we need to stop OctoPrint so that everything can be updated:
                sudo service octoprint stop
                echo The OctoPrint service should now be stopped.
                echo ""
                echo Next, run the following command from your workstation to upload the backup
                echo created earlier:
                tput bold: echo scp \~/dot_octoprint.tar.gz pi@octopi.local:\~/.; tput sgr0
                echo ""
                echo You should see a backup file here:
                ls -l ~/dot_octoprint.tar.gz
                echo ""
                echo If you did not see a file listed above, then you should not continue past
                echo this point.
                echo ""
                echo This next step is potentially dangerous if you did not follow the earlier
                echo instructions. You should have earlier run a remote scp command to download
                echo and now to upload it back to your Raspberry Pi.
                echo "" 
                read -p "Are you sure you want to delete the existing ~/.octoprint folder structure? " -n 1 -r
                if [[ $REPLY =~ ^[Yy]$ ]]
                then
                        echo ""
                        cd ~
                        echo Removing ~/.octoprint...
                        echo rm -rf ~/.octoprint
                        echo ""
                        echo Restoring ~/.octoprint...
                        echo tar -zxvf ~/dot_octoprint.tar.gz
                        echo ""
                        echo Now restarting the OctoPrint service...
                        echo sudo service octoprint start
                        echo 
                        echo When it comes back up, you should now be able to open up OctoPrint in your browser
                        echo and log back in just like before\; however, your plugins are still missing. Go to
                        echo Settings \> Plugin Manager \> Get More... and install the plugins that are seen here:
                        cat ~/.octoprint/current-plugins.txt | grep -v bundled
                fi
        fi
fi

As somebody who does more than a few nuke&paves per week, what I did to speed up my own process is to keep a backup of the wpa-supplicant, and a couple of cura profiles. Then I have a folder full of the plugin zip files.

Since the IP's are assigned by MAC address via my router, unless I actually physically move a pi from one place to another, I always know which one is which

Then, of course, I also have my full sd card images, which is obviously completely different from a load from scratch

What I haven't put any thought processes into, so far, was how to take that folder full of zip files, and install them with one command

Now THAT would be something I would find a time saver. It could take the whole process from 45 minutes all the way down to 38

Maybe even 30

The first thing you could do is make it easier to download the current version of the script!

I did create the file with Unix line endings and it "looks" the same as what you have posted here, however, when I attempt to execute it I get:

scripts/upgrade-help: 12: scripts/upgrade-help: Syntax error: "(" unexpected (expecting "fi")

I edited the second line after the then, adding double quotes around the echo command's content since it includes parentheses and is making your install unhappy.

For what it's worth, this one didn't throw an error on my Raspbian. What o/s & shell are you using?

Hey, I'm still at the gathering-requirements stage. ha

OctoPi 0.14.0 and I believe I'm using bash. I'm not smart enough to use anything else but the default :wink:

When I used nano to fix the line throwing the error, I notice that it colorizes the script and I see multiple occurrences of "reserved" words in the echo strings. I'd suggest that you put quotes around all of them just to be safe.

Noted.

  • quotes for the echo commands
  • Save the /etc/wpa_supplicant/wpa_supplicant.conf file... but isn't that a chicken-and-egg? How can you come back in to run the restore script if you're not already in? Maybe... we need to look for an edited /boot/octopi-wpa-supplicant.txt and download that for the user. And if there isn't one, we need to build one from the /etc/wpa_supplicant/wpa_supplicant.conf file.

I guess there's no easy method of backing up and restoring user access control, right? I couldn't tell you if that's got anything to do with the .octoprint folder but maybe it's not.

I must have guessed wrong when I saw the posted script. I thought it was ready for testing and feedback but it doesn't appear to be (I've found more errors on the backup side).

As for saving the /boot files, I think they should at least be in a separate tarball. Those are files that would be edited while the SD card is plugged into the system that created the SD card from the image file. I would make the assumption that the /boot files were edited successfully in the process of getting the current SD card working. BTW, don't forget to save this script file as well!

I'm looking at this from the perspective of a new version of OctoPi was just released. How do I get my current OctoPrint configuration moved to the new OctoPi image with the minimum amount of effort.

Food for thought... Is there enough room left in the /boot partition to put the tarball(s) in there?

Not on my system :roll_eyes: tarball is 176M, free space on /boot 21M.

I'm in the same boat as you: I'm staring at an upgrade event but I want to minimize the pain for myself. So I thought, well I might as well script this for the times in the future where I'll need this, too.

If... I put the tarball(s) on the /boot partition, isn't that lost with the new OctoPi reload-from-img? I was thinking that the best way would be to download the tarball(s) to the user's workstation, give them some guidance when that's necessary and automate the rest.

I would guess that ultimately Gina/Guy would get this into the OctoPi image itself.

I was just thinking of an alternative to using scp to save the files. In my case, its WinSCP since my workstation is running Windows 10.

Something like run the backup script, shutdown the RPi, move the SD card to the workstation, copy files off of /boot, overwrite the SD card with new one, put files back into /boot, move card back to RPi, boot, run the restore script.

Its a mute point, however, as /boot isn't big enough to hold it.

The /boot/config.txt and /boot/cmdline.txt might be all that you need to backup, especially if you've added an LCD/TFT screen or similar.

In case you're still interested... here is the repository which I've created for the script. Please review and let me know if there's anything amiss.

I have not exercised the restore side of this myself yet; the last thing I did was to remove the "echo" from before those two dangerous commands. I intend to run it through a full test cycle sometime this weekend using a new microSD card and pulling down the latest OctoPi image.

I have adjusted the syntax in many places to minimize problems. I've added a README.md to explain things.

1 Like

I've gotta go mow the lawn, I'll check it out when I get back. Is this something I plug into octoprint, or run from the raspbian CLI ? Or is this something where you remove the SD card and run completely outside the OS ?

I can answer that one. This is a script you run from the CLI (i.e. from an SSH terminal session).

Yes.

  1. Remote into the Pi and follow the instructions to add the script
  2. Run the script and follow the bouncing prompts

(The script will tell you when you need to run something from your workstation or from the Pi itself.)

Other than it wanting to stop the octoprint service itself, the backup side of this is non-destructive. It will prompt you first, though. I would suggest that the backup side of the script should be run once a week or so for good housekeeping.

Sounds like fun

Lemme pick an octo-victim and I'll, um, ask another question when it becomes far too complicated, like, ya know, which side is the gas tank on ?

v1.0.2 is now available and I have run it through a test cycle. This version seems to work as expected.

Read the walk-through documentation

  • It's not a bad effort but I'm still daunted about the sheer number of commands necessary to rev things up a level
  • On the plus side, it's well-documented about the process and may prompt you to save something that you otherwise would have forgotten