I see.
Yeah I had to use it when I got problems with the new wifi interface on the 3+ and the 0W.
But you're right we shouldn't use this for regular updates or fun. And if we use it we should at least backup the sd card.
I'm not sure about the pi 4. It got a SPI EEPROM and got some stuff in it. I have no idea if a rpi-update could brick the pi 4 semi-permanent. Also I don't know if that's the case if loading a new bootloader will flash the EEPROM and fix it.
When I say "brick" I mean "reflash that microSD, you've painted yourself into a corner".
About the only thing that can't be undone on a Raspi is when you tell it to boot from USB instead of microSD. There's no turning back from that stance because it does write to the EEPROM (OTP = one-time programmable memory).
Oh didn't know that you can change that permanent.
I know that the pi 3+ is able to boot from usb out of the box and that you can use program_usb_boot_mode=1
on the pi 3 - but I thought you had to keep your sd card in the pi so it can read this line and boot from usb.
I never questioned why there was program
in the command
Thanks for the information
edit: there is a special bootloader for flashing the new pi 4 EEPROM and you also can flash things like usb firmware to it. That's what I thought could brick it when you use rpi-update and a bad firmware gets flashed to the EEPROM. And I don't think that this one is OTP because of the flashing bootloader.
In case anyone's interested, I've documented what I'm doing to upgrade an OctoPrint 1.3.10 on Stretch installation to an OctoPrint 1.3.11 on Buster (Raspberry Pi 3B). This is a merging of the official documentation versus what is implemented in the standard OctoPi image.
- Clone the microSD card using ApplePi-Baker to another microSD
- Backed up some of the folders on this:
~/.octoprint/uploads
,~/.octoprint/data/myplugin
,~/.octoprint/config.yaml
,~/.octoprint/users.yaml
sudo service octoprint stop
-
grep -rl stretch /etc/apt/ | sudo xargs sed -i 's/stretch/buster/g'
# Marks everything as buster now sudo apt-get update
-
sudo apt-get dist-upgrade
# Should bring in Buster over Stretch (2+ hours)
Here, you'll be prompted many times when confronted by old-versus-new versions of configuration files. Go with the defaults which preserve your original file in each case.
cd ~
mv ~/oprint ~/oprint.last
virtualenv oprint
source oprint/bin/activate
pip install pip --upgrade
pip install https://get.octoprint.org/latest
octoprint serve
Visit http://octopi.local/ to verify that it's working
- Ctl-C to stop that session
sudo reboot
It seems to be happy now. I see this upon the welcome
screen. This is to be expected since I didn't use the latest OctoPi image.
OctoPrint version : 1.3.11
OctoPi version : 0.15.1
I'll now need to reinstall anything that I'd earlier done with a pip install packagename
from before, making sure to first source ~/oprint/bin/activate
to be in the virtual environment. But I still have that ~/oprint.last/lib/python2.7/site-packages
as a reference to what was installed beyond OctoPrint itself.
cd ~
ls -l oprint.last/lib/python2.7/site-packages | awk -F ' ' '{print $9}' | awk -F '.' '{print $1}' > ~/pip.oprint.last
ls -l oprint/lib/python2.7/site-packages | awk -F ' ' '{print $9}' | awk -F '.' '{print $1}' > ~/pip.oprint
diff ~/pip.oprint.last ~/pip.oprint
# Contents of comparison follow
11d9
< backports
14a13,14
> cachelib
> cachelib-0
22c22
< click-6
So... maybe I'm now missing backports perhaps.
--- # These mark transitions from the before/after set of comparisons
> Click-7
24d23
< configparser
26,32d24
< Cython # This was part of the prerequisites for Kivy
< Cython-0
< cython
< cython
< dateutil
< docutils
< docutils-0
34d25
< easy-install
52d42
< flask_principal # This sort of stuff I can ignore
53a44,45
> flask_principal # ...since it's just a slight difference in decoration
> flask_principal
59d50
< garden # This is part of Kivy-Garden, which I'll need
64,65d54
< itsdangerous-0
< itsdangerous
66a56
> itsdangerous-1
69,71d58
< kivy # I'll definitely need to reinstall Kivy
< Kivy-1
< Kivy_Garden-0
75c62
< Markdown-2
---
> Markdown-3
90,91d76
< octoprint_themeify
< MyPlugin # This was the plugin I'm working on, so this needs to be reinstalled
96c81
< pip-9
---
> pip-19
105,109d89
< pybonjour-1 # Not sure why pybonjour seems to be missing now, need to investigate
< pybonjour
< pybonjour
< pygments
< Pygments-2
114d93
< python_dateutil-2
116,118c95,96
< pytz-2018
< pyximport
< PyYAML-3
---
> pytz-2019
> PyYAML-5
120,123d97
< regex-2018
< _regex_core
< _regex_core
< regex
125c99
< _regex
---
> regex-2019
130c104
< rsa-3
---
> rsa-4
138a113,114
> sentry_sdk
> sentry_sdk-0
141c117
< setuptools-39
---
> setuptools-41
152,160d127
< sockjs
< sockjs_tornado-1
< sockjs_tornado-1
< speaklater-1
< speaklater
< speaklater
< test_regex
< test_regex
< Themeify-1
164a132,134
> typing-3
> typing
> typing
Looking in the two site-packages folders, I can see that there are a fair amount of simple python files that would look like entire packages based upon my awk
filter commands above.
From my analysis, I personally would need to reinstall Cython, Kivy, Themeify and my own plugin to get back to a similar rig, having upgraded in-place from Raspbian Stretch + OctoPrint 1.3.10 to Raspbian Buster + OctoPrint 1.3.11.
I can see some advantages to an approach like this:
- The
~/.octoprint/config.yaml
keeps its original API key and salt for encrypting things (presumably some of the data in the~/.octoprint/users.yaml
file. - Likewise, the
config.yaml
should still contain all the edits I made for Themeify (once I reinstall it). - The
~/.octoprint/uploads
folder should still have my uploaded files in addition to the earlier.metadata.json
hidden which which store print history. - The
~/.octoprint/logs
folder should still be intact.