Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[OliverIO]

@blackbeard sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

@OliverIO
da meine Installation ursprünglich mit einem Raspberry angefangen hat, liegen alle Daten im ioBrokerverzeichnis. Bisher habe ich keine gesonderte Datenbank eingerichtet.

hm, dann verstehe ich die Meldung nicht mit connection failed
im dockerfile ist nix mit datenbank konfiguriert,
wenn du keine besondere datenbank im iobroker konfiguriert hast,
dann läufen die objects und states auf jsonl

du könntest den container mal auf debug stellen und schauen was dann im log steht
bzw. dann auch mal ins iobroker log, falls es das da überhaupt schon gibt.

ich weiß jetzt nicht ob du hier auf basis bereits existierender volumes ein update machst
die folgenden Zeilen scheinen ja von dir angepasst worden sein, sie entsprechen nicht dem korrekten format

- Datenverzeichnis_auf_dem_Server:/opt/iobroker
working_dir: /opt/iobroker

kann aber sein, das, weil du vergessen hast das in code tags zu setzen, die formatierung zerhauen hat

wenn du von einer vorhandenen installation upgradest, würde ich lieber in dem alten container ein backup machen und das in einem neuen cleanen container dann einspielen

[Blackbeard]

@oliverio
Ja. Habe keine code tags verwendet.
Das composefile an sich funktioniert wie es soll.
Tatsächlich stoppe ich vor jedem Update den container, mache vom Datenverzeichnis eine Kopie, starte den container wieder und führe das Update durch.

Der container lässt sich mit leeren Datenverzeichnis auch ohne Murren mit neuer Version starten. Erst wenn ich meine Daten einfüge, dann wird eine vorhandene Installation erkannt und er baut eben keine Verbindung zur Datenbank auf. Ich hatte auch versucht, per BackitUp die Daten wieder herzustellen. Aber eben auch ohne Erfolg.

Ich frage mich, was die Installationsroutine da in Schritt 3 macht bzw. sucht dass meine Daten (die vorhanden sind) nicht gefunden werden?

[OliverIO]

@blackbeard

aber wenn du keine datenbank verwendest, wohin soll er kontakt aufnehmen?

[Blackbeard]

@oliverio
Ja genau. Und an dieser Stelle finde ich keine Lösung. Was die Datenbank angeht, ist ja alles in Standardkonfiguration. Daher kann ich mir nicht vorstellen, warum die Installation keine Verbindung zu den Daten herstellen kann.
Einzige Idee die ich noch habe, wäre eine Diskrepanz mit Benutzerrechten.
Aber da weiß ich gerade auch nicht wo ich wie ansetzen sollte. :-/

Daher hatte ich gehofft, dass hier im Forum jemand eine hilfreiche Idee hat oder der Image Ersteller (@andre) die Lösung parat hat.

[Blackbeard]

@marc-berg
Ich hatte node.js auch schon händisch upgedatet und dann versucht das neue Image zu starten. Hat aber keine Veränderung gebracht. Immer das selbe Verhalten. Aktuell läuft v16.20.2, da nach erneuten Erstellen des Containers immer wieder die Version des Images benutzt wird. Daher ließt man auch in der Beschreibung, dass eigentlich nur ein neuer Container mit aktuellem Image gestartet werden sollte und dann alles wieder schick ist. Aber aktuell eben bei mir leider nicht.

[fastfoot]

@blackbeard Hattest du dein Datenverzeichnis schonmal mit v9 genutzt?

[Marc Berg]

@blackbeard sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

Aktuell läuft v16.20.

Dann wiederhole ich meine Frage nochmals: welche Version hat der js-controller? Könnte es sein, dass du "js-controller" und "node.js" durcheinanderwirfst?

[fastfoot]

@marc-berg sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

@blackbeard sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

Aktuell läuft v16.20.

Dann wiederhole ich meine Frage nochmals: welche Version hat der js-controller? Könnte es sein, dass du "js-controller" und "node.js" durcheinanderwirfst?

ich glaube ja eher an so etwas

[Marc Berg]

@fastfoot sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

ich glaube ja eher an so etwas

Das kann ja durchaus sein, aber dann bliebe ja noch das Problem, dass sich auch ein Backup nicht einspielen lässt. (siehe allererster Post). Darum habe ich den Fokus erstmal auf die js-controller Version gesetzt. Die muss im alten Container halt so aktuell wie möglich gebracht werden, damit man nicht in Probleme läuft. Und mit einem Backup einer aktuellen ioBroker Version kann man wesentlich mehr bewegen.

