Openhabian broke on latest update

Setup, Configuration and Use Migration
1

A long time ago I installed Openhabian with OH2 on a raspberry pi. I later upgraded to OH3 through openhab-config after it became available, and it worked fine. I upgraded again in the same way yesterday, and now it looks like almost nothing works. Rules do not trigger, the Android app does not find my server, and the web interface does not work. I have tried cleaning the cache and rebooting, but it doesn’t help. This is the full contents of /var/log/openhab/openhab.log:

2023-04-11 12:43:53.387 [ERROR] [ternal.service.BootFeaturesInstaller] - Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error:
	Error downloading mvn:org.apache.karaf.wrapper/org.apache.karaf.wrapper.core/4.3.7
	at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:91) ~[?:?]
	at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72) ~[?:?]
	at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457) ~[?:?]
	at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452) ~[?:?]
	at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224) ~[?:?]
	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399) ~[?:?]
	at org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121) ~[?:?]
	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) ~[?:?]
	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) [?:?]
	Suppressed: java.io.IOException: Error downloading mvn:org.apache.karaf.wrapper/org.apache.karaf.wrapper.core/4.3.7
		at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77) ~[?:?]
		at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
		at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
		at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
		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: java.io.IOException: Error resolving artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.3.7: [Could not find artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.3.7 in openhab (https://openhab.jfrog.io/openhab/libs-release/)]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.configureIOException(AetherBasedResolver.java:803) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:774) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
		at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:52) ~[?:?]
		at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60) ~[?:?]
		... 6 more
		Suppressed: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.3.7 in openhab (https://openhab.jfrog.io/openhab/libs-release/)
			at shaded.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:48) ~[?:?]
			at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:368) ~[?:?]
			at shaded.org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75) ~[?:?]
			at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:642) ~[?:?]
			at shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262) ~[?:?]
			at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:489) ~[?:?]
			at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:390) ~[?:?]
			at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215) ~[?:?]
			at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192) ~[?:?]
			at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247) ~[?:?]
			at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
			at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
			at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
			at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
			at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:52) ~[?:?]
			at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60) ~[?:?]
			at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
			at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
			at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
			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: shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Error resolving artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.3.7
		at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:413) ~[?:?]
		at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:215) ~[?:?]
		at shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:192) ~[?:?]
		at shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:247) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:767) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:657) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598) ~[?:?]
		at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:565) ~[?:?]
		at org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:52) ~[?:?]
		at org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60) ~[?:?]
		... 6 more

I did some searching, and the only relevant thing I found was someone with the wrong Java version, who was told to ensure that they ran on Java 11. Which it appears I do:

$ java --version
openjdk 11.0.13 2021-10-19 LTS
OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
OpenJDK Client VM Zulu11.52+13-CA (build 11.0.13+8-LTS, mixed mode)

As mentioned above, I upgraded with openhab-config, and I am still able to open it. If I open the menu item to select branch, it claims I am on “some other version you fetched yourself”, which seems wrong. If I try to select “release”, it fails and give the following message:

There was an error or interruption during the execution of:
  "01 | Select Branch"

Please try again. If the error persists, please read
/opt/openhabian/docs/openhabian-DEBUG.md or
https://github.com/openhab/openhabian/blob/main/docs/openhabian-DEBUG.md how
to proceed.

The command line prints:

 $ sudo openhabian-config
