NEWS
*Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*
-
@bananajoe said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Kann sein das der nach einem Neustart dann nicht mit startet,
setz auch noch mal einDen üblichen Neustart in solchen Fällen bin ich aus Windows gewöhnt und hatte ich natürlich durchgeführt.
Es ist in der Tat so, dass der systemctl Befehl aus /bin heraus ausgeführt werden muss. Die System-Variable path wird durch die Installationsschritte nicht gesetzt. Anders ist's bei der Anleitung zu influxDB, hier wird alles eingerichtet, wie ihr's hier erwartet.
Mittlerweile habe ich auch InfluxDB 2.2 installiert. Für heute soll's das gewesen sein. Morgen ist auch noch ein Tag. Dann will ich darangehen die aus der Version 1.8.x vorhandenen Daten zu migrieren. Dazu gilt's jedoch, erst noch eine Anleitung hierzu zu finden.
Vielen Dank an alle, die mich bis hierin tatkräftig unterstützt haben.
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Es ist in der Tat so, dass der systemctl Befehl aus /bin heraus ausgeführt werden muss.
Kann ich nicht bestätigen:
echad@chet:~ $ which systemctl /usr/bin/systemctl echad@chet:~ $ sudo systemctl status grafana-server ● grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: http://docs.grafana.org echad@chet:~ $ sudo systemctl start grafana-server.service echad@chet:~ $ sudo systemctl status grafana-server ● grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled) Active: active (running) since Fri 2022-06-10 19:44:45 CEST; 12s ago Docs: http://docs.grafana.org Main PID: 77680 (grafana-server) Tasks: 13 (limit: 8986) CPU: 2.564s CGroup: /system.slice/grafana-server.service └─77680 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/run/grafana/grafana-server.pid --packaging=deb cfg:default.paths> Jun 10 19:44:56 chet grafana-server[77680]: logger=sqlstore t=2022-06-10T19:44:56.46+0200 lvl=info msg="Created default organization" Jun 10 19:44:56 chet grafana-server[77680]: logger=plugin.manager t=2022-06-10T19:44:56.58+0200 lvl=info msg="Plugin registered" pluginId=input Jun 10 19:44:56 chet grafana-server[77680]: logger=plugin.finder t=2022-06-10T19:44:56.58+0200 lvl=warn msg="Skipping finding plugins as directory does not> Jun 10 19:44:56 chet grafana-server[77680]: logger=query_data t=2022-06-10T19:44:56.59+0200 lvl=info msg="Query Service initialization" Jun 10 19:44:56 chet grafana-server[77680]: logger=live.push_http t=2022-06-10T19:44:56.6+0200 lvl=info msg="Live Push Gateway initialization" Jun 10 19:44:56 chet grafana-server[77680]: logger=server t=2022-06-10T19:44:56.84+0200 lvl=info msg="Writing PID file" path=/run/grafana/grafana-server.pi> Jun 10 19:44:56 chet grafana-server[77680]: logger=ngalert t=2022-06-10T19:44:56.84+0200 lvl=info msg="warming cache for startup" Jun 10 19:44:56 chet grafana-server[77680]: logger=grafanaStorageLogger t=2022-06-10T19:44:56.85+0200 lvl=info msg="storage starting" Jun 10 19:44:56 chet grafana-server[77680]: logger=http.server t=2022-06-10T19:44:56.85+0200 lvl=info msg="HTTP Server Listen" address=[::]:3000 protocol=h> Jun 10 19:44:56 chet grafana-server[77680]: logger=ngalert.multiorg.alertmanager t=2022-06-10T19:44:56.9+0200 lvl=info msg="starting MultiOrg Alertmanager" -
@bananajoe said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Kann sein das der nach einem Neustart dann nicht mit startet,
setz auch noch mal einDen üblichen Neustart in solchen Fällen bin ich aus Windows gewöhnt und hatte ich natürlich durchgeführt.
Es ist in der Tat so, dass der systemctl Befehl aus /bin heraus ausgeführt werden muss. Die System-Variable path wird durch die Installationsschritte nicht gesetzt. Anders ist's bei der Anleitung zu influxDB, hier wird alles eingerichtet, wie ihr's hier erwartet.
Mittlerweile habe ich auch InfluxDB 2.2 installiert. Für heute soll's das gewesen sein. Morgen ist auch noch ein Tag. Dann will ich darangehen die aus der Version 1.8.x vorhandenen Daten zu migrieren. Dazu gilt's jedoch, erst noch eine Anleitung hierzu zu finden.
Vielen Dank an alle, die mich bis hierin tatkräftig unterstützt haben.
@legro said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Dann will ich darangehen die aus der Version 1.8.x vorhandenen Daten zu migrieren
Und dann musst du all deine Dashboards/Panels in einer recht seltsamen Syntax (zumindest für mich) neu erstellen ....
-
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Es ist in der Tat so, dass der systemctl Befehl aus /bin heraus ausgeführt werden muss.
Kann ich nicht bestätigen:
echad@chet:~ $ which systemctl /usr/bin/systemctl echad@chet:~ $ sudo systemctl status grafana-server ● grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: http://docs.grafana.org echad@chet:~ $ sudo systemctl start grafana-server.service echad@chet:~ $ sudo systemctl status grafana-server ● grafana-server.service - Grafana instance Loaded: loaded (/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled) Active: active (running) since Fri 2022-06-10 19:44:45 CEST; 12s ago Docs: http://docs.grafana.org Main PID: 77680 (grafana-server) Tasks: 13 (limit: 8986) CPU: 2.564s CGroup: /system.slice/grafana-server.service └─77680 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/run/grafana/grafana-server.pid --packaging=deb cfg:default.paths> Jun 10 19:44:56 chet grafana-server[77680]: logger=sqlstore t=2022-06-10T19:44:56.46+0200 lvl=info msg="Created default organization" Jun 10 19:44:56 chet grafana-server[77680]: logger=plugin.manager t=2022-06-10T19:44:56.58+0200 lvl=info msg="Plugin registered" pluginId=input Jun 10 19:44:56 chet grafana-server[77680]: logger=plugin.finder t=2022-06-10T19:44:56.58+0200 lvl=warn msg="Skipping finding plugins as directory does not> Jun 10 19:44:56 chet grafana-server[77680]: logger=query_data t=2022-06-10T19:44:56.59+0200 lvl=info msg="Query Service initialization" Jun 10 19:44:56 chet grafana-server[77680]: logger=live.push_http t=2022-06-10T19:44:56.6+0200 lvl=info msg="Live Push Gateway initialization" Jun 10 19:44:56 chet grafana-server[77680]: logger=server t=2022-06-10T19:44:56.84+0200 lvl=info msg="Writing PID file" path=/run/grafana/grafana-server.pi> Jun 10 19:44:56 chet grafana-server[77680]: logger=ngalert t=2022-06-10T19:44:56.84+0200 lvl=info msg="warming cache for startup" Jun 10 19:44:56 chet grafana-server[77680]: logger=grafanaStorageLogger t=2022-06-10T19:44:56.85+0200 lvl=info msg="storage starting" Jun 10 19:44:56 chet grafana-server[77680]: logger=http.server t=2022-06-10T19:44:56.85+0200 lvl=info msg="HTTP Server Listen" address=[::]:3000 protocol=h> Jun 10 19:44:56 chet grafana-server[77680]: logger=ngalert.multiorg.alertmanager t=2022-06-10T19:44:56.9+0200 lvl=info msg="starting MultiOrg Alertmanager"Kann ich nicht bestätigen
Wie du oben an meinen zitierten Auszügen aus der Terminalsitzung sehen kannst, war dem bei mir nicht so.
Den Grund dafür dürfte ich bei der Suche nach diesem Fehler ebenfalls gefunden haben: Es kommt wohl darauf an, ob man die Schritte zur allgemeinen Linux-Installation oder jene von der speziellen für den Raspberry Pi verwendet hat. In dieser wird explizit angeraten, sudo /bin/systemctl start grafana-server zu verwenden.
Stopp! Da fällt mir ein, dass du von Pfad sprichst. Ich kenne eine solche globale Systemvariable Path aus der MSDOS/Windows-Welt. In dieser kann man Pfade zu einzelnen Ressourcen hinterlegen, die immer dann durchsucht werden, wenn eine Referenzierung nicht aufgelöst werden konnte. Gibt es so etwas auch in Linux?
Sei‘s d‘rum! Es funktioniert ja jetzt alles.
Raspberry Pi 5 mit 8GB + 120GB SSD + Coordinator COD-m + ioBroker ..
-
@legro said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Dann will ich darangehen die aus der Version 1.8.x vorhandenen Daten zu migrieren
Und dann musst du all deine Dashboards/Panels in einer recht seltsamen Syntax (zumindest für mich) neu erstellen ....
@einstein67 said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Und dann musst du all deine Dashboards/Panels in einer recht seltsamen Syntax (zumindest für mich) neu erstellen ....
Danke fürs Mutmachen!:wink:
Ja, davon habe ich bereits gelesen. Von abwärts kompatibel halten die Macher von Grafana offenbar nicht das Gringste.:slightly_frowning_face:
-
Kann ich nicht bestätigen
Wie du oben an meinen zitierten Auszügen aus der Terminalsitzung sehen kannst, war dem bei mir nicht so.
Den Grund dafür dürfte ich bei der Suche nach diesem Fehler ebenfalls gefunden haben: Es kommt wohl darauf an, ob man die Schritte zur allgemeinen Linux-Installation oder jene von der speziellen für den Raspberry Pi verwendet hat. In dieser wird explizit angeraten, sudo /bin/systemctl start grafana-server zu verwenden.
Stopp! Da fällt mir ein, dass du von Pfad sprichst. Ich kenne eine solche globale Systemvariable Path aus der MSDOS/Windows-Welt. In dieser kann man Pfade zu einzelnen Ressourcen hinterlegen, die immer dann durchsucht werden, wenn eine Referenzierung nicht aufgelöst werden konnte. Gibt es so etwas auch in Linux?
Sei‘s d‘rum! Es funktioniert ja jetzt alles.
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Wie du oben an meinen zitierten Auszügen aus der Terminalsitzung sehen kannst, war dem bei mir nicht so.
Offen gesagt sehe ich da nur einen Befehl, der so eingegeben nicht funktionieren kann.
-
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Wie du oben an meinen zitierten Auszügen aus der Terminalsitzung sehen kannst, war dem bei mir nicht so.
Offen gesagt sehe ich da nur einen Befehl, der so eingegeben nicht funktionieren kann.
@thomas-braun said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Offen gesagt sehe ich da nur einen Befehl, der so eingegeben nicht funktionieren kann.
Stimmt. Da habe ich offenbar die falschen Zeilen rauskopiert. Selbstverständlich wollte ich die Zeilen zum Befehl sudo systemctl start grafana-server zitieren.
-
Kann ich nicht bestätigen
Wie du oben an meinen zitierten Auszügen aus der Terminalsitzung sehen kannst, war dem bei mir nicht so.
Den Grund dafür dürfte ich bei der Suche nach diesem Fehler ebenfalls gefunden haben: Es kommt wohl darauf an, ob man die Schritte zur allgemeinen Linux-Installation oder jene von der speziellen für den Raspberry Pi verwendet hat. In dieser wird explizit angeraten, sudo /bin/systemctl start grafana-server zu verwenden.
Stopp! Da fällt mir ein, dass du von Pfad sprichst. Ich kenne eine solche globale Systemvariable Path aus der MSDOS/Windows-Welt. In dieser kann man Pfade zu einzelnen Ressourcen hinterlegen, die immer dann durchsucht werden, wenn eine Referenzierung nicht aufgelöst werden konnte. Gibt es so etwas auch in Linux?
Sei‘s d‘rum! Es funktioniert ja jetzt alles.
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Gibt es so etwas auch in Linux?
Natürlich.
echo $PATHgibt dir die zu durchlaufenden Pfade an.
Zu systemctl:
echad@chet:/opt/iobroker $ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games echad@chet:/opt/iobroker $ which systemctl /usr/bin/systemctl -
@legro die Migration von Influxdb v1 zu v2 ist kein großes Ding.
Ist alles in der Doku sehr gut beschrieben.
Glaub auch hier im Forum gib es ein Howto.@simatec said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
@legro die Migration von Influxdb v1 zu v2 ist kein großes Ding.
Von wegen! Du bist offenbar ein gnadenloser Optimist.:wink: Da bin ich wohl eher der Pessimist. Egal, ob Opti- oder Pessi- am Ende steht immer Mist.:joy:
Da ich piVCCU3 verwende und Alexander Reinert ausführt, dass seine virtuelle CCU3-Software nicht in einer gemischten Umgebung 32/64Bit läuft, scheidet bei mir schonmal ein „in place update“ aus. Mithin kann ich nur InfluxDB 2.2 in einem reinen 64Bit-System installieren und manuell die Daten aus der Version 7.5.5 zu übertragen versuchen.
Die Anleitung von Influxdata habe ich gefunden und bin dabei sie durchzuackern. Von einfach kann da keine Rede sein.:disappointed:
Wenn ich das Ganze richtig verstanden habe, muss ich in meinem Fall für meine von ioBroker erzeugten zeitlichen Datensequenzen die Anleitung zu Migration time series data durchführen.:thinking_face:
Aber ich muss wohl erstmal noch weiter grübeln. Ich habe das Gefühl, das Ganze noch nicht richtig verstanden zu haben.
-
@simatec said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
@legro die Migration von Influxdb v1 zu v2 ist kein großes Ding.
Von wegen! Du bist offenbar ein gnadenloser Optimist.:wink: Da bin ich wohl eher der Pessimist. Egal, ob Opti- oder Pessi- am Ende steht immer Mist.:joy:
Da ich piVCCU3 verwende und Alexander Reinert ausführt, dass seine virtuelle CCU3-Software nicht in einer gemischten Umgebung 32/64Bit läuft, scheidet bei mir schonmal ein „in place update“ aus. Mithin kann ich nur InfluxDB 2.2 in einem reinen 64Bit-System installieren und manuell die Daten aus der Version 7.5.5 zu übertragen versuchen.
Die Anleitung von Influxdata habe ich gefunden und bin dabei sie durchzuackern. Von einfach kann da keine Rede sein.:disappointed:
Wenn ich das Ganze richtig verstanden habe, muss ich in meinem Fall für meine von ioBroker erzeugten zeitlichen Datensequenzen die Anleitung zu Migration time series data durchführen.:thinking_face:
Aber ich muss wohl erstmal noch weiter grübeln. Ich habe das Gefühl, das Ganze noch nicht richtig verstanden zu haben.
Bevor ich mich nun an der Datenmigration von InfluxDB 2.2 wage, möchte ich noch verstehen, wie ich's hinbekomme, mittels BackItUp die Migration aller Adapter, Objekte, .. von meiner alten 32Bit-Installation auf mein neues Bullseye System zu retten.
Der Weg über CLI, wie er von Matthias Kleine beschrieben wird, ist mir auf die Dauer einfach zu aufwendig.
Was ich bisher probiert habe ..
- Ich habe BackItUp so konfiguriert, dass die Backups über NAS/kopieren gespeichert werden.
- Zum Test habe ich ein Backup des Bullseye-Systems erstellt. Das hat funktioniert.
- Anschließend habe ich ein Backup des alten Buster-Systems in das Verzeichnis kopiert.
- Der Versuch dieses Backup im Bullseye-System wiederherzustellen scheiterte.
- Also versuchte ich das Ganze mit dem neu erstellten Backup des Bullseye-Systems. Auch dies scheiterte.
Ich erhielt im Log folgende Fehlermeldung:
[DEBUG] [iobroker] Start ioBroker Restore ... [ERROR] [iobroker] host.raspberrypi-dev Cannot extract from file "/opt/iobroker/backups/iobroker_2022_06_06-03_40_20_Gro_backupiobroker.tar.gz": Unknown system error -116: Unknown system error -116, open '/opt/iobroker/backups/iobroker_2022_06_06-03_40_20_Gro_backupiobroker.tar.gz' [DEBUG] [iobroker] ioBroker Restore completed successfully [EXIT] 9Wenn ich das richtig lese, versucht er lokal in /opt/iobroker/backups nach der Backup-Datei zu suchen. Die ist jedoch nicht dort, sondern auf der Fritz!Box und über CIFS zugänglich.
Ich bin ratlos.
Raspberry Pi 5 mit 8GB + 120GB SSD + Coordinator COD-m + ioBroker ..
-
Bevor ich mich nun an der Datenmigration von InfluxDB 2.2 wage, möchte ich noch verstehen, wie ich's hinbekomme, mittels BackItUp die Migration aller Adapter, Objekte, .. von meiner alten 32Bit-Installation auf mein neues Bullseye System zu retten.
Der Weg über CLI, wie er von Matthias Kleine beschrieben wird, ist mir auf die Dauer einfach zu aufwendig.
Was ich bisher probiert habe ..
- Ich habe BackItUp so konfiguriert, dass die Backups über NAS/kopieren gespeichert werden.
- Zum Test habe ich ein Backup des Bullseye-Systems erstellt. Das hat funktioniert.
- Anschließend habe ich ein Backup des alten Buster-Systems in das Verzeichnis kopiert.
- Der Versuch dieses Backup im Bullseye-System wiederherzustellen scheiterte.
- Also versuchte ich das Ganze mit dem neu erstellten Backup des Bullseye-Systems. Auch dies scheiterte.
Ich erhielt im Log folgende Fehlermeldung:
[DEBUG] [iobroker] Start ioBroker Restore ... [ERROR] [iobroker] host.raspberrypi-dev Cannot extract from file "/opt/iobroker/backups/iobroker_2022_06_06-03_40_20_Gro_backupiobroker.tar.gz": Unknown system error -116: Unknown system error -116, open '/opt/iobroker/backups/iobroker_2022_06_06-03_40_20_Gro_backupiobroker.tar.gz' [DEBUG] [iobroker] ioBroker Restore completed successfully [EXIT] 9Wenn ich das richtig lese, versucht er lokal in /opt/iobroker/backups nach der Backup-Datei zu suchen. Die ist jedoch nicht dort, sondern auf der Fritz!Box und über CIFS zugänglich.
Ich bin ratlos.
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
sondern auf der Fritz!Box und über CIFS zugänglich.
Keine Ahnung wo du da ein Problem hast.
Neuen Backitup mit CIFS einrichten, dann von dort das auf dem CIFS liegende Backup referenzieren, Backup einspielen.Da /opt/iobroker/backups/ bei Verwendung von CIFS als Mountpunkt fungiert muss der Adapter auch nirgendwo anders schauen.
-
@legro sagte in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
sondern auf der Fritz!Box und über CIFS zugänglich.
Keine Ahnung wo du da ein Problem hast.
Neuen Backitup mit CIFS einrichten, dann von dort das auf dem CIFS liegende Backup referenzieren, Backup einspielen.Da /opt/iobroker/backups/ bei Verwendung von CIFS als Mountpunkt fungiert muss der Adapter auch nirgendwo anders schauen.
Das habe ich alles gemacht. Dennoch funktioniert's nicht.
Vielleicht kannst du an dem Log-Eintrag ja etwas erkennen. Ich bin nach wie vor ratlos.
backitup.0 2022-06-11 12:34:51.320 error umount: /opt/iobroker/backups: not mounted. backitup.0 2022-06-11 12:32:51.305 error Error: Command failed: sudo mount -t cifs -o username=AdminLocal,password=****,domain=galegro,rw,file_mode=0777,dir_mode=0777 //fritz.nas/fritz.nas/SanDisk/SmartHomeBackup/ioBrokerDev /opt/iobroker/backupsmount error(16): Device or resource busyRefer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) backitup.0 2022-06-11 12:32:50.809 info [iobroker] backup was activated at 02:40 every 1 day(s) backitup.0 2022-06-11 12:32:50.778 warn Cannot read log file: Error: UNKNOWN: unknown error, open '/opt/iobroker/backups/logs.txt'Raspberry Pi 5 mit 8GB + 120GB SSD + Coordinator COD-m + ioBroker ..
-
Das habe ich alles gemacht. Dennoch funktioniert's nicht.
Vielleicht kannst du an dem Log-Eintrag ja etwas erkennen. Ich bin nach wie vor ratlos.
backitup.0 2022-06-11 12:34:51.320 error umount: /opt/iobroker/backups: not mounted. backitup.0 2022-06-11 12:32:51.305 error Error: Command failed: sudo mount -t cifs -o username=AdminLocal,password=****,domain=galegro,rw,file_mode=0777,dir_mode=0777 //fritz.nas/fritz.nas/SanDisk/SmartHomeBackup/ioBrokerDev /opt/iobroker/backupsmount error(16): Device or resource busyRefer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) backitup.0 2022-06-11 12:32:50.809 info [iobroker] backup was activated at 02:40 every 1 day(s) backitup.0 2022-06-11 12:32:50.778 warn Cannot read log file: Error: UNKNOWN: unknown error, open '/opt/iobroker/backups/logs.txt'Direkt auf der FritzBox? Mit welchen Einstellungen im Adapter angelegt?
Die Fritzbox braucht die Option 'noserverino' und SMB-Dialekt 3.1.1 -
Direkt auf der FritzBox? Mit welchen Einstellungen im Adapter angelegt?
Die Fritzbox braucht die Option 'noserverino' und SMB-Dialekt 3.1.1@thomas-braun said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Die Fritzbox braucht die Option 'noserverino' und SMB-Dialekt 3.1.1
Vielen Dank! Das war's.:+1:
Ich erinnere mich daran, dass ich das Problem schon einmal vor ewig langer Zeit hier vortrug. Da es damals keine Lösung gab, verwendete ich einfach weiter fleißig ApplePiBaker.
Und die Moral von der Geschicht',
ohne kluge Leute geht es nicht.:slightly_smiling_face: -
Direkt auf der FritzBox? Mit welchen Einstellungen im Adapter angelegt?
Die Fritzbox braucht die Option 'noserverino' und SMB-Dialekt 3.1.1Nun habe ich bereits den zweiten Versuch hinter mir, meine ioBroker-Installation von Buster (32Bit) zu Bullseye (64Bit) mittels BackItUp zu übertragen. Ergebnis: Alle Adapter scheinen in Ordnung zu sein, nur der VIS-Adapter will einfach nicht.
host.raspberrypi-dev 2022-06-11 17:08:50.013 error 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! host.raspberrypi-dev 2022-06-11 17:08:49.012 info iobroker npm-install: exit 25 host.raspberrypi-dev 2022-06-11 17:08:47.978 error iobroker npm-install: host.raspberrypi-dev Cannot install iobroker.vis@1.4.15: 6 vis.0 2022-06-11 17:08:45.358 warn Terminated (UNCAUGHT_EXCEPTION): Without reason vis.0 2022-06-11 17:08:45.357 info terminating vis.0 2022-06-11 17:08:44.851 error Not exists vis.0 2022-06-11 17:08:44.850 error 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 (internal/timers.js:466:21) vis.0 2022-06-11 17:08:44.848 error unhandled promise rejection: Not exists vis.0 2022-06-11 17:08:44.847 error 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(). vis.0 2022-06-11 17:08:44.542 info vis license is OK. vis.0 2022-06-11 17:08:44.405 info starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v14.19.3, js-controller: 4.0.23 host.raspberrypi-dev 2022-06-11 17:08:42.890 info iobroker npm-install: > iobroker.vis@1.4.15 install /opt/iobroker/node_modules/iobroker.vis> node main.js --install host.raspberrypi-dev 2022-06-11 17:08:42.888 info iobroker npm-install: host.raspberrypi-dev 2022-06-11 17:08:24.206 info iobroker npm-install: Installing iobroker.vis@1.4.15... (System call) host.raspberrypi-dev 2022-06-11 17:08:24.204 info iobroker npm-install: NPM version: 6.14.17 host.raspberrypi-dev 2022-06-11 17:08:21.717 info iobroker install vis@1.4.15 using installedVersion host.raspberrypi-dev 2022-06-11 17:08:21.716 warn startInstance cannot find adapter "vis@1.4.15". Try to install it... 4 attemptMal wieder bin ich ratlos.:disappointed:
Raspberry Pi 5 mit 8GB + 120GB SSD + Coordinator COD-m + ioBroker ..
-
Nun habe ich bereits den zweiten Versuch hinter mir, meine ioBroker-Installation von Buster (32Bit) zu Bullseye (64Bit) mittels BackItUp zu übertragen. Ergebnis: Alle Adapter scheinen in Ordnung zu sein, nur der VIS-Adapter will einfach nicht.
host.raspberrypi-dev 2022-06-11 17:08:50.013 error 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! host.raspberrypi-dev 2022-06-11 17:08:49.012 info iobroker npm-install: exit 25 host.raspberrypi-dev 2022-06-11 17:08:47.978 error iobroker npm-install: host.raspberrypi-dev Cannot install iobroker.vis@1.4.15: 6 vis.0 2022-06-11 17:08:45.358 warn Terminated (UNCAUGHT_EXCEPTION): Without reason vis.0 2022-06-11 17:08:45.357 info terminating vis.0 2022-06-11 17:08:44.851 error Not exists vis.0 2022-06-11 17:08:44.850 error 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 (internal/timers.js:466:21) vis.0 2022-06-11 17:08:44.848 error unhandled promise rejection: Not exists vis.0 2022-06-11 17:08:44.847 error 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(). vis.0 2022-06-11 17:08:44.542 info vis license is OK. vis.0 2022-06-11 17:08:44.405 info starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v14.19.3, js-controller: 4.0.23 host.raspberrypi-dev 2022-06-11 17:08:42.890 info iobroker npm-install: > iobroker.vis@1.4.15 install /opt/iobroker/node_modules/iobroker.vis> node main.js --install host.raspberrypi-dev 2022-06-11 17:08:42.888 info iobroker npm-install: host.raspberrypi-dev 2022-06-11 17:08:24.206 info iobroker npm-install: Installing iobroker.vis@1.4.15... (System call) host.raspberrypi-dev 2022-06-11 17:08:24.204 info iobroker npm-install: NPM version: 6.14.17 host.raspberrypi-dev 2022-06-11 17:08:21.717 info iobroker install vis@1.4.15 using installedVersion host.raspberrypi-dev 2022-06-11 17:08:21.716 warn startInstance cannot find adapter "vis@1.4.15". Try to install it... 4 attemptMal wieder bin ich ratlos.:disappointed:
Versuch mal eine der Vorversionen zu installieren. Wenn ich das richtig mitbekommen habe klemmt es u.U. bei der aktuellen Vis-Version.
-
Versuch mal eine der Vorversionen zu installieren. Wenn ich das richtig mitbekommen habe klemmt es u.U. bei der aktuellen Vis-Version.
Versuch mal eine der Vorversionen ..
Aber wie kann ich das erreichen? Die Version ist doch durch das verwendete Backup festgelegt.
Da fällt mir noch etwas ein ..
Es gibt ja zwei Versionen: Ich habe jene erworben, die sich beim Start nicht über das Internet authentifizieren muss. Könnte es auch daran liegen?
Raspberry Pi 5 mit 8GB + 120GB SSD + Coordinator COD-m + ioBroker ..
-
Versuch mal eine der Vorversionen ..
Aber wie kann ich das erreichen? Die Version ist doch durch das verwendete Backup festgelegt.
Da fällt mir noch etwas ein ..
Es gibt ja zwei Versionen: Ich habe jene erworben, die sich beim Start nicht über das Internet authentifizieren muss. Könnte es auch daran liegen?
Ich hab keine Vis laufen, daher weiß ich auch nicht wie das mit den Lizenzen da genau geregelt ist.
-
Ich hab keine Vis laufen, daher weiß ich auch nicht wie das mit den Lizenzen da genau geregelt ist.
-
Da sitze ich wohl in der Falle: Entfernen lässt sich vis.0 nicht und eine weitere Instanz lässt sich ebenfalls nicht installieren.
iobroker upgrade vis@GEWÜNSCHTE.VERSION.NUMMER -
Nun habe ich bereits den zweiten Versuch hinter mir, meine ioBroker-Installation von Buster (32Bit) zu Bullseye (64Bit) mittels BackItUp zu übertragen. Ergebnis: Alle Adapter scheinen in Ordnung zu sein, nur der VIS-Adapter will einfach nicht.
host.raspberrypi-dev 2022-06-11 17:08:50.013 error 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! host.raspberrypi-dev 2022-06-11 17:08:49.012 info iobroker npm-install: exit 25 host.raspberrypi-dev 2022-06-11 17:08:47.978 error iobroker npm-install: host.raspberrypi-dev Cannot install iobroker.vis@1.4.15: 6 vis.0 2022-06-11 17:08:45.358 warn Terminated (UNCAUGHT_EXCEPTION): Without reason vis.0 2022-06-11 17:08:45.357 info terminating vis.0 2022-06-11 17:08:44.851 error Not exists vis.0 2022-06-11 17:08:44.850 error 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 (internal/timers.js:466:21) vis.0 2022-06-11 17:08:44.848 error unhandled promise rejection: Not exists vis.0 2022-06-11 17:08:44.847 error 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(). vis.0 2022-06-11 17:08:44.542 info vis license is OK. vis.0 2022-06-11 17:08:44.405 info starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v14.19.3, js-controller: 4.0.23 host.raspberrypi-dev 2022-06-11 17:08:42.890 info iobroker npm-install: > iobroker.vis@1.4.15 install /opt/iobroker/node_modules/iobroker.vis> node main.js --install host.raspberrypi-dev 2022-06-11 17:08:42.888 info iobroker npm-install: host.raspberrypi-dev 2022-06-11 17:08:24.206 info iobroker npm-install: Installing iobroker.vis@1.4.15... (System call) host.raspberrypi-dev 2022-06-11 17:08:24.204 info iobroker npm-install: NPM version: 6.14.17 host.raspberrypi-dev 2022-06-11 17:08:21.717 info iobroker install vis@1.4.15 using installedVersion host.raspberrypi-dev 2022-06-11 17:08:21.716 warn startInstance cannot find adapter "vis@1.4.15". Try to install it... 4 attemptMal wieder bin ich ratlos.:disappointed:
@legro said in *Buster* 32bit -> *Bullseye* 64bit mit *BackItUp*:
Alle Adapter scheinen in Ordnung zu sein, nur der VIS-Adapter will einfach nicht
Du musst nur einfach vor dem Restore mit BackitUp, den Vis-Adapter (Version ist egal) manuell installieren. Dann läuft er auch nach dem Restore.
Support us
887
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge