After Migration from 4.0.0 to 4.1.1 openhab totaly down is in Nirvana / working with openhabian

Setup, Configuration and Use Migration
1

Dear all, after update openhab 4.0.0 to openhab 4.1.1

cat /var/lib/openhab/etc/version.properties 4.0
openHAB Distribution Version Information

build-no : Release Build
online-repo : JFrog

Repository Version

openhab-distro : 4.0.0
openhab-core : 4.0.0
openhab-addons : 4.0.0
karaf : 4.4.3

cat /var/lib/openhab/etc/version.properties 4.1
openHAB Distribution Version Information

build-no : Release Build
online-repo : JFrog

Repository Version

openhab-distro : 4.1.1
openhab-core : 4.1.1
openhab-addons : 4.1.1
karaf : 4.4.4

My system doesn´t have a UI and many more ERRORS:
for Example:

024-02-01 20:45:45.530 [ERROR] [Events.Framework ] - FrameworkEvent ERROR org.osgi.framework.BundleException: Could not resolve module: org.connectorio.addons.ui.iconify [245] Unresolved requirement: Import-Package: org.openhab.core.i18n; version=“[3.0.0,4.0.0)”

2024-02-01 20:51:23.806 [ERROR] [unication.SonoffCommunicationManager] - Cannot send command uiActive, all connections are offline for deviceid 1000bcd8fd

2024-01-15 17:02:54.290 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed to refresh bundles after processing config update
java.lang.IllegalStateException: Resource has no uri
at org.apache.karaf.features.internal.service.Deployer.getBundleInputStream(Deployer.java:1631) ~[?:?]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:904) ~[?:?]
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:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]

2024-01-15 16:39:41.765 [ERROR] [unication.SonoffCommunicationManager] - Cannot send command uiActive, all connections are offline for deviceid 1000bcd8fd

2024-01-15 16:41:04.510 [WARN ] [rd.internal.AriesJaxrsServiceRuntime] - Application CachingServiceReference {
cachedProperties={osgi.jaxrs.application.select=null (cached), osgi.jaxrs.application.base=/api, service.id=1565, application.ready.service.filter=null (cached), objectClass=[javax.ws.rs.core.Application], service.scope=singleton, osgi.jaxrs.name=null (cached), osgi.jaxrs.extension.select=null (cached), osgi.http.whiteboard.context.select=null (cached), osgi.jaxrs.whiteboard.target=null (cached), service.bundleid=325}
serviceReference={javax.ws.rs.core.Application}={osgi.jaxrs.application.base=/api, service.id=1565, service.bundleid=325, service.scope=singleton}
} is registered with error
2024-01-15 16:41:04.519 [INFO ] [ulation.internal.HueEmulationService] - Hue Emulation service available under /api
2024-01-15 16:41:04.542 [WARN ] [rd.internal.AriesJaxrsServiceRuntime] - Errored application CachingServiceReference {
cachedProperties={osgi.jaxrs.application.select=null (cached), osgi.jaxrs.application.base=/api, service.id=1565, application.ready.service.filter=null (cached), objectClass=[javax.ws.rs.core.Application], service.scope=singleton, osgi.jaxrs.name=null (cached), osgi.jaxrs.extension.select=null (cached), osgi.http.whiteboard.context.select=null (cached), osgi.jaxrs.whiteboard.target=null (cached), service.bundleid=325}
serviceReference={javax.ws.rs.core.Application}={osgi.jaxrs.application.base=/api, service.id=1565, service.bundleid=325, service.scope=singleton}
} is gone

