search

openhab / openhab-docker

Repository for building Docker containers for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
209 stars 128 forks source link

Replace OracleJDK by Zulu Embedded JDK #26

Closed kaikreuzer closed 7 years ago

kaikreuzer commented 8 years ago

Good news! Azul Systems has released their OpenJDK build for ARM 32-bit, which can be downloaded here: http://zulu.org/download/?platform=Linux&processor=ARM%20v7&bitness=32

In contrast to the OracleJDK, this can be freely redistributed and thus it is a much better option to use within the Docker container. In my initial tests, openHAB is running very smoothly on it and I couldn't make out any performance or stability issues with it - it felt just like the OracleJDK.

I therefore highly recommend to change the Docker image to this JVM.

cniweb commented 8 years ago

Hi @kaikreuzer,

that sounds good. @cyberkov what do you think? We can implement: https://github.com/zulu-openjdk/zulu-openjdk/blob/master/8u102-8.17.0.3/Dockerfile

Chris

kaikreuzer commented 8 years ago

Not sure if https://github.com/zulu-openjdk/zulu-openjdk/blob/master/8u102-8.17.0.3/Dockerfile contains the ARM versions, but you are probably the better ones to tell.

sja commented 8 years ago

As of https://www.azul.com/products/zulu/zulu-system-specifications/

ARM v7 and 32-bit v8

kaikreuzer commented 8 years ago

I was speaking about the linked Dockerfile above. Zulu is definitely available for ARM, that's why I created this issue in the first place.

sja commented 8 years ago

Yees, ok. Ok, they've no tagged ARM version. So either we have to add a Step to the README to build the image first manually on the target system. Then apt will ensure the right platform I think.

Or we integrate the few steps of their dockerfile to our build.

patrickse commented 8 years ago

I´ve just had a look at the zulu repos and it looks like that they do not provide deb´s for the arm version. So I just created a fork of this repository and changed it from oracle jdk to Zulu.

So if you´re interested, take a look at https://github.com/patrickse/openhab-docker/tree/zulu.

I am using this one on my private environment from now on to get a feeling for Zulu. But it looks promising..

patrickse commented 8 years ago

The environment is not working as expected with online mode. Got a problem with certificates for ssl connection.

kaikreuzer commented 7 years ago

that they do not provide deb´s for the arm version.

Probably, this will soon change, what should make the packaging simpler.

The environment is not working as expected with online mode. Got a problem with certificates for ssl connection.

@patrickse Do you have any further details on this?

patrickse commented 7 years ago

Hi Kai,

just tried to reproduce this problem with a current build. It looks like the problem disappeared. The only difference now is, if tried this in docker4mac. I will try to run it tomorrow on one of my Pi´s.

Here´s the Stacktrace of the failure...

2016-09-22 19:48:00.107 [WARN ] [url.mvn.internal.AetherBasedResolver] - Error resolving artifactorg.eclipse.smarthome.extension.ui:org.eclipse.smarthome.ui.paper:jar:0.9.0-SNAPSHOT:Could not transfer artifact org.eclipse.smarthome.extension.ui:org.eclipse.smarthome.ui.paper:jar:0.9.0-SNAPSHOT from/to esh-snapshot-repo (https://repo.eclipse.org/content/repositories/snapshots/): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.eclipse.smarthome.extension.ui:org.eclipse.smarthome.ui.paper:jar:0.9.0-SNAPSHOT from/to esh-snapshot-repo (https://repo.eclipse.org/content/repositories/snapshots/): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)[4:org.ops4j.pax.url.mvn:2.4.5]
    at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:615)[4:org.ops4j.pax.url.mvn:2.4.5]
    at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:570)[4:org.ops4j.pax.url.mvn:2.4.5]
    at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:548)[4:org.ops4j.pax.url.mvn:2.4.5]
    at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:523)[4:org.ops4j.pax.url.mvn:2.4.5]
    at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:34)[9:org.apache.karaf.features.core:4.0.4]
    at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:58)[9:org.apache.karaf.features.core:4.0.4]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_91-Zulu-Embedded]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_91-Zulu-Embedded]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_91-Zulu-Embedded]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_91-Zulu-Embedded]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_91-Zulu-Embedded]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_91-Zulu-Embedded]
    at java.lang.Thread.run(Thread.java:745)[:1.8.0_91-Zulu-Embedded]
