Openhab installs 64 bit jni lib on 32 bit raspberry pi and breaks jdbc sqlite

Setup, Configuration and Use Installation
1

I figured I would try one more time to look at this problem:

I am on a 32bit kernel and userland.

% getconf LONG_BIT
32
% dpkg --print-architecture
armhf
% file /bin/ls
/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV)

However Openhab is installing 64 bit libaries and breaking sqlite via jdbc.

% file /var/lib/openhab/tmp/sqlite-3.40.0.0-6a46d359-1adb-4f74-aefa-ef4da3b206f7-libsqlitejdbc.so
/var/lib/openhab/tmp/sqlite-3.40.0.0-6a46d359-1adb-4f74-aefa-ef4da3b206f7-libsqlitejdbc.so: **ELF 64-bit LSB shared object,** ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7ff423e65a2507864f56df7200190baaaa671712, stripped

So this will fail with a

`java.lang.UnsatisfiedLinkError: 
/var/lib/openhab/tmp/sqlite-3.40.0.0-54dee8cc-2e9e-4ec2-beb1-00476c6e35f1-libsqlitejdbc.so:
 
/var/lib/openhab/tmp/sqlite-3.40.0.0-54dee8cc-2e9e-4ec2-beb1-00476c6e35f1-libsqlitejdbc.so:
 **wrong ELF class: ELFCLASS64 (Possible cause: architecture word width 
mismatch)`**

Is this a packaging issue or jna issue? I’m not sure where to look to fix it.

— Bill

2

The libsqlitejdbc is being extracted by sqllite jdbc driver: https://github.com/xerial/sqlite-jdbc/blob/3.42.0.0/src/main/java/org/sqlite/util/OSInfo.java#L166

It is not something which is done by openHAB itself. Looking at the sources I think you can influence lookup logic by adding valid entries to system.properties file. Try adding there org.sqlite.osinfo.architecture=armv7 (other options are arm, armv6). You can verify if property is visible to openHAB and code running within it by calling system:property|grep sqlite command.

3

Thanks so much! I filed Incorrect JNI installed for 64 bit raspberry pi that had been auto upgraded from 32 bit. getHardwareName() uses unsupported method to determine arch. · Issue #1012 · xerial/sqlite-jdbc · GitHub (lets see if they fix the issue and it’s not a case of finger pointing at the raspberry pi).
This is because sqlite-jdbc uses arch -m which suddenly started returning aarch64 after routine updating of pi via apt upgrade. The correct way to determine architecture is getconf LONG_BIT according to After updating 32 bit Raspi OS Pi 4 is on 64bit kernel · Issue #1795 · raspberrypi/firmware · GitHub

For others that are having the issue with JDBC sqlite after apt upgrading their raspberry pis, add the following to your /etc/defaults/openhab to fix the problem:

EXTRA_JAVA_OPTS=“-Dorg.sqlite.osinfo.architecture=armv7”
and restart…

You will need to do this if uname -m returns aarch64 while getconf LONG_BIT returns 32.

1 Like
4

The other thing that should work as mentioned in that article:

arm_64bit=0 added tot /boot/config.txt

afterwards reboot and then do the binding installation. Not tested but technically that should work.
Problem is that kernel runs in 64bit mode while the ‘OS’ uses 32 bit.

5

I guess the default for that is “1” because I do not have it set, yet arch -m still says aarch64. Even with that the jvm is 32 bit I think. My dpkg is 32bit by default, but maybe that will load a 64 bit ELF. The entire thing is confusing.
Not sure forcing the cpu to 32bit with a 64bit kernel will even boot. Are you saying that you set arm_64bit=0 (after you were running 64bit) and it booted?
You may need to

sudo apt reinstall raspberrypi-kernel raspberrypi-bootloader -y

to go back to the standard kernel.

This is also the reason karaf prints out the error for /var/lib/openhab/tmp/jansi-2.4.0-3519c95ec2a873f1-libjansi.so when you start it. However in that case their osinfo.java doesn’t provide a system property to override it (there is a case open to fix).

It might be good for somebody to figure out how to run a 64bit jvm on a 32bit userland rpi that is running a 64 bit kernel (if possible). I saw some articles on how to do it, but they were all different and I’m not sure of the side effects of installing 64bit software packages when I try to apt upgrade my way to bookworm.

6

I think at least in one of the threads here in the forum a user had the problem that after the upgrade from buster to bullseye the kernel was at 64bit and the packages installed still ( because that was the case before the upgrade ) were on 32bit.
He then set arm_bit=0 and rebooted.
Afterwards the kernel was rebooted in 32bit mode.
This is also how I read the linked article.

7

Yeah that might happen if you upgraded after bullseye changed midway to 64 bit. It will also happen if you had upgraded to bulleye when it was still a 32bit default (prior to March). Then you only hit the problem when you do a apt upgrade which changes it out from under you.
I’m afraid to set that back to 0 now that I’m running 64 bit. I don’t have time to take an image backup in case it doesn’t boot. If somebody else here tried and it works please post. I’de probably rather stay on 64bit now that it’s the default. I’m just getting tired of overriding jvm options because they don’t agree with how the raspberry pi people want you detect 32bits userland.