Thanks for pointing this out. This was not at all clear for me from the information that I could find online before upgrading. Actually, quite in contrast, there were quite a few posts in this forum which talked about doing exactly what I did: install OH 4, restore a backup from OH 3.x, run the upgradetool. I think it was even you, @rlkoshak, who recommended doing it like this here: Upgrade 3.4 to 4, but how? - #2 by rlkoshak
Of course I ran the upgradetool after restoring the backup and before starting OH 4 for the first time.
If restoring a 3.x backup (+ running the upgradetool) to migrate a backed-up OH 3.x configuration into OH4 does indeed not (or no longer) work, this might deserve some clear(er) advice in the documentation? If it does work (as several earlier threads indicate), it might be worth pointing out that this is not the case for full backups.
OH 3.4 to 4.0 can work that way but only for non-full backups.
Or you can clear the cache immediately after restoring the full backup but before running anything else (which essentially converts your full backup to a regular backup since the inclusion of cache and tmp is the only difference between a full and a regular backup.
But that was an exception and not guaranteed to work between any arbitrary OH versions down to the first point level (e.g. 4.2 to 4.3 may not work but 4.3.1 to 4.3.2 should work, though you wonât get any of the updates to your installed add-ons if you use a full backup).
Yep, now we seem to have reached consensus. Thatâs what I figured out the very hard way.
Therefore, again: a hint in the docs that full backups shouldnât be used across versions would be very helpful. Or a warning message of the upgradetool, if the cache is not empty. Or a warning message when restoring a full backup into a newer OH version.
Have just added my description to the Github issue.
Have started experiencing this since upgrading to 4.3 from 4.2.
64bit Openhabian, fairly large system, 1100 items, 135 things, >70 JS rules, all files-based.
In my case the issue occurs occasionally (total of six times since upgrade to 4.3, approx every 4th of 5th system restart), but not reproducably. sysctl restart openhabhas so far reliably fixed the issue when it occured. Nothing in the logs that would suggest an error, just that system only gets to runlevel 40 and not beyond, and then rules engine is not loaded. Which leaves the system functioning, but without any automation.
Key difference in my case compared to many of the other reports: virtually no DSL rules. (There was still one (active but unused) one, which I have now deactivated).
Iâm not sure where backups and restores are documented in the first place. Not that people read the docs in the first place. But if you know where, thereâs a link at the bottom of every documentation page where an edit can be submitted. Itâs a great way to contribute to the project.
On a normal upgrade, when upgradetool runs the cache wouldnât be empty. I think teh cache is cleared as the last step. And you can run upgradetool at any time.
Off topic and sorry to be frank but no!
Upgrade instructions are given where applicable such as in release notes and if users decide to do stuff beyond or ignoring that they must not expect that to work or docs/developers/maintainers to warn them of.
ALL software in general and their docs just donât work that way.
Itâs impossible to list everything one must not do so it remains to be any userâs duty to read and follow the instructions.
Well⊠I read up as much as I could before going that step. And all I found indicated not only that this is possible, but even that itâs the recommended way of doing it when you are going to a new machine and a new OH version at the same time. I linked an example above.
Saying that itâs the userâs fault is⊠well⊠okay. But not if you want this to work for someone who doesnât spend all their time in the intestines of this particular software.
Oh yes, even and especially in that case. If some user does not want to go the extra mile of understanding the internals and proper context, thatâs fine of course.
But then they must be reading the official docs and stick to the documented procedures exclusively and not attempt stuff thatâs not officially documented.
So hands off if you donât find mentioned what youâre about to try.
Note Richâ post you refer to was a forum post, and forum posts are not part of the official docs.
And on the docs part, Iâll renew my statement that you must not expect any software creator to document any No-Go.
Again, thatâs not how any software docs work. Itâs on the user to understand that upfront.
Now please get back on the thread topic. What I understood so far is you had a similar symptom after performing some unsupported form of upgrade (which probably caused that in the first place).
Correct? So I donât think analyzing that contributes to a solution here? or is there anything I missed?
I used the upgrade tool which comes with OH 4.3 and states has the purpose of converting an OH 3.4 configuration to the new version. You are telling me that this despite this tool coming with 4.3 it must under no circumstances be used.