Caused by: shaded.org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.eclipse.smarthome.extension.ui:org.eclipse.smarthome.ui.paper:jar:0.9.0-SNAPSHOT from/to esh-snapshot-repo (https://repo.eclipse.org/content/repositories/snapshots/): java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at shaded.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:43)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)[4:org.ops4j.pax.url.mvn:2.4.5]
    ... 16 more
Caused by: shaded.org.apache.maven.wagon.TransferFailedException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at shaded.org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:1085)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:977)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run(WagonTransporter.java:560)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:427)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.transport.wagon.WagonTransporter.get(WagonTransporter.java:404)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350)[4:org.ops4j.pax.url.mvn:2.4.5]
    ... 21 more
Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1906)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1889)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1410)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)[:1.8.0_91-Zulu-Embedded]
    at shaded.org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:123)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)[4:org.ops4j.pax.url.mvn:2.4.5]
    at org.ops4j.pax.url.mvn.internal.wagon.ConfigurableHttpWagon.execute(ConfigurableHttpWagon.java:142)[4:org.ops4j.pax.url.mvn:2.4.5]
    at shaded.org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:1000)[4:org.ops4j.pax.url.mvn:2.4.5]
    ... 30 more
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:90)[:1.8.0_91-Zulu-Embedded]
    at sun.security.validator.Validator.getInstance(Validator.java:179)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:312)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:171)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:184)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:105)[:1.8.0_91-Zulu-Embedded]
    at shaded.org.apache.http.conn.ssl.SSLContextBuilder$TrustManagerDelegate.checkServerTrusted(SSLContextBuilder.java:190)[4:org.ops4j.pax.url.mvn:2.4.5]
    at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:922)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)[:1.8.0_91-Zulu-Embedded]
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)[:1.8.0_91-Zulu-Embedded]
    ... 44 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
    at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)[:1.8.0_91-Zulu-Embedded]
    at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120)[:1.8.0_91-Zulu-Embedded]
    at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104)[:1.8.0_91-Zulu-Embedded]
    at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:88)[:1.8.0_91-Zulu-Embedded]
    ... 58 more
patrickse commented 7 years ago

Just forgot to mention that I am using Zulu on my pi with the offline distro for 2 weeks now.

kaikreuzer commented 7 years ago

java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

This occurs for all kinds of SSL communication and seems to be solvable by setting some variables and is not really related to Zulu itself.

I am using Zulu on my pi with the offline distro for 2 weeks now.

That is great - so it indeed seems to be working pretty well!

patrickse commented 7 years ago

I do not really see a difference between oracle and azul java on my pi. So I guess it's ok. If you're keen enough you can try my modified openhab image in my repo.

legacycode commented 7 years ago

With PR #47 this project is using OpenJDK8. I think using OpenJDK8 it's better than using Zulu. Can this issue be closed or are there any requirements left for migrating to Zulu?

kaikreuzer commented 7 years ago

I think using OpenJDK8 it's better than using Zulu.

Not at all, openHAB does not work reliably with OpenJDK. Zulu Embedded is the only OpenJDK build that works decently on arm platforms.

legacycode commented 7 years ago

I could not find a download for Zulu architecture ARM64. There are only 32Bit images at: http://www.azul.com/downloads/zulu-embedded/

kaikreuzer commented 7 years ago

Correct. In any case, you should use the 32bit JVM also on ARM64 - see here.

kaikreuzer commented 7 years ago

FTR, there are now alias links available for the Zulu JDK (so that the links do not need to be adapted on any newer JDK update version):

https://www.azul.com/downloads/zulu/zdk-8-ga-linux_aarch32hf.tar.gz https://www.azul.com/downloads/zulu/zdk-8-ga-linux_x64.tar.gz

In a few weeks, we will also see public apt repositories at Azul.

legacycode commented 7 years ago

The 32Bit binaries are not working on 64Bit operating system used by this dockerfile architecture ARM64. For raspberry pi there is only a 32Bit raspian operating system available. That is the reason why you can use the 32Bit armhf version of zulu. So far i did not get it working on ARM64.

umiddelb commented 7 years ago

@legacycode did you try

sudo dpkg --add-architecture armhf
sudo apt install libc6:armhf