and so on and on…
All “old” sugesstions for restart an upgrade are done:
sudo rm -rf /var/lib/openhab/tmp/*
.sudo rm -rf /var/lib/openhab/cache/*
Restart and and (I´m using Openhab since 1.7!!)

Nothing help!

It´s aopenhabian installtion based on 3.3 with an upgrade to 4.0 (BTW in this migration the heating systme loos all Values!)

What can I do to bring my system back to work. in case of the given limitation that Fallback is still not available (nightmare!)
Please give my some instructions to fix

Many thanks to veryone

Hardwaresystem:
on Rapsian “bullseye”:

PRETTY_NAME=“Raspbian GNU/Linux 11 (bullseye)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“11”
VERSION=“11 (bullseye)”
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL=“http://www.raspbian.org/”
SUPPORT_URL=“RaspbianForums - Raspbian”
BUG_REPORT_URL=“RaspbianBugs - Raspbian”

on aRaspberry pi 3B

System is runing on a SSD

Thank you for any hint an tip

Cheers
Stefan

2

We don’t support openHABian running off SSD. The docs are quite explicit on this, aren’t they.

So advice is to reinstall with a standard SD based setup and import your config.

3

You have OH3 addon which interferes with OH4. Please remove this addon, let OH boot fully and then install fresh version of addon.

4

Unfortunately, I also have no idea what the cause could be.
But for the future, I can only recommend that you ALWAYS make a backup
before an upgrade and then boot from the backup system - so that you can go back to the original system immediately in the case of problems.

And this is very well supported when using SD cards.
It may work the same way with SSDs - you just need at least a second SSD to back up to before upgrade.
With SD cards, this would be easy and cheap in any case and, as M.Stormi also wrote, it is supported.

I hope you get the problem under control quickly. :+1:

5

An interesting point. Perhaps we need to make some sort of formal versioning system for add-ons to avoid this very case. i.e. Addons need to have some sort of manifest to mark maximum version and OSGi (or openhab) wouldn’t proceed to load it if this is violated.

I thought that there’s already something like this built in somehow, but I’m not too familiar with how it all works.

6

Cause is shown in logs which are attached:

The iconify addon (which I made and published over marketplace) is bound to OH3 while OP activated OH4. I believe he just need to remove this addon for update time and bring back another version when he is done with update.

Issue has nothing to do with SD or SSD, its hardly to call it update issue since it happens in polluted conditions.

The addons/ folder is a special case as it is pulled by Apache Karaf/Felix Fileinstall itself. It functions as hot deployment directory, beyond direct control of openHAB. However all fileinstall does for us (in case of OH) is getting JARs/KARs and calling bundle.install(uri_of_the_file) or karService.install(..).

There are decade old utilities which could permit static validation of manifest entries. However for a start I’d simply advice to just move installation of third party addons to a separate thread which does not interfere with boot/framework thread.

7

@splatch
Yes, it’s clear: this has nothing to do with the SDD/SDC.
But it is always a good idea to create an executable full backup beforehand so that you can fall back on it in an emergency. And this is only sure supported with SD-Cards.
That’s all I wanted to say. :wink:

8

Right, but any deviation from the default and particularly so on hardware level (SSD) contributes to pollution. And to support “polluted” installations is what every supporter hates doing.

Hence my advice to reinstall, it’s the quickest way out.
Check out the OH4 migration FAQ thread. And re-start without SSD so you will be owning an officially supported system next time, else you will find way less volunteers able and willing to support you now and in the future.

9

I totally understand that the only supported configuration for openhabian is through SD Card. That is made absolutely crystal clear in the documentation.

However, generally speaking and putting openhabian aside, wouldn’t a raspberry pi + SSD boot be a lot more reliable than using an SD card for an unattended 24/7 linux installation?

Also if I understand correctly, doesn’t Rpi5 now support M.2 SSD and that would probably become people’s preference or at least a legitimate choice in the future?

https://www.howtogeek.com/raspberry-pi-5-ssd-adapter/

https://liliputing.com/add-an-m-2-nvme-drive-to-a-raspberry-pi-5-with-waveshares-9-adapter/

1 Like
10

I second this. I already have an NVMeBase attached to my Pi5 and I am happy with this solution. Furthermore I decided for a manual install so that I can make use of bookworm.
It is like you said, it would be good for openhab if openhabian supported SSD. On top of that let‘s also keep in mind our discussion in the home assistant thread or our marketing thread. If potential new users realize that openhab(ian) does not „officially“ support SSDs nowadays that would be reason enough for users to decide against OH.

On the other side I respect stormi‘s decision as the openhabian maintainer not to support SSD for his personal reasons but I do not share this direction.

11

Putting aside that you cannot put that aside as that would turn openHAB unreachable for the majority of people, the answer is a simple No.
(I’m tired of this discussion and won’t join it again, read up here, nothing has changed about that)

No. “People”'s preference is to have a cheap, easy to use turnkey system: the no-frills SD based RPi.
Anything that makes it more complicated and more expensive turns them down.

While rarely people like yourself keep asking for this so far noone has been willing to put the required amount of work into implementing this. SSDs are simply just not implemented/validated to work with openHABian. Note however “implementing” and “validating” doesn’t mean to setup a single instance. It means to ensure, i.e. test and validate that it works with each and every RPi model and other peripheral you want to support, in every combination of hardware openHABian has been supporting, and in combination with every software feature it has been supporting, too (think of mirroring, backup & restore etc).

Evolve your manual installation procedure into a fully parametrized scripted one and validate that it works reliably with all possible SSDs and combinations of HW and SW, turn it into a PR and I’ll happily add it to openHABian provided it that it is in accordance with the coding guidelines.

Oh, and don’t forget to submit vacation to your employer to have the time available it’ll take to help all those people that will be having questions about and problems with using this including all the stuff that’ll come up on upgrades.
My personal decision is I’m not willing to spend any of my personal scarce spare time to help a tiny minority of people accomplish something only they want but noone really needs.
(BTW you two are the only ones I’m aware of that asked for it since that linked thread, i.e. end of '22)
But there is no such “decision” of mine on behalf of openHABian that it cannot become supported.
Just I will not be supporting it. But feel free to join development and make OSS happen.
Or pick and work on any other of the open issues.

So anyone to think along the same lines as Oliver, I’m looking forward to receiving your PRs.
However, if you’re not truely willing to provide any such contribution, please refrain from asking for or promoting it as a presumably good idea. Thank you.

12

I do the best I can and to the best of my knowledge to help users in (other related) issues where help is needed.

Be sure, I gave up on asking, and NO and again NO I will not refrain to talk about this topic whenever I think it is appropriate. It is such a bad style to try to prohibit other opinions. How dare you to decide that your opinion is a better opinion than others‘?
Please feel free to add me to your blocked list or force me again to delete my post what you have already done before.

13

Of couse I have a lot of backups!

I restore the latest → no behaviour change

But in the forum I have read that backups are not helpful, because during the update the database structure changes. So when restore a 4.0 backup there will be a mismatch between stored database and the new structure of 4.1. That’s why I think not having abfallback solution tomstep to 4.0 back with working database and installation is needed … I recommend that since 2.1 when I have the first experience with crash and backups

14

Yes… but how can i remove without working UI.

Is it possible to uninstall with consol?

15

But it works since 2.1

And for what there is a command in openhabian-config to move whole system from SD to SSD?

IMG_0371
IMG_03712160×1620 223 KB

And please explain the different running the whole system on ssd from scratch against running from SD.
What about destroying SD by heave traffic in temp or DSL-rules and and … There are more than a lot entries in the forum, where these errors are based by this issues?

16

You can uninstall it by just moving file from your filesystem. Unless you pull it somehow through marketplace, if so you need to adjust configuration yourself. My suggestion is to look at addons folder first, cause it might retain things across updates. If its empty then look at addons.cfg and comment out iconify icon provider.

17

Which file?

Where is it located?

Even in the backup?

18

I doubt if you will find custom addons in backup. Look at /usr/share/openhab/addons, then contents of addons.conf from /etc/openhab/services/ folder.

19

/usr/share/openhab/addons there aren’t that files

IMG_0372
IMG_03722160×1620 137 KB

Aldo no file in /etc…

IMG_0373
IMG_03732160×1620 248 KB

Where is it?

Or better how is the file named to search for?

Thank you

20

Check contents of addons.cfg.