Is this sufficient? Any other info needed?
Start feeling like a fresh install is needed 
This is usually caused by an incorrectly configured Java, did it update with openHAB?
What is your java -version?
Apparently. I get
Critical /proc/self/exe readlink failure.
response when asking java -version
That doesn’t look good. 
Are you able to reinstall it through the config menu or via apt?
1 Like
In progress via apt.
upd: succeed! Now version shows:
openjdk version "1.8.0_152"
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
Now looks worse
ec 18 15:49:27 orangepione systemd[1]: Started openHAB 2 - empowering the smart home.
Dec 18 15:49:28 orangepione karaf[19322]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione karaf[19322]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione systemd[1]: openhab2.service: Main process exited, code=exited, status=1/FAI
Dec 18 15:49:28 orangepione karaf[19411]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione karaf[19411]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione systemd[1]: openhab2.service: Control process exited, code=exited status=1
Dec 18 15:49:29 orangepione systemd[1]: openhab2.service: Unit entered failed state.
Dec 18 15:49:29 orangepione systemd[1]: openhab2.service: Failed with result 'exit-code'.
Dec 18 15:49:31 orangepione systemd[1]: Stopped openHAB 2 - empowering the smart home.
Dec 18 16:40:29 orangepione systemd[1]: Started openHAB 2 - empowering the smart home.
Dec 18 16:40:32 orangepione karaf[22840]: Unable to update instance pid: Unable to create directory /var
Dec 18 16:40:37 orangepione karaf[22840]: java.lang.RuntimeException: Exception instantiating lock class
Dec 18 16:40:37 orangepione karaf[22840]: Karaf can't startup, make sure the log file can be accessed an
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.Main.createLock(Main.java:490
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.Main.doMonitor(Main.java:388)
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.Main.access$300(Main.java:75)
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.Main$3.run(Main.java:379)
Dec 18 16:40:37 orangepione karaf[22840]: Caused by: java.lang.reflect.InvocationTargetException
Dec 18 16:40:37 orangepione karaf[22840]: at sun.reflect.NativeConstructorAccessorImpl.newInstan
Dec 18 16:40:37 orangepione karaf[22840]: at sun.reflect.NativeConstructorAccessorImpl.newInstan
Dec 18 16:40:37 orangepione karaf[22840]: at sun.reflect.DelegatingConstructorAccessorImpl.newIn
Dec 18 16:40:37 orangepione karaf[22840]: at java.lang.reflect.Constructor.newInstance(Construct
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.Main.createLock(Main.java:486
Dec 18 16:40:37 orangepione karaf[22840]: ... 3 more
Dec 18 16:40:37 orangepione karaf[22840]: Caused by: java.lang.RuntimeException: Karaf can't startup, ma
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.lock.SimpleFileLock.<init>(Si
Dec 18 16:40:37 orangepione karaf[22840]: ... 8 more
Dec 18 16:40:37 orangepione karaf[22840]: Caused by: java.io.FileNotFoundException: /var/lib/openhab2/tm
Dec 18 16:40:37 orangepione karaf[22840]: at java.io.RandomAccessFile.open0(Native Method)
Dec 18 16:40:37 orangepione karaf[22840]: at java.io.RandomAccessFile.open(RandomAccessFile.java
Dec 18 16:40:37 orangepione karaf[22840]: at java.io.RandomAccessFile.<init>(RandomAccessFile.ja
Dec 18 16:40:37 orangepione karaf[22840]: at org.apache.karaf.main.lock.SimpleFileLock.<init>(Si
Dec 18 16:40:37 orangepione karaf[22840]: ... 8 more
Actually that’s getting further along now. Not sure how it’s got like this, but I’d check the state of the SD card.
Check who owns the folders /var/lib/openhab2with ls - l and if it’s not openhab or openhabian, make sure to set it so with chown - R. Otherwise I’d suggest making a new thread on this forum so we can continue the discussion without going too off topic here.
There’s an option for fixing permissions in openhabian-config.
1 Like
Hey,
I just did the upgrade and mostly worked fine. The first start of 2.2 resulted in a rather unstable environment and more than 23000 threads hogging on memory. I rebooted and now I am stable for over an hour with ~300 threads and memory doing fine.
Perhaps your SD card really gave up on this. Does dmesg show any hints?
1 Like
SD card seems to be ok. Now OH 2.2 is running.
What I did is removed zulu, installed oracle java, fixed permissions.
Observe higher RAM (~75%) and almost no CPU load (~5%), which is cool!
Thank you ALL!
I resolved my issue regarding rule engine installation. There was an error in my custom docker image, it should be fine everywhere else
Thank you for your tip!
I have manjaro(arch) and there was only a Package for 2.1.0. This worked fine.
I tried to update wit the sudo ./runtime/bin/update 2.2.0 but was stuck by an error on starting openhab stating Karaf can’t startup, make sure the …
When i found your post, i did:
cd /var/lib/openhab2
chown openhab:openhab -cR *
now openhab works again.
it seems the update-scrip of openhab works as root:root and did not change the updated files to openhab:openhab
Andreas
Hey All,
I am not sure where to ask this, but this topic seems relevant to 2.2.0 release.
I will want to make a PR to fix 2758 for openhab2-addons 2.2.0 (YamahaReceiver). In my opinion this should be released as a patch version 2.2.1 to openhab2-addons, so that users get this faster than having to wait for 2.3.0 (or having to use the unstable 2.3.0-snapshot version).
More discussion about the issue here. It is not a blocker for users, but surely is annoying.
My changes are made on top of the 2.2.0 tag. Is there an established process to push hotfixes to releases and also a way for users to get the updates automatically?
If not, then I could push the PR to the 2.3.0-snapshot.
Please let me know how to go about this.
The issue is that we currently have no process to easily create hotfix branches and create releases on top of them. Doing research and making PoCs regarding this is the next thing on my ToDo list. Maybe we have something until end of the week, but to be honest I cannot promise anything, I’ll just do my best. If somebody wants to support in the area of config and release management, do not hesitate to ping me.
Cheers,
Patrick
Thanks for confirming the current situation and explaining the future plans. This is exactly what I needed. Given there is no actual process in place yet, I will use the usual route of making my PR on top of latest master (2.3.0-snapshot).
@pfink where could I check to see the progress on establishing the patch process? Is there a working community thread or an github isse I could subscribe to? I could not find anything in this topic.
Thanks
Tomasz
1 Like
For specific sub-tasks, there is normally a GitHub issue if it can be related to a particular repository. As it’s a more cross-cutting concern topic, most of the discussions happened in the openhab-distro Gitter chat so far: https://gitter.im/openhab/openhab-distro
Hi all,
stable branches are created now! Maybe the question against which branch a hotfix should go could be answered by @maintainers? To avoid cherry picking, stable branch would be better, probably?
1 Like
Any fix should always first be done on master. If it is decided (contributor together with the repo maintainer(s)) that it should go into a release branch, the simplest solution would be a cherry-pick by the maintainer. If it is a bigger change (which should be an exception for a patch) and there are conflicts, then it makes sense to ask the contributor to create a dedicated PR against the release branch.
2 Likes
Hi all,
our Jenkins release pipeline supports now building releases on top of branches as well. So technically, we’re able to do stable releases without big efforts now 
7 Likes
Hi Ganesh,
Yes, this would be awesome, thanks for volunteering!
As a matter of fact, the branches already exist (see e.g. https://github.com/openhab/openhab2-addons/commits/2.2.x), it is just that no PRs with fixes have been created for it by anyone yet. It would be great if you could help identify critical issues/bugfixes that should be ported to those branches and create the according PRs. We will make sure to merge timely merge them and create regular 2.2.x patch release builds!
Cheers,
Kai
3 Likes
I aggree. But I think this is not possible to handle (to much work).
In my opinion the only way is to split the OH2 distribution from the bindings.
Each binding should have its own version system and should check itself if it is compatible to the installed OH2 version.
This is what i do already. All the bindings i use are in the addon-folder.
The problem at the moment is, i have to compile the bindings i use by myself, and i have to test if the binding is compatible with the installed OH2 version.