NEWS
VIS 1.14.5 lässt sich nicht installieren
-
@homoran sagte in VIS 1.14.5 lässt sich nicht installieren:
das müsste sich @apollon77 dann nochmal aktuell ansehen.
@Bluefox ist da richtiger in dem Fall Ist schon weitergegeben
-
@homoran Könnte das nicht auch ein Grund für die Probleme beim Restore sein? Mir ist auch noch aufgefallen, dass web bei meinem prod System nach den Restore 4.2.3 hat, obwohl ich vor dem Backup alle Adapter aktualisiert hatte. Zudem wird mir nur 4.3.0 angeboten. Installiere ich das Update ist VIS tot.
P.S.: Es gibt auch noch einen Unterschied zwischen CLI und GUI. Ich versuche ja gerade die Situation von meinem Prod System nachzustellen. Der Befehl iobroker install web@4.2.3 installiert die non npm Version ohne Abhängigkeiten wie socket.io / Web Socket während die GUI alles korrekt macht. Ist das so vorgesehen?
-
Also, ich gebe an dieser Stelle mal auf. Ich bin nicht mehr in der Lage ein Restore auf den test System zu fahren. Jeder Versuch endet damit, dass kein Adapter mehr gestartet werden kann (weiter oben beschrieben)
So schaut es vor dem Restore aus:
Used repository: stable Adapter "admin" : 5.3.8 , installed 5.3.8 Adapter "backitup" : 2.4.9 , installed 2.4.9 Adapter "discovery" : 3.0.3 , installed 3.0.3 Controller "js-controller": 4.0.23 , installed 4.0.23 Adapter "simple-api" : 2.6.5 , installed 2.7.0 Adapter "socketio" : 4.2.0 , installed 4.2.0 Adapter "web" : 4.3.0 , installed 4.3.0 Adapter "ws" : 1.3.0 , installed 1.3.0
und so danach:
Used repository: stable Adapter "admin" : 5.3.8 , installed 5.3.8 Adapter "backitup" : 2.4.9 , installed 2.4.9 Controller "js-controller": 4.0.23 , installed 4.0.23
Plattform wie beschrieben Ubuntu 20.04.4 LTS auf einem C4 mit node 14.
Das Backup stammt vom 15.06.2022 ca. 13:00 Uhr. Der erste Restore auf meinem M1 erfolgte keine Stunde später und war, bis auf das VIS 1.14.5 Thema erfolgreich.
Wenn ich noch irgendwo helfen kann lasst es mich wissen!
-
Ok, Du hast einen Restore gemacht. Schön, damit hat das System an sich den Stand von dem Zeitounkt des Backups - inklusive des repo contents.
Und nahezu keiner der Adapter wird installiert sein weil das nach nem Restore mit neuem js-controller so ist.
Was hast Du jetzt als nächstes getan? ioBroker mal gestartet? oder hast Du nur"iob update" aufgerufen oder was ... Dann für mich mal ganz langsam und strukturiert.
Am besten starten wir ioBroker erstmal und lassen Ihn seine Magie nach dem Restore machen und überhaupt mal die Adapter neu installieren. Also iob start und Warten. Im Logfile unter /opt/iobroker/log/... buw mit "iob logs -f" kannst Du zuschauen was er tut
-
@apollon77 Also, ich habe das nun ein halbes Dutzend Mal mit verschidenen Linux /node Versionen und mal mit mal ohne vorher installiertem VIS / web Adapter durchgeführt. Die ausführliche Beschreibung ist hier zu finden: https://forum.iobroker.net/topic/55574/vis-1-14-5-lässt-sich-nicht-installieren/74
-
@andygr42 am Ende sehe ich folgendes. Nach dem restore sagst finagling und Vis sind tod. Was heißt das? Laut log startet Admin korrekt. Ja er sagt „can not read repository“. Das wäre zu checken.
Das log danach (für mich unklar was du dazwischen getan hast (iob stop?) sagt er das er keine Instanzen startet weil keine dem Host zugewiesen sind. Das heißt das sich der hostname zwischen dem stop und nächsten Start geändert haben muss. Weil er für den aktuellen Hostnamen des Servers keine Instanzen findet.
Also mehr Details bitte.
-
@apollon77 Nach dem Restore bleibt iobroker exakt in diesem Status stehen, wie im Logfile zu sehen. Ich habe stop / start, restart und auch einen kompletten reboot probiert, ändert genauso wenig wie eine Stunde warten. VIS ist eh nicht aktiv und Admin kann auch nicht aufgerufen werden.
Da ich, außer dem Restore, nichts gemacht habe die Frage: ändert ein Restore den Hostname? Wenn ja, dann haben wir die Ursache gefunden. Im Testsystem hat iobroker wohl den Hostname vom OS übernommen, was natürlich nicht mit dem Hostname aus dem Backup übereinstimmt.
Interessant wäre nur, warum hat dies bei meinem prod System funktioniert? Das hat auch einen anderen OS Hostname und ich habe hier vor dem Restore auch den iobroker Hostname nicht geändert.
-
Ok, verpasse ich dem Host den alten Namen läuft der Restore einwandfrei durch. Stellt sich mir nur immer noch die Frage, warum das beim Prod System funktioniert hat. Da habe ich den Hostname definitiv nicht vorher geändert. Ich habe es gerade nochmal im Log nachgesehen.
P.S.: Reproduzierbar, wenn der Hostname nicht übereinstimmt, funktioniert Restore nicht. Im Prinzip würde auch ein zweiter Restore funktionieren, da der Erste den Hostname ändert. Das wäre also ein Fix wenn der erste Restore fehlschlug.
-
@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:
ändert ein Restore den Hostname?
nein. Der Hostname bleibt der, der bei der Betriebssystem Installation vergeben wurde und ist ggf. unterschiedlich zu der in Den Instanzen des Backups vergebenen.
-
@homoran Das ist leider inkorrekt:
2022-06-22 06:57:03.677 - info: host.odroid received SIGTERM 2022-06-22 06:57:03.683 - info: backitup.0 (11567) cleaned everything up... 2022-06-22 06:57:03.683 - info: admin.0 (11537) terminating http server on port 8081 2022-06-22 06:57:03.687 - info: host.odroid stopInstance system.adapter.admin.0 (force=false, process=true) 2022-06-22 06:57:03.688 - info: host.odroid stopInstance system.adapter.discovery.0 (force=false, process=true) 2022-06-22 06:57:03.689 - info: host.odroid stopInstance system.adapter.backitup.0 (force=false, process=true) 2022-06-22 06:57:03.701 - info: admin.0 (11537) Got terminate signal TERMINATE_YOURSELF 2022-06-22 06:57:03.704 - info: discovery.0 (11552) Got terminate signal TERMINATE_YOURSELF 2022-06-22 06:57:03.704 - info: backitup.0 (11567) Got terminate signal TERMINATE_YOURSELF 2022-06-22 06:57:03.708 - info: host.odroid stopInstance system.adapter.admin.0 send kill signal 2022-06-22 06:57:03.710 - info: admin.0 (11537) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2022-06-22 06:57:03.710 - info: backitup.0 (11567) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2022-06-22 06:57:03.710 - info: discovery.0 (11552) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2022-06-22 06:57:03.750 - info: host.odroid stopInstance system.adapter.discovery.0 send kill signal 2022-06-22 06:57:03.751 - info: host.odroid stopInstance system.adapter.backitup.0 send kill signal 2022-06-22 06:57:04.346 - info: host.odroid instance system.adapter.admin.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP) 2022-06-22 06:57:04.380 - info: host.odroid instance system.adapter.backitup.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP) 2022-06-22 06:57:04.382 - info: host.odroid instance system.adapter.discovery.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP) 2022-06-22 06:57:04.382 - info: host.odroid All instances are stopped. 2022-06-22 06:57:04.522 - info: host.odroid terminated 2022-06-22 07:00:22.780 - info: host.gt-iob01 iobroker.js-controller version 4.0.23 js-controller starting 2022-06-22 07:00:22.790 - info: host.gt-iob01 Copyright (c) 2014-2022 bluefox, 2014 hobbyquaker 2022-06-22 07:00:22.791 - info: host.gt-iob01 hostname: gt-iob01, node: v16.15.1 2022-06-22 07:00:22.793 - info: host.gt-iob01 ip addresses: 192.168.67.57 fe80::8db6:672a:d749:62d 2022-06-22 07:00:27.984 - info: host.gt-iob01 connected to Objects and States 2022-06-22 07:00:28.109 - info: host.gt-iob01 added notifications configuration of host 2022-06-22 07:00:29.163 - info: host.gt-iob01 Delete host system.host.odroid 2022-06-22 07:00:29.409 - info: host.gt-iob01 41 instances found 2022-06-22 07:00:29.445 - warn: host.gt-iob01 does not start any instances on this host
-
Starte ich nun den gleichen Restore nochmal, mit dem nun gleichen Hostname, funktioniert es einwandfrei:
2022-06-22 07:00:22.780 - info: host.gt-iob01 iobroker.js-controller version 4.0.23 js-controller starting 2022-06-22 07:00:22.790 - info: host.gt-iob01 Copyright (c) 2014-2022 bluefox, 2014 hobbyquaker 2022-06-22 07:00:22.791 - info: host.gt-iob01 hostname: gt-iob01, node: v16.15.1 2022-06-22 07:00:22.793 - info: host.gt-iob01 ip addresses: 192.168.67.57 fe80::8db6:672a:d749:62d 2022-06-22 07:00:27.984 - info: host.gt-iob01 connected to Objects and States 2022-06-22 07:00:28.109 - info: host.gt-iob01 added notifications configuration of host 2022-06-22 07:00:29.163 - info: host.gt-iob01 Delete host system.host.odroid 2022-06-22 07:00:29.409 - info: host.gt-iob01 41 instances found 2022-06-22 07:00:29.445 - warn: host.gt-iob01 does not start any instances on this host 2022-06-22 07:01:55.692 - info: host.gt-iob01 received SIGTERM 2022-06-22 07:01:55.757 - info: host.gt-iob01 terminated 2022-06-22 07:04:49.372 - info: host.gt-iob01 iobroker.js-controller version 4.0.23 js-controller starting 2022-06-22 07:04:49.381 - info: host.gt-iob01 Copyright (c) 2014-2022 bluefox, 2014 hobbyquaker 2022-06-22 07:04:49.383 - info: host.gt-iob01 hostname: gt-iob01, node: v16.15.1 2022-06-22 07:04:49.385 - info: host.gt-iob01 ip addresses: 192.168.67.57 fe80::8db6:672a:d749:62d 2022-06-22 07:04:55.980 - info: host.gt-iob01 connected to Objects and States 2022-06-22 07:04:56.104 - info: host.gt-iob01 added notifications configuration of host 2022-06-22 07:04:57.186 - info: host.gt-iob01 Delete host system.host.gt-iob01 2022-06-22 07:04:57.443 - info: host.gt-iob01 41 instances found 2022-06-22 07:04:57.505 - warn: host.gt-iob01 startInstance cannot find adapter "devices@1.0.10". Try to install it... 1 attempt 2022-06-22 07:04:57.506 - info: host.gt-iob01 iobroker install devices@1.0.10 using installedFrom 2022-06-22 07:04:57.579 - info: host.gt-iob01 starting 2 instances 2022-06-22 07:04:57.919 - info: host.gt-iob01 instance system.adapter.admin.0 started with pid 11868 2022-06-22 07:05:02.150 - info: host.gt-iob01 instance system.adapter.backitup.0 started with pid 11883 2022-06-22 07:05:03.583 - info: host.gt-iob01 iobroker npm-install: NPM version: 8.11.0Installing iobroker.devices@1.0.10... (System call) 2022-06-22 07:05:05.447 - info: admin.0 (11868) starting. Version 5.3.8 in /opt/iobroker/node_modules/iobroker.admin, node: v16.15.1, js-controller: 4.0.23 2022-06-22 07:05:05.533 - info: admin.0 (11868) requesting all states 2022-06-22 07:05:05.534 - info: admin.0 (11868) requesting all objects
-
@andygr42 Was auch reproduzierbar bleibt ist das Problem mit dem VIS Adapter (weshalb ich überhaupt den ganzen Aufriss mit dem Restore auf dem Test System gemacht habe):
2022-06-22 07:25:37.356 - warn: host.gt-iob01 startInstance cannot find adapter "vis@1.4.15". Try to install it... 2 attempt 2022-06-22 07:25:37.356 - info: host.gt-iob01 iobroker install vis@1.4.15 using installedFrom 2022-06-22 07:25:41.477 - info: host.gt-iob01 iobroker npm-install: NPM version: 8.11.0 2022-06-22 07:25:41.479 - info: host.gt-iob01 iobroker npm-install: Installing iobroker.vis@1.4.15... (System call) 2022-06-22 07:25:56.983 - info: vis.0 (14042) starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v16.15.1, js-controller: 4.0.23 2022-06-22 07:25:57.179 - info: vis.0 (14042) vis license is OK. 2022-06-22 07:25:57.515 - error: vis.0 (14042) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 2022-06-22 07:25:57.517 - error: vis.0 (14042) unhandled promise rejection: Not exists 2022-06-22 07:25:57.521 - error: vis.0 (14042) Error: Not exists at Object.maybeCallbackWithError (/opt/iobroker/node_modules/@iobroker/js-controller-common/lib/common/tools.js:2973:17) at ObjectsInRedisClient._readFile (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1043:26) at Immediate.<anonymous> (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1092:29) at processImmediate (node:internal/timers:468:21) 2022-06-22 07:25:57.524 - error: vis.0 (14042) Not exists 2022-06-22 07:25:58.031 - info: vis.0 (14042) terminating 2022-06-22 07:25:58.033 - warn: vis.0 (14042) Terminated (UNCAUGHT_EXCEPTION): Without reason 2022-06-22 07:25:58.869 - error: host.gt-iob01 iobroker npm-install: host.gt-iob01 Cannot install iobroker.vis@1.4.15: 6 2022-06-22 07:25:59.905 - info: host.gt-iob01 iobroker npm-install: exit 25 2022-06-22 07:26:00.905 - warn: host.gt-iob01 startInstance cannot find adapter "vis@1.4.15". Try to install it... 3 attempt 2022-06-22 07:26:00.908 - info: host.gt-iob01 iobroker install vis@1.4.15 using installedVersion 2022-06-22 07:26:04.954 - info: host.gt-iob01 iobroker npm-install: NPM version: 8.11.0 2022-06-22 07:26:04.957 - info: host.gt-iob01 iobroker npm-install: Installing iobroker.vis@1.4.15... (System call) 2022-06-22 07:26:20.268 - info: vis.0 (14088) starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v16.15.1, js-controller: 4.0.23 2022-06-22 07:26:20.451 - info: vis.0 (14088) vis license is OK. 2022-06-22 07:26:20.799 - error: vis.0 (14088) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 2022-06-22 07:26:20.801 - error: vis.0 (14088) unhandled promise rejection: Not exists 2022-06-22 07:26:20.806 - error: vis.0 (14088) Error: Not exists at Object.maybeCallbackWithError (/opt/iobroker/node_modules/@iobroker/js-controller-common/lib/common/tools.js:2973:17) at ObjectsInRedisClient._readFile (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1043:26) at Immediate.<anonymous> (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1092:29) at processImmediate (node:internal/timers:468:21) 2022-06-22 07:26:20.808 - error: vis.0 (14088) Not exists 2022-06-22 07:26:21.315 - info: vis.0 (14088) terminating 2022-06-22 07:26:21.317 - warn: vis.0 (14088) Terminated (UNCAUGHT_EXCEPTION): Without reason 2022-06-22 07:26:22.166 - error: host.gt-iob01 iobroker npm-install: host.gt-iob01 Cannot install iobroker.vis@1.4.15: 6 2022-06-22 07:26:23.210 - info: host.gt-iob01 iobroker npm-install: exit 25 2022-06-22 07:26:24.211 - warn: host.gt-iob01 startInstance cannot find adapter "vis@1.4.15". Try to install it... 4 attempt 2022-06-22 07:26:24.212 - info: host.gt-iob01 iobroker install vis@1.4.15 using installedVersion 2022-06-22 07:26:28.304 - info: host.gt-iob01 iobroker npm-install: NPM version: 8.11.0 2022-06-22 07:26:28.307 - info: host.gt-iob01 iobroker npm-install: Installing iobroker.vis@1.4.15... (System call) 2022-06-22 07:26:43.559 - info: vis.0 (14134) starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v16.15.1, js-controller: 4.0.23 2022-06-22 07:26:43.772 - info: vis.0 (14134) vis license is OK. 2022-06-22 07:26:44.107 - error: vis.0 (14134) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 2022-06-22 07:26:44.109 - error: vis.0 (14134) unhandled promise rejection: Not exists 2022-06-22 07:26:44.114 - error: vis.0 (14134) Error: Not exists at Object.maybeCallbackWithError (/opt/iobroker/node_modules/@iobroker/js-controller-common/lib/common/tools.js:2973:17) at ObjectsInRedisClient._readFile (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1043:26) at Immediate.<anonymous> (/opt/iobroker/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:1092:29) at processImmediate (node:internal/timers:468:21) 2022-06-22 07:26:44.116 - error: vis.0 (14134) Not exists 2022-06-22 07:26:44.623 - info: vis.0 (14134) terminating 2022-06-22 07:26:44.625 - warn: vis.0 (14134) Terminated (UNCAUGHT_EXCEPTION): Without reason 2022-06-22 07:26:45.474 - error: host.gt-iob01 iobroker npm-install: host.gt-iob01 Cannot install iobroker.vis@1.4.15: 6 2022-06-22 07:26:46.508 - info: host.gt-iob01 iobroker npm-install: exit 25 2022-06-22 07:26:47.509 - error: host.gt-iob01 Cannot download and install adapter "vis@1.4.15". To retry it disable/enable the adapter or restart host. Also check the error messages in the log!
-
@andygr42 wo wir wieder bei dem Thema sind
https://forum.iobroker.net/post/813432
Unter anderem würde es wahrscheinlich auch mit einer älteren js-controller Version funktionieren. Ab welcher das Problem jedoch aufkam, kann ich aber nicht aus dem Stehgreif sagen, das war irgendwo in einem anderen Thread. -
@crunchip Ja, hier bin ich auch einen Schritt weiter. Ich muss das aber nochmal sauber reproduzieren. Es scheint aber so, als ob man bei gestoppten iobroker mit "npm install iobroker.vis" einen Zustand herstellen kann, dass beim nächsten Start von iobroker VIS automatisch installiert wird. Wie gesagt, muss ich nochmal reproduzieren.
P.S.: zu früh gefreut. VIS Adapter lässt sich installieren, läuft aber nicht...
-
@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:
Das ist leider inkorrekt:
was genau?
Der Hostname wird bei der Installation des OS vergeben.
Deswegen muss dieser bei Änderung zum Backup nach dem Restore und vor dem ersten Start von ioBroker diesem viaiobroker host this
mitgeteilt werden. -
@homoran Restore ändert den Hostname. Du meintest, dass würde nicht passieren. Passt der Hostname vom Zielsystem nicht zum Hostname aus dem Backup, dann schlägt der Restore fehl und kein Adapter startet. Dennoch wird der Hostname des Zielsystem geändert, so dass bei einem zweiten Restore alles (bis auf VIS) funktioniert. Wenn man das weiß, ist alles ok. Eine Abfrage beim Restore wäre perfekt, aber so geht's ja auch.
P.S.: oder natürlich man passt den Namen vorher an.
-
@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:
Passt der Hostname vom Zielsystem nicht zum Hostname aus dem Backup, dann schlägt der Restore fehl und kein Adapter startet
das kann sein, wenn der neue Hostname der ioBroker Installation aus dem Backup nicht mitgeteilt wurde. (siehe letzten Post)
Das war schon immer so, zumindest gab es dann immer schon mal Probleme.Das sieht man unter system.host.xxxx
@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:
Dennoch wird der Hostname des Zielsystem geändert,
im Betriebssystem??
kann ich nicht glauben
-
@andygr42 AAaaalso wenn man tiefer reinschauen wollte ....
Den Hostnamen des Hosts ändern wir in keinem Fall beim Restore. Was aber sein kann ist folgendes:
Man kann im iobroker.json den Hostname quasi überschreiben. Wenn das bei einem System gemacht wurde und das dann gebackupped wird dann steht dieser Hostname im backup und wird beim Restore auch wieder hergestellt. Wenn dort keiner definiert ist dann kommt auch keiner in die Konfig und es gilt der Hostname des Systems.
Weiterhin gibt es beim backup eine Logik die "die Objekte von dem Host wo das Backup läuft" mit nem Patzhalter versieht und beim Restore wird der Platzhalter mit dem Hostname der nach obiger Logik dann gilt wieder geschrieben. Wenn aber noch andere Hosts im System sind (zb wegen Multihost) dann bleiben die auf Ihren Namen auch nach dem backup.
Lange rede kurzer Sinn: Das kann schnell etwas komplexig werden und ohne jetzt bei Dir hier genau zu schauen welche Kombination beim Backup war und was dann beim Restore galt kommen wir nicht weiter
-
@andygr42 said in VIS 1.14.5 lässt sich nicht installieren:
Starte ich nun den gleichen Restore nochmal, mit dem nun gleichen Hostname, funktioniert es einwandfrei:
Kann (muss) ich leider bestätigen. Das hat aber vor ein paar Tagen noch problemlos funktioniert.Edit: Fehler tritt bei mir nur auf wenn das BackUp von einer SSL geschützten Iobroker-Installation gemacht wird. Ohne SSL gibts keine Probleme.
-
@homoran Natürlich nicht der vom OS sondern von iobroker
@apollon77 Danke für die ausführliche Erklärung. Mein Quellsystem hatte den iobroker Host Namen vom OS übernommen. Da bin ich mir ziemlich sicher, da ich damals im Netzwerk noch mit dynamischen DNS Updates per DHCP gearbeitet habe und deshalb der OS Hostname wichtig war. Mache ich mittlerweile nicht mehr, weil zu aufwändig. Die 2-3 Systeme wo DNS Auflösung wichtig ist, bekommen halt eine feste IP und einen DNS Eintrag. Von daher bin ich ziemlich sicher, dass ich nix per Hand in eine config Datei geschrieben haben. Multihost hab ich auch nicht.