Fehler beim Versuch Java21 zu installieren

[FrankW5300]

Hallo,

ich nutze Debian 12 und habe Openhabian installiert. Bei der openhabian-config wurde mir angezeigt das man in vorbereitung auf Openhab 5 auch schon Java21 installieren kann. Ich hab das auch versucht über den Menüpunkt 45. Leider hat sich dabei das System bei der Installation von openjdk21 wahrscheinlich aufgehangen. Im Prinzip läuft das System auch noch, aber beim Update bekomme ich folgende Fehlermeldungen:

Code: Alles auswählen

sudo apt-get upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libc-bin : Hängt ab von: libc6 (< 2.37) aber 2.41-7 ist installiert
 libc-dev-bin : Hängt ab von: libc6 (< 2.37) aber 2.41-7 ist installiert
 libc6 : Beschädigt: systemd (< 256~rc4-1~) aber 252.36-1~deb12u1 ist installiert
 libc6-dev : Hängt ab von: libc6 (= 2.36-9+deb12u10) aber 2.41-7 ist installiert
 locales : Hängt ab von: libc-bin (> 2.41) aber 2.36-9+deb12u10 ist installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an).
sudo apt --fix-broken install
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Abhängigkeiten werden korrigiert … fehlgeschlagen.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libc-bin : Hängt ab von: libc6 (< 2.37) aber 2.41-7 ist installiert
 libc-dev-bin : Hängt ab von: libc6 (< 2.37) aber 2.41-7 ist installiert
 libc6 : Beschädigt: systemd (< 256~rc4-1~) aber 252.36-1~deb12u1 ist installiert
 libc6-dev : Hängt ab von: libc6 (= 2.36-9+deb12u10) aber 2.41-7 ist installiert
 locales : Hängt ab von: libc-bin (> 2.41) aber 2.36-9+deb12u10 ist installiert
E: Fehler: Unterbrechungen durch pkgProblemResolver::Resolve hervorgerufen; dies könnte durch zurückgehaltene Pakete verursacht worden sein.
E: Abhängigkeiten konnten nicht korrigiert werden.

Kann mir jemand helfen diese Fehler zu beseitigen? Ich habe schon versucht die Bibliotheken neu zu installieren aber ohne Erfolg.

Grüße
Frank

[nw378]

Herzlichen Glückwunsch, Du hast nun ein Frankendebian. https://wiki.debian.org/DontBreakDebian ... nkenDebian

Ich hatte die gleiche Idee wie Du und mir hat das Java Update genauso das System zerschossen. Ob's zu retten ist? Ich hab's nicht geschafft; nach einem Tag tüfteln habe ich es neu installiert (aktuelles Backup ist Gold wert - das sollte sich ja noch ziehen lassen, wenn das System so noch läuft). Neuinstallation ist ja in 30 Minuten erledigt.
Ich warte jetzt darauf, dass OH 5.0 stable wird - und es dann hoffentlich eine brauchbare Lösung/Tutorial gibt. Solange bleibe ich bei Java 17.

Im englischen Forum wird auch an vielen Stellen dazu geraten, alternativ Temurin 21 zu verwenden: https://community.openhab.org/t/openhab ... 23?u=nw378

[FrankW5300]

FUCK!! Das hört sich nicht gut an. Naja, es läuft ja zum Glück noch. Ich hab zwar ein Backup von Openhab aber von Grafana und der Influxdb muss ich noch eins anfertigen. Da da ich auch kein Vollbackup habe wird das bei mit garantiert länger dauern als 30min. Ich muss dann erstmal nachvollziehen wie ich das damals installiert habe.

[udo1toni]

