gespiegelte SD startet nicht

[iTob]

Hallo,

ich habe noch ein am openHAB 2.5.12 am Laufen und möchte nun die Updates angehen.

Dazu habe ich per:
openHABian Configuration Tool
53 | Setup SD mirroring Setup mirroring of internal to external SD card
eine Spiegelung der SD Karte erzeugt.
in einem zweiten Raspberry startet diese Kopie einfach nicht.
Der Boot-Vorgang hängt nach
USB Hub found
4 ports detected

Schliesse ich eine Tastatur an, dann wird diese erkannt.
Nach längerer Zeit kommt dann noch die Zeile:
random: crng init done

Hat jemand eine Idee, was hier schief läuft?

VG und Vielen Dank.

[udo1toni]

Ich fürchte, Du wirst ohnehin kein In-Place Update machen können.
Erfolgversprechender wäre deshalb, ein System komplett neu aufzusetzen (mit openHAB2.5.12), anschließend vom alten System nur die openHAB-Konfiguration zu laden (openhab-cli backup -> zipdatei auf neues System kopieren -> openhab-cli restore <pfad/zur/zip-datei>) und dann dieses System Schritt für Schritt upzudaten (also zunächst auf openHAB3.4, danach auf openHAB4)
Wobei es (abhängig von den installierten Addons) eventuell einfacher wäre, die Konfiguration manuell zu übernehmen und das neue System "from scratch" aufzusetzen. Dabei musst Du unbedingt zunächst in die openHAB Doku schauen, und zwar in die ersten Schritte. Zu viele Dinge haben sich seit openHAB2 fundamental geändert.
Rules wirst Du so oder so anpassen müssen, hier ist es das einfachste, die Rules zunächst alle zu deaktivieren und dann jede Rule einzeln an die neuen Gegebenheiten anzupassen.
Rules ohne weitere Abhängigkeiten kannst Du dann schrittweise auf dem alten System deaktivieren und auf dem neuen System aktivieren.

Soweit Du Deine Konfiguration textbasiert angelegt hast (also alles unter /etc/openhab2/), kannst Du diese Dateien zum allergrößten Teil direkt übernehmen. Was unter services liegt, ist aber tabu und bei den anderen Ordnern kann es sein, dass Du Anpassungen vornehmen musst. Bei Items sind viele neue Optionen dazu gekommen, die alte Konfiguration sollte aber spielen, soweit es v2-Bindings betrifft. v1 ist raus, das muss komplett neu gemacht werden.
Bei den Things kommt es auf das Binding an, bei vielen Bindings haben sich teilweise die Namen der Parameter geändert.

[iTob]

Ich verstehe nicht ganz, wozu ich das identische System neu aufsetzen soll? Um alte Dinge zu bereinigen?
Eine Sicherung gleich auf einer neueren Version einspielen - das funktioniert wohl nicht?

Hast Du trotzdem eine Idee, warum meine, mit Spiegelung erstellte "Sicherheitskopie" nicht startet?

Vielen Dank schon für die Tipps.

[udo1toni]

Eine Sicherung gleich auf einer neueren Version einspielen - das funktioniert wohl nicht?

Genau das ist der Punkt.

Hast Du trotzdem eine Idee, warum meine, mit Spiegelung erstellte "Sicherheitskopie" nicht startet?

Na ja, im Zweifel ist halt ein blödes Detail kaputt. Da das System uralt ist würde ich da keine fünf Minuten investieren - weil mir vollkommen klar ist, dass aus diesen fünf Minuten unweigerlich fünf Stunden werden, und in dieser Zeit setze ich ein System locker zweimal neu auf.

[iTob]

Weißt Du, ob ich da mit ruhigem Gewissen das aktuelle SD-Image vom 2.5.12 nutzen kann oder ist da auch schon vieles vom Raspberry Pi OS zu alt?
Sollte ich dann lieber gleich auf 64 bit gehen?
Dann bin ich ja mal gespannt wie ich alles so zum Laufen bekkomme: openHAB, MQTT, InfluxDB, Grafana, HomeMatic,...

[udo1toni]

Die Frage ist, was Du als Hardware nutzt. Läuft das Ganze auf einem Pi? Wenn ja, welches Modell?

Mittelfristig (Juli 2025) führt an 64 Bit kein Weg vorbei, es sei denn, Du bleibst dann auf der Version 4.3.x (allgemein nicht zu empfehlen). Aber 64 Bit ist sinnvoll nur nutzbar, wenn Du einen Rechner mit mindestens 2, besser 4 oder 8 GByte RAM hast. openHAB5 wird nur noch 64 Bit unterstützen, was auch schon sehr deutlich angekündigt wurde.

Wenn schon das Image der SD-Karte nicht läuft, ist es fragwürdig, ob die eigentliche Installation nicht ebenfalls auf tönernen Füßen steht. Wie gesagt ist ein Upgrade bis auf den aktuellen Stand mit hohem Aufwand verbunden. Und da das System vermutlich beim Aufsetzen "aktuell" war, musst Du nicht nur mehrere openHAB Versionen upgraden, sondern zusätzlich auch noch das OS (in zwei Etappen). Jedes Update für sich ist relativ problemlos möglich, aber genauso kann bei jedem einzelnen Update ein kleines Detail nicht so laufen, wie es soll, und das muss dann alles mühsam gefixt werden.
Deshalb denke ich, dass es sinnvoller ist, ein komplett neues System aufzusetzen.

Je nach Geldbeutel und/oder vorhandener Hardware gibt es diverse gute Optionen.
Der Pi4 oder Pi5 sind klasse, und man kann dann mit openHABian den "mach-es-einfach" Weg gehen. Andererseits sehe ich Anzeichen dafür, dass openHABian über kurz oder lang auch abgelöst werden könnte, evtl. zugunsten einer Docker Variante, damit lassen sich viele Dinge deutlich leichter lösen. Und selbstverständlich kann man auch ohne Probleme selbst sein System mit Docker aufsetzen.
Es gibt auch nicht wenige Anwender, die inzwischen auf einen (gebrauchten) NUC geschwenkt haben - ein komplettes System mit Gehäuse, Netzteil und Massenspeicher, welches nicht teurer ist als ein Pi5 mit gleicher Ausstattung, aber deutlich schneller bei gleichem Strombedarf.
Auf einem NUC kann man dann durchaus darüber nachdenken, ob man Docker nutzt oder (wie in meinem Fall) Proxmox oder einen anderen "ausgewachsenen" Hypervisor. Im Fall von Proxmox bekommt man da jede Menge nette Zusatzfunktionen, z.B. mit zwei SSDs ganz einfach ein RAIDz1 mit autosnapshot und (so ein 2. System vorhanden ist) vollautomatischer Replikation. Aber natürlich kann man auch openHABian verwenden (die Scriptsammlung, nicht das Pi-Image) und das System monolithisch betreiben.

[iTob]

Hallo,
vielen Dank für die Antworten.
Ich nutze aktuell ein Raspberry Pi 4 mit openHAB 2.5.12.
Ich habe viele Scripte geschrieben und ermittle aus den verschiedenen Homematic-Thermostaten die größte Themperatur-Differenz und sende diese an die Therme. Und es funktioniert ja auch alles.
Ich habe mich auf einem Test-Pi mit verschiedenen Updates befasst - aber es geht da immer etwas schief.
Vieleicht sollte ich doch openhab 4 komplett neu aufsetzen und meine Scripte übernehmen und ggf anpassen?
Aber gibt es überhaupt einen Grund von 2.5.12 nach oben zu wechseln oder lasse ich das System einfach so laufen.
Ich mache aktuell regelmäßig eine Sicherung mit raspiBackup. Bei den Tests ist mir nun nur aufgefallen, dass ich vor der Sicherung zumindest zram anhalten sollte. Aber nun funktioniert auch im Ernstrfall die Rücksicherung.
VG, Tobias

[udo1toni]

gibt es überhaupt einen Grund von 2.5.12 nach oben zu wechseln

