2023-07-30 00:20:16.615 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.xtext [135]
a couple other lines, but basically everyone complaining about not having about the events framework missing modules.
one line is different though:
2023-07-30 00:20:25.361 [ERROR] [ternal.service.BootFeaturesInstaller] - Error installing boot features
java.lang.IllegalStateException: Resource has no uri
On the topic of missing out on prerequisites, I think the problem is that some of us don’t really think of Openhabian as it’s own thing and expect to find out about new requirements as part of the ”normal” update flow. Unless you install fresh, it’s pretty easy to miss out on documentation in separate channels - especially when it’s not enough to follow changes connected to the platform itself. I would argue that Openhabian would benefit from a smarter way to inform of such (breaking and generation shifting changes) from within it’s own shell. But that’s my opinion. You’re welcome to project the expectation back on the users. Might be worth a thought though.
(With a giant piece of humble cake acknowledging that I might have missed something very obvious)
Anyway, speaking for myself, I actually thought I had been running Bullseye for some time and probably did until I did a system restore some time back. I arrived at the conclusion that the volume of issues and potential side-issues following at later dates didn’t warrant an attempt to save my original install - at least not unless it was really necessary. I saved the card, did a fresh install on a new SD-card and restored. Had som symlinks and other system stuff that needed manual correction otherwise, but the whole restore procedure worked better than most similar cases I’ve been involved in from a professional stance. Huge kudos to that!
My recommendation thus; try a fresh install and restore config. It’s most probably faster and will give you a more reliable platform to continue working with. 
For what it’sworth; I never got libc to update, neither automatically or manually,which prevented me from installing Java 17. I had high hopes that Bullseye would solve it, but it wasn’t enough. I’m pretty sure that was down to something I did somewhere in ye Olde Times, so didn’t bother with a more serious RCA.
GL!
So what ? openHABian 1.8 was released in June and since then it is based on bulleye.
This is independend of the openHAB version.
Thanks, might just try to get it running on a seperate SDCard. Will probably move to Docker soon anyways. Your thread had my hopes pretty low on getting Java17, but java is up with the correct version reported, so I still have a little spark of hope left 
If you have the energy, maybe do both? I strongly suspect that going fresh > restore will be faster, so it might be worth trying to get back to operation. But if you have the time, go back to the other SD card and see if you can figure this out?
Some old posts have me thinking that there are indeed users who have suffered the same root problem before and successfully countered it with a system upgrade and some manual apt-installs, but there seem to be several having issues now. A guide would probably be appreciated by the community if you can figure it out.
So I might have some good news, this thread faced a similar problem and indeed was able to fix it by clean-cache. am in the console now
https://community.openhab.org/t/openhab-4-0r-not-starting/146669
EDIT: Webinterface is up!
I think this is as good ad it gets at 1am
Looks like I may be a few minutes late to respond but I ran into a huge issue as well earlier today after upgrading using openHABian. My system was starting but would not use Java 17, it was trying to use 11. I have Java 8, 11 and 17 installed due to past upgrades.
I ran the following command and selected the option to use Java 17 and my system started working after restating the openhab service:
sudo update-alternatives --config java
Craig
I have added a check now openHABian refuses to proceed if you select menu 03 (“Install”) and are on buster or earlier.
But it’s an illusion to think this is a proper solution. Thing is there’s several install and upgrade pathes and although this is already documented in several places including the openHABian News pop-up
as devs we cannot catch them all.
And we didn’t know about this dependency ourselves before it showed up.
We cannot test all the combos for you upfront can we. That’s why there’s documented prerequisites that anyone who wants to benefit from our work has to meet.
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.