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.
@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.
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.
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?
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.
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.
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.
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
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?
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.
User is always the major error of systems - mea culpa
Can we focus to find a workaround to rescue my system?
Is there any option to bulid a new openhabian from scratch with version 4.0.0?
I have several backups!
When 4.0.0 is up and runing I can delete missing “org.connectorio.addons.ui.iconify” and migrate again … seeing what happens
Or not… old system is full working an backup restore is tested (i do it all the times!)
I already suggested reinstalling right in my first post.
Use a fresh SD so you have your old system as a fallback.
Should you need to install 3.X, search the forum for the OH4 migration FAQ first.
Else just ex- and import your config via openhABian menu or openhab-cli.
