Upgrade 3.2.0 to 4.x.x -> System not available

Setup, Configuration and Use Migration
1

Today I tried to upgrade my OpenHAB from 3.2.0 to the latest 4.x.x version on OpenHABian on a Raspberry Pi 3B.

Therefore I first of all uninstall java

sudo apt remove java*

Then I installed the Java 17.0.10 LTS version from Zulu and set the environment variables

update-alternatives --install /usr/bin/java java /opt/java/zulu17.42.19-ca-jdk17.0.7-linux_aarch32hf/bin/java 1 update-alternatives --install /usr/bin/javac javac /opt/java/zulu17.42.19-ca-jdk17.0.7-linux_aarch32hf/bin/javac 1
update-alternatives --config java`

which gives me the following output for java-version:

openjdk version “17.0.10” 2024-01-16 LTS
OpenJDK Runtime Environment Zulu17.48+15-CA (build 17.0.10+7-LTS)
OpenJDK Server VM Zulu17.48+15-CA (build 17.0.10+7-LTS, mixed mode)

Next, I fetched the new repo key with this command:

wget -qO- https://openhab.jfrog.io/artifactory/api/gpg/key/public | gpg --dearmor | sudo tee /usr/share/keyrings/openhab.gpg >/dev/null

Then I ran

sudo apt update
sudo apt upgrade

Everything looked ok, except some warnings for bindings, I don’t think I use at all.

But OpenHAB is not reachable via browser. So I restarted Raspberry Pi and checked the logs. Openhab.log:

2024-03-18 14:38:11.526 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.openhab.core.karaf/3.2.0
2024-03-18 14:38:11.541 [INFO ] [ll.impl.action.osgi.CommandExtension] - Updating commands for bundle org.apache.karaf.jaas.command/4.3.4
2024-03-18 14:38:11.551 [INFO ] [ll.impl.action.osgi.CommandExtension] - Updating commands for bundle org.apache.karaf.jaas.command/4.3.4
2024-03-18 14:38:23.692 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:23.825 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.075 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.190 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.303 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.389 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.480 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.578 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.656 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.732 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.791 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.844 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.893 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.938 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:24.975 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:25.031 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:25.070 [INFO ] [org.apache.cxf.endpoint.ServerImpl ] - Setting the server’s publish address to be /
2024-03-18 14:38:25.317 [INFO ] [vice.internal.HttpServiceFactoryImpl] - Unbinding bundle: [org.openhab.core.io.http.auth_3.2.0 [173]]
2024-03-18 14:38:25.322 [INFO ] [.jetty.server.handler.ContextHandler] - Stopped HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.openhab.core.io.http.auth_3.2.0 [173], contextID=default]}
2024-03-18 14:38:25.349 [INFO ] [vice.internal.HttpServiceFactoryImpl] - Unbinding bundle: [org.openhab.core.audio_3.2.0 [154]]
2024-03-18 14:38:25.353 [INFO ] [.jetty.server.handler.ContextHandler] - Stopped HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.openhab.core.audio_3.2.0 [154], contextID=custom]}
2024-03-18 14:38:25.361 [INFO ] [vice.internal.HttpServiceFactoryImpl] - Unbinding bundle: [org.openhab.core.io.http_3.2.0 [172]]
2024-03-18 14:38:26.026 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.event/4.3.4
2024-03-18 14:38:26.052 [INFO ] [org.apache.cxf.bus.osgi.CXFActivator] - Removing the extensions for bundle 65
2024-03-18 14:38:26.054 [INFO ] [org.apache.cxf.bus.osgi.CXFActivator] - Removing the extensions for bundle 67
2024-03-18 14:38:26.056 [INFO ] [org.apache.cxf.bus.osgi.CXFActivator] - Removing the extensions for bundle 63
2024-03-18 14:38:26.081 [INFO ] [vice.internal.HttpServiceFactoryImpl] - Unbinding bundle: [org.apache.aries.jax.rs.whiteboard_2.0.0 [59]]
2024-03-18 14:38:26.085 [INFO ] [.jetty.server.handler.ContextHandler] - Stopped HttpServiceContext{httpContext=org.ops4j.pax.web.extender.whiteboard.internal.WebApplication$1@48f0a6}
2024-03-18 14:38:26.093 [INFO ] [rd.activator.CxfJaxrsBundleActivator] - destroyed whiteboard from configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
2024-03-18 14:38:26.099 [INFO ] [rd.activator.CxfJaxrsBundleActivator] - Unregistered SseEventSourceFactory
2024-03-18 14:38:26.102 [INFO ] [rd.activator.CxfJaxrsBundleActivator] - Unregistered ClientBuilder
2024-03-18 14:38:26.212 [INFO ] [vice.internal.HttpServiceFactoryImpl] - Unbinding bundle: [org.ops4j.pax.web.pax-web-extender-whiteboard_7.3.23 [220]]
2024-03-18 14:38:26.214 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.http.core/4.3.4
2024-03-18 14:38:26.214 [INFO ] [vice.internal.HttpServiceFactoryImpl] - Unbinding bundle: [org.apache.karaf.http.core_4.3.4 [78]]
2024-03-18 14:38:26.262 [INFO ] [lipse.jetty.server.AbstractConnector] - Stopped 0.0.0.0:8443@138c7cf{SSL, (ssl, http/1.1)}{0.0.0.0:8443}
2024-03-18 14:38:26.266 [INFO ] [lipse.jetty.server.AbstractConnector] - Stopped default@10c04a4{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
2024-03-18 14:38:26.268 [INFO ] [org.eclipse.jetty.server.session ] - node0 Stopped scavenging
2024-03-18 14:38:26.272 [INFO ] [.jetty.server.handler.ContextHandler] - Stopped o.e.j.s.h.ContextHandler@122a251{/static,null,STOPPED}
2024-03-18 14:38:26.279 [INFO ] [j.pax.web.service.internal.Activator] - ServerControllerFactory is gone, HTTP Service is not available now.
2024-03-18 14:38:26.283 [INFO ] [j.pax.web.service.internal.Activator] - Pax Web stopped
2024-03-18 14:38:26.397 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.system.core/4.3.4
2024-03-18 14:38:26.404 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.shell.ssh/4.3.4
2024-03-18 14:38:26.499 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.service.core/4.3.4
2024-03-18 14:38:26.513 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.package.core/4.3.4
2024-03-18 14:38:26.520 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.log.core/4.3.4
2024-03-18 14:38:26.531 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.kar.core/4.3.4
2024-03-18 14:38:26.540 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.instance.core/4.3.4
2024-03-18 14:38:26.559 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.features.command/4.3.4
2024-03-18 14:38:26.565 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.diagnostic.core/4.3.4
2024-03-18 14:38:26.572 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.config.core/4.3.4
2024-03-18 14:38:26.586 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.bundle.core/4.3.4
2024-03-18 14:38:26.628 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.wrapper.core/4.3.4
2024-03-18 14:38:26.636 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.shell.commands/4.3.4
2024-03-18 14:38:26.638 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.jaas.command/4.3.4
2024-03-18 14:38:26.641 [INFO ] [ll.impl.action.osgi.CommandExtension] - Unregistering commands for bundle org.apache.karaf.deployer.kar/4.3.4

When I request the service’s status with

sudo service status

sudo service openhab status

openhab.service - openHAB instance, reachable at http://openhabian:8080
Loaded: loaded (/lib/systemd/system/openhab.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/openhab.service.d
└─override.conf
Active: activating (auto-restart) (Result: exit-code) since Mon 2024-03-18 18:45:12 CET; 3s ago
Docs: Introduction | openHAB
https://community.openhab.org
Process: 12981 ExecStart=/usr/share/openhab/runtime/bin/karaf ${OPENHAB_STARTMODE} (code=exited, statu>
Main PID: 12981 (code=exited, status=1/FAILURE)
CPU: 3.730s

Mar 18 18:45:12 openhabian systemd[1]: openhab.service: Consumed 3.730s CPU time.

Can you please help me what to check further? I think, even if my bindings, items or anything else were now deprecated, OpenHAB should still start and tell me, which bindings, etc. don’t work anymore?!

Thanks and kind regards,

Dirk

2

Are you using openHAB or openHABian. You’ve not mentioned but the status shows openhabian.

If you are running openHABian, why did you not do all these steps through openhabian-config? What you did is what I would expect for steps for someone running OH on Linux without openHABian. I don’t know that necessarily will cause a problem, but it could.

Everything looked ok where? What sorts of warnings?

When posting logs please use code fences.

```
code or logs go here
```

The logs you have posted look like what OH logs when shutting down. Do you have startup logs?

All the status shows is OH failed to come up, exiting with an error code.

1 Like
3

Output of java -version looks good. I’m using the same version together with OH 4.2.0.M1

If you use Openhabian → Why not update with openhabian-config ?

40 OpenHAB related → 41 Install latest openHAB Release, Milestone or Snapshot

Snapshot I would not recommend if this is your productive system. But Milestone is running without any issues on my Raspi (a huge system with 200 Things, 950 Items, 100 rules). I would try to re-install Release or Milestone using openhabian-config.

And maybe clear-cache also helps:

sudo systemctl stop openhab
sudo openhab-cli clean-cache
sudo systemctl start openhab
1 Like
4

Thanks a lot for your responses. Sorry, I was not aware I could use openhab-config. I thought OpenHABian was just the distribution/a debian fork and that is running OpenHAB as any other Linux.

I ran openhab-config now and installed the latest release. This gives me the same output for

sudo systemctl status openhab

as mentioned in the first post.

Sadly it still doesn’t work. What works is http://openhabian:9001. There I see some log output, but only from my openhab.log, as far as I can judge that. Latest is from 14:38 o’clock. Before the upgrade.

When I check the daemon.log I see the following:

Mar 18 20:40:10 openhabian karaf[21578]: Incompatible magic value 4294967295 in class file java/util/logging/ConsoleHandler
Mar 18 20:40:10 openhabian karaf[21578]: Exception in thread "main" java.lang.ClassFormatError: Incompatible magic value 4294967295 in class file java/util/logging/LogRecord
Mar 18 20:40:10 openhabian karaf[21578]: #011at java.logging/java.util.logging.Logger.log(Logger.java:1116)
Mar 18 20:40:10 openhabian karaf[21578]: #011at org.apache.karaf.main.Main.main(Main.java:188)
Mar 18 20:40:10 openhabian systemd[1]: openhab.service: Main process exited, code=exited, status=1/FAILURE
Mar 18 20:40:10 openhabian systemd[1]: openhab.service: Failed with result 'exit-code'.
Mar 18 20:40:10 openhabian systemd[1]: openhab.service: Consumed 4.010s CPU time.

syslog and daemon.log are the only logs that are updated when I open http://:8080 in the browser.

In the browser’s developer tools in the network tab I see “(error)ret=ERR_CONNECTION_REFUSED” for http://:8080.

5

In fact it’s just the opposite. It’s a stock Raspberry Pi OS with some scripts that run on first boot and/or when using openhabian-config to install stuff and configure it.

Well, that tells us what the error is. What it means is something else entirely. I would guess that you’ve either not installed Java 17 or somehow it’s not actually using that.

1 Like
6

Thanks for your response.

That sounds promising.

As I wrote in my first post, I get the following response when entering java -version in the shell:

openjdk version “17.0.10” 2024-01-16 LTS
OpenJDK Runtime Environment Zulu17.48+15-CA (build 17.0.10+7-LTS)
OpenJDK Server VM Zulu17.48+15-CA (build 17.0.10+7-LTS, mixed mode)

So it’s definitely installed and I uninstalled the previous version 11(?) with the command apt remove java*.
Is there a way to find out, why my java 17 doesn’t seem to be used or that I can force OpenHAB to use it?

7

Sure, but what Java is openHAB using when it starts up?

I’m sure but someone more knowledgable with openHABian will have to chime in. I don’t have that knowledge.

1 Like
8

Well you can attempt to install java through option 45 but if that doesn’t work it’s a waste of time to attempt debugging a messed-up install. It’s better to export your config, reinstall openHABian from scratch to a new SD card and re-import your config.

1 Like
9

Thanks for your responses.

To be honest, I don’t know (how to check) which Java OpenHAB is using.

Probably you are right with a re-installation, but sadly I still have a USB-“receiver” for my temperature and humidity sensors installed plus several scripts outside of OpenHAB that are triggered by mosquitto and if I could repair the system it would hopefully not be such a mess as fixing OpenHAB to use the right Java version.

Does OpenHAB bring its own Java and doesn’t use the system java? If so, I will try to install/update Java with openhabian-config option 45. And then I would expect/hope it works. If not, I would go the ugly way and re-install everything from scretch.

10

No. It uses a separately installed Java which lets the end users choose which Java implementation they want to use.

1 Like
11

Thanks for your response.

I see. I still don’t understand why it didn’t use my Zulu Java 17 installation, BUT: I installed Java via openhabian-config and now it works and all my used bindings / scripts seem to work. Had no time yet to test it, but at least in the Things and Items overview there are no errors. Some values are still null, but probably they take more than just some seconds to request the data again.

Awesome. Thanks a lot to all of you, great help!