[fastfoot]

@marc-berg oh ja, sorry, das war auch gar nicht als Widerrede oder gar bessere Lösung gedacht, eher als Ergänzung.

[Blackbeard]

@marc-berg
Ja. Habe ich tatsächlich verwechselt.
Aktuell läuft 5.0.12
Habe aber eben nochmal auf 5.0.16 aktualisiert.

[Marc Berg]

@blackbeard sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

Habe aber eben nochmal auf 5.0.16 aktualisiert.

Okay, prima. Warum das "inline" Update des Containers nicht funktioniert, kann ich nicht sagen, es sind ja beide Ansätze in die Hose gegangen. Es wäre jetzt aus meiner Sicht auch müßig, in die Detailsuche zu gehen.

Aber das saubere Aufsetzen eines neuen V8 (oder besser noch V9) Images mit dem Einspielen des aktuellen Backups sollte funktionieren. Du hattest geschrieben, dass dies fehlgeschlagen sei. Was ist konkret passiert?

[Blackbeard]

@marc-berg
Dauert immer etwas, bis ich dazu komme, Zeit zu finden.

Der Start des v8 Containers mit leerem Verzeichnis läuft problemlos. Nachdem ich einen neuen Admin eingerichtet habe und das Backup ins Verzeichnis kopiert habe, habe ich im Adapter die Wiederherstellung gestartet. Danach passiert nichts mehr auf dem Bildschirm.
In Portainer sehe ich in der Console, dass der Cointainer neu startet und dann wie bei allen anderen Versuchen vorher die Verbindung zur Datenbank nicht hergestellt werden kann. Dann beginnt wieder der Neustart des Containers...

Eben habe ich ein Downgrade auf den v6 versucht. Irgendwelche Modulfehler in Schritt 5/5. Aber zumindest nicht die fehlende Verbindung zur Datenbank in Schritt 3/5.

Ich bin echt ratlos.

[Marc Berg]

@blackbeard sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

Dauert immer etwas, bis ich dazu komme, Zeit zu finden.

Geht mir auch so :-)

Ein paar Fragen habe ich dazu:

• welche Version hat der js-controller vor dem Restore?
• ist der Hostname der gleiche wie der, von dem das Backup stammt?
• was passiert, wenn du den Restore auf der Kommandozeile mit "m restore" startest?

[Blackbeard]

@marc-berg
Update auf v8 ist gelaufen!
Danke für die richtige Frage. Die Antwort ist: Der js-controller des v8-Containers war mittlerweile ebenfalls veraltet. So dass mein Backup mittlerweile aktueller ist als das "alte" Image. Puhhh....

Aber war mache ich jetzt mit den nicht gestarteten Instanzen?

Einfach deinstallieren und wieder neu installieren? Oder kann man "drüber installieren"?

[Marc Berg]

@blackbeard
Zum VIS Problem beim Restore gibt es ja hier viele Threads, da gibt es einen Workaround, einfach mal suchen.
Zu Sourceanalytics kann ich nichts sagen.

[Blackbeard]

@marc-berg
Trotzdem nochmal herzlichen Dank für deine Mühe und Geduld.

Die "fehlerhaften" Adapter reparieren sich selbstständig, wenn man eine weitere Instanz des fehlerhaften Adapters installiert. Anschließend kann diese wieder gelöscht werden und der erste Adapter funktioniert wieder wie gewohnt.

[Thomas Braun]

@blackbeard sagte in Probleme beim ioBroker-Update von docker v7 auf v8:

Aber war mache ich jetzt mit den nicht gestarteten Instanzen?

Auf dem Screenshot deutet es darauf hin, dass diese Adapter noch nicht gebaut worden sind. Sonst sollte das Icon das passende sein und nicht der graue Ersatz.

[Blackbeard]

@thomas-braun
Irgendwie scheinen beim Backup oder beim Widerherstellen aus dem Backup Dateien nicht hergestellt zu werden. Oder so ähnlich. Denn wie oben geschrieben, repariert sich der "fehlerhafte" Adapter, wenn man eine weiter Instanz installiert. Vis habe ich einfach den "alten" Ordner aus meiner Sicherung in den aktuellen Ordner kopiert. Funktioniert jetzt ebenfalls.

[Thomas Braun]

@blackbeard

Hört sich nach wüstem herumgehacke an.