So your point is I as the dev have to spend even more of my private spare time because you have so little precious time that you cannot afford to waste any of that to read the docs essentials I wrote for you?
What a poor attitude.
Note it’s not about reading any post - it is about reading the Readme of a software before using it. That’s standard isn’t it.
0k, lets all take a breath here…
Comment:
I would like to have control over the OS upgrade independent if it is windows or if it is any flavor of Linux. So in most if not in all cases before executing the upgrade/update I am checking what is available ( windows shows what will be updated; on apt base systems I can do apt-get -s upgrade ( which lists the packages to be upgrade ).
Maybe try the Zulu JVM instead? They compile using older libc versions to support older platforms. I’ve even run Java 17 code on Ubuntu 12.04 (libc 2.15) that way. 
So I would like to just tell you what I had to do to fix this and maybe provide some references for people facing similar problems.
Now after I was pointed towards the Debian version being not up to date, I first ran the upgrade by the usual way of changing apt sources and running apt update and apt full-upgrade. This worked, but afterwords I had major issues trying to get apt sources up and running again. The issue was, that the keys of the repositorys were not in the apt keyring. As the keyservers used by pretty much any online guide are not running any more. So I used the Ubuntu keyservers, they worke fine. Btw. The add keys command mentioned in the docs is not working either anymore, seems like the server does not support the command or it is disabled, so it would be necessary to update this page.
However, this lead to a running bullseye Debian on which I was able to install java17.
However, openhab would still not run, I could not get into the console or the Webinterface. After a bit of fiddling around, I stumbled across a thread in here with a similar issue and a openhab-cli clean-cache did the trick.
Now openhab worked fine, but mosquito did not work yet. It got upgraded at some point in my wild adventure of apt upgrade variations to 2.xx. Now the issue was the pid file, whatever this is, I needed to comment out the line in the configuration mentioning it aaaand everything worked.
Now as to weigh in on the update discussion. I am a pretty experienced user of Debian and apt. Nevertheless, the update mechanism of openhab remains very unclear to me. For example, what does openhabian-config do different from apt update and apt upgrade? Also the commands run by this tool are not output to the console and neither is the output. This would make debugging much easier as you could just get more info than failed. Now I am sure there is some file with the output, but as you have to go into the shell anyway, there seems to be little advantage to not displaying the output for quick reference.
Now as a long term goal, I think it should be a simple thing of some Webinterface existing to manage the server and upgrading with every necessary part of it, from the os to various openhab components. This would widely broaden the userbase.
Also I try to keep up to date with the news on a update, but sources are just very unclear. Where is the proper documentation? Is it on GitHub? Or in the docs? Now I am sure this is not a problem for the people maintaining openhab, but it is for the people who are not as familiar with the way open source projects are structured. I would love to contribute to these issues myself, but I just can’t seem to understand how things are supposed to be done.
Nevertheless, I have the deepest respect of all the people keeping openhab up and running and providing such a mature software with such great functionality. Especially considering the way openhab has gone from 2.5., I love using it and working around getting stuff running with the quirky ways manufacturers build their devices.
Often times the script that starts a service running in the background will save the ID of the running process (i.e. the PID) to a well known file in a well known place. That way, when the startup system is asked to restart or stop that background service, it knows which process to send the signal to. If the permissions on the pid file get messed up or the number stored in the pid file get’s out of sync there can be problems.
I would have expected a simple reboot to fix the problem. I fear simply commenting out the line in the start script may cause problems down the road.
Nothing really. openhabian-config calls apt to do the update/upgrade.
You can turn on debug mode. Details are in the openHABian docs.
We’ve been down this path multiple times. It is anything but a simple thing, which is why we remain with openhabian-config.
Proper documentation for what? For openHABian I believe the “stable” set of docs as Introduction | openHAB keeps up with the latest release of openHABian. So what you see there will be up to date, unless you use some other branch of openHABian in which case, see the latest readme on GitHub that corresponds with the branch you are using.
There’s an excellent tutorial posted on contributing to the docs at [Wiki] How to contribute to the openHAB Documentation.
The key is to understand where the docs come from. Since OH has multiple repos, parts of the documentation come from different repos as well and gets compiled into one unified documentation page from those multiple sources.
openHABian updates the openHAB keys on every start of openhabian-config.
Provide the docs link you refer to please.
https://www.openhab.org/docs/installation/linux.html
The command for adding the key didn’t work for me. Tripple checked I had propper Internet, so this was not the issue for sure.
curl -fsSL "https://openhab.jfrog.io/artifactory/api/gpg/key/public" | gpg --dearmor > openhab.gpg
What did not work ? What was the error message if any ?
The server does not support the command, didn’t write it down (stupid me…), but that basically was the message.
That only could be the case if either curl or gpg is not available/installed.
Well it wasn’t a message about my Pi not supporting the command, but the return from the server https://openhab.jfrog.io/artifactory/api/gpg/key/public not supporting gpg.
curl just does an HTTP request, server’s gpg support is irrelevant, the gpg command would need to execute on your box
Oh, maybe I missinterpreted the output in that case. Will try a little on the weekend and see if I can reprocduce the error.
I used the wget command from this post Linux Repo Public Key is Expiring Soon. Maybe it makes a difference?
TLDR: Both the line in the Linux Repo Public Key is Expiring Soon link and in the lines (note: plural) in the docs do the same thing. The version in the docs breaks each step down in a way more suitable for first time installers. The version in the forum link is a useful one liner that is should work for most Linux distributions.
Generally, wget is available by default on most Linux distributions. curl is usually available, but not as much as wget.
The lines:
wget -qO- https://openhab.jfrog.io/artifactory/api/gpg/key/public | gpg --dearmor | sudo tee /usr/share/keyrings/openhab.gpg >/dev/null
and
curl -fsSL "https://openhab.jfrog.io/artifactory/api/gpg/key/public" | gpg --dearmor > openhab.gpg
Are different in two places.
The first uses wget and the other uses curl to dump the contents of the download into the standard output. The result of these commands should be identical (for the link we’re using).
In the second, gpg --dearmor > openhab.gpg writes the output of the gpg command to a file called openhab.gpg in the current directory (folder). The use of > means you must have write access to this directory, even using sudo won’t work here. That means after you’ve run the command, you need to move it to /usr/share/keyrings/ in a separate command afterwards.The first example makes use of an additional tee command to make use of sudo and a write to a protected folder.
Actually, the command works now, so probably something messed up with the old version of Debian
This doesn’t work for me. I get “Unable to locate package openjdk-17-jre-headless”.
When I do “apt-cache search openjdk”, the only Java 17 packages are doc and source.
I’m running Raspbian bullseye.
Any suggestions would be greatly appreciated.
Try installing zulu java 17
Thanks, that did the trick, after I figured out how to install it.
Just curious, does anyone know why openjdk 17 has disappeared from the normal distribution channel?