Re-install 1.3.9 from command line

Get Help
1

What is the problem?
Tried to get Octopi to upgrade to 1.3.9. Now I get Error 503 Service unavailable.

What did you already try to solve it?
Still have access to the Pi via Putty. I can sudo shutdown -h now. Power down both printer and Pi and then restart with no success on the Octopi Error 503 issue. Still have access via Putty.

What I need is what to type on the command line to bring in 1.3.9 or 1.3.8 so that my system is restored to where it was before this failure.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Repetier is 0.91. Pi is Rev 2 with external USB WiFi.

2

Maybe this can help you: Setup und Update

3

Thanks. From that link...

The instructions are not quite correct or else my Pi OS is way too old.
"sudo apt-get update " works
" sudo apt upate" as shown in the example doesn't

I have an Octoprint folder but no venv folder so I had to first
virtualenv venv
source venv/bin/activate

Then tried to pull in the last working 1.3.8 version with
source ~/OctoPrint/venv/bin/activate
pip install https://get.octoprint.org/last

Didn't work. Here's the pip log file.
Any Suggestions?
John

(venv)pi@octopi ~ $ cat /home/pi/.pip/pip.log

/home/pi/OctoPrint/venv/bin/pip run on Wed Jul 25 13:59:57 2018
Downloading/unpacking https://get.octoprint.org/last

Downloading from URL https://get.octoprint.org/last
Running setup.py egg_info for package from https://get.octoprint.org/last

running egg_info
creating pip-egg-info/OctoPrint.egg-info
writing requirements to pip-egg-info/OctoPrint.egg-info/requires.txt
writing pip-egg-info/OctoPrint.egg-info/PKG-INFO
writing top-level names to pip-egg-info/OctoPrint.egg-info/top_level.txt
writing dependency_links to pip-egg-info/OctoPrint.egg-info/dependency_links.txt
writing entry points to pip-egg-info/OctoPrint.egg-info/entry_points.txt
writing manifest file 'pip-egg-info/OctoPrint.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found


reading manifest file 'pip-egg-info/OctoPrint.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pip-egg-info/OctoPrint.egg-info/SOURCES.txt'

skipping extra develop
skipping extra develop
skipping extra develop
skipping extra develop
skipping extra develop
skipping extra develop
skipping extra develop
skipping extra develop
skipping extra plugins
Downloading/unpacking flask>=0.9,<0.11 (from OctoPrint==1.3.8)

Getting page http://pypi.python.org/simple/flask
Could not fetch URL http://pypi.python.org/simple/flask: HTTP Error 403: SSL is required
Will skip URL http://pypi.python.org/simple/flask when looking for download links for flask>=0.9,<0.11 (from OctoPrint==1.3.8)
Getting page http://pypi.python.org/simple/
Could not fetch URL http://pypi.python.org/simple/: HTTP Error 403: SSL is required
Will skip URL http://pypi.python.org/simple/ when looking for download links for flask>=0.9,<0.11 (from OctoPrint==1.3.8)
Cannot fetch index base URL http://pypi.python.org/simple/

URLs to search for versions for flask>=0.9,<0.11 (from OctoPrint==1.3.8):

No distributions at all found for flask>=0.9,<0.11 (from OctoPrint==1.3.8)

Exception information:
Traceback (most recent call last):
File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/basecommand.py", line 104, in main
status = self.run(options, args)
File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/commands/install.py", line 245, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/req.py", line 978, in prepare_files
url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg/pip/index.py", line 157, in find_requirement
raise DistributionNotFound('No distributions at all found for %s' % req)
DistributionNotFound: No distributions at all found for flask>=0.9,<0.11 (from OctoPrint==1.3.8)
(venv)pi@octopi ~ $

4

When you have a OctoPi installation, there is no venv folder (afaik).
My thoughts were that the OctoPrint server does not start.
You could do this manually with

sudo service octoprint start

5

OK. More information after many hours of trying things including a drive to the local computer store to buy a 16GB MicroSD in case the upgrade was just running out of space and therefore crashing.

I was running on a Pi2B with USB WiFi
Linux octopi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l

