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

[Blackbeard]

@haselchen Ich habe den momentanen Container umbenannt und gestoppt. Dann das Datenverzeichnis umbenannt und ein neues, leeres Datenverzeichnis erstellt. Dann das Composefile auf v8 geändert und einen neuen Container erstellt. Diesen dann wieder gestoppt, das alte Datenverzeichnis wieder in den notwendigen Namen umbenannt und den v8-Container neu gestartet.
Mit folgender Ausgabe:
...

----- Step 3 of 5: Checking ioBroker installation -----

(Re)setting permissions (This might take a while! Please be patient!)... Done.

Fixing "sudo-bug" by replacing sudo with gosu... Done.

Checking Database connection... Failed.
Please check your configuration and try again.
For more information see ioBroker Docker Image Docs (https://docs.buanet.de/iobroker-docker-image/docs).

This Script will exit now.

Ich bin echt ratlos.

[haselchen]

@blackbeard

Puh, auf welcher Hardware bist Du unterwegs ?
Bin leider nicht mehr Up to Date in dem Thread.

[OliverIO]

@blackbeard

hast du ein
depends_on:

eingebaut, evtl ist iobroker container schneller wie der datenbank container?
was sagt das log des datenbank containers
dürfen wir dein docker compose sehen?

[Blackbeard]

@oliverio Nö hab nix eingebaut
Hier der Inhalt meiner docker compose files:
version: "3"

services:
ioBroker:
container_name: ioBroker
environment:
- DEBIAN_FRONTEND=teletype
- DEBUG=false
- LANG=de_DE.UTF‑8
- LANGUAGE=de_DE:de
- LC_ALL=de_DE.UTF‑8
- PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
- SETGID=1000
- SETUID=1000
- TZ=Europe/Berlin
hostname: ioBroker-Master
image: iobroker/iobroker:latest-v8

ports:
- 1883:1883/tcp
- 1882:1882/tcp
- 80:80/tcp
- 8081:8081/tcp
- 8082:8082/tcp
- 8087:8087/tcp
- 9001:9001/tcp
- 9002:9002/tcp
restart: unless-stopped
stdin_open: true
tty: true
volumes:
- Datenverzeichnis_auf_dem_Server:/opt/iobroker
working_dir: /opt/iobroker

networks:
host:
external: true

Läuft aber nicht. Bisher habe ich auch keinen externen Datenbankcontainer eingerichtet. Wäre es sinnvoll das zu machen?

[OliverIO]

@blackbeard
und wo hast du zuvor deine states und objects gespeichert?
datenbank, redis, jsonl?

[Blackbeard]

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

[Blackbeard]

@andre
Du kennst mich nicht. Aber ich finde es klasse, dass du das dockerimage so regelmäßig bereitstellst.
Wie im Thema erwähnt, kann ich kein Update von v7 auf v8 durchführe, da beim Erstellen des Containers Schritt 3 fehlschlägt:
----- Step 3 of 5: Checking ioBroker installation -----
(Re)setting permissions (This might take a while! Please be patient!)... Done.
Fixing "sudo-bug" by replacing sudo with gosu... Done.
Checking Database connection... Failed.
...

Ich benutze ein composefile, dass ich weiter oben auch schon gepostet habe.
Hats du ein Idee, wo der Fehler liegt? Bzw. wie ich dem Problem auf die Schliche komme?

Grüße
Christian

[Marc Berg]

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

Ich habe jetzt ein Nodejs Update gemacht. Die ioBroker-Übersicht zeit in der Info jetzt:
...
Plattform: docker (official image - v7.2.0)
Node.js: v18.18.2
NPM: 9.8.1

Von einem Node.js Update hatte niemand etwas gesagt, weiß nicht, ob das jetzt kontraproduktiv war. Eine entscheidende Info hast du uns noch vorenthalten: welche Version hat der js-controller?

[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?