Moving Cloned OH2.x RPi4B SD Card to new RPi4B faild

Hello,
My openHAB 2.5.x Z-Wave system built on a RPi4B is, and has been running fine for a long time.
In an attempt to build a backup unit (cold redundancy) a new RPi4B was purchased.
The prod SD Card was cloned and plugged into the new RPi, BUT to my surprise did not boot.
The following screen appared:

A lengthy search found the two RPi4Bs to have different hardware revisien. The old was 1.1, while the new was 1.5, which indicates physical difference(s).
To my surprise OH3 loaded fine on the new RPi which indicates a good RPi, but I’m not ready for OH3 yet.
Anyone seen this and/or have suggestions on how to fix it? Is a newer OH boot required for RPi4B rev 1.5 or…?
Bjorn

Install a fresh openHABian with OH2 and import your old config.
Then use openHABian’s SD mirroring to clone the card.

Thanks Markus,
I tried your suggested approach - first line - without success. I loaded openhabian v 1.7.3 to SD (or should I have used 1.6.6) with openhabian.conf set to “stable” and “initial.zip”, and with “initial.zip” file in boot directory.
putty showed OH 2.5.12 after boot, but directories are missing (ex: /var/lib/openhab2/backup).
All my files are also missing (.rules etc.) from etc directory (maybe the whole backup?).
I’m using WinSCP for insight.

Where do I go wrong?
Also, in case I need it: What is the latest PURE OH2.x openhabian image (without OH3) and where can I find it?

Bjorn

Of course, it’s a new install !? As I said import your old config.

There isn’t any.

Markus,
Sorry, maybe I misunderstand, but my old system backup file (initial.zip) was added to openhabian.conf and the boot directory, and should consequently have been part of the installation - or am I missing something?

And again, do you or anyone else know why an OH2.5.x SD card running pefectly well on RPi4B v1.1 does not boot on a RPi4B v1.5. I would love to understand why
Bjorn.

You can interactively import it after install from the menu (need to place it to /var/lib/openhab/backups/ to make it show up.

There’s a gazillion of potential explanations. Without logs, it’s impossible to tell what’s going on.

Markus,

Yes, there are no logs, just the picture in post 1 which points to a boot issue?
Let me know if you stumble across someone who might know more about this.
Bjorn

According to your screenshot the firmware or parts of the bootloader are not compatible with your v1.5 pi.
See e.g. Raspberry Pi 4B firmware + BOOT (SOLVED) - Raspberry Pi Forums

Thanks, enlightening!

If i understand correctly this is an OH2 issue since OH3 boots fine on v1.5.
Can anything be done to fix this? There must be thousands out there still running OH2 who would love to have a plug and play backup in place and enjoy a good night sleep.
RPi v1.1 to 1.4 is no longer available.

Nah. Firmware has nothing to do with the OH version.
As @Wolfgang_S said the OS on the SD you use is not compatible with your RPi.
As I already advised, install from scratch and import your old config. That’ll give you the latest OS which will work with your current RPI and its firmware.

Thanks Markus,

Your point is and was well taken and I’m now exploring the OH3 Z-Wave consequences.
It will probably require some experimenting/adjustments affecting 24/7 ops and even worse if I do something terribly wrong. Also I need to keep OH2 as a failback option. Therefore I’m rushing slowly to avoid a crash landing.

Really? I advised to reinstall latest openHABian not latest OH3. You can install latest openHABian with either OH2 or OH3 so no need to explore OH2->3 migration consequences for this step

Markus,

I hear you, your’e right. Bad wording! I already have OH3->OH2 running fine without the the Stick.
So, I am just exploring the consequences of going all the way to OH3 before I decide.

Markus,
One more quick (a bit off topic, sorry) question please:
I’ve been using WinSCP without issues since I started to play with OH1.x way back.
When transferring files to OH3->2 now, WinSCP gives me the error:
image
The file transfers OK, but on the OH side the Timestamp is altered to time of arrival in OH, which generates confusion.
I have no clue why and how to fix it (~zero unix knowledge).
Do you?

Sorry, but no sorry I’m not into your or anyone’s general Linux education. There’s more than enough resources available for that on the net.

Wow!!!
Did I ask for Linux education? Don’t think so!
WinSCP has worked for years with OH2. Moving to OH3->2 led to issue!
WinSCP has not changed, so has OH3>2 permission strategy changed ?
Of all maintainers I thought you would be the one to know?
But thanks for your reply.

What are the settings that you use to copy the files ?
There should be a log of the winscp session. Would you mind to share the details of that logging file ?

Hi Wolfgang,
Thanks for responding,
Here is the log of WinSCP startup, copy 1 file to OH and Shutdown.
29220501-WinSCP-Copy-1-File.log (12.0 KB)
Can you make any sense of it?
Bjorn

Timestamp of the file cannot be preserved because files are copied as user openhabian while the file in the target directory is being owned by user openhab.
Timestamp can be preserved either by copying the file as user openhab or by changing the owner in the target directory to user openhabian ( the later could cause other issues with regard to permissions ).

Hi Wolfgang and thanks a million.
This is a bit strange because putty shows the following user at startup: Using username “openhabian”., which works.
So where does user openhab come from that WinSCP sees? Is it a OH3 replacement for openhabian, or are there more than 1 users for an OH3>OH2 instance with my old OH2 Backup restored on top, also with openhabian - for now?
Sorry to bother you, but any ideas?