pi@octopi ~/OctoPrint $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.9G 2.7G 114M 96% /
devtmpfs 427M 0 427M 0% /dev
tmpfs 87M 268K 86M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 173M 0 173M 0% /run/shm
/dev/mmcblk0p1 56M 20M 37M

Originally created from
2015-05-05-octopi-wheezy-0.12.0.img
And over the last number years slowly upgraded as new versions showed up. Also running a few plugins although I don't remember which ones other than the enclosure which reported a DS-22 RHT sensor temperature and RH.

Up to 1.3.8 the system has been turnkey. Works perfectly. Pi Camera has maybe 1/2 second lag so the printer sits in another room and once started can run for hours or overnight with confidence.
Then came 1.3.9. Told me it was restarting the server and after that it would no longer run Octoprint. puTTY still works so Octopi was intact.
I put the same distro onto the new 16GB card, expanded it to 16GB.
Rebooted and it ran Octoprint 1.2.2 Says 1.3.9 is available.
Told it to upgrade same result so where 1.3.8 worked with this OS 1.3.9 does not.
After various other trials I finally downloaded the latest Octopi img file and it shows 1.3.8 as for Octoprint and told me 1.3.9 is available. Upgraded. Server reboot and now I have 1.3.9,

Where before the system was like a table saw or band saw where I walked up, turned it on, cut a piece wood and then turned it off, this system has random disconnects that also shut down the pi. Octoprint stops responding and the console window with puTTy is also closed. Reproducible by clicking on one of the hyper links in the setup screens that change to a different URL. Almost as if that change also sends a shutdown command to the Pi.
Although I followed the instructions step by step and installed the Adafruit DHT software and in fact can, from the command line, request temperature and RH which works, the actual display on the Octoprint program shows 0C and 0% RH. This used to work too.

The Pi camera now lags as much as 10 seconds I can walk from where the printer sits into the other room and still see my hands in the camera image and that's 10 seconds later.

It's late here now on the west coast of Canada. I'll grab the proper files and post more tomorrow. I wish I could turn the clock back 24 hours. I can't believe how much time I've wasted on this.

6

Gina,
Here are the logs from the original 4GB sd card. I did try installing and compiling Octopi manually. That also failed so the logs may not have what you want.
Octoprintlogs.zip (120.6 KB)

7

This honestly sounds more like something about the OS or hardware is unstable (yes, things that worked flawlessly for years can start to die randomly, especially if taxed like they are e.g. by running updates). What are you using to power that Pi? When you putty in, can you run vcgencmd get_throttled and tell us what it reports back?

Wow, that is ancient.

8

One tends to not fix what is not broken. From the plugin_software_update log it's clear that there are some old programs that needed upgrading. pip for one. In 22 days from Rev 10 to Rev 18.
It's not reasonable to go back to Wheezy even though it ran well on the Pi2B. I'm suspicious that Stretch isn't really great on the 2B. Perhaps that's the reason for the video slow down. Before I realized it was that slow I'd already jogged the carriage up into the end stops, thrown out my alignment and now home isn't where it used to be. So that's yet another result of all this.

9

I'm ancient too though. Bit of background. Not a big fan of Linux. But BSc in Comp Sci back when a PDP-10 running Unix was a big deal. Designed the lights (PIC18F), firmware for the lights (Microchip C), Control System module (Freescale 9S12), Control software for 9S12 in C, Windows control program through USB port software written in Delphi. This was used by another programmer as the basis for the light show software. Total of 1500 lamps (750 per side) with 36 RGBW LEDs per lamp and 5 CAN bus channels per side.

Barge1a
Barge1a.jpg1280×852 144 KB

But I'm still a rank amateur with Linux.

10

I haven't heard anything negative about newer OctoPi versions from people running 2Bs, and I also haven't observed any troubles with my own 2B against 0.15.1 (in fact, reinstalled OctoPi on that one several times yesterday during the update tests with no issues at all).

pip loves whining on about wanting to be updated. Unless you have a really really old version (1.something) that usually isn't in fact necessary though.

Let me repeat my earlier request since that might give us some insight into what is happening here:

11

OctoPrint version : 1.3.9
OctoPi version : 0.15.1

pi@octopi:~ $ vcgencmd get_throttled
throttled=0x0