after unpacking the 32 bit ARM Zulu JDK?

legacycode commented 7 years ago

Yes. I have tried following commands:

docker run --rm --privileged multiarch/qemu-user-static:register --reset
docker run -it multiarch/debian-debootstrap:arm64-jessie /bin/bash

dpkg --add-architecture armhf
apt-get update
apt-get install libc6:armhf
wget https://www.azul.com/downloads/zulu/zdk-8-ga-linux_aarch32hf.tar.gz
tar xvfz zdk-8-ga-linux_aarch32hf.tar.gz
cd ezdk-1.8.0_102-8.17.0.21-eval-linux_aarch32hf/bin/
./java -version

bash: ./java: No such file or directory

without success... for amd64 and armhf these commands works fine. maybe you can find the solution.

umiddelb commented 7 years ago

If I execute Docker on the arm64 device directly (without qemu), everything runs fine ...

docker run -it multiarch/debian-debootstrap:arm64-jessie /bin/bash

dpkg --add-architecture armhf
apt update
apt upgrade -y
apt install -y curl libc6:armhf
mkdir /usr/lib/jvm 
curl -sSL https://www.azul.com/downloads/zulu/zdk-8-ga-linux_aarch32hf.tar.gz |  tar -xzvf - -C /usr/lib/jvm
/usr/lib/jvm/ezdk-1.8.0_102-8.17.0.21-eval-linux_aarch32hf/bin/java -version

root@65c52cef99cf:/# /usr/lib/jvm/ezdk-1.8.0_102-8.17.0.21-eval-linux_aarch32hf/bin/java -version
openjdk version "1.8.0_102"
OpenJDK Runtime Environment (Zulu Embedded 8.17.0.21-linux-aarch32hf) (build 1.8.0_102-b21)
OpenJDK Client VM (Zulu Embedded 8.17.0.21-linux-aarch32hf) (build 25.102-b21, mixed mode, Evaluation)

But on a amd64, I'm getting the ' No such file or directory' error message (which you get on arm64 as well if you forget to install the armv7 shared libraries).

May be we can ask @moul if he has an idea.

P.S. I was unable to use ezdk on the latest arm64 kernel, calling javac stops with an 'undefined instruction' error.

legacycode commented 7 years ago

I found the reason. Qemu-*-static is only compiled for ELF 64-bit. You can find the releases and details at:

https://github.com/multiarch/qemu-user-static/releases/

This meens that we are able to compile the docker images for 32-bit arm and zulu, but we can not launch openhab with Qemu.

I mailed zulu and get the following answer:

I forwarded your response on to our team and unfortunately they have responded that the Zulu Embedded build for ARM64 may become generally available before the end of this quarter, and will then be freely downloadable from http://www.azul.com/downloads/zulu-embedded/

We should wait till the download for arm64 is available.

kaikreuzer commented 7 years ago

As mentioned in my https://github.com/openhab/openhab-docker/issues/26#issuecomment-272218253, I do not advice a 64-bit JVM, we should stick to 32-bit by all means. If this doesn't work for qemu, so be it and it needs some specific solution, but the general arm64 Docker image should package the 32-bit JVM. So imho no need to wait for anything.

umiddelb commented 7 years ago

IHMO Qemu is needed for automated builds on Dockerhub.

I hope Azul does a better job than Oracle when building a JVM for aarch64.

kaikreuzer commented 7 years ago

IHMO Qemu is needed for automated builds on Dockerhub.

Hm, that's bad then...

I hope Azul does a better job than Oracle when building a JVM for aarch64.

It is not just the issues of the JVM itself. Note that with e 64-bit JVM (regardless how well this works), no binding that requires serial connection (like e.g. Z-Wave) will work. Therefore such an openHAB installation will be useless for many users.

umiddelb commented 7 years ago

It is not just the issues of the JVM itself. Note that with e 64-bit JVM (regardless how well this works), no binding that requires serial connection (like e.g. Z-Wave) will work. Therefore such an openHAB installation will be useless for many users.

Unless you issue your own aarch64 build of libNRJavaSerial.so.

legacycode commented 7 years ago

I have done a lot of work the last days and tried a lot. I can only test the amd64 version and it seems to be running fine.

