The port conflict yes. The error with the arch command should happen in both cases.
The export config that you pasted looks similar
Did you use export JAVA_DEBUG_OPTS or export DEFAULT_JAVA_DEBUG_OPTS? Small difference, but only the first one will work.
java version “1.7.0_80”
Given that OH2 is compiled against Java 8, that could be an issue 
It does - it’s in the first error message I posted as well…
Ah - is that another change then? I thought 1.7 was the dependancy, not 1.8. For sure, the previous version which I loaded a few weeks back worked fine under 1.7 
Commenting out the lines you suggested has worked to some degree - the runtime has started and I have the console, but there’s no web interface (I’m getting an error there which I’ll need to track down). However, ‘exit’ doesn’t work, so I’m stuck in the console - something isn’t right, but maybe that’s associated with running 1.7.
Having killed off the console, I confirmed that actually the export you posted does work (by which I mean I don’t get the error - it still doesn’t actually work yet) - when I ran it earlier I still have port 5006 which is also used on Synology.
I guess I now need to work out how to upgrade the system to 1.8 and see if that fixes things…
@kai - can you confirm that Java 8 is indeed now required - I thought that previous discussions were that 7 was going to be the baseline and I can’t find 8 stated in the docs anywhere (yet). This might be a problem for Synology as the docs say only 7 is currently supported 
Same problem here.
I am running OH2 on a jail in Freenas (Freebsd)
@chris: Does the command “uname -m” work on your system. This is the more common command to be used to get the machine hardware name.
If a java compiler 1.8 is used and a java runtime 1.7 this could throw errors, regardless if source / target 1.7 is used. See e.g. https://gist.github.com/AlainODea/1375759b8720a3f9f094
It just returns x86_64.
It’s running DSM 5.2 (Synology) and it’s BusyBox v1.16.1 (2015-10-28 13:23:20 CST)
Hmmm - this might be of interest @Kai
2016-01-16 21:10:59.442 [WARN ] [url.mvn.internal.AetherBasedResolver] - Error resolving artifactorg.openhab.core:org.openhab.io.rest.docs:jar:2.0.0-SNAPSHOT:Could not transfer artifact org.openhab.core:org.openhab.io.rest.docs:jar:2.0.0-SNAPSHOT from/to oh-snapshot-repo (http://oss.jfrog.org/libs-snapshot/): Failed to transfer file: http://oss.jfrog.org/libs-snapshot/org/openhab/core/org.openhab.io.rest.docs/2.0.0-SNAPSHOT/org.openhab.io.rest.docs-2.0.0-SNAPSHOT.jar. Return code is: 503 , ReasonPhrase:Service Unavailable: Back-end server is at capacity.
It looks like whatever is serving up the online system is broken (or maxed out)!
It seems to run with the offline version - at least on my Debian machine (which is also running Java 7, so I don’t think 8 is needed). I’ll try putting the offline onto my Synology and see if that works (I suspect it might)…
According to [this] (http://forum.synology.com/enu/viewtopic.php?f=190&t=100426#p389386) forum, it is possible to install Java 8 (via a workaround) on Synology.
Thanks Davy,
I’m still unsure if 8 is needed - I don’t think so as once I’d sorted out the problem with problem with the Karaf port (thanks 
) and changed to using the offline version, it seems to run fine with 7…
Cheers
Chris
When @davy was working on performance improvements, we decided to go for Java 8 in openHAB 2, since testing on only one JVM reduces the possible problems and after all, Java 7 is out of support by Oracle since almost 2 years. Java 8 should be available (and used as a default) on almost all platforms, so there isn’t really a reason to support Java 7.
Ok - thanks Kai. It just might be useful to make that clear since it doesn’t seem to be documented anywhere (at least not that I’ve seen)…
I’ve upgraded the synology as per @davy’s suggestion - this seemed to work, but I still can’t run in debug mode - there’s no output. Normal mode seems to at least get to the console, but that’s not so helpful for debugging…
I’ll move on to trying to get another system up…
Did you enable debug logging (log:set on the console)?
Note that even if you use start_debug.sh, the logging is by default still INFO level
Sorry - I wasn’t very clear - I meant there’s no console, not no output. The console starts up in normal mode only - it just hangs if I start in debug (nothing is logged either).
Chris, there is an issue with the offline distro in snapshot 87, which causes the startup to fail. See also
We need your help on testing!. This should be fixed in tonight’s build.
Hi,
I’ve just installed 2.0.0.002-beta2 I also received an error when starting from my synology 1513+ package manager. I then run the start_debug.sh from the command line, which failed. But starting the application from the command line worked (see below)
/volume1/@appstore/OpenHAB$ sh start_debug.sh
Launching the openHAB runtime…
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
Aborted
admin@DiskStation001:/volume1/@appstore/OpenHAB$ sh start.sh
Launching the openHAB runtime…
Hit ‘’ for a list of available commands
and ‘[cmd] --help’ for help on a specific command.
Hit ‘’ or type ‘system:shutdown’ or ‘logout’ to shutdown openHAB.
I hope this helps someone.