hello guys. I just briked my installation on my RPI OH3 going to 4.
I updated yesterday, first thing that happened was that the front end didnt load anylonger.
I guessed it was Java so tried to updated to 17 as per instructions and got repeat failed on the retrieving part of the update.
i then tried to update everything via the config tool and it stopped working all together. Before i could putty into the text interface but now it has stopeed responding.
Good news is I have an old version of SD card image (missing about 6months of changes) which means i can recover at least in part.
could someone with a deeper understanding help me tranfer my rules/devices/etc from the current version? (i have made small changes here and there to rules and added some devices during the past 6 months?)
is there anything besides items/things/rules i might be missing here?
thanks to the cleverer people for the time
(from reading around i see only direct restores etc and am missing the copy file version. That and i am leaving on holiday in less than 48hours so trying to move quickly)
Use openhab-cli backup and restore and that will grab everything. Without knowing how you’ve configured everything it’s impossible to know what exactly you need but in general you need all of /etc/openhab and most of /var/lib/openhab to get a full backup.
Be sure that your new installation is the same version as the old one before running the restore. Then upgrade. Attempting to restore a config across versions, particularly if you have some managed configs, will skip the upgrade process which will leave you a bunch of manual changes to make.
thanks Rich - as always appreciate your taking the time to help- perhaps i didnt explain my position well enough.
I cant opehab-cli backup because the “bricked version 4” doesnt allow me to connect anylonger via putty *i will try actually to connect locally (keyboard and screen - incase it is a network issue)
i can access the SD card of the bricked version by using (on windows) Linux_Reader.exe
I would love to try and recover from the bricked v4.0 the items rules things that i have there by (copying?) the files to the old version.
basically a manual cli backup. my changes are primarily things + rules so i dont think i will loose much otherwise (nothing too complex)
does that make sense? is it indeed the folder you just mentioned in this use case?
But you can on the older backup SD card. I thought you were looking to copy the config from there to a new install.
There is a backup.sh script in the bin folder for OH. You can see if you can run that script. If not you can try to grab everything from those two folders except the /var/lib/openhab/cache and tmp folders and cross your fingers. But you really have no way of know whether those configs were upgraded to 4 or are still 3 so will it work?
But you can on the older backup SD card. I thought you were looking to copy the config from there to a new install.
I have a working version of 3.4.2 (but outdated) so my MVP fix to leave a working system is(as i am about to go on holiday is)
just run with it (seems ok although missing some updates)
run it as is + and update the things items. If this works I can wait for version 4 which is not working for me due to java 17 failing to install ( i guess)
in a perfect world i would clean install 4 and tranfer everything from either 1 or 2 above.
(i could also do a mix of everything but right now as time is the biggest issue. a 3.4.2 version with a quick items/rules/things update would probably serve
then yes i think i will try to do a clean install and transfer things.
(bonus question. the linux version opehabian runs on is the clean install right? - so by a clean install i get the most recent linux version also?)
Well, in fact, Raspberry Pi OS is bookworm since June, and openHABian 1.8 Image is still bullseye, so no, it’s not the latest and greatest…
But both should and will work (and you can install openHABian manually to the clean bookworm Image for convenience).
Raspberry Pi OS is not stock Debian so it usually takes a little bit of time from Debian release and Raspberry Pi OS release, though I expected support to be available before now.
you guys are just teasing my complusion now… do i wait for the new version thanks for the answers. the conclusion for people reading is.
my old openhab version 3.4 was running on a previous linux version (Debian Buster)
the new 4.0 openhab/openhabian needed the newer linux version (Bullseye) to install java 17 which is mandatory.
so the front end crashed due to the incompatibility with java 11. and java 17 wouldn’t install due to incompatibility.
as a bonus the dhcp service crashed during all this (no idea why) so i couldn’t access the RPI remotely but after some sound advice in here i discovered i can access locally (with screen and keyboard)
Using the local access - i managed to backup using openhabian config (backup option menu) , transferred the file using a RPI with Rasberry OS to the new Bulleye SD image and restored. it worked i only had to reinstall ffmpeg and a script for the argon case fan to keep it from working all the time.
Other Raspberry Pi OS (e.g. Stretch and Bullseye) releases have come out 2 and 3 (respectively) months after the Debian release date - so I imagine we may have some more time to wait.
I don’t expect there to be a noticeable day-to-day difference for many openHAB users, RPi OS bullseye is already on the 6.1 Kernel and contains Java 17. (I currently use a Debian bookworm image on my RPi 4 and I’m not sure I can tell!)
Awesome, thanks! I’m planning to get a Pi 5 and do this Bookworm upgrade. One suggestion/question:
Beware that running in 64 bit has a major drawback: increased memory usage.
That is not a good idea on a heavily memory constrained platform like a RPi.
Since there are also 4 GB and 8 GB versions of Pi, perhaps this should be rephrased? Would you agree that >= 4 GB should be fine for the 64 bit version? Perhaps we should even recommend 64 bit for these memory abundant versions, since there are also benefits from that (faster JavaScript warm-up)? For 8 GB it would be counter-productive to go with 32 bit.
No, overall that’s still a valid statement so I don’t want to change it for the time being.
And I’m not convinced that 64bit is the right and final mitigation on that startup issue.
Should rather be fixed in GraalVM or whatever it is that does not work properly with 32bit.
Well, at least I hope we can agree that the statement that a RPi with 8 GB RAM is a “heavily memory contrained platform” is not valid in 2023? I think we can no longer generalize RPi as such since there has been >= 4 GB variants since RPi 4.
So I think there are two separate things at play:
The phrasing itself categorizing RPi generally as “heavily memory constrained”.
The recommendation whether to use 32 bit or 64 bit.
Disregarding the GraalVM issue and looking at the recommendation in general, I understand you still prefer 32 bit. Given an 8 GB RPi, do you see any drawbacks in using the 64 bit version?
Still applies to 95+% of Pis hence people that’s why I want to keep it.
Even most RPi5 buyers will select the smallest memory size so effectively the statement will keep applying.
I’m not seeing any advantage of substance in going 64bit. Drawbacks there’s several.
There have been kernel issues in the near past with process sizes >3.75G that I wouldn’t be sure all have been found and fixed. Given 64bit has not been in widespread use, I’d guess there’s more looming throughout the whole OS. And there’s RAM price of course.
Everybody is of course free to get and use whatever their preference and belief is, but as an overall recommendation to address normal OH users, I’d be doing a disservice to the community if I changed that.
Thanks for clarifying this, I was not aware. If this is still true, even if this is the only reason, that would be one very good reason not to choose 64 bit.
I generally agree but I disagree with some of these assertions.
A 10x + improvement in the first load of JS Scripting rules is hardly an advantage of no substance. Needing to wait 20+ seconds between editing a rule and being able to test that rule would even drive me to another platform. Demanding GraalVM fix it is a non-starter, they never have offered 32-bit builds and who are we to demand they do? And we don’t actually know whether a 32-bit GraalVM will perform better than the 32-bit OpenJDK. That’s just an assumption. But we do know that both the 64-bit GraalVM and the 64-bit OpenJDK runtimes lead to 10x improvements, going from 20+ seconds for a first load of a rule to 2 seconds. This is a significant problem for our users. Refusing to even acknowledge that is pretty end user hostile.
To the contrary I am increasingly finding more and more software, Docker containers, etc. which only offer arm64 builds and do not offer armhf builds at all. Perhaps it’s not to parity with 32-bit yet but it is to the point that I’ve been forced to move two of my RPis to 64-bit because of lack of support for 32-bit builds. In my experience, this assertion is either no longer valid or will not be valid for much longer.