Could you please verify my arm64 image with the 32-Bit Azul version. You can download it from openhab:2.1.0-snapshot.

Btw: Note that i deleted gosu and the entryfile. Therefore the default docker behaviour in managing data in containers gets in place. If you would like to use a volume on the host with the default openhab config files generated use the ADD method in the following documentation. If you would like to use existing openhab config files, you can MOUNT them:

https://docs.docker.com/engine/tutorials/dockervolumes/

ADD Method (generates openhab config files in volume):

docker run \
        --name openhab \
        --net=host \
        -v /etc/localtime:/etc/localtime:ro \
        -v /etc/timezone:/etc/timezone:ro \
        -v /openhab/conf \
        -v /openhab/userdata \
        -d \
        legacycode/openhab2-docker:amd64

MOUNT Method (mount existing configuration files to openhab). Do not forget to set permission for the openhab user on your hosts filesystem. It runs user id 9001 and group id 9001. You have to chown 9001.9001 /opt/openhab -R on the host system before starting the container:

docker run \
        --name openhab \
        --net=host \
        -v /etc/localtime:/etc/localtime:ro \
        -v /etc/timezone:/etc/timezone:ro \
        -v /opt/openhab/conf:/openhab/conf \
        -v /opt/openhab/userdata:/openhab/userdata \
        -d \
        legacycode/openhab2-docker:amd64

Any comments?

cniweb commented 7 years ago

LGTM

legacycode commented 7 years ago

@umiddelb have you tested the new 2.1.0-snapshot? This runs zulu in 32bit on arm64. Could you please verify if it works as expected?

umiddelb commented 7 years ago

I've created /opt/openhab/conf and /opt/openhab/userdata with uid 9001 and gui 9001, but it seems that something more is missing. It would help if I can populate /opt/openhab with a working/initial directory structure before starting the container. 

