Complete failure to install add-ons / bindings / extensions after upgrade to 2.5.8

  • Platform information:
    • Hardware: Arm based
    • OS: ‘Armbian’ / Debian buster
    • Java Runtime Environment: 11.0.8
    • openHAB version: 2.5.8 (upgraded from 2.5.7)
  • Issue of the topic: After an upgrade to 2.5.8, openhab2 is not restarting fully. It does not install any add-ons (bindings, transformations, etc.)
  • If logs where generated please post these here using code fences:

The following error is shown

2020-09-02 13:31:34.564 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-binding-http1, openhab-binding-exec, openhab-ui-homebuilder, openhab-misc-openhabcloud, openhab-transformation-javascript, openhab-misc-ruleengine, openhab-persistence-mysql, openhab-transformation-regex, openhab-ui-habpanel, openhab-binding-gpio1, openhab-transformation-xpath, openhab-binding-mqtt, openhab-transformation-map, openhab-ui-basic, openhab-binding-ntp, openhab-binding-astro, openhab-binding-squeezebox, openhab-binding-homematic, openhab-transformation-exec, openhab-ui-paper’: Error occurred installing a bundle.

My addons.config is as follows:

$cat /var/lib/openhab2/config/org/openhab/addons.config

:org.apache.felix.configadmin.revision:=L"13"
binding=“gpio1,http1,ntp,squeezebox,exec,homematic,mqtt,astro”
misc=“openhabcloud,ruleengine”
package=“standard”
persistence=",mysql"
service.pid=“org.openhab.addons”
transformation=“regex,exec,xpath,javascript,map”
ui=“basic,paper,habpanel,homebuilder”

I would hate to delete it and reconfigure all add-ons. I did make backups, but believe I may get the same error when I restore them.
Any ideas on how I could perform some “surgery” deleting single entries in the addons.cfg and/or a pid file that may still trail somewhere?

ok. I found some more in the syslog, which probably leads to a solution:

Sep 2 13:45:34 localhost karaf[18271]: org.osgi.framework.BundleException: Error occurred installing a bundle.
Sep 2 13:45:34 localhost karaf[18271]: #011at org.eclipse.osgi.storage.Storage.install(Storage.java:574)
Sep 2 13:45:34 localhost karaf[18271]: #011at org.eclipse.osgi.internal.framework.BundleContextImpl.installBundle(BundleContextImpl.java:146)

Sep 2 13:45:34 localhost karaf[18271]: #011at java.base/java.lang.Thread.run(Thread.java:834)
Sep 2 13:45:34 localhost karaf[18271]: Caused by: java.util.zip.ZipException: Exception in opening zip file: /var/lib/openhab2/cache/org.eclipse.osgi/299/0/bundleFile
Sep 2 13:45:34 localhost karaf[18271]: #011at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:317)

Sep 2 13:45:34 localhost karaf[18271]: #011… 12 more
Sep 2 13:45:34 localhost karaf[18271]: Caused by: java.util.zip.ZipException: zip END header not found
Sep 2 13:45:34 localhost karaf[18271]: #011at java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1567)

Sep 2 13:45:34 localhost karaf[18271]: #011… 16 more

Indeed, the subdirectory /var/lib/openhab2/cache/org.eclipse.osgi/299 does not exist. There is subdirectories going up to 259 under org.exclipse.osgi
Can I safely delete the cache folder?

Yes, shutdown the OH service then you can delete the cache and the tmp folder content.

see e.g.: Clear the Cache

OpenHAB 2 is officially only supported on Java 8. OH3 will use Java 11.

Interesting. I never realized this, but just saw in the docs that java 8 is recommended. With cleaning the cache and tmp folders I am up and runing again, though. However, I do have some ‘hickups’ when starting up. It takes forever (like 20 minutes) until I can access the Basic UI and I often have to make a restart of openhab since for some reason the items are not available at the first launch. I wonder if this is related to that.

Sadly that is fairly typical. There is a “cache” file that gets cleared by upgrade, and there is general grief until it is fully populated before a start attempt. So two or three restarts are required to get a clean start.

So far as I understand, much of 2.5.x has been loosely validated against Java 11 in preparation for OH3 but operational use is at your own risk.