5V 2A supply. Appears stable. I'll measure the voltage if you want. I'm not happy with the WiFi coverage I get where the printer is located. My first step to address the video response should be to run a hard wire connection. I'll try and do that in the next couple of days. We have a heat wave too so it's a good time to print ABS for the PIR motion sensor covers that go onto those ring lamps.

12

Gina,
I'd like to just summarize what's been done.

  1. Wheezy very old install ran up to 1.3.8. Didn't have apt-get update done for a long time.
  2. 1.3.9 crashed Octoprint. Even with a fresh install of that Wheezy and a direct upgrade to 1.3.9. It still crashed Octoprint.
  3. 0.15.0 of Octopi installed 1.3.8 which was then upgraded to 1.3.9. That works.

Unless you think there might be a lurking issue between 1.3.8 and 1.3.9 I'm not sure it's worth chasing this problem.

The odd shut down issues are probably the biggest question. Playing with the Wheezy install again I didn't find any random shutdowns. I did with the Stretch. But I also didn't really try to do the same things.
If I install Wheezy Octopi on a 4GB sd card again is there a way I can only update to 1.3.8 instead of 1.3.9?

13

Yes, a manual one:

source ~/oprint/bin/activate
pip install https://github.com/foosel/OctoPrint/archive/1.3.8.zip
sudo service octoprint restart

But if I were in your shoes I'd seriously consider looking into why your Pi is not running properly with OctoPi 0.15.1 instead of continuing to run a three year old image which is no longer supported in any way (and AFAIK also not getting any kind of security updates for the underlying operating system).

Unfortunately I can't help you with troubleshooting this though - all I can tell you is that I have an RPi 2 here running OctoPi 0.15.1 with OctoPrint 1.3.9 without any hiccups or issues, so whatever it is, it's not a general issue with the software but probably rather something up with the hardware it runs on. But I have no clue what that could be. The issues you described smelled like under voltage, but at least vcgencmd isn't reporting that.

I'd start with checking if there are any helpful error messages in /var/log/syslog - whatever is going on, it's on the system level.

14

I've installed Octopi 0.15.0 onto a 16GB card and upgraded from the 1.3.8 to 1.3.9 all running on a Pi2B.

Distance to WiFI router is about 20m using a Realtek USB Wifi dongle, with Wheezy and 1.3.8 the identical hardware was usable although camera updates sometimes lagged a bit or were jerky but the system has worked for more than 3 years.

But with Stretch Octopi 0.15.0 and Octoprint 1.3.9 and the same WiFi dongle the ability for the system to function is so poor as to make it unusable. Video updates taking a long time. A jog to move an axis taking 30 seconds before motion begins.

The only real change is the OS as all that happened was insertion of a new MicroSD card. And clearly, which is why I'm always hesitant to upgrade a Linux OS, support for this USB dongle must be incredibly bad.

Change to a wired connection (the WiFi dongle removed) and the Pi2B, Stretch 0.15.0 and Octoprint 1.3.9 works and camera update is closer to real time.

I've not been able to recreate a Wheezy based 1.3.8 uSD version that doesn't respond with Error 503 so I can't take a step back to compare WiFi performance.

It clearly was a mistake moving from 1.3.8 to 1.3.9. I've spent more than a day troubleshooting, realigning the 3D printer because the jog axis buttons were so badly delayed they queued up and ran the carriage into the end stop frame.

I will now have to properly run cable. Although the DHT-22 temperature and RH is available from the command line via puTTY, it reports as 0C and 0% on Octoprint. Don't know if that's a 1.3.9 problem or yet something else. I'll post on a separate help topic for that.

15

I'm going to call this closed. My DHT-22 sensor has been found by unchecking the use sudo in advanced options under the plugin settings. Lack of support for 3 different WiFi dongles I plugged into the Pi2B means I'm best to stay with a hardwired connection.

16

Interesting thread... I had a similar problem upgrading to 1.3.9 from the devel branch. Having issues upgrading from 1.3.8 now. If you think Octopi 0.15.0 is old, I'm on 0.13.0. So there definitely is something different in 1.3.9 that does not like older Octopi.

I've got a new RPi 3B+ with current Octopi, just haven't gotten around to switching over. So no issues here. Just another data point if someone is trying to chase this down.

