Hallo zusammen,
auf heise.de hab ich vernommen, dass es eine Updatehilfe für OH 5 geben könnte:
https://www.heise.de/news/Smart-Home-op ... 23727.html
Leider bin ich in Linux nicht wirklich fit und scheue mich den wohl komplizierten/aufwändigen Weg von OH 4 auf OH 5 zu gehen.
Aktuelle Konfig:
Release = Raspbian GNU/Linux 11 (bullseye)
Kernel = Linux 6.1.21-v8+
Platform = Raspberry Pi 4 Model B Rev 1.5
openHAB 4.1.3 - Release Build
Wie ich verstanden habe, muss ich erst mal auf Java21 und ein 64 bit-System gehen. --> Das bekomme ich vmtl. noch hin - wäre aber auch schön, wenn das über in klassisches Update geht.
Wird es aber noch eine Möglichkeit geben, die persönliche Config aus dem OH4 automatisiert in OH5 zu übertragen?
Ich verstehe, dass es hin und wieder größere Umbrüche in der SW braucht, um zukunftsfähig zu bleiben. Dem Umstand, dass aber viele Liebhaber dann bei ihren "alten Leisten" bleiben, weil der Umstieg mit zu viel Risiko behaftet ist, wird hoffentlich noch Rechnung getragen?
Vielen herzlichen Dank
Tom
Updatehilfe von OH 4 auf OH 5
- udo1toni
- Beiträge: 15546
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Updatehilfe von OH 4 auf OH 5
Du kannst immer (egal von welcher Version Du kommst) die Konfiguration sichern und in der neuen Version einspielen.
Natürlich gibt es ein paar Einschränkungen, aber die betreffen vor allem die richtig alten Versionen (V1 hatte z.B. noch kein Backup Werkzeug an Bord) und das Grundsatz ist so korrekt.
Solange Du Dich in der Version aufwärts bewegst, wirst Du auch nur wenige Überraschungen erleben, aber es gibt immer (selbst bei Minor Updates) Breaking Changes. Entsprechend ist es wichtig, sich alle Changelogs aller Zwischenversionen anzuschauen. Man muss es nicht en detail lesen, aber zumindest querlesen sollte man schon. Schau insbesondere, welche Addons Du einsetzt, ob es dort Änderungen gab.
Das Verhalten der Persistence wurde z.B. mit dem Umstieg auf 5.1 geändert (wobei es früher schon mal so war... unter V1...), dahingehend, dass nun keine Persistence per default Items sichert. Man muss mindestens eine Strategy für * definieren, um dies wieder zu erreichen.
Ich bin mir gerade nicht sicher, ob es viele andere Änderungen zwischen 4.1 und 5.0 gab, das ist schon so lange her...
Was das eigentliche Update betrifft, wäre die erste Frage, ob Dein altes System noch ein 32-Bit-Image ist (vermutlich ja...) Ein In situ Update von 32 Bit auf 64 Bit ist meines Wissens nicht möglich, Du wirst in diesem Fall also so oder so neu installieren müssen. Das ist aber eine Beschränkung des OS, nicht von openHAB selbst.
Falls Du allerdings schon 64 Bit hast, steht es Dir frei, das Betriebssystem zunächst auf bookworm anzuheben:
und anschließend das Upgrade nach trixie zu vollziehen:
In der Theorie sollte openHAB dabei alle wesentlichen Dinge selbst beachten, aber wer will sich schon auf Theorie verlassen...
Was machen die einzelnen Befehle?
apt-mark dient dazu, eine bestehende Version "anzupinnen", d.h. apt upgrade wird diese(s) Paket(e) nicht anfassen.
Anschließend wird das System auf den letzten Stand gebracht (apt update && apt full-upgrade), notfalls werden auch neue Pakete installiert.
Danach wird in allen Dateien unterhalb /etc/apt/ die Buchstabenfolge bullseye durch bookworm ersetzt.
Anschließend werden die "neuen" Pakete installiert.
trixie bringt ein neues Konfigurationsformat für die Paketquellen mit, apt modernize-sources aktualisiert die Dateien passend.
Zum Abschluss muss dann noch Java 21 eingespielt und openHAB selbst upgegradet werden.
Wie gesagt, das geht, aber nur, wenn Du schon auf 64 Bit bist.
Ansonsten gilt:
Das fertige zip-Archiv landet in $OPENHAB_USERDATA/backups/ und kann von dort auf die neue SD-Karte (mit trixie 64-Bit) kopiert werden.
Sobald Du openHAB 5 mit Java21 einmal gestartet hast, kannst Du es wieder stoppen und mittels
Deine Daten wiederherstellen.
Als Nacharbeiten musst Du dann noch unbedingt (!) die folgenden Befehle absetzen:
Ersterer löscht die "zuviel" kopierten Dateien vom Backup, Letzterer sorgt dafür, dass ale Dateien und Verzeichnisse dem richtigen User zugeordnet sind.
Wenn Du beim Backup das --full weg lässt, werden nur die Konfigurationsdaten gesichert, nicht aber die Persistence (mapdb und rrd4j). Ein solches Backup beinhaltet auch keinen Cache, so dass man evtl. sogar auf den entsprechenden Befehl verzichten könnte, aber das Aufräumen schadet nicht
Bleibt man bei der identischen Version, kann der Cache auch erhalten bleiben.
Wenn das Restore auf einer anderen als der Quellversion erfolgt, muss hingegen der Cache gelöscht werden, damit openHAB beim ersten Start die zur Version passenden Addons lädt.
Natürlich gibt es ein paar Einschränkungen, aber die betreffen vor allem die richtig alten Versionen (V1 hatte z.B. noch kein Backup Werkzeug an Bord) und das Grundsatz ist so korrekt.
Solange Du Dich in der Version aufwärts bewegst, wirst Du auch nur wenige Überraschungen erleben, aber es gibt immer (selbst bei Minor Updates) Breaking Changes. Entsprechend ist es wichtig, sich alle Changelogs aller Zwischenversionen anzuschauen. Man muss es nicht en detail lesen, aber zumindest querlesen sollte man schon. Schau insbesondere, welche Addons Du einsetzt, ob es dort Änderungen gab.
Das Verhalten der Persistence wurde z.B. mit dem Umstieg auf 5.1 geändert (wobei es früher schon mal so war... unter V1...), dahingehend, dass nun keine Persistence per default Items sichert. Man muss mindestens eine Strategy für * definieren, um dies wieder zu erreichen.
Ich bin mir gerade nicht sicher, ob es viele andere Änderungen zwischen 4.1 und 5.0 gab, das ist schon so lange her...
Was das eigentliche Update betrifft, wäre die erste Frage, ob Dein altes System noch ein 32-Bit-Image ist (vermutlich ja...) Ein In situ Update von 32 Bit auf 64 Bit ist meines Wissens nicht möglich, Du wirst in diesem Fall also so oder so neu installieren müssen. Das ist aber eine Beschränkung des OS, nicht von openHAB selbst.
Falls Du allerdings schon 64 Bit hast, steht es Dir frei, das Betriebssystem zunächst auf bookworm anzuheben:
Code: Alles auswählen
sudo apt-mark hold openhab openhab-addons
sudo apt update && sudo apt -y full-upgrade
...
reboot
...
grep -rl bullseye /etc/apt/ | sudo xargs sed -i 's/bullseye/bookworm/g'
sudo apt update && sudo apt -y full-upgrade
...
reboot
Code: Alles auswählen
grep -rl bookworm /etc/apt/ | sudo xargs sed -i 's/bookworm/trixie/g'
sudo apt update && sudo apt -y full-upgrade
...
reboot
...
sudo apt modernize-sources
sudo apt-mark unhold openhab openhab-addons
sudo apt install -y openjdk-21-jre-headless
sudo apt update && sudo apt -y full-upgrade
Was machen die einzelnen Befehle?
apt-mark dient dazu, eine bestehende Version "anzupinnen", d.h. apt upgrade wird diese(s) Paket(e) nicht anfassen.
Anschließend wird das System auf den letzten Stand gebracht (apt update && apt full-upgrade), notfalls werden auch neue Pakete installiert.
Danach wird in allen Dateien unterhalb /etc/apt/ die Buchstabenfolge bullseye durch bookworm ersetzt.
Anschließend werden die "neuen" Pakete installiert.
trixie bringt ein neues Konfigurationsformat für die Paketquellen mit, apt modernize-sources aktualisiert die Dateien passend.
Zum Abschluss muss dann noch Java 21 eingespielt und openHAB selbst upgegradet werden.
Wie gesagt, das geht, aber nur, wenn Du schon auf 64 Bit bist.
Ansonsten gilt:
Code: Alles auswählen
sudo openhab-cli backup --fullSobald Du openHAB 5 mit Java21 einmal gestartet hast, kannst Du es wieder stoppen und mittels
Code: Alles auswählen
sudo openhab-cli restore /pfad/zur/zip-dateiAls Nacharbeiten musst Du dann noch unbedingt (!) die folgenden Befehle absetzen:
Code: Alles auswählen
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownershipWenn Du beim Backup das --full weg lässt, werden nur die Konfigurationsdaten gesichert, nicht aber die Persistence (mapdb und rrd4j). Ein solches Backup beinhaltet auch keinen Cache, so dass man evtl. sogar auf den entsprechenden Befehl verzichten könnte, aber das Aufräumen schadet nicht
Bleibt man bei der identischen Version, kann der Cache auch erhalten bleiben.
Wenn das Restore auf einer anderen als der Quellversion erfolgt, muss hingegen der Cache gelöscht werden, damit openHAB beim ersten Start die zur Version passenden Addons lädt.
openHAB5.0.3 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime - LXC, 4 Kerne, 3 GByte RAM)
Hostsystem Proxmox 9.1.4 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte
Hostsystem Proxmox 9.1.4 - AMD Ryzen 5 3600 6 Kerne, 12 Threads - 64 GByte RAM - ZFS Pools: Raid Z1, 3 x 20 TB HDD -> 40 TByte und Raid Z0-Mirrored 4 x 1 TByte NVMe -> 2 TByte
-
Corsair83
- Beiträge: 2
- Registriert: 28. Dez 2019 12:22
Re: Updatehilfe von OH 4 auf OH 5
Hallo Udo,
vielen herzlichen Dank für die schnelle Rückmeldung.
Dann werde ich mich mal daran versuchen.
Ich bin in der Tat noch auf 32 bit.
Melde mich wieder wenn ich wo hänge, bzw. wenn es funktioniert hat
.
VG
Tom
vielen herzlichen Dank für die schnelle Rückmeldung.
Dann werde ich mich mal daran versuchen.
Ich bin in der Tat noch auf 32 bit.
Melde mich wieder wenn ich wo hänge, bzw. wenn es funktioniert hat
VG
Tom