Update to Raspberry Pi 4 (from working Pi 3+) [solved]

Alright. Will test this tomorrow :slight_smile:

Thank you very much

Have a good night :slight_smile:

Ok done :slight_smile:
In the end I flashed a new image and migrated the settings as you suggested.
I thought even if I get the venv issues fixes there will maybe new ones in the future and it's not worth the trouble.
I'll mark this problem as solved :slight_smile:

1 Like

Just wondering... did we just learn that attempting to do a dist-upgrade to Buster from a working 0.16.0 OctoPi-imaged setup doesn't work...?

Well it was my own setup but I guess it was as close to octopi as it could be.
Is the newest octopi image still on stretch? I could test it.

From what I understand, the newest production version is 0.16.0 and therefore is based upon Stretch and isn't compatible with the Pi4. Guy provided a link to his nightly build from June 20th which is based upon Buster and which therefore is.

Ok I tested it.
I flashed the latest stable image ( 0.16.0 ), run the webinterface wizard and updated to the latest octoprint.
Then I dist-upgraded to buster.
After that the same arror as in my case - venv seems broken.

(oprint) pi@octopi:~ $ ~/oprint/bin/octoprint serve
Traceback (most recent call last):
  File "/home/pi/oprint/bin/octoprint", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/home/pi/oprint/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 74, in <module>
  File "/home/pi/oprint/local/lib/python2.7/site-packages/pkg_resources/extern/__init__.py", line 61, in load_module
ImportError: The 'packaging.requirements' package is required; normally this is bundled with this package so if you get this warning, consult the packager of your distribution.
(oprint) pi@octopi:~ $

I guess it's safe to say normal users shouldn't dist upgrade to buster.


I have ran into the same problem
I have a Pi3 Raspbian Stretch with OctoPrint installed
I the Upgraded to Buster and now OctoPrint fails to start

I had to rename the /home/pi/OctoPrint folder to /home/pi/OctoPrint.org
then I proceeded to follow Setting up OctoPrint on a Raspberry Pi running Raspbian
to rebuild the virtualenv venv
and Now OctoPrint is running on Buster via a Pi3

by the way Buster has been made Stable in the repo


Glad to hear you got a solution.
I thought before there are potential problems in the future like installing plugins fails or updating octoprint itself etc I'm safer if I just set up a clean fresh install.

Good work :+1:

To run on pi 4 (advanced):

  • (optional but recommended, on the pi3) apt update + upgrade
  • take the working pi3 SD (from now on sd).
  • put it in a pc running any linux distro (easier).
  • download the buster raspbian image for a pi4 (this .img has 2 partitions fat/ext)
  • (optional but recommended) resize sd partitions. fat should be 256 mb.
  • loop mount both partitions in the img file and in the SD. At this point you have both "disks" accesible.
  • copy recursive from [buster/FAT]/ to the [sd/FAT]/ EXCEPT the config files. Leave old config files to preserve settings.
  • copy recursive from [buster/ext]/lib/modules/ to [sd/ext]/lib/modules
  • copy recursive from [buster/ext]/lib/firmware/ to [sd/ext]/lib/firmware
  • unmount
  • put the sd into the raspberry 4
  • power it on

..everything works on my end (BUT STILL ON STRETCH)

I'm guessing that you'd also need to reinstall all third-party plugins as well.

Well, that's an interesting method. I wonder if it would survive a sudo apt-get update && sudo apt-get upgrade cycle, though.

it definitely does survive because update channel is still stretch.
the only thing which doesn't get updated is stretch kernel (because buster runs on 4.19.57-v7l+ while stretch is a previous version)
...oh... by the way...in this case, if you want to update the kernel/firmware (from github), you can do a sudo rpi-update

....as I said I'm running on it...


Oh man, wrong answer. As I've posted many times on the Internet and here, rpi-update should only be used by the people who are actually coding kernel drivers, for example, for Raspbian. It will pull from the next branch of Raspbian's repository rather than from master. It will often brick a Raspi, by the way.

Well it shouldn't be used for regular updates - that's right.
But if you want the new things from the next branch it's the thing you want do.

I only did it if I wanted the new branch and had never issues with it. That doesn't mean that others can't have issues. I'm just saying it went fine for me.

It very much depends upon your timing ("your mileage may vary"). There are nights when the build on a next/development branch result in something that really doesn't work. The wi-fi/ethernet stack didn't load the last time I tried this on a Raspi 3B, for what it's worth.

1 Like

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.

1 Like

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).

1 Like

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 :smiley:

Thanks for the information :slight_smile:

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.

1 Like

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

< backports
> cachelib
> cachelib-0
< click-6
So... maybe I'm now missing backports perhaps.

--- # These mark transitions from the before/after set of comparisons
> Click-7
< configparser
< Cython # This was part of the prerequisites for Kivy
< Cython-0
< cython
< cython
< dateutil
< docutils
< docutils-0
< easy-install
< flask_principal # This sort of stuff I can ignore
> flask_principal # ...since it's just a slight difference in decoration
> flask_principal
< garden # This is part of Kivy-Garden, which I'll need
< itsdangerous-0
< itsdangerous
> itsdangerous-1
< kivy # I'll definitely need to reinstall Kivy
< Kivy-1
< Kivy_Garden-0
< Markdown-2
> Markdown-3
< octoprint_themeify
< MyPlugin # This was the plugin I'm working on, so this needs to be reinstalled
< pip-9
> pip-19
< pybonjour-1 # Not sure why pybonjour seems to be missing now, need to investigate
< pybonjour
< pybonjour
< pygments
< Pygments-2
< python_dateutil-2
< pytz-2018
< pyximport
< PyYAML-3
> pytz-2019
> PyYAML-5
< regex-2018
< _regex_core
< _regex_core
< regex
< _regex
> regex-2019
< rsa-3
> rsa-4
> sentry_sdk
> sentry_sdk-0
< setuptools-39
> setuptools-41
< sockjs
< sockjs_tornado-1
< sockjs_tornado-1
< speaklater-1
< speaklater
< speaklater
< test_regex
< test_regex
< Themeify-1
> 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.
1 Like