17

Just for the record, all four RCs and the final release went through update testing that involved setting up fresh images of 0.14, 0.15.0 and 0.15.1 all in about 30 times and testing updating to 1.3.9 from various starting states and various release channel configurations.

OctoPrint isn't an operating system. It is python program running in userspace. Its upgrades can't change system drivers or underlying configuration, it can't cause firmwares to suddenly start throwing mintemp errors and it also won't eat your dog.

I can see there being trouble with some of the updates dependencies on very old python and pip versions and also just learned that apparently some people simply ignored my warning I posted back in November about upgrading issues with OctoPi 0.12 unless certain steps I explained how to do were taken. But with newer images, especially 0.14+ I have absolutely no idea. If there is an underlying issue here, it's something I have no clue on how to reproduce.

Guess we need even more people testing RCs to cover more setup scenarios :woman_shrugging:

18

Ok. First of all I don't remember anything about November and upgrading issues about Octopi 0.12. It's also possible that during that time I skipped several upgrades and didn't read anything during November.

But I'd be real careful here!

I know that Octoprint is an application running in user space. Not everyone does though.

Several of my friends from a metal working group are in their 80's and don't know anything about Linux. And even I, for my 3D printer, will fall into the class of I really don't care.

It's a black box where one cable goes to the Ardunio based printer driver board. And which has a WiFi USB dongle purchased because it was compatible with the Octopi I installed on my Pi2B. Stock Raspberry Pi Camera. For me the DHT-22 came years later after I found the plug-in.

Any here's the key thing: You don't have the right to "blame the user" with comments about November and warnings. Your application software allowed itself to be upgraded on Octopi 0.12. Because of that you are obligated to test and make sure your application still runs on black boxes that are still working with that OS.

It's really that simple. You are now supporting, and being supported by Patreon, software that is old by current Linux standards. Since yours is an application and not an OS, it's your responsibility to check the OS version and not allow an upgrade until the OS has been upgraded if you don't want to test on Linux installations that are 3 or 30 years old.

The information banner that shows up at the side informing a user of a new version should state that the OS first needs to be upgraded for this new Octoprint. It should include a link to a step by step process that saves the user configuration information while upgrading to say Stretch from Wheezy. Then a reboot will change your message to allow the Octoprint upgrade.

Yes, someone could still do it from the command line but again, most never even use puTTY or something similar to go into their Octopi controller I suspect and aren't the majority of your users.

19

I'm not obligated to forgo my sleep, sanity and health to maintain OctoPrint. What you are expecting here would need exactly that.

I'm doing what I can with the resources available to me to keep this running. I have to make decisions while I do this. These decisions include deciding on test scenarios prior to every release that allow test completion in a timely manner. Nobody will be happy if all I do anymore is testing against the multitude of potential setups out there. By your argument I'd have to check every possible version of OctoPi with every possible starting version of OctoPrint and potential system updates applied by the user in between. Over the whole course of existence of OctoPrint and OctoPi. This is not possible. It wouldn't even be possible if I had a huge team at my disposal to help test all this. Which I don't, I have to rely on people volunteering to give the RCs a test drive.

I know of someone who updated to 1.3.9 from an ancient pip version during the RC. The same one that comes with OctoPi 0.12. No issue. I didn't get any reports over five weeks of RC phase of any update issues at all. But according to you I still should have scheduled in several days per RC doing nothing but flashing various starting scenarios and test them and still not have a chance to cover every possible combination.

If this is what you're expecting for your support on Patreon, then please stop supporting me there or elsewhere. My goal is to keep OctoPrint developed sustainably in the long run for everyone, not spend all my time exclusively on protecting against potential issues with setup scenarios that make up a tiny minority of the install base.

20

Gina you totally missed my point.

If the oldest Octopi version you test with is 0.14 or 0.15 then your software must not allow upgrading automatically for older versions. What someone does from the command line you can't control.

That's all I'm saying. So if you know (from something last November) that there is an issue with 0.12 then don't allow the upgrade.

And if that's the case, in that same messages box tell the users to make a new SD card with the latest Octopi. Then give instructions on how to bring over the appropriate Octoprint files or folders so a user doesn't have to spend days reconstructing their systems with their plugins.