I’m considering upgrading my openhabian instance on rpi 4 (OH 3.3.0.M5) from buster to bullseye and I understand the preferred (read supported) method is to reinstall openhabian with bullseye from scratch. That being said, what is the least intrusive method that works?
upgrade in place using apt dist-upgrade? What is the experience with this approach?
install openhabian/bullseye from scratch and restore from openhab-cli backup? Any gotcha’s here?
Reinstall openHABian with bullseye from scratch will be the lest intrusive method that is guaranteed to work.
It’s more involved than that. You’ll need to manually edit the apt sources files first to point at bullseye instead of buster.
I usually try this first because many of my RPis are hard to get at. It works roughly 75% of the time. If you’ve not plugged in to a keyboard or monitor make sure to use screen or some other command to keep the upgrade running if you lose your SSH connection or else you are hosed.
I believe that’s what is meant by reinstall openHABian from scratch. Just make sure the new version of OH is the same as the old version. It usually doesn’t work to install a backup from an older version of OH to a newer version of OH. So this approach is the recommended approach.
The only gotchas are the openhab-cli backup only backs up openHAB’s configs. If you’ve edited configs for other openHABian services (e.g. Mosquitto, NodeRed, etc.) or data (e.g. InfluxDB, etc.) you’ll need to figure out how to backup and restore those yourself.
Yes. If you do a full backup it’ll even back up the installed add-ons. A normal backup will cause OH to redownload and install the add-ons upon restore. But in both cases all the add-ons will be there (after a time) after the restore.
Always watch the logs for errors though in case something unexpected goes wrong.
Understood. I take normal openhab-cli backups on a sporadic basis that average about 100mb. I just took a full backup which appears to include the cache and it came out to about 560mb.
I’ll attempt my restore on a fresh openhabian bullseye install from the full backup and report back.
Well it’s done and working fine so far. I imaged the sd card as a backup and then did a fresh install of openhabian bullseye, then restored the openhab-cli full backup. Some obvious config steps need to be redone, like setting timezone, passwords, re-enabling zram and sd card mirroring, but all through the openhabian-config utility.
The only unexpected hitch I ran into was related to persistence. I use the mariadb jdbc driver installed in /usr/share/openhab/addons/ to communicate with the db instance on a nas. Although all the persistence setup was restored, the driver jar file itself was not and had to be re-added manually. I also ran into some cache issues with my amazon echo control binding which is a bit of non-standard setup in my case…but no fault of the restore procedure and clearing the cache via the openhab-cli console fixed the issue.
Other than this, no issue so far. Thx for the help.
Cheers
I have a question about this. When I try to install from Buster openHAB 4 (03 Install openHAB), it fails and I get the message that the operating system is too old.
However, if you can not restore a backup from an old openHAB version. How do I set this then?
Wouldn’t it be a good idea for the upgrade process to do an OS check for bullseye before even allowing the OH4 upgrade to proceed on a buster implementation?
what do you mean by “here” ? I just did, didn’t I.
And all that information is also part of the official docs.
Yes. It already does.
But we cannot save everybody from themselves to attempt an upgrade without proper preparation.
The best idea still is an old-fashioned one: to read the docs before upgrading
Particularly worth reading when you haven’t been touching your system in a while.
They clearly state that bullseye is a prerequisite to OH4.
I understand and agree it’s always better to ‘read the documentation’, and openhab’s documentation is really quite good. But keep in mind OH is competing with a slough of other home automation solutions and ease of use is one of those qualities it needs to improve if it is to continue to expand its user base. In reviews and comparisons time after time it is this gap…ease of use…that is mentioned for OH.
Don’t get me wrong, I’m a fan of OH, I chose it over other options, and I’m sticking with it.
But saving users from themselves is exactly what any good software solution strives to do. Particularly where mandatory basic repeated functions, like patches and upgrades are concerned.
Well there’s many different ways to install OH, on various hardware, on many OSs. It’s way more flexible and comprehensive in what you can operate it on than other HA ‘competitors’.
People to have hit this buster/bullseye issue didn’t look at their system but at most once in a year or two. Some have setup their box 4 or 5 yrs ago and expect instant seamless automatic upgradeability.
Not to mention that many mess around with their system on their own causing the issues themselves but still expect us devs to handle that for them as well.
There’s limits to what we can anticipate and spend our sparse spare time on to save users from themselves, and there’s also limits as to our willingness to support users that in turn sometimes are unwilling even to contribute a little share of theirs which is really small when it’s just about reading the docs before taking action.
Speaking for openHABian and myself, your mileage (and other dev’s) may vary.
Agreed, and it is definitely true that OH offers basically unlimited flexibility which means in practice you can’t police the configuration of all users. The alternative is a locked down and restrictive model which I think no one wants for OH.
I guess my thought is that a few low hanging fruit type improvements/safeguards, like an os version check for example, could both help with the impression of OH in the marketplace and help with some of the support asks/noise seen on this forum. OH3 and OH4 upgrades both seem to have been quite painful for some users.
As said I already added that openHABian will refuse to upgrade if on buster or stretch now.
That’s what the FAQ is for, but you cannot prevent upfront what you didn’t anticipate because noone came up with this during the snapshot and testing phases.
But you cannot prepare for everything like say people to still be on even 4yr old stretch or to run Ubuntu which has never been supported. Still that’s what happens.
It’s a volunteer’s job with many takers, little gratitude and fast when it comes to criticism.
OH2->3 issues were a lot about in-app changes while those OH4 upgrade issues I’ve seen so far are mostly about external components of the OH environment like long existing setups, OS settings and Java. Strictly speaking, these aren’t even openHAB issues and as such something users would have to take care of all by themselves.
I’ve upgrade bullseye from buster and don’t have any issue at the moment. System itself is very stable. Only Openhab makes me heavy headache but that’s another story…
