are there ways i can temp fix things without re-image?
i need to get a sd-card reader as i have packed away the only laptop that has one (but it does not have a keyboard or trackpad)
I don't know. If it's only that file, yeah, sure, fix it. It should be this, but better do a diff: Wrong file I think. Seems to be part of libc6-dev, so maybe try apt install --reinstall libc6-dev.
But as I said, it's very likely that this isn't the only things that's corrupt on this image, only the first thing that you ran into, so I can't tell you if that will lead to success or just make you run head first into the next wall.
for sure i need to re-image
but if i can keep it going for 2 weeks more i will just buy a sd card reader and a new sd card and be done with it
time will tell
sudo apt-get install --reinstall libc6-dev and then
sudo service octoprint stop
source ~/oprint/bin/activate
pip install --force-reinstall https://get.octoprint.org/latest
octoprint serve --safe
but yes i'm now in "limb" mode
I ended up just reinstalling my SD card, however I did include the tail of octoprint.log and the update log in the opening post. I saw no errors or anything in them, but now they are lost to the nether.
The card was initially updated from a fresh install - I had literally installed it two nights before the update and never got to use it, so it was an entirely fresh install of octopi with no modifications/updates/etc.
Nothing was run as sudo unless noted, I'm pretty picky about running things as sudo. Perms also looked ok as everything was owned by pi/pi but i ran the chown command to ensure this just to be sure, and it made no difference.
I have not yet updated my reinstall.
I wanted to highlight this.
You didn't get an error about urllib, you got a warning about urllib. It's a fairly strong and serious-looking warning, but .. it's just a warning.
More detail: the boto3 and requests peeps haven't blessed urllib's 1.25.x stuff yet, so the warning says to narrow the requirements to urllib3<1.25,>=1.20. It's a little excessive to do that everywhere.
requests also wants chardet to be narrowly specified.
1 Like
It's difficult for characters in the middle of a text file to get corrupt like this. I would suggest that power-cycling the Raspberry Pi during an upgrade would result in perhaps several related truncated and corrupted text files. Their endings would be trashed rather than the middle.
The underlying ext4 is a journaling file system with checksums. Even if the Raspberry Pi's 5V dropped down to something too low to write to the microSD, it should at least throw a kernel error. (Looking for undervoltage in a case like this is probably a good way of preventing future problems on the same rig.) I would guess that delayed allocation couldn't be blamed here (again, it would be an ending problem). Check /var/log/kern.log, probably looking for the word crc or CRC.
My gut's telling me that this is a network problem during some update/upgrade step which faithfully wrote in-transit corrupted data. But you'd think tcp would prevent that. Apologies, but this sort of thing really shouldn't happen at all.
There's an expression, "one bad apple spoils the whole bushel". If I saw a single corrupted system text file like this, I would start over from scratch. Whatever conditions allowed this corruption in the past likely could have spilled over to other files so it's effectively a ticking time bomb waiting to go off in the future. It's not worth risking your print job(s) to this.
There's definitely a "is it work fixing or just replacing" thing here.
I thought it was "one bad Lisa almost spoils the Apple"?
You can try this:
nano ~/OctoPrint/venv/bin/octoprint
Change, if necessary, 1.3.10 to 1.3.11
pip uninstall urllib3
pip install -I urllib3==1.24.3
sudo reboot
edited to remove the scary-looking URL. Again, I repeat myself: the urllib3 version message is a warning, not an error. It's not the cause of "breaking" Octoprint.
1 Like
Hi tedder42!
It was just a direct link to official website. I don't know why, but in my case "==1.24.3" construction doesn't work.
I did not think about errors or warnings. I just ran this, got errors and made changes to make it work:
~/OctoPrint/venv/bin/octoprint
Traceback (most recent call last):
File "/home/opi/OctoPrint/venv/bin/octoprint", line 6, in <module>
from pkg_resources import load_entry_point
File "/home/opi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3019, in <module>
@_call_aside
File "/home/opi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside
f(*args, **kwargs)
File "/home/opi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/home/opi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 657, in _build_master
return cls._build_from_requirements(__requires__)
File "/home/opi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 670, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/home/opi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 854, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (urllib3 1.25 (/home/opi/.local/lib/python2.7/site-packages), Requirement.parse('urllib3<1.25,>=1.21.1'), set(['requests']))
Ok, I thought because the installer exited here.
I can not reproduce it any more. I have installed Octoprint on the same OS, after cleaning the Octoprint folders and reinstalled urllib3, and at now everything works fine even with the restored backup. If I uninstall urllib3 the octoprint installer install it again and works fine.
If it's any consolation, I just fired up my printer having returned from working away for the last 2 weeks and it all started up fine. There was a nag box on Octoprint telling me an update was available so I installed it, or at least attempted to. It killed it. I've just downloaded the latest version from Octoprint and installed on a spare SD card. It's all working fine again now but there's something in that update that seems to corrupt the install. My Pi was running a pure Octoprint image, nothing else, no plug-ins etc. It could do with fixing or at lease withdrawing until it gets fixed. I'm not sure what it give that the old version didn't but it's not worth the hassle until it's fixed.
I did 10 update scenarios from various OctoPrint+OctoPi installation combinations to 1.3.11. I did another 6 per each RC. Not a single issue. At the time of writing this there are currently over 8000 installations of 1.3.11 reported in the field world wide, with over 34000 hours of successful print jobs shared between them since May 14th. Add to that another ~1000 instances that updated to and ran the RCs and accumulated another 58000 hours of successful printjobs on those.
Given these numbers I think we can safely assume that this isn't a widespread general problem but rather something that seems to affect a small handful of people with what looks like diverse base environments with unknown maintenance state and also very different manifesting symptoms, which makes a common problem that would justify "withdrawing" very unlikely, and also so far doesn't even give a hint that there is something to be fixed on OctoPrint's end in the first place.
That being said I'm happy to give support to people running into update issues - as long as they provide the information needed in order to help them that is, "it's broken" doesn't suffice - and I'll happily push out a hotfix release if during the course of that an actual problem with the update should get identified.
1 Like
You should paste the error.
We might deduce from this that your original OctoPi instance wasn't 0.16.0 (with underlying Raspbian Nov 2018) but more probably 0.15.1 or earlier (with Raspbian Jun 2018). It would be great to know any errors you saw (if any) during that earlier upgrade attempt.
Hello,
I'm on windows and I got the same problem while udpdating. I don't remember the previous version unfortunately. Here is the log :
C:\OctoPrint\venv\Scripts\octoprint.exe serve --port 5005
Traceback (most recent call last):
File "C:\OctoPrint\venv\Scripts\octoprint-script.py", line 6, in
from pkg_resources import load_entry_point
File "c:\octoprint\venv\lib\site-packages\pkg_resources_init_.py", line 309
8, in
@call_aside
File "c:\octoprint\venv\lib\site-packages\pkg_resources_init.py", line 308
2, in call_aside
f(*args, **kwargs)
File "c:\octoprint\venv\lib\site-packages\pkg_resources_init.py", line 311
1, in _initialize_master_working_set
working_set = WorkingSet.build_master()
File "c:\octoprint\venv\lib\site-packages\pkg_resources_init.py", line 575
, in _build_master
return cls.build_from_requirements(requires)
File "c:\octoprint\venv\lib\site-packages\pkg_resources_init.py", line 588
, in build_from_requirements
dists = ws.resolve(reqs, Environment())
File "c:\octoprint\venv\lib\site-packages\pkg_resources_init.py", line 777
, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'watchdog<0.9,>=0.8.3' distribution was
not found and is required by OctoPrint
My problem is that I don't know how to force reinstall under windows. And I don't want to lose my whole configuration.
I note that you don't appear to be running this under the control of virtualenv; I'm used to seeing a command prompt which demonstrates that you earlier ran something like source venv/bin/activate.
If you've not done that then python/pip will be using a more global set of modules and executables instead of the OctoPrint-controlled virtual environment. In this controlled one, the watchdog piece of all this might be the correct version for all we know.
I had the same issue. After trying every suggested step here in the topic, i tried to just reinstall every package and after this the update to 1.3.11 worked like charm.
These were the steps I took:
dpkg --get-selections | grep -v deinstall | awk '{print $1}' > list.log
awk '$1=$1' ORS=' ' list.log > newlist.log
sudo apt-get install --reinstall $(cat newlist.log)
~/oprint/bin/pip install --no-cache-dir https://get.octoprint.org/latest
sudo service octoprint restart
It is not the most filigree solution, but rather the steam hammer, but now everything is running again.
1 Like