I think I am experiencing the same problem and am curious if you mean by restore , openhab-cli restore backup.zip?
I see these errors in the logs when installing a brand new openhabian on an new SD card while trying to import a openhab backup via openhabian.conf. Starting openhab.service “works” as de JVM is started, but it hangs and does not start the console, the webUI (or openHAB alltogether).
If I install without importing a backup, everything goes fine. But as soon as I restore my latest backup via openhab-cli and restart openhab the issue starts again.
Is org.apache.karaf.features.xml part of an openhab backup? Is that the reason it can get corrupted or is it that compatibility issues can arise between openhab the previous Milestone release and 3.2?
If needed I have first-boot.log and openhab.log of all installation attempts (openhabian with backup.zip installed at first-boot, vanilla install, after importing backup.zip after vanilla install.
Issue is the same on a second openhabian machine with different addons.
By restoring my openHAB backup the file gets overwritten (It finally sunk in what Tim meant when writing: “I found the culprit, restore replaces the file”).
I can imagine this prevents (a lot of) other users from upgrading their working systems by flashing a brand new openhabian and restoring a backup. Isn’t this a breaking feature or a bug?
If you take a backup/export pre-upgrade i.e. on the older version, then wipe and install the latest version (i.e. NOT upgrade), then restore then you don’t follow the recommended upgrade path.
That is not a bug. Yours actually is a procedure that is neither designed to work nor recommended. You must only ever restore to the same software version you took the backup on.
I’d be wondering if you had seen that anywhere on the official docs? Or why have you come up with that idea ?
You should re-do your upgrade even if you think you have fixed it as you cannot be sure there’s similar issues with other files you just don’t get to see (yet).
So yes if this prevents others from taking that path that’s good
Please correct me if I am wrong but Release openHABian v1.7.1 · openhab/openhabian · GitHub states that it is recommended to reinstall (Please note that if you choose to upgrade and not reinstall, you are on your own, don’t expect to get support from the developers of openHABian if something goes wrong.).
Adittionally under Setup notes: You can have openHABian import a working openHAB configuration right from the start at installation time like when you migrate or reinstall
Given these options it seems logical to me that this would be the way to upgrade openhab and restore my settings.
Thus I’ve tried the upgrade by using a freshly flashed SD card with openhabian 1.7.1 and restoring via the openhabian.conf (naming a initial.zip file to restore a backup) option and a second time by restoring my backup after a new fresh install. Both resulted in overwriting of the org.apache.karaf.features.xml file.
So I am clearly missing the recommended upgrade path (including restoring an old configuration). But how should one go by upgrading and restoring a working configuration? I am not able to find it in the docs.
I’m sorry but you got the context of these statements wrong and what they refer to.
This was referring to the sentence right before which was about the Linux distribution. It was about an upgrade of a Linux Debian buster base distribution (which openHABian is based on).
It is not a statement on the openHABian version or even openHAB version.
These are excerpts from the reference docs, not from release notes or any document that is about installing or upgrading, so they don’t refer to that process. So it is not logical to apply them to it.
There is no operations manual or the like.
If any instructions, those are in the openHAB release notes which as with any software should be consulted before installing. Unfortunately there was a problem with the build tools last time that resulted in that this section was removed from the release note document, but you should be finding it if you search.
It says to upgrade the openHAB version on the running openHABian box (if you have one, note there’s many more different ways of running OH). No need to restore the config. No recommendation to reinstall (should be needless to mention as anything not explicitly listed means not recommended).
You mixed backup/restore with upgrading that’s the origin of your problems.
It is always a bad idea to import or restore the config of a software version A to that software’s version B even if versions are said or expected to be compatible. And nowhere in OH docs it says to do that. It results in the old config to be restored/imported to the new software (the openHAB version you upgraded to) as its initial config. That’ll skip execution of the config migration script in the openHAB package (if any, it depends on the version).
Thank you, Marcus, for your reply.
In essence you are telling me to not use a fresh openhabian SD image to upgrade my excisiting openhab setup. Restoring a backup between release upgrades is asking for trouble.
To upgrade using openhabian-config (essentially an apt upgrade).
That leaves me with two questions:
But isn’t a backp and restore part of upgrading? For example, in an apt upgradedpkg is carefull to backup configuration files that look to be user altered between upgrades. And when updating my digitalsSTROM server, I allways make a backup in case flashing the dSS messes something up and necessitates me to re-apply my configuration.
What about future upgrades, especially in 2 years when Debian’s support for Buster will end? Since openhabians recommendation seems to be not to do an apt dist-upgrade but to use a fresh openhabian image instead and many users (if not all) will likely want to avoid having tot do their setups all over again, you would want a way to transfer a working configuration. However restoring your openhab-cli backup will probably result in problems.
This might be solved by special instructions in the release notes.
Maybe it can be solved by a backup / restore script rewrite.
At least it would be usefull if there was some reference in the official docs about upgrading. I would be happy to contribute that. Should I write up a proposal on github and do a PR? Or better to discuss here a bit further until it’s clear my PR won’t contain total gibberish?
Am I correct that with text based configuration (OH2) restore was easier, only needing restoring files to /etc/openhab/ ? Whilst in OH3 with the configuration db in json (in /var/lib/etc | {userdata}) these aditional files and locations complicates this more? Maybe extra so because the files in the {userdata} folder can be machine altered?
No. You should backup in the beginning to have a fallback in case you need it but clearly it is not part of the upgrade process itself. Never has been in generic terms.
I believe you still didn’t understand the major point in this as you keep asking that:
you make a mistake to mix OS and application.
You need to upgrade the application (openHAB, that is) on your box FIRST. AFTER that you can create a config backup that’ll work with the new application version (OH 3.2).
THEN you can either dist-upgrade or reinstall/replace the OS of your box with latest (bullseye or whatever). As a fresh openHABian install always installs the latest OH version, too, in both cases you will have the latest application version OH3.2 after that step.
FINALLY as that is the very same application version you took the backup on, you can import it.
That’s how upgrades work, that’s what is recommended. That’s what’ll work when you want to upgrade the OS in the future.
It doesn’t work and never will to write instruction that apply to all the use cases.
OH runs on top of so many HW and OSs that this is not feasible.
So that what you and other users hope to get, instructions best tailored to your specific setup, will not happen. This is being asked for over and over but it is a very bad effort vs usefulness ratio and actually asked way too much from the few volunteers that we currently are.
We would be happy if you contributed an installation document.
Just remember it needs to apply to all possible use cases, i.e. all HW and OS you can run openHAB on.
Or it at least properly needs to state which setups it applies to and which ones it does not.
You also need to distinguish software (openHAB) from openHABian and the mechanisms of the underlying OS such as dist-upgrade.
Also mind the various cases like on Raspi hardware or on Debian or other Linuxes on x86 or even on Windows.
Not really. The issue is not about files in /etc/openhab but about those in /var/lib/openhab/etc and openhab-cli has always been backing up/restored those files, too. OH3 added jsondb but essentially it didn’t change anything substantial.
