So I have a pretty spectacular failure I think @MrPetter also faced.
I am using my openhabian since OH2.5 and the upgrade to OH4 has failed spectacularly. Openhab does not start up and once I checked my java install, I found out I was still running java 11, which I thought would be upgraded with the update but hey. So I ran apt dist-upgrade trying to get my debian, which seems to be in a very bad shape overall, to install the latest packages…
Well smart me. Just got nothing working, not even ssh. When hooking up to my rpi via hdmi, I found out I had a big problem with dhcpcd. I got it to work by following this guide: fix dhcpcd . Once I worked this out, I proceded to try and get java17 but have stumbelded across this https://community.openhab.org/t/openhabian-update-to-oh4-failed-fetching-java17/147975/3 thread which sounds (sadly) like my issue. Now i tried most the things I am familiar with, as I have had my fair share of dancing with apt, but it seems like this is pretty persistent. Does anyone have any clue how to get java17 up and running? or is it a lost cause and I have to hope my backup before the upgrade is fine?
EDIT: I think at least on some level there is an issue with openhab repo authentification
An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable InRelease: The following signatures were invalid: xxxxx
Got this error in apt update. When I try to add the appropriate openhab key, like mentioned in the docs https://www.openhab.org/docs/installation/linux.html, I get a openhab.gpg: Permission denied. So the issue might be on the authentication of the repo?
First question: Which version is the underlying os?
If debian or Raspberry Pi OS buster, please upgrade to debian or Raspberry Pi OS bullseye first.
After successful upgrade to bullseye, try to install Java17 by issuing
No but Zulu in version 17 would be available.
Nevertheless recommended version is bullseye as there are other dependencies that are made available rely on libc that is used in bullseye.
What's Changed
This image prepares for openHAB 4. It will install OH 4 and Java 17 by default.
(you will get the latest milestone release until final availability of OH4 will replace it by the release version when that gets released).
Based on latest Raspi OS image on bullseye as of May 3rd, 2023
Install log now on port 81
So I have gotten further, I have now upgraded and got java17 up and running, but am unable to get a console, although openhab reports to be running (web interface doesn’t work either). Seems the update to bullseye.
Wasn’t intending to blame anyone, should have read the docs. Checking the version really might be an option to increase user friendlyness
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.
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.
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:
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.