Ja, das fängt damit an, dass Du etwas verpasst (wobei Du Dich auf einem Testsystem - gerne auch als VM auf dem Desktop - leicht von den Neuerungen motivieren lassen kannst). Je länger man nicht updatet, um so schwieriger wird es, überhaupt noch upzudaten (Du bist ja schon an dem Punkt, wo es Dir unmöglich erscheint - wobei Dein Fehler mutmaßlich darin liegt, dass Du davon ausgehst, Du könntest "einfach so" updaten).
openHAB2.5.12 läuft unter Java 8. Vielleicht kannst Du es tatsächlich "sogar" auch noch unter Java 11 nutzen (käme auf einen Versuch an), aber danach ist definitiv Schluss. Der Premier Support für Java 11 ist im September 2023 ausgelaufen. Für Java 8 SE ist 2030 endgültig Schluss, das ist tatsächlich noch etwas hin, aber absehbar, und wie gesagt, ein direktes Update ist nicht möglich, egal, was Du anstellst. Du musst also entweder von 0 anfangen, oder eine Menge Zwischenschritte gehen, von 2.5.12 auf 3.4.5 (ersteres unter Java 8, Letzteres zwingend auf Java 11, d.h. Upgrade der Java Umgebung bei zeitgleichem Update von openHAB., Danach dann Update auf 4.3.1, welches dummerweise Java 17 fordert.
Besser wäre also das Update von 2.5.12 auf 3.0.0 mit Java 8, dann Update auf Java 11, dann Update auf 3.4.5, dann Update auf Java 17, dann Update auf 4.0.0, dann Update auf 4.3.1.
Und ich habe es oben ja schon angedeutet... Java 17 wirst Du für buster nicht bekommen, Du wirst also zusätzlich zwischendrin noch die Distribution upgraden müssen, mehrfach. Im Sommer kommt Debian trixie, dann ist bookworm oldstable und bullseye ist oldoldstable. buster ist jetzt schon nicht mehr supportet und es gibt offiziell keine Patches mehr.
openHAB5 wird Java 21 in 64 Bit fordern, das wird dann - ebenso wie alle anderen vergangenen Versionen - wieder eine LongTerm Version sein, die mehrere Jahre Sicherheitsupdates erhält.
Denke daran, dass openHAB gewöhnlich zumindest nicht völlig isoliert läuft. Du möchtest Dein Haus keinem unsicheren System anvertrauen - ganz besonders nicht die essenziellen Systeme wie Heizung und Strom.

[iTob]

Hallo,

ich habe das update 2.5 auf 3 über sudo openhabian-config gestartet - erst lief es gar nicht, dann hat er ein Update durchgeführt, obenhab startete aber gar nicht mehr.
Dann habe ich erst manuell buster --> bullseye geupdated, openhabian-config hat dann das java update auf die 11 durchgeführt. Nun läuft 2.5 noch.
Das nächste update per openhabian-config meldet plötzlich ein update auf 4 und schlägt fehl.
Oder sollte ich die Updates vom openhab auch lieber manuell machen und nicht per openhabian-config? Damit habe ich mich aber noch nicht befasst.

Eine Sicherung vom 2.5 kann man nicht in der 4 oder 3 einlesen? Vieleicht auch mit einer manuellen Anpassung...

Wenn ich sehe, wie viel Zeit ich schon in die Update-Versuche gesteckt habe, überlege ich, ob es einfacher ist eine 4 neu aufzusetzen.

VG, Tobias

[udo1toni]

Du musst bei openHABian dafür sorgen, dass es die "richtige" Version wählt, in diesem Fall musst Du händisch in /etc/openhabian,conf einen Eintrag anpassen.
Von der Linux Shell aus: sudo nano /etc/openhabian.conf
Anschließend scrollst Du zur Zeile clonebranch=openHAB und schreibst hinten noch eine 3 dran: clonebranch=openHAB3
Nun sollte openhabian-config Menüpunkt 40, 41 openHAB Release und anschließend 02 Upgrade System openHAB auf Version 3.4.5 upgraden.
openHAB sollte dann zumindest starten, aber viel(es) wird nicht funktionieren.

Jegliche V1 Bindings müssen komplett neu konfiguriert werden.
In vielen V2 Bindings haben sich Parameternamen geändert, die Du mutmaßlich mindestens teilweise von Hand anpassen musst.

In der Rule Engine hat es diverse teils große Änderungen gegeben - z.B. unter 2.5.x gab es triggeringItem als implizite Variable in allen Rules, die über ein Item oder den Member einer Group getriggert wurden (egal ob changed, received update oder received command). Ab 3.0 gilt triggeringItem nur noch für Trigger durch Member of, beim Trigger Item gibt es nun eine andere implizite Variable, triggeringItemName. Der große Unterschied: triggeringItem ist vom Typ genericItem, man kann es also genauso behandeln, als sei es ein bestimmtes Item, triggeringItemName ist hingegen vom Typ String, es enthält also tatsächlich nur einen String, der gleich dem Namen des triggernden Items ist. Um das Item selbst zu nutzen, muss es dann auf anderem Weg zur Verfügung gestellt werden.
Der größte Unterschied besteht natürlich im Ersatz von Joda Time. Schon seit Java8 gibt es JavaTime, und seitdem war Joda Time auch schon deprecated, wurde aber noch mit ausgeliefert. Mit Java11 (Voraussetzung für OH3) ist damit Schluss und ein Gutteil der Aufrufe, die sich auf Datums- und Zeitberechnungen beziehen muss mindestens angepasst werden.
Wenn das System soweit wieder läuft, kannst Du anschließend gleich das Upgrade auf bookworm durchziehen und danach clonebranch wieder auf openHAB ändern. Dann kannst Du auf openHAB4 upgraden. Die meisten Änderungen hast Du zu dem Zeitpunkt schon hinter Dir. Die Upgrade Scripte können allerdings nur gemanagte Dateien ändern, alles, was über /etc/openhab/* über Textdatei konfiguriert ist, musst Du selbst korrigieren.

Ach so... Pfade... openHAB1 nutzte im Pfad openhab als Hierarchieebene, openHAB2 nutzte (dummerweise) openhab2. Alle nachfolgenden Versionen nutzen wieder das einfache openhab. Auch das ist eine der Sachen, die Du evtl. manuell anpassen musst (das ist alles schon so lange her...).