2023-04-11_20:35:46_CEST [openHABian] Checking for root privileges... OK
2023-04-11_20:35:47_CEST [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
2023-04-11_20:35:47_CEST [openHABian] openHABian configuration tool version: []{}()
2023-04-11_20:35:47_CEST [openHABian] Checking for changes in origin branch openHAB3... fatal: not in a git directory
FAILED (git email)
2023-04-11_20:35:47_CEST [openHABian] Adding slightly tuned bash configuration files to system... OK
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
2023-04-11_20:37:32_CEST [openHABian] Updating myself... fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
mv: cannot stat '/opt/openhabian/docs/NEWS.md': No such file or directory
FAILED (update git repo)
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian
fatal: detected dubious ownership in repository at '/opt/openhabian'
To add an exception for this directory, call:

        git config --global --add safe.directory /opt/openhabian

I really have no idea how to fix this, and I really don’t want to reinstall everything. Is someone able to parse what the problem is from the log? Or have some suggestions for what to try?

2

OH 4 required Java 17. Which version did you upgrade to?

3

3.4.2 it looks like:

$ openhab-cli info

Version:     3.4.2 (Build)
4

OK, then Java 11 is correct. So that’s not the problem.

git has changed behavior since you installed openHABian and it’s failing to update because of the file ownership of the /opt/openhabian. You can maker that error go away by running the command it’s printing to ignore that folder.

Once that’s fixed openHABian should be able to update itself and perhaps it can do additional required setup steps this version might not implement.

If that doesn’t work all I can recommend is to follow the instructions in message and read and follow the debug instructions.

5

I did run the git command before opening this thread, and it didn’t help, but obviously that’s because i ran openhabian-config as root with sudo and the git command as my own user. Running the git command with sudo got rid of that terminal output from openhabian-config, and set the branch back to “release”, but it did not fix anything else. It is still broken. I did try to clean the cache and reboot again, just to be sure.

The system is fully upgraded through openhabian-config, I ran the “Packages”, “System Tweaks” and “Fix Permissions” items from the menu too.

But the log still has the same error message, rules do not trigger, the app does not find the server, and the web interface still doesn’t work.

6

what’s the content of /etc/os-release?

7 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
8

I’ve never coded anything in Java, so I’m not familiar with the details of the language, but this part of the error message seems important:

Caused by: java.io.IOException: Error resolving artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.3.7: [Could not find artifact org.apache.karaf.wrapper:org.apache.karaf.wrapper.core:jar:4.3.7 in openhab (https://openhab.jfrog.io/openhab/libs-release/)]

Is it missing a jar file somewhere? Is there a version mismatch?

9

Well, the first problem is, you’re still on buster (this is oldstable branch of debian/raspbian).

Now, as your openHAB is broken anyway, the question is: better repair or better renew.

steps needed for repair: make sure your system is up to date - i.e.

sudo apt update && sudo apt -y full-upgrade
reboot

Then change to bullseye:

sudo nano /etc/apt/sources.list

change every appearance from buster to bullseye. Save.
Repeat update:

sudo apt update && sudo apt -y full-upgrade

Be prepared for a long upgrade (like 600 packets to upgrade)
Don’t forget to reboot afterwards, as also the kernel was changed.

After that, you’ should be on Raspberry Pi OS - bullseye.
Try to reinstall openHAB via openhabian-config, this may or may not work.

The other option (with sort of guarantee of success):
Backup your configuration (try to use sudo openhab-cli backup first), copy the created zip file to a safe place, create a new SD-Card with the current openHABian Image 1.7.5 - best option is Pi Imager → Choose OS → Other specific-purpose OS → Home assistants and home automation → openHAB → openHABian (Raspberry Pi OS lite 32 bit)
Afterwards, copy the backup file to the first partition (the one which is visible from Windows) and name it initial.zip.
Switch the card to your Raspberry and startup. Wait (something like 20 Minutes, depending on your internet connection.and the Pi model)
Get into your openHAB with all old settings…

If you can’t get the backup process to work, save the directories manually, this is:
/etc/openhab/, /var/lib/openhab/ and /usr/share/openhab/addons/
As you have no zip file, you will have to stop openHAB after initial startup and copy the files manually to the correct Directories, only problem is, you won’t need all files from the formerly saved directories (but the most of them).

10

Thanks Udo, I’ll give it a shot. :slight_smile: However, this does raise a few questions…

  1. Why was the openhabian image set up with a release codename instead of a running distribution like stable? It seems bound to cause problems down the road, especially when it isn’t automatically updated according to needs.

  2. Why did the openhabian-config update process not ensure that the release it upgrades to is compatible with whatever distribution is used, or ensure that the distribution is updated as required? After all, openhabian is described as follows: “The Raspberry Pi is quite a famous platform for openHAB. However, setting up a fully working Linux system with all recommended packages and openHAB recommendations is a boring task, takes a lot of time and Linux newcomers are challenged in a number of ways although all they want is to run openHAB and not some server.” With the additional catch phrase: A home automation enthusiast doesn’t have to be a Linux enthusiast!

  3. I would expect misalignment in versioning to appear as unresolvable package dependencies in apt (or some additional check in the openhabian-config wrapping of it), and not as what appears to be error messages in the openhab log about jar files missing from openhab itself. Don’t misunderstand though, I’m not saying I think you’re wrong to suspect that this is the problem, but I am saying that it is surprising behavior that someone should look into.

11

There is no such thing as “stable Debian”. There are long term supported releases of the OS and short term supported releases. Each release has a code name. You can update within a codename up to the point where Debian drops support at which point no more updates, not even security updates.

Typically it is recommended against upgrading a Debian operating system from one codename version to another. Debian provides no tools to do this for you, it’s unsupported, often takes longer than it would take to burn a new SD with the new OS and set it up again, and it doesn’t always work.

In short, you can’t just set the repo to “stable” and forever remain updated. Eventually you will have to upgrade, either with a fresh install or through the process @Udo_Hartmann outlines, or remain running on an unsupported and increasingly vulnerable OS.

I’m not convinced that’s the original problem. However, you won’t go wrong moving to the new OS release and in the process you likely will solve what ever the original problem was. But even if it was, the answer to your question is in the docs for openHABian.

We expect you to use the current stable distribution ‘bullseye’ for Debian (x86). The current Raspberry Pi image is based on this, too. To install openHABian on anything older or newer may work or not. If you do and encounter issues, you may need to upgrade first or to live with the consequences of running an OS on the edge of software development.

There are far too many variables for openHABian to know when it will work or not. So either they can lock it down and make it only run on the one OS supported and refuse to work on anything else (which will cause people to complain mightily) or make a best effort to run and if it fails, offer a path to make it work.

And as already discussed, it can’t to the full OS upgrade from one to the next. That is not something you want to run unattended and automatically.

Me too which is why I’m not convinced this is necessarily the problem. But we can spend hours trying to figure out what the problem is (which frankly will require some Java and Linux expertise) or move to the new OS which I’m confident will fix the problem in the process anyway.

The error itself comes from OH attempting to find and download a version of a library from http://openhab.jfrong.io. Looking there and indeed, that library isn’t hosted there. Why is your install looking for a library that isn’t part of OH any more? :person_shrugging: Why isn’t that library hosted on jfrog any more? :person_shrugging: What does this library even do? :person_shrugging: We could spend the time researching this. all of these questions do have answers. But is it worth it? Especially since you will have to move to Raspberry Pi OS Bullseye sooner rather than later anyway and in the process you’ll get a fresh install of openHAB which likely solves the problem.

12

There is no such thing as “stable Debian”.

I’m sorry, but you’ve got that wrong. There are three main distributions of debian: stable, testing and unstable. The codenames, jessie, stretch, buster, bullseye, etc, are symbolic links that change as new releases are created. At any given time, one codename points to the stable distribution (currently bullseye), one points to the testing distribution (currently bookworm), and one points to the unstable distribution (always sid). In addition, buster points to the oldstable distribution, and there is an additional experimental distribution, and I also think there’s an oldoldstable pointed to by stretch, but that’s beside the point. The point is that there is such a thing as “stable Debian.” If you’re interested, the Debian docs have some more in-depth information: Chapter 6. The Debian archives

Typically it is recommended against upgrading a Debian operating system from one codename version to another. Debian provides no tools to do this for you, it’s unsupported, often takes longer than it would take to burn a new SD with the new OS and set it up again, and it doesn’t always work.

Upgrading from one release to another, even when using codenames, is completely standard and simple, and described, among other places, here: DebianUpgrade - Debian Wiki However, upgrading further than to the next release, skipping one or more in the process, is not recommended.

My main computer is running Debian testing, directly without referencing codenames/releases. It has been through multiple cross release upgrades. I’ve had other older computers that have gone through the same process, all the way from lenny or so onwards, some running on stable, some running on testing, some using codenamed releases, some just pointing to stable or testing directly. It works just fine.

There are far too many variables for openHABian to know when it will work or not.

Sure, if I manually installed openhab on some ancient Debian version, I wouldn’t be surprised to run into trouble. But this was an official vanilla openhabian image based on buster, before it switched to using bullseye.

And as already discussed, it can’t to the full OS upgrade from one to the next. That is not something you want to run unattended and automatically.

It can, but release upgrade could also be a controlled and deliberate process from the openhabian-config scripts.

Me too which is why I’m not convinced this is necessarily the problem. But we can spend hours trying to figure out what the problem is (which frankly will require some Java and Linux expertise) or move to the new OS which I’m confident will fix the problem in the process anyway.

It’s probably not important, because it seems like we won’t figure out what the problem is anyway, but although I’m not an expert, I do have some Linux expertise, having used Debian based Linux as my main computer both at work and at home for the last 20 years or so. I also have a fair amount of experience with programming, although my main line of work is designing hardware with SystemVerilog. I just don’t have any particular experience with Java, which makes it hard for me to parse the error messages.

Also, it might not have been clear from the start, but I don’t have any kind of Frankenstein’s monster of an openhab install. As I mentioned above, I installed the official openhabian image back when it was still using buster, so this is simply a case of openhab breaking its own back through perfectly normal use of the built-in upgrade process. Which is surprising.

Thing is, I don’t find clean-installing operating systems on raspberry pis and reconfiguring my home automation system particularly rewarding. So I’m giving the release upgrade a shot first.

13

I should have been more specific. Raspberry Pi OS, which is not actually Debian Is what openHABian is built on.

And what I’ve said is true of Raspberry Pi OS. The two are so close it’s easy to fall into the habit of referring to the two as one in the same but they are not.

And frankly it may not still be true on Raspberry Pi OS either. But I do know that when I updated four of my RPis from Buster to Bullseye all the docs and all the forums said don’t do it, install fresh instead but if you must… And indeed, only three of the four actually worked and the third had to be reinstalled from scratch.