[Solved] OpenHAB 3 on Ubuntu LTS 20.04 doesn't start

  • Platform information:
    • Hardware: AMD Ryzen 3600
    • OS: Ubuntu 20.04
    • Java 14
    • openHAB version: 3.0.1
  • Issue of the topic: I cannot get OpenHAB to start

Hello,

I’ve downloaded the OpenHAB 3.0.1 stable ZIP file, created a user openhab3 on my system (all as what I did with OpenHAB 2 earlier), but I am not able to start the system. The output on start I get is just:

~/openhab$ ./start_debug.sh
Launching the openHAB runtime...
Listening for transport dt_socket at address: 7005
Error occurred while checking the system module.

When looking into the openhab.log file, I get a bunch of these:

2021-03-23 10:22:08.260 [SEVERE] [org.apache.karaf.main.Main] - Could not launch framework
java.lang.RuntimeException: Error occurred while checking the system module.
	at org.eclipse.osgi.storage.Storage.checkSystemBundle(Storage.java:311)
	at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:87)
	at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:68)
	at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31)
	at org.eclipse.osgi.launch.EquinoxFactory.newFramework(EquinoxFactory.java:24)
	at org.apache.karaf.main.Main.launch(Main.java:256)
	at org.apache.karaf.main.Main.main(Main.java:178)
Caused by: org.osgi.framework.BundleException: Invalid manifest header Export-Package: "org.osgi.dto;version="1.0",org.osgi.resource;version="1.0",org.osgi.resource.dto;version="1.0";uses:="org.osgi.dto",org.osgi.framework;version="1.8",org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto",org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framework",org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring",org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework",org.osgi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring",org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework",org.osgi.framework.namespace;version="1.1";uses:="org.osgi.resource",org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework",org.osgi.framework.startlevel.dto;version="1.0";uses:="org.osgi.dto",org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource",org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi.dto,org.osgi.resource.dto",org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin",org.osgi.service.packageadmin;version="1.2";uses:="org.osgi.framework",org.osgi.service.permissionadmin;version="1.2",org.osgi.service.resolver;version="1.0";uses:="org.osgi.resource",org.osgi.service.startlevel;version="1.1";uses:="org.osgi.framework",org.osgi.service.url;version="1.0",org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework",org.apache.karaf.version;version="4.2.7",org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version="4.2.7",org.apache.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version="4.2.7",org.apache.karaf.info;version="4.2.7",, org.apache.karaf.branding, sun.misc, org.apache.karaf.jaas.boot;uses:="javax.security.auth,javax.security.auth.callback,javax.security.auth.login,javax.security.auth.spi,org.osgi.framework";version=4.2.7, org.apache.karaf.jaas.boot.principal;uses:=javax.security.auth;version=4.2.7, org.apache.karaf.diagnostic.core;uses:=org.osgi.framework;version=4.2.7, org.apache.karaf.diagnostic.core.common;uses:=org.apache.karaf.diagnostic.core;version=4.2.7"
	at org.eclipse.osgi.util.ManifestElement.parseHeader(ManifestElement.java:353)
	at org.eclipse.osgi.container.builders.OSGiManifestBuilderFactory.createBuilder(OSGiManifestBuilderFactory.java:85)
	at org.eclipse.osgi.storage.Storage.getBuilder(Storage.java:632)
	at org.eclipse.osgi.storage.Storage.checkSystemBundle(Storage.java:263)
	... 6 more

and here I am :frowning: I am not really able to understand what the issue is, or how to handle this.

Please read the prerequisits, openHAB 3 needs Java 11, no higher version supported !!!

2 Likes

Hello @hmerk ,

oh - thank you. I read that Java 11 is required, but I understood that’s a minimum requirement and thought if a higher version is unsupported, I’d get an error message that says that.

I’ll give it a try. Thanks.

Java 11 is the long term support version.

Later versions are supported on a much shorter term as they try adding & changing features for the next long term support version. I know it is confusing but it seems to be a rather common development model now.

1 Like

Thank you for the explanation. Indeed with Java 11 it works flawless. Indeed it wouldn’t be bad, if start.sh just said “Sorry, wrong Java version - yours is too new”. It’s such an obvious thing but for me it was hard to figure out (and frustrating before I posted here).

As someone who’s just installed openHAB3 on the same Ubuntu 20.04, but used the repositories via apt - what’s the reason you’ve installed via the zip file? Does it provide any benefits?

They did not add the prophecy package to determine that :rofl:

1 Like

I have once learned from a guy who is a professional sysadmin that I should, whenever possible, install software as a particular user. It gives me the opportunity to learn different things and - as in my case - I have now on the same machine OpenHAB2 (my old system) and OpenHAB3 installed which use different Java versions (8 and 11) without any further issues (I have downloaded the particular Java version and unpacked in the particular users’ home directory). With apt-get I don’t know whether I would be able to have my currently productive OpenHAB2 system running alongside the new OpenHAB3 to which I can now slowly migrate as I have time.

Also this way I make sure nothing can run as root / administrator (when using apt packages it’s always a question of trust how things are installed). It’s perhaps paranoic, but it’s not really much more effort in my eyes but gives me a lot of flexibility, control and security.

Ah - and to get rid of it I just delete the user and do rm -rf /home/username :see_no_evil: no dependencies, no issues and keeps my system clean. I have installed other stuff as well the same way and usually it’s not a lot more than unzipping a package and starting it (and yes - I create a systemd script in /etc/systemd which starts the software as the appropriate user).

2 Likes

Using Docker does a great job too. I hav a test Pi sunning OH 2 & 3 with the remoteopenhab binding connecting them.

Oh no - Docker won’t make it’s way to my machine :wink:

1 Like

You concerned about a trojan horse? ( playing off your username…)

See this talk from the Chaos Computer Club for example (in German though, but a lot on that topic is on the net also in English) :smiley:

And the user-based installation I described above is IMHO even less effort than setting up Docker and the environment. And more secure :wink:

Ah this one then :wink:

By the way, all OS security is hidden behind cryptic options that require administrators & developers as interprreters.

Rather this one :stuck_out_tongue_winking_eye:

Don’t oversee my reply from above just when you posted.

True - but if I install something just in the home of an unprivileged user, I’m much more secure than running thing in a container that runs with root privileges (and root in the container is also root on the host → see the talk I posted above).

We are talking about a machine not to be exposed to the internet, but only accessed locally.
Really don’t understand your concerns.

2 Likes

My machine is exposed to the internet as well, as I want remote access to my OpenHAB installation.

Also - I don’t want to offend anybody using Docker. Do what you like. I got the response to my setup, that Docker is an alternative (which I’m aware of), but not for me. And I delivered a rationale upon being asked (and with a smiley which I thought shows that this is to be taken with a salt of humor). I don’t want to convert anybody from using Docker though, because when it’s setup well, it can perfectly serve its purpose.

This should not be done. Either secure it via VPN or use the free myopenHAB service. No need to expose it to have remote access.

I don’t use docker, so cannot be offended, and I also don’t want to convince you to use docker.

That confuses me though. The OpenHAB app offers me for every instance to setup a local and a remote address and I never read it wasn’t meant to be running on a server exposed to the internet (why does it then actually provide SSL-secured access if that’s not intended?)?

This is a misunderstanding. Remote URL ist the URL to our myopenHAB service, or a self hosted myopenHAB. In Any case, using this service, you don’t expose your local instance to the internet.

1 Like

I was never aware of that. Thank you for pointing this out to me, that OpenHAB is not meant to be exposed ever to the internet. Will see to shut that off asap.