sudo docker run --name openhab --net=host -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro -v /opt/openhab/conf:/openhab/conf -v /opt/openhab/userdata:/openhab/userdata openhab/openhab:2.1.0-snapshot-arm64
Launching the openHAB runtime...
/openhab/runtime/bin/setenv: line 181: [: : integer expression expected
karaf: KARAF_ETC is not valid: /openhab/userdata/etc

If I use /opt/openhab from the Docker image, I get

sudo docker run --name openhab --net=host -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro openhab/openhab:2.1.0-snapshot-arm64
Launching the openHAB runtime...
/openhab/runtime/bin/setenv: line 181: [: : integer expression expected
./runtime/bin/karaf: line 261: [: : integer expression expected
./runtime/bin/karaf: line 306: [: : integer expression expected
./runtime/bin/karaf: line 409:    53 Illegal instruction     (core dumped) ${KARAF_EXEC} "${JAVA}" ${JAVA_OPTS} -Djava.endorsed.dirs="${JAVA_ENDORSED_DIRS}" -Djava.ext.dirs="${JAVA_EXT_DIRS}" -Dkaraf.instances="${KARAF_HOME}/instances" -Dkaraf.home="${KARAF_HOME}" -Dkaraf.base="${KARAF_BASE}" -Dkaraf.data="${KARAF_DATA}" -Dkaraf.etc="${KARAF_ETC}" -Dkaraf.restart.jvm.supported=true -Djava.io.tmpdir="${KARAF_DATA}/tmp" -Djava.util.logging.config.file="${KARAF_BASE}/etc/java.util.logging.properties" ${KARAF_SYSTEM_OPTS} ${KARAF_OPTS} ${OPTS} -classpath "${CLASSPATH}" ${MAIN} "$@"

I could set up one Pine64 for external access (DMZ) so that you can test it by yourself directly. Just send me your ssh key to uli@middelberg.de

legacycode commented 7 years ago

I know. It's an open todo. I will write a setup script to initiate the directories and update the docs next week. In the meantime you can create the files from the image by following:

Create the mountpoints:

sudo mkdir /opt/openhab/ && \
sudo mkdir /opt/openhab/conf/ && \
sudo mkdir /opt/openhab/userdata/ && \
sudo chown 9001.9001 /opt/openhab -R

Copy config files from image to mount point:

sudo docker run --rm \
  -v /opt/openhab/conf:/openhab/conf \
  -v /opt/openhab/userdata:/openhab/userdata \
  openhab/openhab:2.1.0-snapshot-arm64 \
  sh -c 'cp -av /openhab/userdata.dist/. /openhab/userdata/ && \
  cp -av /openhab/conf.dist/. /openhab/conf/'

Or you can run the image by using a docker data volume:

sudo docker run \
  --name openhab \
  --net=host \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v /openhab/conf \
  -v /openhab/userdata \
  openhab/openhab:2.1.0-snapshot-arm64

There is a difference between using docker data container or docker mount points. Docker data containers are copying the volumes. Docker mount points does not do that. Thats the normal behaviour. For details visit:

https://docs.docker.com/engine/tutorials/dockervolumes/

Volumes are initialized when a container is created. If the container’s base image contains data at the specified mount point, that existing data is copied into the new volume upon volume initialization. (Note that this does not apply when mounting a host directory.)

umiddelb commented 7 years ago

OK. Beside of this it should work without mounting /opt/openhab, shouldn't it.

legacycode commented 7 years ago

Yep. My last example should always run. Because the volumes are defined in the Dockerfile as well, mounting the data volume is redundant anyway.

cniweb commented 7 years ago

I think, we can close this issue, or? The Image uses the zulu Java: https://github.com/openhab/openhab-docker/blob/master/update.sh#L44

legacycode commented 7 years ago

Yes. I will check if it works when my aarch64 arrives :-)

umiddelb commented 7 years ago

the ZDK is there, but OH doesn't start properly.

legacycode commented 7 years ago

hmmm... ok. maybe we should fallback to oracle for aarch64 till azul publishes the 64bit version.

umiddelb commented 7 years ago

IMHO this issue doesn't seem to be related to the choice of the JDK, looks like a missing parameter or wrong shell:

sudo docker run --name openhab --net=host -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro openhab/openhab:2.1.0-snapshot-arm64
Launching the openHAB runtime...
/openhab/runtime/bin/setenv: line 181: [: : integer expression expected
./runtime/bin/karaf: line 261: [: : integer expression expected
./runtime/bin/karaf: line 306: [: : integer expression expected
./runtime/bin/karaf: line 409:    53 Illegal instruction     (core dumped) ${KARAF_EXEC} "${JAVA}" ${JAVA_OPTS} -Djava.endorsed.dirs="${JAVA_ENDORSED_DIRS}" -Djava.ext.dirs="${JAVA_EXT_DIRS}" -Dkaraf.instances="${KARAF_HOME}/instances" -Dkaraf.home="${KARAF_HOME}" -Dkaraf.base="${KARAF_BASE}" -Dkaraf.data="${KARAF_DATA}" -Dkaraf.etc="${KARAF_ETC}" -Dkaraf.restart.jvm.supported=true -Djava.io.tmpdir="${KARAF_DATA}/tmp" -Djava.util.logging.config.file="${KARAF_BASE}/etc/java.util.logging.properties" ${KARAF_SYSTEM_OPTS} ${KARAF_OPTS} ${OPTS} -classpath "${CLASSPATH}" ${MAIN} "$@"
cniweb commented 7 years ago

On my machine (amd64) works zulu java!

cniweb commented 7 years ago

Could this font problem be related to the zulu Java? https://community.openhab.org/t/upgraded-docker-openhab-openhab-2-0-0-amd64-and-now-fonts-error/21787 Or do the fonts still need to be installed?

legacycode commented 7 years ago

That does not relate to the zulu Java version. I think there is a permission problem with the docker mounted volume. We changed it from uid 1000 to 9001. The local filesystem on the host must reflect this uid. I dont loke mounted volumes for beginners. Therefore i changed the documentation to use named volumes instead. I will write an upgrade section in the next days.

cniweb commented 7 years ago

Back to zulu, would not it be better if you directly installed the linux packages per apt-get? http://repos.azulsystems.com/

legacycode commented 7 years ago

Zulu only provides the amd64 images in an apt-repository. For armhf it needs to be installed manually and for aarch64 there is only the 32bit armhf version. That does not bring any benefit right now.

legacycode commented 7 years ago

i will do some more tests when my aarch 64 arrives.

legacycode commented 7 years ago

@cniweb: We are on Azul Zulu right now and i think we should not change this. Pls close this issue and lets create new issues for upcoming problems.