NEWS
[HowTo] ioBroker unter Docker auf Synology DiskStation
-
@Scheddy das es ein Backup einer älteren Version ist sollte kein Problem sein. Aktuelles Image nehmen, neuen Ordner für iobroker data und da das eine Backup file rein und wenn was nicht klappen sollte dann bitte das Log file vom Container start posten.
@duffbeer2000 okay danke schon mal für die Info das alte Backups funktionieren sollten.
Ich habe es gerade noch mal gestartet mit den Backups und leerem Ordner, wie von dir beschrieben.
Anbei alle wichtigen Logs, ich sehe leider nix was mir weiterhelfen würde.
iobrokerneu.html iobroker.2020-03-28.log restore.log -
@duffbeer2000 okay danke schon mal für die Info das alte Backups funktionieren sollten.
Ich habe es gerade noch mal gestartet mit den Backups und leerem Ordner, wie von dir beschrieben.
Anbei alle wichtigen Logs, ich sehe leider nix was mir weiterhelfen würde.
iobrokerneu.html iobroker.2020-03-28.log restore.log@Scheddy Sehr komisch, ich bin auch damit auf die 2er js-controller version inkl. Node.js upgrade gegangen. Was ist denn wenn du den Backitup Adapter installierst und dann damit ein Restore durchführst?
Bzw. andere Idee:- Du startest den Container mit einem leeren Data-Folder und wartest kurz bis du auf die Admin-Oberfläche kommst.
- Dann stoppst du den Container wieder und löscht aus dem Daten-Verzeichnis des Containers den Ordner "iobroker-data" und kopierst von deinem alten Container den Ordner "iobroker-data" in das neue Datenverzeichnis.
- Jetzt startest du den neuen Container wieder und ioBroker sollte anfangen alle fehlenden Adapter zu installieren.
-
@Scheddy Sehr komisch, ich bin auch damit auf die 2er js-controller version inkl. Node.js upgrade gegangen. Was ist denn wenn du den Backitup Adapter installierst und dann damit ein Restore durchführst?
Bzw. andere Idee:- Du startest den Container mit einem leeren Data-Folder und wartest kurz bis du auf die Admin-Oberfläche kommst.
- Dann stoppst du den Container wieder und löscht aus dem Daten-Verzeichnis des Containers den Ordner "iobroker-data" und kopierst von deinem alten Container den Ordner "iobroker-data" in das neue Datenverzeichnis.
- Jetzt startest du den neuen Container wieder und ioBroker sollte anfangen alle fehlenden Adapter zu installieren.
@duffbeer2000 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@Scheddy Sehr komisch, ich bin auch damit auf die 2er js-controller version inkl. Node.js upgrade gegangen. Was ist denn wenn du den Backitup Adapter installierst und dann damit ein Restore durchführst?
Bzw. andere Idee:- Du startest den Container mit einem leeren Data-Folder und wartest kurz bis du auf die Admin-Oberfläche kommst.
- Dann stoppst du den Container wieder und löscht aus dem Daten-Verzeichnis des Containers den Ordner "iobroker-data" und kopierst von deinem alten Container den Ordner "iobroker-data" in das neue Datenverzeichnis.
- Jetzt startest du den neuen Container wieder und ioBroker sollte anfangen alle fehlenden Adapter zu installieren.
Die andere Idee scheint zu funktionieren. Adapter sind installier mein VIS läuft. Bisher noch nix aufgefallen was NICHT funktioniert
Ich hoffe es bleibt so. Tausend Dank für deine Hilfe! -
@duffbeer2000 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@Scheddy Sehr komisch, ich bin auch damit auf die 2er js-controller version inkl. Node.js upgrade gegangen. Was ist denn wenn du den Backitup Adapter installierst und dann damit ein Restore durchführst?
Bzw. andere Idee:- Du startest den Container mit einem leeren Data-Folder und wartest kurz bis du auf die Admin-Oberfläche kommst.
- Dann stoppst du den Container wieder und löscht aus dem Daten-Verzeichnis des Containers den Ordner "iobroker-data" und kopierst von deinem alten Container den Ordner "iobroker-data" in das neue Datenverzeichnis.
- Jetzt startest du den neuen Container wieder und ioBroker sollte anfangen alle fehlenden Adapter zu installieren.
Die andere Idee scheint zu funktionieren. Adapter sind installier mein VIS läuft. Bisher noch nix aufgefallen was NICHT funktioniert
Ich hoffe es bleibt so. Tausend Dank für deine Hilfe!@Scheddy Perfekt, das freut mich zu hören. Wenns jetzt nicht geklappt hätte wäre ich auch überfragt gewesen
-
@FoodFighter
Scheinbar lag der Fehler darin, dass die Paketebuild-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devnicht installiert werden, wenn man sie in der ENV-Variable einträgt.
Wenn der Container hochgefahren ist und man über dessen Konsole
sudo apt-get install build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devausführt, werden keine Pakete gefunden - man MUSS vorher ein
sudo apt-get updateausführen, danach kann man über die Konsole die Pakete installieren, dann funktioniert auch alles.
Wieso ist das so und wieso macht der start-script nicht automatisch ein apt-get update?
@FoodFighter
Was sagt denn das Logfile beim Starten des Containers zur Installation der von dir gewünschten Pakete? Eigentlich sollte die dann dort aufgelistet werden.@andre
Könntest du vielleicht noch mal die Anleitung zum Update des js-controllers mit in die Readme auf Github aufnehmen?
Vielleicht wäre es ja sogar möglich, dass dein Startscript das auf Wunsch (env Variabel) oder nach Prüfung ob ansonsten alle Adapter aktuell sind automatisch macht? -
@Holzlenkrad
Ja, die Pakete werden in der Startscript-log aufgelistet.
Das Problem war, dass ich das per default eingetragene "vi" noch vor allen anderen Paketen drin hatte. Vi existiert in der Paketliste (arm7 - RaspberryPi4) aber nicht, so wurde die apt-get install direkt bei vi abgebrochen und hat die anderen Pakete erst gar nicht angetastet.
Leider wird dies (noch ?) nicht in der log gemeldet, dass es bei der apt-get install einen fehler gab und nicht alle Pekete installiert werden konnten.Sobald ich das "vi" aus der ENV-PACKAGES-Variable raus gelöscht habe, funktioniert alles, wie es soll.
Wieso man die Pakete nach dem Hochfahren erst nach einem erneuten apt-get update installieren konnte bleibt mir schleierhaft - aber nun funktioniert ja alles beim Container-Start, von daher bin ich zufrieden.
Danke -
@Holzlenkrad
Ja, die Pakete werden in der Startscript-log aufgelistet.
Das Problem war, dass ich das per default eingetragene "vi" noch vor allen anderen Paketen drin hatte. Vi existiert in der Paketliste (arm7 - RaspberryPi4) aber nicht, so wurde die apt-get install direkt bei vi abgebrochen und hat die anderen Pakete erst gar nicht angetastet.
Leider wird dies (noch ?) nicht in der log gemeldet, dass es bei der apt-get install einen fehler gab und nicht alle Pekete installiert werden konnten.Sobald ich das "vi" aus der ENV-PACKAGES-Variable raus gelöscht habe, funktioniert alles, wie es soll.
Wieso man die Pakete nach dem Hochfahren erst nach einem erneuten apt-get update installieren konnte bleibt mir schleierhaft - aber nun funktioniert ja alles beim Container-Start, von daher bin ich zufrieden.
Danke@FoodFighter said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Wieso man die Pakete nach dem Hochfahren erst nach einem erneuten apt-get update installieren konnte bleibt mir schleierhaft - aber nun funktioniert ja alles beim Container-Start, von daher bin ich zufrieden.
Das liegt daran, weil es bei Docker Container best practice ist, die Paketlisten nach der Installation der benötigten Pakete wieder zu löschen. Somit reduziert man die Image-Größe und - viel wichtiger - sorgt dafür, dass ein möglichst großer Teil des Containers mit evtl. anderen verwendeten Container übereinstimmt, sodass möglichst viele Ressourcen für mehrere Container genutzt werden können.
-
@FoodFighter said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Wieso man die Pakete nach dem Hochfahren erst nach einem erneuten apt-get update installieren konnte bleibt mir schleierhaft - aber nun funktioniert ja alles beim Container-Start, von daher bin ich zufrieden.
Das liegt daran, weil es bei Docker Container best practice ist, die Paketlisten nach der Installation der benötigten Pakete wieder zu löschen. Somit reduziert man die Image-Größe und - viel wichtiger - sorgt dafür, dass ein möglichst großer Teil des Containers mit evtl. anderen verwendeten Container übereinstimmt, sodass möglichst viele Ressourcen für mehrere Container genutzt werden können.
@Holzlenkrad
Vielen Dank für die Aufklärung -
@Holzlenkrad
Ja, die Pakete werden in der Startscript-log aufgelistet.
Das Problem war, dass ich das per default eingetragene "vi" noch vor allen anderen Paketen drin hatte. Vi existiert in der Paketliste (arm7 - RaspberryPi4) aber nicht, so wurde die apt-get install direkt bei vi abgebrochen und hat die anderen Pakete erst gar nicht angetastet.
Leider wird dies (noch ?) nicht in der log gemeldet, dass es bei der apt-get install einen fehler gab und nicht alle Pekete installiert werden konnten.Sobald ich das "vi" aus der ENV-PACKAGES-Variable raus gelöscht habe, funktioniert alles, wie es soll.
Wieso man die Pakete nach dem Hochfahren erst nach einem erneuten apt-get update installieren konnte bleibt mir schleierhaft - aber nun funktioniert ja alles beim Container-Start, von daher bin ich zufrieden.
Danke@FoodFighter sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Das Problem war, dass ich das per default eingetragene "vi" noch vor allen anderen Paketen drin hatte. Vi existiert in der Paketliste (arm7 - RaspberryPi4) aber nicht, so wurde die apt-get install direkt bei vi abgebrochen und hat die anderen Pakete erst gar nicht angetastet.
Leider wird dies (noch ?) nicht in der log gemeldet, dass es bei der apt-get install einen fehler gab und nicht alle Pekete installiert werden konnten.Dazu habe ich bereits was gemacht. Ist aber aktuell noch nicht im beta vorhanden. Werde die Option erst testen und dann ins nächste Beta überführen.
https://github.com/buanet/docker-iobroker/issues/86#issuecomment-609089241
MfG,
André -
Hallo Andre,
Ich habe bei meiner Installation immer wieder das Problem, dass die Verbindung zum Zigbee Stick verloren geht.
Das passiert ca. 1x pro Woche und dann hilft nur ein kompletter neustart der Synology.
Die ENV ist wie volgt eingetragen: USBDEVICES=/dev/ttyACM1 und der Stick ist auch am ttyACM1 wenn ich mit WinSCP prüfe.
Was kann da sein?
Mein System sieht wie folgt aus:- Hardware Synology 918+
IoBroker Docker Image von Andre
Zigbee Coordinator CC2538 von dimaiv
Zigbee Geräte 22Stk.
Sonoff Geräte 32Stk.
- Hardware Synology 918+
-
Hallo Andre,
Ich habe bei meiner Installation immer wieder das Problem, dass die Verbindung zum Zigbee Stick verloren geht.
Das passiert ca. 1x pro Woche und dann hilft nur ein kompletter neustart der Synology.
Die ENV ist wie volgt eingetragen: USBDEVICES=/dev/ttyACM1 und der Stick ist auch am ttyACM1 wenn ich mit WinSCP prüfe.
Was kann da sein?
Mein System sieht wie folgt aus:- Hardware Synology 918+
IoBroker Docker Image von Andre
Zigbee Coordinator CC2538 von dimaiv
Zigbee Geräte 22Stk.
Sonoff Geräte 32Stk.
@gerald123
Also zunächst solltest du mal zum Ansprechen des Sticks /dev/serial/by-id/xxx nutzen, denn dann ändert sich der Pfad des Stick garantiert nie.Hab auch den Zigbee-Stick und damit keine Probleme. Adapter neustarten hilft nicht?
- Hardware Synology 918+
-
@andre
Ich bin jetzt auch auf dein Docker Image umgestiegen, nachdem ich mir das lange Zeit selbst erstellt habe auf Grundlage deines Dockerfiles, denn für den Raspberry Pi gibt es dein Image erst seit kurzem. Danke dafür.Mein Dockerfile war praktisch identisch zu deinem, nur halt minus ENV, weil ich mein Dockerfile ja ohnehin selbst anpassen konnte.
Allerdings habe ich schon vor ein paar Monaten das Base Image auf debian:buster geändert und das funktioniert absolut ohne Probleme.
Du bist immer noch auf Stretch, weil es irgendwann mal irgendwelche Probleme gab oder? Hast du mittlerweile mal wieder Buster ausprobiert? Können wir dir vielleicht bei konkreten Problemen weiter helfen?Da meine sonstigen Docker Container mittlerweile auch alle auf Buster basieren wäre es im Sinne der Ressourcen-Ersparnis schon praktisch, wenn du auch den Schritt gehen könntest
Und was ist der Hintergrund, dass du für ARM das Balena-Image nutzt? -
@gerald123
Also zunächst solltest du mal zum Ansprechen des Sticks /dev/serial/by-id/xxx nutzen, denn dann ändert sich der Pfad des Stick garantiert nie.Hab auch den Zigbee-Stick und damit keine Probleme. Adapter neustarten hilft nicht?
@Holzlenkrad aber leider gibt es bei mir kein Verzeichnis /serial oder wie kann ich das anlegen
-
@andre
Ich bin jetzt auch auf dein Docker Image umgestiegen, nachdem ich mir das lange Zeit selbst erstellt habe auf Grundlage deines Dockerfiles, denn für den Raspberry Pi gibt es dein Image erst seit kurzem. Danke dafür.Mein Dockerfile war praktisch identisch zu deinem, nur halt minus ENV, weil ich mein Dockerfile ja ohnehin selbst anpassen konnte.
Allerdings habe ich schon vor ein paar Monaten das Base Image auf debian:buster geändert und das funktioniert absolut ohne Probleme.
Du bist immer noch auf Stretch, weil es irgendwann mal irgendwelche Probleme gab oder? Hast du mittlerweile mal wieder Buster ausprobiert? Können wir dir vielleicht bei konkreten Problemen weiter helfen?Da meine sonstigen Docker Container mittlerweile auch alle auf Buster basieren wäre es im Sinne der Ressourcen-Ersparnis schon praktisch, wenn du auch den Schritt gehen könntest
Und was ist der Hintergrund, dass du für ARM das Balena-Image nutzt?@Holzlenkrad said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Da meine sonstigen Docker Container mittlerweile auch alle auf Buster basieren wäre es im Sinne der Ressourcen-Ersparnis schon praktisch, wenn du auch den Schritt gehen könntest
Man mag mich jetzt steinigen, aber ich habe den buanet-iobroker-container auf einem RaspPi 4 mit raspbian buster lite (2020-02-13) laufen und bis auf den rpi2.0-adapter, der ständig
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied /bin/sh: 1: vcgencmd: not foundmeckert, könnte ich jetzt so keine weiteren Probleme feststellen.
Mir war ehrlich gesagt gar nicht bewusst, dass ich hätte darauf achten müssen, auf welcher Version der Container basiert.
Oder meinst du mit "Ressourcen-Ersparnis" was anderes? -
@Holzlenkrad aber leider gibt es bei mir kein Verzeichnis /serial oder wie kann ich das anlegen
@gerald123 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@Holzlenkrad aber leider gibt es bei mir kein Verzeichnis /serial oder wie kann ich das anlegen
Ach ich erinnere mich. Bei Synology ist ja vieles anders, als bei einem normalen Linux. Kann also sein, dass es das Verzeichnis wirklich nicht gibt.
@FoodFighter
Ich kann mir vorstellen, dass du diese cpuinfo...-Datei in den Docker Container rein reichen musst, damit der Adapter darauf zugreifen kann. Also mit -v usw. -
@andre
Ich bin jetzt auch auf dein Docker Image umgestiegen, nachdem ich mir das lange Zeit selbst erstellt habe auf Grundlage deines Dockerfiles, denn für den Raspberry Pi gibt es dein Image erst seit kurzem. Danke dafür.Mein Dockerfile war praktisch identisch zu deinem, nur halt minus ENV, weil ich mein Dockerfile ja ohnehin selbst anpassen konnte.
Allerdings habe ich schon vor ein paar Monaten das Base Image auf debian:buster geändert und das funktioniert absolut ohne Probleme.
Du bist immer noch auf Stretch, weil es irgendwann mal irgendwelche Probleme gab oder? Hast du mittlerweile mal wieder Buster ausprobiert? Können wir dir vielleicht bei konkreten Problemen weiter helfen?Da meine sonstigen Docker Container mittlerweile auch alle auf Buster basieren wäre es im Sinne der Ressourcen-Ersparnis schon praktisch, wenn du auch den Schritt gehen könntest
Und was ist der Hintergrund, dass du für ARM das Balena-Image nutzt?@Holzlenkrad said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Balena
Das Balena-Image für ARM kommt durch die eingebaute cross-build Funktionalität um ARM-Container zu bauen. Da gab es mit den standard Base-Images von Debian vorher Probleme.
-
@Holzlenkrad said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Da meine sonstigen Docker Container mittlerweile auch alle auf Buster basieren wäre es im Sinne der Ressourcen-Ersparnis schon praktisch, wenn du auch den Schritt gehen könntest
Man mag mich jetzt steinigen, aber ich habe den buanet-iobroker-container auf einem RaspPi 4 mit raspbian buster lite (2020-02-13) laufen und bis auf den rpi2.0-adapter, der ständig
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied /bin/sh: 1: vcgencmd: not foundmeckert, könnte ich jetzt so keine weiteren Probleme feststellen.
Mir war ehrlich gesagt gar nicht bewusst, dass ich hätte darauf achten müssen, auf welcher Version der Container basiert.
Oder meinst du mit "Ressourcen-Ersparnis" was anderes?@FoodFighter Die Ressourcen-Ersparnis kommt von vielen gleichen Base-Images
Container Base-Image Runtime Anwendung
A Debian-Stretch xy app1
B Debian-Buster xy app2
C Debian-Buster xy app3Somit läuft auf dem Host einmal das Base-Image Debian-Stretch und einmal Debian-Buster. Stellt man Container A jetzt auch auf Debian-Buster um spare ich mir die Ressourcen und den Plattenplatz für Debian-Stretch da nur noch einmal Debian-Buster läuft.
-
@FoodFighter Die Ressourcen-Ersparnis kommt von vielen gleichen Base-Images
Container Base-Image Runtime Anwendung
A Debian-Stretch xy app1
B Debian-Buster xy app2
C Debian-Buster xy app3Somit läuft auf dem Host einmal das Base-Image Debian-Stretch und einmal Debian-Buster. Stellt man Container A jetzt auch auf Debian-Buster um spare ich mir die Ressourcen und den Plattenplatz für Debian-Stretch da nur noch einmal Debian-Buster läuft.
@duffbeer2000
Also emuliert ein Stretch-Base-Container, der auf einem buster-system läuft die komplette stretch-distribution?
Dann müsste der Container ja weit größer sein.
Irgendwas verstehe ich wohl grade falsch.Ich hatte das erst so verstanden, dass ein Container, der auf Stretch basiert, eventuell gar nicht unter/in einem buster-docker-host läuft...wäre hier aber der Fall.
-
@duffbeer2000
Also emuliert ein Stretch-Base-Container, der auf einem buster-system läuft die komplette stretch-distribution?
Dann müsste der Container ja weit größer sein.
Irgendwas verstehe ich wohl grade falsch.Ich hatte das erst so verstanden, dass ein Container, der auf Stretch basiert, eventuell gar nicht unter/in einem buster-docker-host läuft...wäre hier aber der Fall.
@FoodFighter Nein das verstehst du nicht komplett falsch, das Base-Image enthält aber nur die wichtigsten Komponenten der Distribution. Den Kernel teilt es sich z.B. mit dem Host. Deshalb sind die Base-Images auch so klein.
Ein Container der auf Stretch basiert läuft auch unter einem Host mit Buster. -
@FoodFighter Nein das verstehst du nicht komplett falsch, das Base-Image enthält aber nur die wichtigsten Komponenten der Distribution. Den Kernel teilt es sich z.B. mit dem Host. Deshalb sind die Base-Images auch so klein.
Ein Container der auf Stretch basiert läuft auch unter einem Host mit Buster.@duffbeer2000
Vielen Dank, jetzt hab ich's kapiert.
754
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge