Thanks, @Wolfgang_S - I have some config file backups from a few months ago. So as far as I understand it, even though the sources.list was set to testing (milestone) on Ver 3.4.2, openhabian should never have upgraded the system to openhab 4. Is that correct? Just want to make sure so that I don’t make the same mistake again.
To prevent that from happening pinning for a specific version would have to be done. Which is not done. This is why this kind of updates/upgrades are happening.
In case you manually call the update, upgrade procedure you can do a try run and will see what will happen in case the upgrade command is executed. As openhabian-config is some kind of UI for non linux experts this is not being shown and just executed as the software ‘assumes’ everything that is requested will be done.
This also will happen for users that are in stable release at this moment. Once OH4 will be made a stable version the upgrade from OH3 to OH4 will take place as well.
So I have managed to recover by changing the openhab version from testing to stable. I did this in openhabian-config. Openhab was then re-installed and after a couple of reboots the system is back without needing to restore config files. It looks like Openhab 3 Milestone release option is now pointing to Openhab 4 M1. Hence when I used Openhabian to upgrade the system it partly upgraded to 4M1.
Is that how it should be? Are all new milestone releases on Ver.4 and no longer on Ver.3?
To reiterate what @Wolfgang_S said, each repo always points to the most recent release of that type. That’s the way it is, has been and is supposed to be.
The most recent release is 3.4.2.
The most recent testing release is 4.0.0 M1.
The most resent snapshot is 4.0.0 SNAPSHOT #33?? (I don’t know the latest number).
1 Like
Liebe Gemeinde,
Leider ist mein Englisch nicht ausreichend um meiner Kritik Luft zu machen.
Nach einem sudo openhabian-config mal wieder ein abgeschossenes System mit der Meldung
2023-03-17 13:11:13.142 [ERROR] [ternal.service.BootFeaturesInstaller] - Error installing boot features
org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-runtime-ui; type=karaf.feature; version=“[4.0.0.M1,4.0.0.M1]”; filter:=“(&(osgi.identity=openhab-runtime-ui)(type=karaf.feature)(version>=4.0.0.M1)(version<=4.0.0.M1))” [caused by: Unable to resolve openhab-runtime-ui/4.0.0.M1: missing requirement [openhab-runtime-ui/4.0.0.M1] osgi.identity; osgi.identity=org.openhab.ui.iconset.classic; type=osgi.bundle; version=“[4.0.0.M1,4.0.0.M1]”; resolution:=mandatory [caused by: Unable to resolve org.openhab.ui.iconset.classic/4.0.0.M1: missing requirement [org.openhab.ui.iconset.classic/4.0.0.M1] osgi.wiring.package; filter:=“(osgi.wiring.package=org.openhab.core.i18n)” [caused by: Unable to resolve org.openhab.core/4.0.0.M1: missing requirement [org.openhab.core/4.0.0.M1] osgi.ee; filter:=“(&(osgi.ee=JavaSE)(version=17))”]]]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:433) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:420) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:374) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:256) ~[?:?]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) ~[?:?]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve openhab-runtime-ui/4.0.0.M1: missing requirement [openhab-runtime-ui/4.0.0.M1] osgi.identity; osgi.identity=org.openhab.ui.iconset.classic; type=osgi.bundle; version=“[4.0.0.M1,4.0.0.M1]”; resolution:=mandatory [caused by: Unable to resolve org.openhab.ui.iconset.classic/4.0.0.M1: missing requirement [org.openhab.ui.iconset.classic/4.0.0.M1] osgi.wiring.package; filter:=“(osgi.wiring.package=org.openhab.core.i18n)” [caused by: Unable to resolve org.openhab.core/4.0.0.M1: missing requirement [org.openhab.core/4.0.0.M1] osgi.ee; filter:=“(&(osgi.ee=JavaSE)(version=17))”]]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
... 12 more
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve org.openhab.ui.iconset.classic/4.0.0.M1: missing requirement [org.openhab.ui.iconset.classic/4.0.0.M1] osgi.wiring.package; filter:=“(osgi.wiring.package=org.openhab.core.i18n)” [caused by: Unable to resolve org.openhab.core/4.0.0.M1: missing requirement [org.openhab.core/4.0.0.M1] osgi.ee; filter:=“(&(osgi.ee=JavaSE)(version=17))”]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
... 12 more
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve org.openhab.core/4.0.0.M1: missing requirement [org.openhab.core/4.0.0.M1] osgi.ee; filter:=“(&(osgi.ee=JavaSE)(version=17))”
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
... 12 more
Macht einfach kein Spaß mehr. Die Folge der geschätzt fünfte Neuaufbau in drei Jahren…
Ich wünsche euch noch viel Spaß mit eurer Baustelle, produktiv kann man das nicht einsetzen.
Mfg
Rolf
The version you installed is not yet intended to be used in a production environment…
Installing 4.0.0M1 requires Java 17 to be installed which seems not to be the case for your environment.
4 Likes
dear I upgrade OH from 3.4 to 4 milestone
first i upgrade java version
result oh java and javac version are the following
OH:~$ java --version
java 17.0.6 2023-01-17 LTS
Java™ SE Runtime Environment (build 17.0.6+9-LTS-190)
Java HotSpot™ 64-Bit Server VM (build 17.0.6+9-LTS-190, mixed mode, sharing)
OH:~$
OH:~$ javac --version
javac 17.0.6
the result of echo $JAVA_HOME is
/usr/lib/jvm/jdk-17/bin/
the log reports
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve org.openhab.core/4.0.0.M1: missing requirement [org.openhab.core/4.0.0.M1] osgi.ee; filter:=“(&(osgi.ee=JavaSE)(version=17))”
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341) ~[org.eclipse.osgi-3.18.0.jar:?]
… 12 more
I have changed also setted the path with the following commands
sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/YOUR_JAVA_VERSION/bin/java 1
sudo update-alternatives --install /usr/bin/java javac /usr/lib/jvm/YOUR_JAVA_VERSION/bin/javac 1
but i noticed that if i reboot the system, after the $JAVA_HOME returns the old one related to zulu11
where I’m wrong?
I have no problem because I have anoter VM with OH4 latest snapshot that is running wonderful without error, but i prefer to mantain also a second one in case that the one with the latest snapshot crashes
Looks like the environment variable is set in a profile which is sourced during login.
Check the if it is defined in the users home directory in .* files or files located in /etc/.
Try to find the file using:
find ${HOME} /etc -type f -exec grep -l JAVA_HOME {} \; 2>/dev/null
This will look into the logged in user’s home directory and in /etc/.
Hello, I have suddenly the same Problem, but I’m not sure why…
I did today the usual update with openhabian-config and after that I got that problems running openhab, I got the same problem with apache as written above.
I’m on the OH3 stable branch:
but I have absolutely no Idea what it means with “custom version” or “some other version”, I always did updates through openhabian-config and I always was on this branch.
Before the Update today morning, I was on the version 3.4.2 but after the update, it seems I’m on the version 4.0.0:
How could that happen? How can I return back to latest 3.4.2?
I don’t think that I can run 4.0.0, as I have still Debian 10 (buster) and OpenJDK 17 is not able to install on this system:
In my openhab.list I have:
Is this right or wrong for OH3.4.2?
Thanks for help!
It means you are not running the release version of openHABian. You are running some other branch. If you want to keep up with development of openHABian, I recommend sticking with “release”.
You are configured to run the latest release of OH. OH 4.0 was release this weekend. If you did not want to upgrade when OH releases new versions you would need to fix the version number. I don’t know if that can be done in openHABian which is always going to give you the latest version of whatever branch of OH you are running: release, testing, snapshot.
sudo apt-mark hold openhab-3.4.2
sudo apt upgrade
I think that’s how it’s listed. You should do an apt-cache search openhab if that doesn’t work.
That does seem to be the case for most.
It’s definitely right. It’s just 3.4.2 isn’t the latest release any more. It’s been replaced (three times over, the latest OH 3 is 3.4.4, and as I said OH 4.0.0 was release this weekend).
3 Likes
Ok, thanks for the reply, I will try 3.4.4, currently I have this:
openhabian@openhab:~ $ sudo apt-cache search openhab
openhab-addons - openhab-addons
openhab - openhab
openhab2-addons - openhab2-addons
openhab2-addons-legacy - openhab2-addons-legacy
openhab2 - openhab2
openhabian@openhab:~ $ sudo apt search openhab
Sorting… Done
Full Text Search… Done
openhab/stable,now 4.0.0-1 all [installed]
openhabopenhab-addons/stable,now 4.0.0-1 all [installed]
openhab-addonsopenhab2/stable 2.5.12-1 all
openhab2openhab2-addons/stable 2.5.12-1 all
openhab2-addonsopenhab2-addons-legacy/stable 2.5.3-1 all
openhab2-addons-legacy
So I will try to stick to 3.4.4, I assume I need to do this with the addons also?
Edit: That one does not work:
openhabian@openhab:~ $ sudo apt-mark hold openhab-3.4.4
E: Unable to locate package openhab-3.4.4
Actually, it looks like 3.4.5 was just released.
Use apt-cache showpkg openhab
I don’t know if the add-ons need to be installed or not. If it is then OH I think doesn’t download from the internet when installing add-ons and instead grabs it from the installed package. If you’ve installed the add-ons package, you’ll probably want to fix that package too.
1 Like
Ok, it seems I managed to get it run 
First I downgraded openhab:
openhabian@openhab:~ $ sudo apt-get install openhab=3.4.5-1
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
raspi-gpio raspinfo
Use ‘sudo apt autoremove’ to remove them.
The following held packages will be changed:
openhab
The following packages will be DOWNGRADED:
openhab
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 21 not upgraded.
Need to get 104 MB of archives.
After this operation, 129 kB of additional disk space will be used.
Do you want to continue? [Y/n]
…
Then the same with openhab-addons:
openhabian@openhab:~ $ sudo apt-get install openhab-addons=3.4.5-1
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
raspi-gpio raspinfo
Use ‘sudo apt autoremove’ to remove them.
The following packages will be DOWNGRADED:
openhab-addons
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 22 not upgraded.
Need to get 378 MB of archives.
After this operation, 15.4 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 JFrog stable/main armhf openhab-addons all 3.4.5-1 [378 MB]
Fetched 378 MB in 1min 1s (6,233 kB/s)
dpkg: warning: downgrading openhab-addons from 4.0.0-1 to 3.4.5-1
(Reading database … 63738 files and directories currently installed.)
Preparing to unpack …/openhab-addons_3.4.5-1_all.deb …
Unpacking openhab-addons (3.4.5-1) over (4.0.0-1) …
Setting up openhab-addons (3.4.5-1) …
Updating FireMotD available updates count …
Then I set both on hold:
openhabian@openhab:~ $ sudo apt-mark hold openhab
openhab set on hold.
openhabian@openhab:~ $ sudo apt-mark hold openhab-addons
openhab-addons set on hold.
openhabian@openhab:~ $ sudo apt-mark showhold
openhab
openhab-addons
Now everything works fine again, thanks a lot! 
3 Likes
Worked for me too:
Just mark your openHAB version hold to prevent apt from upgrading it.
Yes, I didn’t mention
sudo apt-mark hold openhab
Do I have to repeat this after every new start of the system?
No!
The same upgrade to 4.0 happened to me. I followed Panicman’s advice, but no joy. In final desperation, I went to my backup “tapes” from a week earlier and restored all openhab directories. That worked. Then I locked version 3.4 down as per Panicman’s advice.
Worked for me too! At the beginning of the week, I went to do my usual update and suddenly found myself going from 3.4.5 to 4.0.2 and the system stopped working. Thanks to Rich Koshak and thanks to you for posting your solution steps here. Got my system back up and running again. 
Will now put my OH3 production systems on hold to prevent this from happening on them!
Unfortunately it didn’t remember „on hold“ after reboot
Update:
I have to correct my message. It happened after the manually update from 3.4.4-2 to 3.4.5-1
To avoid this in the future I have written a system script to run the hold statement before starting a weekly script to automatically run an system update.
1 Like