Unable to install Java 17

Setup, Configuration and Use Migration
,
1

Hi all,

I am unable to install OpenJDK 17 on my Pi which is required for running Openhab 4. The setup fails with the following error message:

The following packages have unmet dependencies:
openjdk-17-jdk : Depends: openjdk-17-jre (= 17.0.8+7-1) but it is not going to be installed
Depends: openjdk-17-jdk-headless (= 17.0.8+7-1) but it is not going to be installed
Depends: libc6 (>= 2.34) but 2.31-13+rpi1+deb11u6 is to be installed
Recommends: libxt-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I am running bullseye at the moment. Does anybody have an idea how to fix this issue? Since my Pi runs multiple home automation services, I do not want to start from scratch with a backup.

Thanks,
Florian

1 Like
2

From a quick google search, it appears Java 17 should install on bullseye
Here is a thread I wrote awhile back on how I installed OH4 including java 17. Maybe it will provide you some clues
Warning, it is not for openHabian
https://community.openhab.org/t/upgrading-oh3-to-oh4-linux-mint/145156

3

I did some research. Libc6 > 2.34 which is required is not available for bullseye. Upgraded to bookworm and everything works as it is expected.

4

how did that happen ? For others it is working. That would mean you have/had a mixture of repositories or you did not install Java from a repo but by manually downloading it ?
And it is not an openhabian based system I assume.

5

OpenJDK 17 definitely runs on bullseye and is installable via apt. There must be another issue on OPs system.

6

Same story here. I also would expect that if I just do an apt-get update and apt-get upgrade, that not my openhab isnā€™t working anymore. So if already known that JAVA 17 needs to be available, it would be a very good idea that somebody is providing the apt-get commands to upgrade that java 11 to java 17. Because Iā€™m having the same problem now as the OP that on my bullseye version it is impossible to get JAVA 17 installed. So maybe on the 64 bits version it is working, but on the 32 bits it looks like there is no JAVA 17 available.

So it looks like that Iā€™m now stuck without OpenHab. Are there options to rollback OH4 to the previous version without losing all settings?

7

Azul provides Zulu Java 17 32bitā€¦.

8

Yes, but HOW to install it the easy way?

9

They provide instructions, there is no easy way Iā€˜m afraid.

10

The problem is already which version to choose. Iā€™m running on a Pi4 32 bit. If I go to their site from my windows PC, I end up with all versions, but donā€™t know which one for the Pi.

12

No the Pi has an ARM chip, so ā€œARM 32-bit HF
v7, v8ā€ should work.

13

So why not using openHABian image, instead of messing around?

14

Because I had a complete working system were Openhab is just one of the components running on it. I created this one 1.5 years ago, so it was time to do some update. Bad idea.

OK, so almost the wrong version installed.

15

So this is the version?

java17
java171900Ɨ649 72.6 KB

16

OK, getting a step closer.

java-installed
java-installed1066Ɨ180 34.1 KB

Iā€™ve put the install dir close to the version 11. But now how to switch over to make this ZULU version the default?

And who decided that you can only make 3 replies on this forum??? So now teverything is going out of sequence.

So here is my update to a post that is below:

Looks like if I read your story, that the tunnel is getting longer by the minute.

As I already wrote, I managed to unpack JAVA. But until now all options to make that version 17 the default is not working. So

update-alternatives is very complex. Nobody is sugesting to go this way, unless it is already preconfigured. If you do a manual install, forget it.

THen this is written:

The best answer is go back to the basics.

set in your .bash_profile (for your user) or in /etc/profile (for every user) the following variables:

JAVA_HOME=<The home of your new java distribution>

PATH=<The bin directory of your new java distribution>:$PATH

But, after adding this, it is still bypassing it. So where on earth is it that you can get this BULLSEYE working as I need it?

17

I was running OH3 on buster with openhabian. I then upgraded to OH4 with openhabian. During the upgrade fetching and installing Java17 failed.

I stumbled upon a post that said Java17 is not supported on buster, so I upgraded to bullseye. After upgrading to bullseye, I tried to install Java17 again. Tried through openhabian and apt. Gave me the same error message that the libc6 version is too low.

If you look at Java 17 (ARMHF), it requires libc6 > 2.34. Bullseye, however, has libc6 (see 2.31-13+deb11u6) Debian -- Details of package libc6 in bullseye). I do not know if the openhabian distribution for the Pi has made changes so it installs on Bullseye or even Buster, however, I had to upgrade to bookworm, which comes with libc6 (2.36-9+deb12u1).

After upgrading to bookworm, I did not have any issues installing Java 17 the expected way. System is running flawlessly since then (except from some minor fixes to scripts and third party tools due to the bookworm upgrade).

Best,
Florian

18

No there is. 32bit is the default for openHABian on RPi/ARM, hereā€™s a link with the list:
Thereā€™s various combos we test with each openHABian build run.

We no longer support Zulu though.

It has always been working on bullseye and never on buster.
However, once you have manually messed around with your system we cannot truely speak of either of those any more. The reference starting point has become unknown and no-one but yourself knows what you did to it. So any future outcome is basically unpredictable for us, too.
Glad bookworm seems to work for you but be aware that officially it is not supported (yet).

19

OK, somehow, I can make now a new reply. (Strange forum).

Yes, that there is indeed a Java 17 for 32 bits was already mentioned. But if the JAVA 17 is that important, it would be advisable that you create a step-by-step description on how to upgrade the Java 11 to Java 17. Because thinking that everybody is just doing a completely new install on a Pi is for most users not going to happen. It took me now 7 hours to figure out on how to get that JAVA installed and make it the default. Most users are not messing around on there Pi. It is just the standard version and from that point on you do the upgrades. So if you do the apt-get upgrade, you must be able to believe that this is going OK. The OH4 should not be able to upgrade if it is missing that JAVA 17. The OP was also telling this. If a waring was displayed (or it was just not upgrading), then at least the OH3.x was still working. Now you end up with a a not working OH4. And if it was an easy command to get that JAVA installed, then it was easy. But now it is waiting for more and more users that run in this problem.

21

OH runs on about every hardware x86 or ARM, about every Linux with different distro generations and even on Windoze and MacOS. On VMs, NASes and hell even on a thermostat.
Any Java installation/upgrade now can be individual and depends on all of these factors.
So who do you think should be writing the instructions for all those combos for you ?
Those few volunteers we are donā€™t have all the HW and OSs let alone the time that would take.

Note that all of this would not have happened if people had properly read the docs to state the prerequisites which I feel is a minimum we can expect users to contribute as their share.

22

I know that you canā€™t predict all options. But because OH4 is completely written in JAVA, then that component is very important. And you canā€™t expect that the user is reading the docs, if it is not expecting that OH is going to upgrade if you do an upgrade of a LINUX dist. Normally an aplication is blocking itself if the requirements are not met. So also in this case, if JAVA 17 is missing, then OH should stop itā€™s upgrade. If the user then wants to do the OH upgrade, if will notice that it is not happening and will then start reading the docs. Not the other way around. Your way of working is like it was 20 years ago. if an update was needed, then you were creating a new device and are testing eveyr application before you are going to do the upgrade on the production device. Well, that time is far behind us. Now a day itā€™s call ā€œrisk based upgradeā€ and you may assume that if an upgrade is starting, it is already sure tha tit is going to work. THatā€™s how Windows, MAC (IPAD), Android, etc is working.