Ein vollständiges Backup des Systems nützt hier nichts, Du musst stattdessen
- ein Backup von openHAB selbst erstellen (openhab-cli backup --full)
- Ein Backup der Grafana Konfiguration (ich habe nur ein Dashboard und mache dann einfach einen Export des Dashboards als JSON, evtl. gibt's auch eine elegante Variante für die komplette Konfiguration, keine Ahnung)
- Ein Backup der InfluxDB (abhängig von der exakten Version und allgemein ein PitA, weil InfluxData Dich lieber in der Cloud sehen möchte - ist aber machbar)

Die Daten sicherst Du anschließend z.B. über Netzwerk extern, anschließend setzt Du das System komplett neu auf und spielst die Daten wieder ein.

Grundsätzlich kannst Du Java21 64-Bit ganz locker auch unter Debian12 laufen lassen, allerdings sollte das nicht nativ über apt erfolgen - bzw. sollte openJDK21 nicht über eine Paketquelle eingebunden, sondern allenfalls als *.deb Datei lokal eingespielt werden.
Ich nutze hier das Originalpaket von Oracle, das hat den Vorteil, nicht speziell für eine bestimmte Debianversion gebaut zu sein. (eigentlich sollte das auch bei openJDK nicht anders sein, aber wer weiß schon, was da nebenher in openHABian tolles integriert wurde...)

Ich habe lange openHABian genutzt, komme inzwischen aber davon ab, die Installation von openHAB selbst ist trivial (zumal bestens dokumentiert), alles andere läuft bei mir in separaten Containern und nähme nur unnötig Platz weg. Einzig die Samba Freigabe kann vielleicht etwas herausfordernd sein, aber da ich das nicht mehr nutze (zugunsten des Remote Zugriffs per VS Code, ebenfalls recht einfach einzurichten) spielt das für mich auch keine Rolle.
Der Web Logviewer ist inzwischen nativ in openHAB eingebaut und FireMotD wird über kurz oder lang auch raus fliegen, da es nicht mehr weiterentwickelt wird. Bleibt noch das Syntax highlighting in nano, vi und Co, brauche ich nicht, weil ich ja VS Code remote nutze...

[FrankW5300]

Ein vollständiges Backup des Systems nützt hier nichts, ...

Warum? Wenn ich ein Image von der Platte gesichert hätte, sollte man das System doch relativ einfach wiederherstellen können.

- ein Backup von openHAB selbst erstellen (openhab-cli backup --full)

Ich habe immer die Backupfunktion in der Openhabian Oberfläche genutzt. Ich hoffe das entspricht dem Full.
Grafana sehe ich auch unkritisch gegenüber.

Ein Backup der InfluxDB...

hier werden meine Probleme anfangen. Inzwischen startet der Computer doch nicht mehr.. Aber ansonsten sollte es doch genauso einfach gehen wie bei Openhab (influx backup <backup-path> -t <root-token>).

Grundsätzlich kannst Du Java21 64-Bit ganz locker auch unter Debian12 laufen lassen, allerdings sollte das nicht nativ über apt erfolgen - bzw. sollte openJDK21 nicht über eine Paketquelle eingebunden, sondern allenfalls als *.deb Datei lokal eingespielt werden.

Warum, was ist hierfür der Hintergrund (abgesehen davon das das openjdk21 Paket das System zerlegt)?

Ich nutze hier das Originalpaket ...

Das habe ich bis jetzt nicht verstanden. Welche Javavariante ist für was und warum arbeitet man nicht an einer Variante. Gibt es da Vor- und Nachteile oder sind das nur rechtliche Hürden? Bei der Dokumentation von Openhab liest sich das immer wie openjdk ist das Beste und der Rest ist zweite Wahl.

Ich würde das neue System dann auch in Container (Promox) aufsetzen wollen habe nur diesbezüglich keine Erfahrung. Kann man die Container am Stück sichern? Die Kommunikation (z.B. Openhab vs. Influx) untereinander läuft dann vermutlich einfach über die IP. Gibt es da Hürden bei der Freigabe? Bisher habe ich Openhab, Mosquito (Mqtt), Influxdb und Grafana verwendet. Die müssten dann vermutlich alle einen eignen Container erhalten. Hier bräuchte ich vielleicht etwas Hilfe wie man das am Besten neu aufsetzt.

Der Web Logviewer ist inzwischen nativ in openHAB eingebaut und FireMotD ...

Ich fand den Frontail bisher immer ganz schön, da man sofort gesehen hat was zuletzt geschehen ist. Der neue Logviewer hat bei mir immer erst das Angezeigt, was nach dem aufrufen des Viewers passiert. Vielleicht ist das auch eine Fehlbedienung von mir. Und bei FireMotD weiß ich nicht was das überhaupt gemacht hat.

Abgesehen von meinen Problemen wünsche ich allen ein schönes Ostern...

[nw378]

hier werden meine Probleme anfangen. Inzwischen startet der Computer doch nicht mehr.. Aber ansonsten sollte es doch genauso einfach gehen wie bei Openhab (influx backup <backup-path> -t <root-token>).

Ich lasse Influx im Docker Container laufen und habe für die Backups ein Skript. Dieses löscht sogar alte Backups.

Code: Alles auswählen

#!/usr/bin/env bash

export LANG="en_US.UTF-8"
#Load the Pathes
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# set the variables

# Where to store the Backup files?
# mount that directory to /backup into the influxdb containers
BACKUPDIR=/volume1/docker/influxdb/backup

# How many Days should a backup be available?
DAYS=14

TIMESTAMP=$(date +"%Y%m%d%H%M")

CONTAINER=$(docker ps --format '{{.Names}}:{{.Image}}' | grep 'influxdb' | cut -d":" -f1)

### Do the stuff
echo -e "Start $TIMESTAMP Backup for Databases: \n"
if [ ! -d $BACKUPDIR ]; then
        mkdir -p $BACKUPDIR
fi

for i in $CONTAINER; do
        echo -e " create Backup for Database on Container:\n  * $i";
        docker exec -e i=$i -e TIMESTAMP=$TIMESTAMP $i influx backup --compression gzip /backup/influxdb/$i-$TIMESTAMP > /dev/null 2>&1 
        # dont delete last old backups!
        OLD_BACKUPS=$(ls -d1 $BACKUPDIR/$i* |wc -l)
        if [ $OLD_BACKUPS -gt $DAYS ]; then
                find $BACKUPDIR -maxdepth 1 -name "$i*" -type d -daystart -mtime +$DAYS -type d -exec rm -rf {} \;
        fi
done
echo -e "\n$TIMESTAMP Backup for Databases completed\n"

Ich würde das neue System dann auch in Container (Promox) aufsetzen wollen habe nur diesbezüglich keine Erfahrung. Kann man die Container am Stück sichern? Die Kommunikation (z.B. Openhab vs. Influx) untereinander läuft dann vermutlich einfach über die IP. Gibt es da Hürden bei der Freigabe?

Genau. Influx kannst Du direkt in openHAB über die IP einbinden. Details zu Proxmox steuert sicherlich Udo bei.

influx.png

In Grafana musst Du dann ebenfalls die IP der Datenbank angeben.

grafana.png

Das wars eigentlich schon. Die Links zu den Graphiken erstellt Grafana ja selber.

Happy Easter.

[udo1toni]

Wenn ich ein Image von der Platte gesichert hätte, sollte man das System doch relativ einfach wiederherstellen können.

Aber ja nur den Zustand zum Zeitpunkt des Backups, für das gesamte System. Du kannst Kein vollständiges Backup einspielen, welches dann aber nur einen Teil des Systems wiederherstellt.

Ich habe immer die Backupfunktion in der Openhabian Oberfläche genutzt.

Ja, das sollte dem nativen Befehl entsprechen. Da ich openhabian-config nie für Backups verwendet habe, weiß ich aber nicht, ob hier immer mit der Option --full gesichert wird (sichert auch den Cache und die Persistence mit, kann aber nur in die exakt gleiche openHAB Version sauber zurückgespielt werden), oder ob hier ohne --full gesichert wird (enthält nur die Konfiguration, kann auch in die nächste, teilweise sogar mehrere Versionen später wieder erfolgreich eingespielt werden). In der Tendenz sollte ein Backup ohne --full wenige zehn MByte groß sein (kommt natürlich auf die Größe des Systems an), während die --full Version meist deutlich in Richtung 100 MByte oder darüber hinaus geht.

Allerdings reden wird dann ja gar nicht von einem vollständigen Backup des Gesamtsystems, das ist normalerweise eine 1:1 Kopie auf einer zweiten SD-Karte, also mehrere GByte groß. Auch für diese Variante gibt es eine Option in openhabian-config, es kommt also darauf an, welche Funktion Du tatsächlich genutzt hast.

ansonsten sollte es doch genauso einfach gehen wie bei Openhab (influx backup <backup-path> -t <root-token>).

Wäre schön - Schau mal in die Influx Doku zu dem Thema das wird Dich dann unsanft auf den Boden der Tatsachen holen.

Warum, was ist hierfür der Hintergrund (abgesehen davon das das openjdk21 Paket das System zerlegt)?

Genau das ist da Problem. Das fragliche Paket steht nicht für debian bookworm zur Verfügung, und da es offensichtlich Abhängigkeiten gibt, zerschießt Dir das Paket Dein Betriebssystem. Das Paket von Oracle hat diese Abhängigkeiten nicht (es gibt nur 1 Paket für alle apt-basierten Systeme, das Paket bringt also alle Abhängigkeiten in einer Form mit, die unabhängig vom Betriebssystem ist)

Welche Javavariante ist für was und warum arbeitet man nicht an einer Variante.

Oracle ist die Firma hinter Java (ursprünglich war es mal Sun, aber Oracle hat Java gekauft). Es gibt diverse Implementierungen von Java, unter anderem die Zulu-Variante und OpenJDK. Dabei gibt es immer leichte Unterschiede, relevant ist aber vor allem die Lizenz, die ist für Privatpersonen allerdings "egal" (soweit Du nicht selbst publizierst natürlich)
Zumindest für die nicht nativ unterstützte Variante ist meiner Erfahrung nach die Originalimplementation immer das Maß der Dinge. Sobald es Java21 als OpenJDK offiziell in debian gibt, kannst Du dies genauso gut verwenden. Allerdings kannst Du davon ausgehen, dass dies erst für Trixie der Fall sein wird (die kommende Version 13). Kann sein, dass es auch als Backport angeboten wird, danach habe ich nie gesucht, weil Trixie eh recht zeitnah erscheinen wird (üblicherweise im Juni, wenn es keine Probleme gibt, durch die sich die Veröffentlichung verzögert) und da sollte Java21 dann als OpenJDK verfügbar sein.

Ich würde das neue System dann auch in Container (Promox) aufsetzen wollen habe nur diesbezüglich keine Erfahrung. Kann man die Container am Stück sichern?

Unter Proxmox ist ZFS als Dateisystem die erste Wahl (wenn es um kleine Systeme geht - Datacenter mit zig Nodes werden eher Ceph nutzen, weil das besser skaliert, aber das ist ein anderes Thema).
Mit ZFS kann man für die Datasets automatisch Snapshots erstellen lassen und diese auch automatisiert auf ein Sekundärsystem kopieren lassen (womit wir dann ein versioniertes Backup haben).
Ich nutze ein separates Dataset für die Nutzdaten (Konfiguration und interne Persistence...), das kann man easy als zusätzlichen Mountpoint direkt in Proxmox einrichten. Damit kann man dann Betriebssystem und openHAB unabhängig voneinander zurückspielen, wenn man z.B. ein Update vermasselt hat. Dabei ist noch anzumerken, dass die Snapshots virtuell alle Daten enthalten und man auf jeden Snapshot zugreifen kann, um notfalls auch einzelne Dateien aus dem Dataset zurückzurollen. Dabei enthält jeder Snapshot physisch aber nur die Änderungen zum Vorgänger.
ZFS stellt die Datenintegrität zu jedem Zeitpunkt über alle Snapshots hinweg sicher.

Die Kommunikation (z.B. Openhab vs. Influx) untereinander läuft dann vermutlich einfach über die IP.

Genau. Bei LXC bekommt jeder Container einen "ganz normalen" IP Stack verpasst, der "ganz normal" am Netzwerk hängt, als sei der Container ein eigenständiger Rechner. Das macht vieles aus Adminsicht sehr viel einfacher.

Die müssten dann vermutlich alle einen eignen Container erhalten.

Das ist nicht zwingend, aber naheliegend, weil Du nur mit separaten Containern auch eine völlige Trennung der Software hast. Auf der anderen Seite hast Du eben pro Softwarestack einen eigenen Container, d.h. Du musst Dir auch keine Gedanken um Abhängigkeiten machen, Du setzt die Software einfach als Standalone Version auf.

Der neue Logviewer hat bei mir immer erst das Angezeigt, was nach dem aufrufen des Viewers passiert. Vielleicht ist das auch eine Fehlbedienung von mir. Und bei FireMotD weiß ich nicht was das überhaupt gemacht hat.

Ja, nein, das ist keine Fehlbedienung. Aber Frontail hat ja auch nicht immer alles angezeigt, sondern maximal die letzten 1000(?) Zeilen, und beim ersten Aufruf von Frontail in der aktuellen Session halt auch nur die letzten paar Zeilen. Dabei ist das Log schon immer vollständig, nur halt nicht über Frontail einsehbar, das geht uneingeschränkt nur über die Shell. Insofern sehe ich hier keinen großen Komfortverlust mit der neuen Variante.
Was FireMotD betrifft, so ist das die Zusammenfassung des Systemdaten zu Beginn der Shell Session:

Code: Alles auswählen

Using username "openhabian".
Authenticating with public key "eddsa-key-20250401 openHABian" from agent
Linux openhab 6.8.12-9-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-9 (2025-03-16T19:18Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Apr 15 14:45:31 2025 from 192.168.178.55

DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
iiiiiiiiiiiiiii  openhab  iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
DD        Ip -> 192.168.178.92
DD   Release -> Debian GNU/Linux 12 (bookworm)
DD    Kernel -> Linux 6.8.12-9-pve
DD  Platform -> lxc
DD    Uptime -> 16 day(s). 15:19:24
DD CPU Usage -> 7.72% avg over 4 cpu(s) (6 core(s) x 1 socket(s))
DD  CPU Load -> 1m: 0.82, 5m: 0.88, 15m: 0.90
DD    Memory -> Free: 0.95GB (32%), Used: 2.04GB (68%), Total: 3.00GB
DD      Swap -> Free: 0.00GB (0%), Used: 0.00GB (100%), Total: 0.00GB
DD      Root -> Free: 5.55GB (69%), Used: 2.44GB (31%), Total: 8.00GB
DD   Updates -> 0 apt updates available.
DD  Sessions -> 1 session(s)
DD Processes -> 33 running processes of 4194304 maximum processes
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

                          _   _     _     ____   _
  ___   ___   ___   ___  | | | |   / \   | __ ) (_)  ____   ___
 / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \ | | / _  \ / _ \
| (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )| || (_) || | | |
 \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/ |_| \__|_||_| | |
      |_|                  openHAB 4.3.4 - Release Build

Looking for a place to get started? Check out 'sudo openhabian-config' and the
documentation at https://www.openhab.org/docs/installation/openhabian.html
The openHAB dashboard can be reached at http://openhab:8080
To interact with openHAB on the command line, execute: 'openhab-cli --help'

openhabian@openhab:~$

FireMotD ist der Teil von DDDD... bis ...SSSS, d.h. das Login gehört zum Loginprozess der Shell und der große openHABian Schriftzug stammt von openHABian. Du bekommst die also die wichtigsten Daten zum Zustand des Systems.

[FrankW5300]

Aber ja nur den Zustand zum Zeitpunkt des Backups,...

Ist klar, was anderes hätte ich auch nicht erwartet.

Allerdings reden wird dann ja gar nicht von einem vollständigen Backup des Gesamtsystems,...

Passt, warscheinlich war es kein full Backup (Punkt 50 im Menü). Zumindest konnte ich es nicht im Quelltext erkennen.

Wäre schön - Schau mal in die Influx Doku zu dem Thema...

Ok, der Befehl war aus der Doku. Zumindest hat es bei mir einmal schon so funktioniert.

Zumindest für die nicht nativ unterstützte Variante ist meiner Erfahrung nach die Originalimplementation immer das Maß der Dinge.

Ok, wie läuft das dann wenn mein System openkdk17 hat und ich installiere Oracle Java 21? Wird dann das 17er deinstalliert? Und was passiert mit den Oracle Java 21 wenn auf das System auf Trixie geupdated wird läuft dann wieder openjdk21?

Unter Proxmox ist ZFS als Dateisystem die erste Wahl...

Ok, ich hätte ein neues Debian aufgesetzt und Promox installiert und die Container (Debian) sollen dann ZFS als Dateisystem nutzen. Eventuell sollten wir das in einen neuen Thema behandeln... Wie installiere ich das System ausfallsicher bzw. einfach wiederherstellbar.

Aber Frontail hat ja auch nicht immer alles angezeigt, sondern maximal die letzten 1000(?) Zeilen, und beim ersten Aufruf von Frontail in der aktuellen Session halt auch nur die letzten paar Zeilen.

Stimmt, aber ich konnte auf den ersten Blick sehen, ob es in der letzten Zeit Fehler gab, bzw. ob nach einen Neustart alles lief. Das fehlt mir bei der neuen Version. Hier wäre es auch schön wenn ich die letzten x Einträge sehen könnte.

FireMotD ist der Teil von DDDD... bis ...SSSS,

Ok, gut zu wissen. Das wurde bei mir aber nur in ca. 30% der Logins angezeigt. Das habe ich eigentlich auch nie groß verwendet (außer die Info über die Festplattenbelegung).

Auf jeden Fall muss ich erstmal das System wieder zum laufen bekommen (Kernel Panic beim Start) dann kann ich die Backups (die Openhab habe ich ja, aber das von der Influxdb brauche ich noch) machen und danach das ganze frisch aufsetzen.

[udo1toni]

Zumindest hat es bei mir einmal schon so funktioniert.

Jetzt wo ich genauer darüber nachdenke, ist das eigentliche Problem nicht das komplette Backup und das komplette Wiederherstellen, sondern der Umzug von einer Version auf eine andere... Da bin ich durcheinander gekommen, sorry.
Wichtig ist aber, dass InfluxDB getrennt betrachtet werden muss.

Was Proxmox betrifft:
Du erstellst ein Bootmedium für den Rechner, auf dem Proxmox installiert werden soll (heutzutage üblicherweise einen USB-Stick, aber natürlich geht das auch per CD-ROM bzw. DVD-ROM, Netboot usw. Für das Bootmedium verwendest Du das aktuelle Promox VE Image von der Proxmox Seite.

Dann bootest Du den Rechner von dem Bootmedium und folgst den Anweisungen. Nach einigen Fragen und Kopiervorgängen startet der Rechner neu und bootet Proxmox VE. Am Prompt bekommst Du eine Ausgabe, über welceh IP das System erreichbar ist, und dass Du per https über den Port 8006 zugreifen kannst. Danach meldest Du Dich per Browser an Proxmox VE an.

Mehr dazu aber tatsächlich gerne in einem separaten Thread.